bfd does not work in a vrf

Ondrej Zajicek santiago at crfreenet.org
Wed Jul 17 16:46:37 CEST 2019


On Wed, Jul 17, 2019 at 03:08:45PM +0200, Alexander Zubkov wrote:
> On Wed, Jul 17, 2019 at 2:47 PM Ondrej Zajicek <santiago at crfreenet.org> 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:

 - There was check in BFD code that forbade multiple BFD instances, that
   has to be removed.

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

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


More information about the Bird-users mailing list