On Apr 22, 2016, at 11:45 AM, Donald Sharp <[email protected]> wrote: > Paul and I have been discussing this commit: > > https://github.com/donaldsharp/quagga/commit/4a77fb6cc78cacfd0c6cd0c35ba766f994a87e11 > > Quagga behavior without this patch does not take into effect for already > processed events. So if you change a route-map > you need to reset the peer by hand to make it take into effect. > > With this code change a timer is started that gets executed after a small > time that causes all routes to be reprocessed. > > Paul suggestion is to add an event on 'conf t' exit to immediately expire the > timer if it is still running. Which I am planning on writing here > shortly. > > Having said that does anyone else have thoughts on this behavior and what it > may or may not do?
Did anyone answer you? (If so I missed it.) I'd love to see this feature, since this has been a PITA for the last 20 years. However... this could lead to surprising behavior. It wouldn't be at all unusual for someone to change a route map, then change a prefix list it uses, then a community list, etc... all while in config mode, to be followed by a soft reconfigure of the BGP session when done. (And yes, you could argue that you should configure the dependencies first, but doing it this way has always been safe.) But now with your patch, what if your timer expires while the user is still doing the configure? Undefined and possibly catastrophic behavior. I'd suggest removing the timer and just recalculating on exit from configure. That doesn't guarantee the scenario above can't happen, but it's pretty close. Alternatively, you could have an option to add both behaviors if the option is set and neither if it isn't. Also, if you reprocess on exit from configure, it would be nice to say so on the console (or log it?). /a _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
