bfd does not work in a vrf

[Alexander Zubkov]

On Wed, Jul 17, 2019 at 4:46 PM Ondrej Zajicek <santiago at crfreenet.org> 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 <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:

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