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 <[email protected]> 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: [email protected]) > OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) > "To err is human -- to blame it on a computer is even more so." >
