Hi David, No problem at all! To be honest, I’d completely forgotten about this.
I was only setting up a test network for learning, and if what you say about interfaces bouncing is true then you are right not to mess with the systemd scripts. If I try this again in future, I’ll go for loopback interfaces as you suggest. Keep up the good work! Kind regards, Nick > On 6 May 2024, at 15:16, David Lamparter <equinox-deb...@diac24.net> wrote: > > Hi Nick, > > > (first of all, sorry, I kinda blanked out this bug report for some time, > see below for why) > > On Mon, Mar 07, 2022 at 06:16:03PM +0000, Nick wrote: > [...] >> Because of the above, I checked out >> /etc/systemd/system/multi-user.target.wants/frr.service and found >> that it is set to start with 'After=network-pre.target'. I replaced >> Wants= and After= with 'network-online.target' and removed Before= >> entirely. >> >> * What was the outcome of this action? >> >> Having modified the systemd start script, routes are always inserted >> on boot! > [...] > > The problem with this is that while this fixes your specific scenario, > it also breaks other users' setups since network-online.target itself is > on occasion made to depend on frr.service, which would now create a > loop. > > Further, the issue you're seeing is specific to your configuration with > these two route-maps: > > [...] >> route-map RM_SET_SRC permit 10 >> set src 25.0.1.1 >> ! >> route-map RM_SET_SRC6 permit 10 >> set src <censored>:f0a1::1 > [...] > > You're correct to observe that these require the interface that owns > these IP addresses to be up and configured before they can take effect, > and the kernel will reject them otherwise. zebra's behavior on this > is... call it "suboptimal" in not retrying the install; however the > behavior of FRR is designed against a limitation of "normal" policy > setups. route-maps, especially in zebra, are essentially code, and > there are *lots* of possibilities to create edge cases or non-working > setups. > > In your specific setup, the "FRR recommended practice" would be: add > both of these IP addresses (25.0.1.1 and XYZ:f0a1::1) as /32 / /128 to > your loopback interface. This will ensure they are always available. > (This is generally recommended for a router's primary addresses.) > > Alternatively, your fix in editing the dependency is also viable, > assuming you don't need to deal with cases where the interface or > addresses go away and come back. I can't incorporate it into the > package though because it is specific to your situation. > > > Sorry, I'm not sure there is anything else I can do here, > > > equi (David)
