[PATCH 2.x branch] BGP: Bind listen socket to VRF

[Alexander Zubkov]

Sure, for listen any case it would be an issue. I use strict bind in my
setup, so I noticed no problems. It worked in different configurations of
server and peer: active-active, active-passive and passive-active.
When I did not specify vrf it was not working with strict bind. It worked
only with listen any (for 1.6 too), but it could not accept connections
unless I did:
net.ipv4.tcp_l3mdev_accept = 1

On Fri, Oct 26, 2018 at 10:46 PM, Ondrej Zajicek <santiago at crfreenet.org>
wrote:

> On Fri, Oct 26, 2018 at 08:38:28PM +0200, Alexander Zubkov wrote:
> > Hi,
> >
> > Thank you for improving the patch.
> >
> > Did I get it right? You mean the case when one has the same IP for BGP
> > sessions in different VRFs on different interfaces?
>
> Unless 'strict bind' option is used, local IP is irrelevant, because
> listening socket is bound to 0.0.0.0 anyways (addr in bgp_open() is
> IPA_NONE4/6).
>
> If i have two BGP protocols, one in vrf1 and the second in vrf2, then i
> need two listening sockets, first bound to 0.0.0.0 in vrf1, second to
> 0.0.0.0 in vrf2, they are bound to the same IPA_NONE4/6 address, but in
> different VRFs. In your patch the second socket would not be created,
> instead the first one would be reused (incorrectly) for the second
> protocol.
>
> The old code (without setting vrf) would have one listening socket not
> bound to any vrf, such socket would accept incoming sessions from both
> vrf1 and vrf2, but cannot distinguish them properly if both have the
> same remote ip.
>
> Also, it is possible that the new code has a problem that it would fail
> when there are two BGP sessions, one bound to a VRF and one that is not,
> because such two listening sockets would be incompatible, i would have to
> check that.
>
> Now thinking about it, i also need to fix bgp_find_proto() so that
> incoming connections are dispatched properly based on vrfs.
>
> --
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20181026/a193fbba/attachment.html>