Re: Next-hop check not needed?
❦ 28 juin 2017 14:01 +0200, Ondrej Zajicek <santiago@crfreenet.org> :
Note that when learning route from the kernel you could workaround it by using 'onlink' route flag.
Great! It seems to work: $ ip route show table public dev eth2 203.0.113.1 scope link metric 10 203.0.113.10 via 203.0.113.1 metric 10 onlink bird> show route table public 203.0.113.10/32 via 203.0.113.1 on eth2 [kernel_public 15:58:09] * (200) 203.0.113.1/32 dev eth2 [kernel_public 15:58:09] * (200) But BIRD (1.6.3) still seems to be a bit confused, since I got this message in a loop: 2017-06-28 16:01:20 <ERR> KRT: Received route 203.0.113.10/32 with strange next-hop 203.0.113.1 2017-06-28 16:01:20 <WARN> Netlink: File exists Other than that, everything works as expected. I don't know how to interpret the first message (is it receiving two routes?) but the second message seems to say that it tries to reinstall the same route it received. -- 10.0 times 0.1 is hardly ever 1.0. - The Elements of Programming Style (Kernighan & Plauger)
❦ 28 juin 2017 16:12 +0200, Vincent Bernat <bernat@luffy.cx> :
Note that when learning route from the kernel you could workaround it by using 'onlink' route flag.
Great!
It seems to work:
$ ip route show table public dev eth2 203.0.113.1 scope link metric 10 203.0.113.10 via 203.0.113.1 metric 10 onlink
bird> show route table public 203.0.113.10/32 via 203.0.113.1 on eth2 [kernel_public 15:58:09] * (200) 203.0.113.1/32 dev eth2 [kernel_public 15:58:09] * (200)
But BIRD (1.6.3) still seems to be a bit confused, since I got this message in a loop:
2017-06-28 16:01:20 <ERR> KRT: Received route 203.0.113.10/32 with strange next-hop 203.0.113.1 2017-06-28 16:01:20 <WARN> Netlink: File exists
Other than that, everything works as expected. I don't know how to interpret the first message (is it receiving two routes?) but the second message seems to say that it tries to reinstall the same route it received.
After investigating a bit more, the problem is triggered by the fact that BIRD doesn't install the route with the "onlink" attribute. I am using this kind of configuration to maintain a stripped version of the routing table for local use: table local_out; protocol kernel kernel_local_out { persist; import none; export filter { krt_prefsrc = loopback_private; accept; }; scan time 10; kernel table 100; table local_out; device routes yes; merge paths yes; } protocol pipe private_local_out { table private; peer table local_out; import none; export all; } protocol pipe public_local_out { table public; peer table local_out; import none; export filter { if proto = "kernel_public" then accept; reject; }; } So, when the route is copied to the "local_out" table, it is copied without the "onlink" parameter: $ ip route show table public dev eth2 203.0.113.1 scope link metric 10 203.0.113.10 via 203.0.113.1 metric 10 onlink $ ip route show table local-out dev eth2 203.0.113.1 proto bird scope link src 172.22.2.1 metric 10 203.0.113.10 via 203.0.113.1 proto bird src 172.22.2.1 metric 10 On the next pass, BIRD doesn't recognize it (KRT: Received route 203.0.113.10/32 with strange next-hop 203.0.113.1) and tries to install it again but it already exists (Netlink: File exists). I'll dig more to find a workaround. -- "Elves and Dragons!" I says to him. "Cabbages and potatoes are better for you and me." -- J. R. R. Tolkien
❦ 29 juin 2017 10:12 +0200, Vincent Bernat <bernat@luffy.cx> :
On the next pass, BIRD doesn't recognize it (KRT: Received route 203.0.113.10/32 with strange next-hop 203.0.113.1) and tries to install it again but it already exists (Netlink: File exists). I'll dig more to find a workaround.
I didn't find any work-around, so I made this patch instead. Works for me. -- Treat end of file conditions in a uniform manner. - The Elements of Programming Style (Kernighan & Plauger)
❦ 29 juin 2017 11:02 +0200, Vincent Bernat <bernat@luffy.cx> :
On the next pass, BIRD doesn't recognize it (KRT: Received route 203.0.113.10/32 with strange next-hop 203.0.113.1) and tries to install it again but it already exists (Netlink: File exists). I'll dig more to find a workaround.
I didn't find any work-around, so I made this patch instead. Works for me.
It doesn't replace an existing route when the flag is just flipped. I don't know what's the best way to do that. -- This was the most unkindest cut of all. -- William Shakespeare, "Julius Caesar"
On Thu, Jun 29, 2017 at 02:56:17PM +0200, Vincent Bernat wrote:
❦ 29 juin 2017 11:02 +0200, Vincent Bernat <bernat@luffy.cx> :
On the next pass, BIRD doesn't recognize it (KRT: Received route 203.0.113.10/32 with strange next-hop 203.0.113.1) and tries to install it again but it already exists (Netlink: File exists). I'll dig more to find a workaround.
I didn't find any work-around, so I made this patch instead. Works for me.
Hi The patch looks fine, but there is one conceptual problem - onlink flag is not really property of a route, but property of a next hop, so your patch is incompatible with ECMP. Unfortunately, we currently do not have similar flexile attribute mechanism for per-next-hop data. As nexthop handling has some significant changes between 1.6.x and 2.0, we will fix this for 2.0 internally (some flag in next hop struct) and keep the current behavior for 1.6.x .
It doesn't replace an existing route when the flag is just flipped. I don't know what's the best way to do that.
It is possible that this is a limitation in BIRD that it does not check for change of other attributes during periodic scans, it checks only destinations and next hops (see krt_got_route(), krt_same_dest()). OTOH, asynchronous updates should be processed properly. -- 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."
❦ 4 juillet 2017 14:49 +0200, Ondrej Zajicek <santiago@crfreenet.org> :
The patch looks fine, but there is one conceptual problem - onlink flag is not really property of a route, but property of a next hop, so your patch is incompatible with ECMP. Unfortunately, we currently do not have similar flexile attribute mechanism for per-next-hop data.
Understood. Fortunately, in my case, those routes are not really needed locally, so I can just filter them and announce them only over BGP. Thanks for the help. -- Localise input and output in subroutines. - The Elements of Programming Style (Kernighan & Plauger)
participants (2)
-
Ondrej Zajicek -
Vincent Bernat