Fix IPv6 ECMP handling with 4.11+ kernel
Hey! Starting from kernel 4.11 (commit beb1afac518d), IPv6 are now notified using RTA_MULTIPATH, like IPv4 routes. Those routes are not handled correctly by BIRD. We handle them correctly. This also enable to parse alien routes correctly. Route modifications is still done in the old way as for insertion/deletion, this is not helpful to optimize in those cases and for replace, IPv4 case is not optimized either. It should be possible to detect appropriate support for RTA_MULTIPATH when receiving an IPv6 route with this attribute, but I don't see how it would be helpful, so I didn't do it (simpler code this way). I did some quick tests and routes are removed/added correctly: Deleted 2001:db8:a3::/64 proto bird metric 1024 nexthop via 2001:db8:ff::5 dev vti5 weight 1 nexthop via 2001:db8:ff::7 dev vti6 weight 1 2001:db8:a3::/64 via 2001:db8:ff::7 dev vti6 proto bird metric 1024 pref medium Deleted 2001:db8:a3::/64 via 2001:db8:ff::7 dev vti6 proto bird metric 1024 pref medium 2001:db8:a3::/64 via 2001:db8:ff::5 dev vti5 proto bird metric 1024 pref medium 2001:db8:a3::/64 proto bird metric 1024 nexthop via 2001:db8:ff::7 dev vti6 weight 1 nexthop via 2001:db8:ff::5 dev vti5 weight 1 Also, alien routes are correctly parsed when next-hops are correctly ordered (I didn't check if this restriction is also present for IPv4 or if Linux is always sending IPv4 multipath routes with next-hops correctly ordered): 2001:db8:a4::/64 metric 1024 nexthop via 2001:db8:ff::5 dev vti5 weight 1 nexthop via 2001:db8:ff::7 dev vti6 weight 1 2001:db8:a4::/64 multipath [kernel1 22:30:54] * (10) via 2001:db8:ff::5 on vti5 weight 1 via 2001:db8:ff::7 on vti6 weight 1 I'll try to investigate that unless someone already knows the answer. -- Make input easy to proofread. - The Elements of Programming Style (Kernighan & Plauger)
❦ 31 août 2017 22:39 +0200, Vincent Bernat <bernat@luffy.cx> :
Also, alien routes are correctly parsed when next-hops are correctly ordered (I didn't check if this restriction is also present for IPv4 or if Linux is always sending IPv4 multipath routes with next-hops correctly ordered)
It's the same for IPv4. Dunno if it should be considered as a bug? -- Use the "telephone test" for readability. - The Elements of Programming Style (Kernighan & Plauger)
On Fri, Sep 01, 2017 at 11:19:40AM +0200, Vincent Bernat wrote:
❦ 31 août 2017 22:39 +0200, Vincent Bernat <bernat@luffy.cx> :
Also, alien routes are correctly parsed when next-hops are correctly ordered (I didn't check if this restriction is also present for IPv4 or if Linux is always sending IPv4 multipath routes with next-hops correctly ordered)
It's the same for IPv4. Dunno if it should be considered as a bug?
Not sure what is a problem here. Do you mean that alien routes are not correctly parsed when next-hops are not ordered? How does the problem manifests? -- 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."
❦ 1 septembre 2017 13:12 +0200, Ondrej Zajicek <santiago@crfreenet.org> :
Also, alien routes are correctly parsed when next-hops are correctly ordered (I didn't check if this restriction is also present for IPv4 or if Linux is always sending IPv4 multipath routes with next-hops correctly ordered)
It's the same for IPv4. Dunno if it should be considered as a bug?
Not sure what is a problem here. Do you mean that alien routes are not correctly parsed when next-hops are not ordered? How does the problem manifests?
Yes. 2017-09-01T13:19:20.741524+02:00 V1-1 bird6: Ignoring unsorted multipath route 2001:db8:a5::/64 received via kernel1 The route: 2001:db8:a5::/64 metric 1024 nexthop via 2001:db8:ff::3 dev vti4 weight 1 nexthop via 2001:db8:ff::1 dev vti3 weight 1 Same for IPv4. -- Identify bad input; recover if possible. - The Elements of Programming Style (Kernighan & Plauger)
On Fri, Sep 01, 2017 at 01:19:57PM +0200, Vincent Bernat wrote:
❦ 1 septembre 2017 13:12 +0200, Ondrej Zajicek <santiago@crfreenet.org> :
Also, alien routes are correctly parsed when next-hops are correctly ordered (I didn't check if this restriction is also present for IPv4 or if Linux is always sending IPv4 multipath routes with next-hops correctly ordered)
It's the same for IPv4. Dunno if it should be considered as a bug?
Not sure what is a problem here. Do you mean that alien routes are not correctly parsed when next-hops are not ordered? How does the problem manifests?
Yes.
2017-09-01T13:19:20.741524+02:00 V1-1 bird6: Ignoring unsorted multipath route 2001:db8:a5::/64 received via kernel1
The route:
2001:db8:a5::/64 metric 1024 nexthop via 2001:db8:ff::3 dev vti4 weight 1 nexthop via 2001:db8:ff::1 dev vti3 weight 1
OK, seems like this issue is fixed in 2.0 branch but we forgot to backport to 1.6.x branch. Will fix it. -- 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."
On Thu, Aug 31, 2017 at 10:39:01PM +0200, Vincent Bernat wrote:
Hey!
Starting from kernel 4.11 (commit beb1afac518d), IPv6 are now notified using RTA_MULTIPATH, like IPv4 routes. Those routes are not handled correctly by BIRD. We handle them correctly. This also enable to parse alien routes correctly. Route modifications is still done in the old way as for insertion/deletion, this is not helpful to optimize in those cases and for replace, IPv4 case is not optimized either. It should be possible to detect appropriate support for RTA_MULTIPATH when receiving an IPv6 route with this attribute, but I don't see how it would be helpful, so I didn't do it (simpler code this way).
Hi Thanks for the patch, it looks OK. I will try it and merge it. We plan to simplify the multipath processing code in 2.x branch so that it will depend on the new kernel behavior (and therefore will require Linux 4.0.11 for IPv6 multipath), but we keep the current code in 1.6.x. -- 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."
On Fri, Sep 01, 2017 at 11:36:01AM +0200, Ondrej Zajicek wrote:
Starting from kernel 4.11 (commit beb1afac518d), IPv6 are now notified using RTA_MULTIPATH, like IPv4 routes. Those routes are not handled correctly by BIRD. We handle them correctly. This also enable to parse alien routes correctly. Route modifications is still done in the old way as for insertion/deletion, this is not helpful to optimize in those cases and for replace, IPv4 case is not optimized either. It should be possible to detect appropriate support for RTA_MULTIPATH when receiving an IPv6 route with this attribute, but I don't see how it would be helpful, so I didn't do it (simpler code this way).
Hi
Thanks for the patch, it looks OK. I will try it and merge it.
We plan to simplify the multipath processing code in 2.x branch so that it will depend on the new kernel behavior (and therefore will require Linux 4.0.11 for IPv6 multipath), but we keep the current code in 1.6.x.
We have lots of kit (e.g. https://www.arista.com/en/products/7280r-series) that comes with: Linux labtest 3.4.43.Ar-3964936.4173F #1 SMP PREEMPT Mon Dec 19 14:31:21 PST 2016 x86_64 x86_64 x86_64 GNU/Linux And which is impossible for us to upgrade to newer kernel versions. If bird 2.0 will require Linux >= 4.11 for IPv6 multipath, then upgrading to bird 2.0 would not be an option for us.
❦ 1 septembre 2017 12:53 +0300, Lennert Buytenhek <buytenh@wantstofly.org> :
Starting from kernel 4.11 (commit beb1afac518d), IPv6 are now notified using RTA_MULTIPATH, like IPv4 routes. Those routes are not handled correctly by BIRD. We handle them correctly. This also enable to parse alien routes correctly. Route modifications is still done in the old way as for insertion/deletion, this is not helpful to optimize in those cases and for replace, IPv4 case is not optimized either. It should be possible to detect appropriate support for RTA_MULTIPATH when receiving an IPv6 route with this attribute, but I don't see how it would be helpful, so I didn't do it (simpler code this way).
Hi
Thanks for the patch, it looks OK. I will try it and merge it.
We plan to simplify the multipath processing code in 2.x branch so that it will depend on the new kernel behavior (and therefore will require Linux 4.0.11 for IPv6 multipath), but we keep the current code in 1.6.x.
We have lots of kit (e.g. https://www.arista.com/en/products/7280r-series) that comes with:
Linux labtest 3.4.43.Ar-3964936.4173F #1 SMP PREEMPT Mon Dec 19 14:31:21 PST 2016 x86_64 x86_64 x86_64 GNU/Linux
And which is impossible for us to upgrade to newer kernel versions. If bird 2.0 will require Linux >= 4.11 for IPv6 multipath, then upgrading to bird 2.0 would not be an option for us.
I agree with you. Currently, there is no distro with a 4.11+ kernel (Ubuntu LTS is 4.4, Debian is 4.9, CentOS is 3.13). It seems a bit early to require such a recent kernel. -- In the first place, God made idiots; this was for practice; then he made school boards. -- Mark Twain
On Fri, Sep 01, 2017 at 11:59:19AM +0200, Vincent Bernat wrote:
We have lots of kit (e.g. https://www.arista.com/en/products/7280r-series) that comes with:
Linux labtest 3.4.43.Ar-3964936.4173F #1 SMP PREEMPT Mon Dec 19 14:31:21 PST 2016 x86_64 x86_64 x86_64 GNU/Linux
And which is impossible for us to upgrade to newer kernel versions. If bird 2.0 will require Linux >= 4.11 for IPv6 multipath, then upgrading to bird 2.0 would not be an option for us.
I agree with you. Currently, there is no distro with a 4.11+ kernel (Ubuntu LTS is 4.4, Debian is 4.9, CentOS is 3.13). It seems a bit early to require such a recent kernel.
Well, that was a reason why i was reluctant for long to include IPv6 multipath support in BIRD, hoping that Kernel people fix their API. That happened about half year after i finally gave up. OK, so we will likely postpone the transition. Hopefully our plan to ditch 2.4.x kernel workarounds in BIRD 2.0 will meet less resistance. ;-) -- 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."
participants (3)
-
Lennert Buytenhek -
Ondrej Zajicek -
Vincent Bernat