Source Address Dependent Routing patch
Hello, This is another try at extending the static and OSPFv3 protocols to support Source Address Dependent Routing (SADR), also called Source Specific Routing. This basically means that routing will take into account not only the destination address, but the source address as well. IPv6 subtrees are needed to support SADR in the kernel. They should be available for Linux kernel versions newer than 3.11. If they are not enabled, the kernel needs to be compiled with the option to enable them. The patches are based on bird-2.0.0-pre0.
Dean <dluga93@gmail.com> writes:
Hello,
This is another try at extending the static and OSPFv3 protocols to support Source Address Dependent Routing (SADR), also called Source Specific Routing. This basically means that routing will take into account not only the destination address, but the source address as well.
Nice work! After a quick look at this (I'll go through it in more detail later), it looks like I can use the core parts of this for Babel as well. :) It looks like a separate channel is needed for SADR routes; (right?) but can SADR and non-SADR ipv6 routes co-exist in the same FIB? -Toke
On 22 May 2017 11:28, "Toke Høiland-Jørgensen" <toke@toke.dk> wrote: Dean <dluga93@gmail.com> writes:
Hello,
This is another try at extending the static and OSPFv3 protocols to support Source Address Dependent Routing (SADR), also called Source Specific Routing. This basically means that routing will take into account not only the destination address, but the source address as well.
Nice work! After a quick look at this (I'll go through it in more detail later), it looks like I can use the core parts of this for Babel as well. :) It looks like a separate channel is needed for SADR routes; (right?) but can SADR and non-SADR ipv6 routes co-exist in the same FIB? -Token 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. 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.
Dean Luga <dluga93@gmail.com> writes:
On 22 May 2017 11:28, "Toke Høiland-Jørgensen" <toke@toke.dk> wrote:
Dean <dluga93@gmail.com> writes:
Hello,
This is another try at extending the static and OSPFv3 protocols to support Source Address Dependent Routing (SADR), also called Source Specific Routing. This basically means that routing will take into account not only the destination address, but the source address as well.
Nice work! After a quick look at this (I'll go through it in more detail later), it looks like I can use the core parts of this for Babel as well. :)
It looks like a separate channel is needed for SADR routes; (right?) but can SADR and non-SADR ipv6 routes co-exist in the same FIB?
-Token
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?
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? -Toke
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? 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.
On 05/22/2017 12:36 PM, Dean wrote:
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? 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.
To add SADR routes with ip route you can use 'from'. I can't find this in the manual. ip -6 route add 2001:db9:1::3 from 2001:db9:1::4 dev v0
Dean <dluga93@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
participants (3)
-
Dean -
Dean Luga
-
Toke Høiland-Jørgensen