Donald Sharp <[email protected]> writes: > This patch changes the behavior of Quagga to reinstall routes, that were > sourced from Quagga, back into the kernel if a route delete is received. > David felt that this behavior was enough of a change that it should be > brought to the list for discussion/decision. The whole crux of the > decision revolves around the question 'Who is the source of truth for > routes?'. We've written this patch because we believe that the answer to > this question is that Quagga is the source of truth of routes if it is > being run.
Definitely this needs discussion. At first glance this seems like it should be an option, not default behavior. In a system with a kernel, quagga, and other things, there needs to be a plan. I see your point that if the plan is other than "quagga controls", things are perhaps messy. But quagga deals with static routes that were already installed (leavint them, and redistributing them) and I think would cope with newly-appearing static routes. To make the plan work, the total system needs to be arranged so that other things that modify routes don't fight quagga. I can see why you'd want quagga to put routes back, but if two programs play this game it's just going to be a mess. I think it would be helpful to hear about a situation where there is some other program modifying the routing table while quagga is running and where that isn't just a misconfiguration that should be corrected (and then perhaps a reboot). So far this seems like a workaround for a wrong configuration and I don't see why it isn't better to expect people to fix their misconfigurations. An alternative approach could be to set some sort of ACLs and permissions on routes so that non-quagga could not change quagga routes. > Finally David also had some questions about how this could be done on BSD > as well. Looking at the patch, it seems to be at the zebra level and thus should work the same way. On BSD, the routing socket sends RTM_DELETE messages, and this should get reflected into the zebra API.
pgplJeg_PvGww.pgp
Description: PGP signature
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
