I have also prepared some changes to the documentation. But it probably should wait unitl the questions with VRF and non VRF are finalized. For example in the current state, that catch-all behaviour better to be described too.
On Wed, Jul 17, 2019 at 6:03 PM Alexander Zubkov <[email protected]> wrote: > > On Wed, Jul 17, 2019 at 4:46 PM Ondrej Zajicek <[email protected]> wrote: > > > > On Wed, Jul 17, 2019 at 03:08:45PM +0200, Alexander Zubkov wrote: > > > On Wed, Jul 17, 2019 at 2:47 PM Ondrej Zajicek <[email protected]> > > > wrote: > > > > Hello > > > > > > > > This would work, it is necessary to also set sk->vrf for > > > > bfd_open_tx_sk() > > > > foir multihop BFD. It is not necessary to handle it in > > > > bfd_reconfigure(), > > > > as VRF change is handled in generic code in proto_reconfigure(). > > > > > > > > I also just implemented BFD request dispatch based on VRFs to handle > > > > multiple > > > > VRFs and multiple BFD instances. > > > > > > Oh! I was just trying to figure out it myself today too. See the > > > attached patch. :) > > > > Your patch is correct and mostly the same as mine [*]. There are just > > two differences: > > I'm glad to hear that I have figured out it correctly. :) > > > > > - There was check in BFD code that forbade multiple BFD instances, that > > has to be removed. > > Yes. I was thinking if I could replace it with some check that only > one bfd per vrf exists. But delete way is easier here. :) > > > > > - I allowed request in VRF to be handled by BFD protocol in default/NULL > > VRF. > > That would make it compatible with one BFD and > > net.ipv4.udp_l3mdev_accept=1. > > I see. But in that case if one had a mixed "environment" with vrfs and > non-vrf protocols, than the default bfd would be able to catch other > vrf's sessions first. May be it would make sence to introduce some > check that config has non-default vrf options or some configuration > option for bfd protocol. > > > > > Note that it was true that wildcard socket bind in default VRF blocked > > bind in other VRFs, so it would not be possible to run BFD in both > > default VRF and regular VRFs, but that was fixed in Linux kernel 5.0, > > so perhaps it would make sense to change it that BFD in default VRF > > only accept requests from default BFD, like in your patch. > > > > > > [*] > > https://gitlab.labs.nic.cz/labs/bird/commit/cf7ff99513728e4e405508e5ccd7522289d4ec82 > > > > -- > > 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."
--- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -1896,7 +1896,12 @@ the BFD session went down). advanced features like the echo mode or authentication are not implemented), IP transport for BFD as defined in <rfc id="5881"> and <rfc id="5883"> and interaction with client protocols as defined in <rfc id="5882">. -We currently support at most one protocol instance. + +<p>As BFD protocol implementation binds a wildcard socket, at most one protocol +instance per VRF is supported. Note, that Linux kernel versions below 5.0 do +not allow simultaneous wildcard sockets in several VRFs. In that case you can +use single BFD instance without VRF with sysctl option set: +<cf>net.ipv4.udp_l3mdev_accept=1</cf> <p>BFD packets are sent with a dynamic source port number. Linux systems use by default a bit different dynamic port range than the IANA approved one
