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."
