On Sun, Aug 06, 2017 at 05:03:00PM +0200, Clément Guivy wrote:
On 06/08/2017 12:27, Ondrej Zajicek wrote:
The difference is that such bug affect only outgoing connnections, not incoming connections. In your IBGP case, both routers are affected by the bug, so no connection is possible. In your EBGP case, incoming connections are from hardware routers not affected by the bug.
ok, that makes sense.
I got confirmed from David Ahern that kernel patch fixing the behavior for sockets bound to VRF-enslaved devices was just released yesterday: http://www.spinics.net/lists/netdev/msg448040.html http://www.spinics.net/lists/netdev/msg448223.html
My mistake. It is commit 33b6c292c3e3a8972d0b9f43d156aae50db65720 [1], which is newer than the verson 1.6.3, which you are probably using.
[1] https://gitlab.labs.nic.cz/labs/bird/commit/33b6c292c3e3a8972d0b9f43d156aae5...
that's in version 2 I suppose ? (don't have much knowledge of gitlab sorry). If so I'd rather not use it until it's out of beta. Good to know it's coming though.
It is devel code for branch 1.6.x.
I don't think it is deterministic by BIRD code, if you have multiple interfaces with the same prefix, the selected interface for given IP depends probably on the order in which BIRD found them.
Not sure I fully understand here, what if I set different IP to eth1.3 and internet vrf interface (while leaving them in the same prefix) ? Since in the bird.conf we specify a source IP address (not a prefix), wouldn't that be enough to guarantee that internet vrf interface is picked and not eth1.3 ?
No, because the search is based on IP address of the neighbor. But if your interfaces are created in fixed order during boot, then they will be enumerated in fixed order and you get selected the same iface. -- 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."