[quagga-dev 10870] Re: [PATCH 2/4] zebra: quagga-re-onlink-support.patch

Christian Franke nobody at nowhere.ws
Tue Oct 29 13:44:59 GMT 2013

On 10/29/2013 01:40 PM, Joakim Tjernlund wrote:
> Christian Franke <chris at opensourcerouting.org> wrote on 2013/10/29 12:39:40:
> We could limit this to /32 masks(aka unnumbered) to begin with if that
> is the only need today.

I would be interested whether this is considered sufficient, especially
by the babel folks, but of course by any other potential users as well.

>> One question that comes to my mind, though: Wouldn't it then be easier
>> to just always set onlink when we encounter ZEBRA_NEXTHOP_IPV4_IFINDEX?
>> The only difference that I see is that a route installed without onlink
>> will be removed from the FIB when the matching IP-Network is
>> deconfigured from the outgoing interface.
>> In that case, Zebra would notice that the route is gone and readd it
>> with onlink set if your suggested change was implemented, wouldn't it?
> hmm, will Q mess with routes that wasn't added by Q in the first place?
> Or am I misreading this?

I made a wrong assumption there, the kernel won't even remove a route of
which the nexthop becomes unreachable.

What I meant, and what is still (more) valid: It seems that the only
thing onlink is doing, is overwriting the reachability check for the
gateway when installing the route into the kernel.

So why should we set onlink only when the nexthop is not reachable? If
the nexthop is reachable, setting onlink wouldn't change the semantics
anyway, would it?

(That general point is only valid if we set onlink for any configured
netmask. It doesn't apply if we only do that for /32)


More information about the Quagga-dev mailing list