<div dir="ltr"><div>Hello,</div><div><br></div><div>Not sure if those are forgotten or are unwanted modifications. Please let me know.</div><div><br></div><div>And I also have another idea regarding the subject. The idea is to configure the file where bird will keep the states of the protocols (I mean enabled/disabled states). Then during loading the configuration it alters the states to reflect the saved ones. So the states are persistent during reconfiguration and also during restart of a daemon. The draft patch is attached. Please take a look.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 30, 2022 at 3:44 PM Alexander Zubkov <<a href="mailto:green@qrator.net">green@qrator.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Could we continue with these modifcations?<br>
<br>
On Mon, Jan 3, 2022 at 2:10 PM Alexander Zubkov <<a href="mailto:green@qrator.net" target="_blank">green@qrator.net</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> Lets resurrect this one too. Please check the series of pathces in the<br>
> attachment.<br>
> 1) Convert reconfigure type variables to bitmask.<br>
> 2) Add flag to keep running state<br>
> 3) Add support in CLI<br>
><br>
> Only the states of protocols are kept with this flag now. Anyone<br>
> interested can add support of keeping other interesting runtime<br>
> states, like Ondrej suggested.<br>
><br>
> On Sun, Feb 10, 2019 at 11:23 PM Thomás S. Bregolin <<a href="mailto:thoms3rd@gmail.com" target="_blank">thoms3rd@gmail.com</a>> wrote:<br>
> ><br>
> > Nice!<br>
> ><br>
> > Ondrej,<br>
> ><br>
> > I disagree somewhat with your first response, unless I misunderstand it. I don't think it makes sense at all to persist a whole bunch of settings and still do a soft reconfiguration.<br>
> ><br>
> > There is a very good, non-remote use case to keep the session up on reconfigurations regardless of the 'disabled' option on startup.<br>
> ><br>
> > Would you be able to point us to the way forward?<br>
> ><br>
> > Cheers,<br>
> ><br>
> > Thomás<br>
> ><br>
> > On Sun, Feb 10, 2019, 19:05 Alexander Zubkov <<a href="mailto:green@qrator.net" target="_blank">green@qrator.net</a> wrote:<br>
> >><br>
> >> Hi,<br>
> >><br>
> >> I had almost the same idea in my original patch. But Ondrej have<br>
> >> slightly better ideas regarding this.<br>
> >><br>
> >> On Sun, Feb 10, 2019 at 6:59 PM Thomás S. Bregolin <<a href="mailto:thoms3rd@gmail.com" target="_blank">thoms3rd@gmail.com</a>> wrote:<br>
> >> ><br>
> >> > My attempt was a bit more crude:<br>
> >> ><br>
> >> > diff --git a/nest/config.Y b/nest/config.Y<br>
> >> > index aef5ed46..829bf96c 100644<br>
> >> > --- a/nest/config.Y<br>
> >> > +++ b/nest/config.Y<br>
> >> > @@ -64,7 +64,7 @@ proto_postconfig(void)<br>
> >> ><br>
> >> > CF_DECLS<br>
> >> ><br>
> >> > -CF_KEYWORDS(ROUTER, ID, PROTOCOL, TEMPLATE, PREFERENCE, DISABLED, DEBUG, ALL, OFF, DIRECT)<br>
> >> > +CF_KEYWORDS(ROUTER, ID, PROTOCOL, TEMPLATE, PREFERENCE, DISABLED, KEEP_STATE, DEBUG, ALL, OFF, DIRECT)<br>
> >> > CF_KEYWORDS(INTERFACE, IMPORT, EXPORT, FILTER, NONE, VRF, TABLE, STATES, ROUTES, FILTERS)<br>
> >> > CF_KEYWORDS(IPV4, IPV6, VPN4, VPN6, ROA4, ROA6, FLOW4, FLOW6, SADR, MPLS)<br>
> >> > CF_KEYWORDS(RECEIVE, LIMIT, ACTION, WARN, BLOCK, RESTART, DISABLE, KEEP, FILTERED)<br>
> >> > @@ -205,6 +205,7 @@ proto_name:<br>
> >> > proto_item:<br>
> >> > /* EMPTY */<br>
> >> > | DISABLED bool { this_proto->disabled = $2; }<br>
> >> > + | KEEP_STATE bool { this_proto->keep_state = $2 }<br>
> >> > | DEBUG debug_mask { this_proto->debug = $2; }<br>
> >> > | MRTDUMP mrtdump_mask { this_proto->mrtdump = $2; }<br>
> >> > | ROUTER ID idval { this_proto->router_id = $3; }<br>
> >> > diff --git a/nest/proto.c b/nest/proto.c<br>
> >> > index d4a333d0..397d6fb2 100644<br>
> >> > --- a/nest/proto.c<br>
> >> > +++ b/nest/proto.c<br>
> >> > @@ -984,6 +984,8 @@ protos_commit(struct config *new, struct config *old, int force_reconfig, int ty<br>
> >> > if (! force_reconfig && proto_reconfigure(p, oc, nc, type))<br>
> >> > continue;<br>
> >> ><br>
> >> > + nc->disabled = nc->keep_state ? p->disabled : nc->disabled;<br>
> >> > +<br>
> >> > /* Unsuccessful, we will restart it */<br>
> >> > if (!p->disabled && !nc->disabled)<br>
> >> > log(L_INFO "Restarting protocol %s", p->name);<br>
> >> > diff --git a/nest/protocol.h b/nest/protocol.h<br>
> >> > index 6c04071b..d984b4c2 100644<br>
> >> > --- a/nest/protocol.h<br>
> >> > +++ b/nest/protocol.h<br>
> >> > @@ -118,6 +118,7 @@ struct proto_config {<br>
> >> > int class; /* SYM_PROTO or SYM_TEMPLATE */<br>
> >> > u8 net_type; /* Protocol network type (NET_*), 0 for undefined */<br>
> >> > u8 disabled; /* Protocol enabled/disabled by default */<br>
> >> > + u8 keep_state; /* Keep current enabled/disabled state during reconfiguration */<br>
> >> > u32 debug, mrtdump; /* Debugging bitfields, both use D_* constants */<br>
> >> > u32 router_id; /* Protocol specific router ID */<br>
> >> ><br>
> >> ><br>
> >> > On Tue, Dec 4, 2018 at 12:07 PM Alexander Zubkov <<a href="mailto:green@qrator.net" target="_blank">green@qrator.net</a>> wrote:<br>
> >> >><br>
> >> >> And implementation as a separate flag. But I'm not sure here how to<br>
> >> >> add another parameter to configure command. What I could imagine -<br>
> >> >> would add multiple numerous combinations and look terrible. And not<br>
> >> >> sure yet with the naming so it is not too long and not too ambiguous:<br>
> >> >> keep, keepstate, keeprun, ...?<br>
> >> >> On Tue, Dec 4, 2018 at 12:21 PM Alexander Zubkov <<a href="mailto:green@qrator.net" target="_blank">green@qrator.net</a>> wrote:<br>
> >> >> ><br>
> >> >> > The easiest patch would be to implement this behaviour for soft<br>
> >> >> > reconfig. :) But that is not backward-compatible and might break<br>
> >> >> > something for somebody. I'm also working on implementing it as<br>
> >> >> > additional option.<br>
> >> >> > On Mon, Dec 3, 2018 at 2:51 PM Thomás S. Bregolin <<a href="mailto:thoms3rd@gmail.com" target="_blank">thoms3rd@gmail.com</a>> wrote:<br>
> >> >> > ><br>
> >> >> > > Hello,<br>
> >> >> > ><br>
> >> >> > > On Wed, Nov 28, 2018, 16:34 Alexander Zubkov <<a href="mailto:green@qrator.net" target="_blank">green@qrator.net</a> wrote:<br>
> >> >> > >><br>
> >> >> > >> Hello,<br>
> >> >> > >><br>
> >> >> > >> I have received no feedback on this suggestion and suppose it got<br>
> >> >> > >> lost. I would be glad to hear some comments about this improvement.<br>
> >> >> > >> On Fri, Nov 16, 2018 at 4:36 PM Alexander Zubkov <<a href="mailto:green@qrator.net" target="_blank">green@qrator.net</a>> wrote:<br>
> >> >> > >> ><br>
> >> >> > >> > Hello.<br>
> >> >> > >> ><br>
> >> >> > >> > I have created a patch (attached) with new protocol option: disabled<br>
> >> >> > >> > keep on|off. To keep the protocol's state while loading new config. It<br>
> >> >> > >> > is useful when protocols disabled manually in the runtime, but we want<br>
> >> >> > >> > to keep that state when loading new config. Patch is attached. I have<br>
> >> >> > >> > made it against the current int-new branch.<br>
> >> >> > ><br>
> >> >> > ><br>
> >> >> > > I will second this would be nice to have. I use bird with protocols set to disabled to keep them from coming up at the same time as the daemon, and have actually resorted to a wrapper that changes the configuration file in-place to "disabled no" before doing soft reconfiguration, and then back to "yes".<br>
> >> >> > ><br>
> >> >> > > Regards,<br>
> >> >> > ><br>
> >> >> > > Thomás<br>
> >> >> > ><br>
</blockquote></div>