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 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 +, 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 :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)
