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:


> > 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/33b6c292c3e3a8972d0b9f43d156aae50db65720
> 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: santi...@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."

Attachment: signature.asc
Description: PGP signature

Reply via email to