BIRD BGP and VRF - Cannot assign requested address

[Clément Guivy]

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 ?).

I tried the replicated address in the vrf interface trick and the 
"interface" option as you suggested, but the service won't start :

###########################################
bird: /etc/bird/bird.conf, line 58: Link-local address and interface 
scope must be used together
###########################################

As per the documentation this error makes sense as it should be only 
used with link-local addresses. Am I missing something ?

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
###########################################

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.

Also, being bound to a virtual interface, bird doesn't benefit from the 
physical link failure detection. "Check link" option doesn't work, which 
I guess makes sense since it probably tracks the state of the vrf 
interface itself, which doesn't go down. At least I could use BFD to 
circumvent that I suppose.