Re: Source Address Dependent Routing for BIRD
Static routes can be added in the configuration file with a source address constraint. To match an entry in the routing table, you have to match both the source and destination address. The same thing as running the command: ip -6 route add 2001:db9:1::/64 from 2001:db9:2::/64 dev eth0 Meaning we can only send packets to the network 2001:db9:1::/64 if the source address is part of the 2001:db9:2::/64 subnet. Otherwise we get a network unreachable message. One little problem is that it needs the IPV6_SUBTREES kernel option, which is available in linux kernel versions later than 3.11, but it might not be enabled by default. It's being explored in the IETF as a way of handling multihoming for IPv6 without NAT. OSPF can then spread the route through the network. It's also called source-specific routing. There's a paper out there for an implementation in babel. About the patch: it might be a little long, about 60 commits. And I started working last year, on BIRD 1.6.2, so some things might be different. Should I still just send each commit one by one here? On 03/05/2017 08:57 PM, Ondrej Zajicek wrote:
On Sun, Mar 05, 2017 at 07:39:57PM +0100, Dean wrote:
Hello,
I have been working on implementing SADR (Source Address Dependent Routing) in BIRD for the static and OSPFv3 protocols. Interesting. How it works?
What's the procedure for publishing the code? Should I put it on a repository online and send you a link? Generally just send a patch / patch set to the mailing list.
On Sun, Mar 05, 2017 at 09:21:43PM +0100, Dean wrote:
About the patch: it might be a little long, about 60 commits. And I started working last year, on BIRD 1.6.2, so some things might be different. Should I still just send each commit one by one here?
Generally, commits that are series of work on one logical part should be merged together, while conceptually separate changes should be in separate patches. In your case perhaps one patch for shared infrastructure (nest), one patch for kernel proto support, one patch for static, one or more patches for OSPFv3. See https://kernel.org/doc/html/latest/process/submitting-patches.html esp. https://kernel.org/doc/html/latest/process/submitting-patches.html#separate-... -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Dean <dluga93@gmail.com> writes:
Static routes can be added in the configuration file with a source
address constraint. To match an entry in the routing table, you have to match both the source and destination address. The same thing as running the command:
ip -6 route add 2001:db9:1::/64 from 2001:db9:2::/64 dev eth0
Meaning we can only send packets to the network 2001:db9:1::/64 if the source address is part of the 2001:db9:2::/64 subnet. Otherwise we get a network unreachable message. One little problem is that it needs the IPV6_SUBTREES kernel option, which is available in linux kernel versions later than 3.11, but it might not be enabled by default. It's being explored in the IETF as a way of handling multihoming for IPv6 without NAT.
OSPF can then spread the route through the network. It's also called source-specific routing. There's a paper out there for an implementation in babel.
Very cool! This is on my list of things to add to the Babel protocol as well, so I'll be interested in looking over your patch - the core parts should be reusable, and exchanging source-specific routes between Babel and OSPF should also be doable I guess. As for the lack of IPV6_SUBTREES: It is possible to achieve source-specific routing by using policy routing in Linux (i.e. `ip rule`), but it's somewhat of a hack. May be necessary to do something like that anyway for BSD, though... Here's the draft on the Babel source-specific extension: https://tools.ietf.org/html/draft-boutier-babel-source-specific-01 -Toke
There is already an implementation for that here (https://github.com/jech/babeld), if you want to check. I think this supports both IPV6_SUBTREES and policy routing, not sure. And I encountered another problem with IPV6_SUBTREES yesterday. Having source constrained routes and normal routes in the same routing table leads to unintended behavior. In my case, the normal route was ignored. If I had both a normal route and a source constrained route (with a wrong source address) in the table, it automatically returned a Network Unreachable, ignoring the normal route which should have worked. On 03/06/2017 11:27 AM, Toke Høiland-Jørgensen wrote:
Dean <dluga93@gmail.com> writes:
Static routes can be added in the configuration file with a source
address constraint. To match an entry in the routing table, you have to match both the source and destination address. The same thing as running the command:
ip -6 route add 2001:db9:1::/64 from 2001:db9:2::/64 dev eth0
Meaning we can only send packets to the network 2001:db9:1::/64 if the source address is part of the 2001:db9:2::/64 subnet. Otherwise we get a network unreachable message. One little problem is that it needs the IPV6_SUBTREES kernel option, which is available in linux kernel versions later than 3.11, but it might not be enabled by default. It's being explored in the IETF as a way of handling multihoming for IPv6 without NAT.
OSPF can then spread the route through the network. It's also called source-specific routing. There's a paper out there for an implementation in babel. Very cool! This is on my list of things to add to the Babel protocol as well, so I'll be interested in looking over your patch - the core parts should be reusable, and exchanging source-specific routes between Babel and OSPF should also be doable I guess.
As for the lack of IPV6_SUBTREES: It is possible to achieve source-specific routing by using policy routing in Linux (i.e. `ip rule`), but it's somewhat of a hack. May be necessary to do something like that anyway for BSD, though...
Here's the draft on the Babel source-specific extension: https://tools.ietf.org/html/draft-boutier-babel-source-specific-01
-Toke
Dean <dluga93@gmail.com> writes:
There is already an implementation for that here (https://github.com/jech/babeld), if you want to check. I think this supports both IPV6_SUBTREES and policy routing, not sure.
I meant for the Bird Babel implementation. And yeah, that was what I was referring to with policy routing:)
And I encountered another problem with IPV6_SUBTREES yesterday. Having source constrained routes and normal routes in the same routing table leads to unintended behavior. In my case, the normal route was ignored. If I had both a normal route and a source constrained route (with a wrong source address) in the table, it automatically returned a Network Unreachable, ignoring the normal route which should have worked.
Hmm, I have been running babeld with source-specific routes for quite some time and never run into this problem. Are you sure you didn't botch the netlink calls? ;) -Toke
Hmm, I have been running babeld with source-specific routes for quite some time and never run into this problem. Are you sure you didn't botch the netlink calls? ;)
I don't think so, I even tested inserting the routes with ip route without running bird. It was a documented behavior in net/ipv6/Kconfig in the kernel source. config IPV6_SUBTREES bool "IPv6: source address based routing" depends on IPV6_MULTIPLE_TABLES ---help--- Enable routing by source address or prefix. The destination address is still the primary routing key, so mixing normal and source prefix specific routes in the same routing table may sometimes lead to unintended routing behavior. This can be avoided by defining different routing tables for the normal and source prefix specific routes. If unsure, say N. On Mon, Mar 6, 2017 at 11:40 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
Dean <dluga93@gmail.com> writes:
There is already an implementation for that here (https://github.com/jech/babeld), if you want to check. I think this supports both IPV6_SUBTREES and policy routing, not sure.
I meant for the Bird Babel implementation. And yeah, that was what I was referring to with policy routing:)
And I encountered another problem with IPV6_SUBTREES yesterday. Having source constrained routes and normal routes in the same routing table leads to unintended behavior. In my case, the normal route was ignored. If I had both a normal route and a source constrained route (with a wrong source address) in the table, it automatically returned a Network Unreachable, ignoring the normal route which should have worked.
Hmm, I have been running babeld with source-specific routes for quite some time and never run into this problem. Are you sure you didn't botch the netlink calls? ;)
-Toke
Dean Luga <dluga93@gmail.com> writes:
Hmm, I have been running babeld with source-specific routes for quite some time and never run into this problem. Are you sure you didn't botch the netlink calls? ;)
I don't think so, I even tested inserting the routes with ip route without running bird. It was a documented behavior in net/ipv6/Kconfig in the kernel source.
Ah, I see. What was the specific route table entries that elicited this behaviour? And what kernel version? Will see if I can replicate it on my system... -Toke
On 03/06/2017 12:10 PM, Toke Høiland-Jørgensen wrote:
Dean Luga <dluga93@gmail.com> writes:
Hmm, I have been running babeld with source-specific routes for quite some time and never run into this problem. Are you sure you didn't botch the netlink calls? ;)
I don't think so, I even tested inserting the routes with ip route without running bird. It was a documented behavior in net/ipv6/Kconfig in the kernel source. Ah, I see. What was the specific route table entries that elicited this behaviour? And what kernel version? Will see if I can replicate it on my system...
-Toke
I had a system with an address of 2001:db9:1::2 connected to another with an address of 2001:db9:1::3. With one route: 2001:db9:1::3 dev v0 metric 1024 Ping was successful. Adding a route with a wrong source address: 2001:db9:1::3 from 2001:db9:1::1 dev v0 metric 1024 2001:db9:1::3 dev v0 metric 1024 I got a network unreachable message. Adding another source constrained route with the correct source: 2001:db9:1::3 from 2001:db9:1::1 dev v0 metric 1024 2001:db9:1::3 from 2001:db9:1::2 dev v0 metric 1024 2001:db9:1::3 dev v0 metric 1024 Ping successful.
On 03/06/2017 12:40 PM, Dean wrote:
On 03/06/2017 12:10 PM, Toke Høiland-Jørgensen wrote:
Dean Luga <dluga93@gmail.com> writes:
Hmm, I have been running babeld with source-specific routes for quite some time and never run into this problem. Are you sure you didn't botch the netlink calls? ;)
I don't think so, I even tested inserting the routes with ip route without running bird. It was a documented behavior in net/ipv6/Kconfig in the kernel source. Ah, I see. What was the specific route table entries that elicited this behaviour? And what kernel version? Will see if I can replicate it on my system...
-Toke
I had a system with an address of 2001:db9:1::2 connected to another with an address of 2001:db9:1::3. With one route:
2001:db9:1::3 dev v0 metric 1024
Ping was successful. Adding a route with a wrong source address:
2001:db9:1::3 from 2001:db9:1::1 dev v0 metric 1024 2001:db9:1::3 dev v0 metric 1024
I got a network unreachable message. Adding another source constrained route with the correct source:
2001:db9:1::3 from 2001:db9:1::1 dev v0 metric 1024 2001:db9:1::3 from 2001:db9:1::2 dev v0 metric 1024 2001:db9:1::3 dev v0 metric 1024
Ping successful.
Also, kernel version 4.9.13.
participants (4)
-
Dean -
Dean Luga
-
Ondrej Zajicek -
Toke Høiland-Jørgensen