BIRD BGP and VRF - Cannot assign requested address

[Ondrej Zajicek]

On Sun, Aug 06, 2017 at 08:05:38AM +0200, Clément Guivy wrote:
> On 05/08/2017 23:55, Ondrej Zajicek wrote:
> > I found that it is probably a bug/behavior of Linux VRF implementation.
> > Socket can be bound to an iface, which is also used to choose related
> > VRF. For UDP sockets, it works for both VRF ifaces and underlying (real)
> > ifaces. But for TCP (and perhaps ICMP) sockets it seems to work only for
> > VRF ifaces, while BIRD tries to bind the socket with the real iface.
> > 
> > A very ugly workaround for BIRD BGP is to add appropriate IP addresses
> > also to vrf iface (with 'noprefixroute' option to not mess routing
> > table) and then use 'interface' BGP protocol option with vrf interface.
> 
> Thanks for your answer. First to respond to your previous mail, I'm using
> stock Debian kernel 4.9.0.3. I have read the changelog for version 4.10 and
> 4.11, didn't find anything related to my case.
> 
> What I don't get with the Linux bug/behavior idea is that the peering with
> the downstream router works fine where I would expect it to fail as well
> since it uses the same vrf setup (it is EBGP instead of IBGP but I don't see
> that making a difference from the kernel point of view ?).

Hi

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.

> I tried the replicated address in the vrf interface trick and the
> "interface" option as you suggested, but the service won't start :
> 
> As per the documentation this error makes sense as it should be only used
> with link-local addresses. Am I missing something ?

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

> Nonetheless, with just the replicated address in the vrf interface, the
> peering establishes. bird6 just complains a little but that doesn't seem too
> bad :
> 
> ###########################################
> bird6: ibgp_internet: Missing link local address on interface internet
> ###########################################

This can be ignored.

> But I wonder if this behavior is deterministic (and if yes according to
> which algorithm), or if the system could at some point revert to bind to
> eth1.3 and get back to its prior behaviour (sending RST after receiving
> SYN+ACK). I tried to reboot and bring down/up interfaces, for now it keeps
> re-establishing peering.

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.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20170806/b18cea73/attachment.asc>