Source Address Dependent Routing patch

[Toke Høiland-Jørgensen]

Dean <dluga93 at gmail.com> writes:

> On 05/22/2017 12:07 PM, Toke Høiland-Jørgensen wrote:
>
>>  Yes, they can. You can use two kernel protocols, one with the SADR
>> channel  and the other with ipv6. Both sets of routes are stored in
>> the same kernel table.
>>
>> Ah, yes, but I meant inside Bird in this instance. Can the bird 'struct
>> fib' hold both types of routes, or do you need a separate one for each?
>
> No, the fib structure holds only one address type. But depending on
> how you plan to use it, maybe you can simulate non-sadr entries using
> ::/0 source prefix?

Right. Well, I have only just started to convert Babel to support
dual-stack v4/v6 routing; source-specific will come later. If I end up
keeping the current structure, I'll need to disambiguate anyway, so
another address family won't hurt too much...

>>>  But the kernel bug is still present. Using both types of routes in the
>>> same table gives undefined behavior. A hacky workaround would be to
>>> replace ::/0 sources with 2000::/3 in netlink, but it would reduce the
>>> set of accepted prefixes.
>>
>> Do you have a quick howto on triggering this bug?
>
> If you insert two routes with the same destination in the routing
> table, one of them being SADR, the dst-only route is ignored.
>
> 2001:db9:1::3 from 2001:db9:1::4 dev v0  metric 1024 
> 2001:db9:1::3 dev v0  metric 1024
>
> Pinging to 2001:db9:1::3 using a source address that's not
> 2001:db9:1::4 gives a network unreachable error. Though if you remove
> the SADR route, or if you add another SADR route with the correct
> source address, it works fine.

Yeah, I can reproduce this on older kernels, but it seems to have been
fixed in  the 4.10.16 kernel that my desktop is currently running.

This doesn't apply to default routes, though (e.g. ':: from xxx/64') ?
All of the actual source-specific routes I have in my network are
default routes, and I've never been plagued by this bug on those...

-Toke