bfd does not work in a vrf

[Alexander Zubkov]

Hi,

I have attached a patch to check if there are any vrf-base bfd
protocols. And if there are none of them, then protocol non-vrf bfd
protocols takes all sessions. Otherwise it takes only non-vrf
sessions. I added a global option into config structure, but not sure
if it is an approved way of doing things like that.

It still leaves open a case when one have vrfs but want bfd only in
the default and some protocols in vrf have bfd enabled, so it will
send packets trying to establish them. But I think it is a rare and
weird case to enable bfd sessions in protocols, when they are not
supposed to work anyway.

On Wed, Jul 17, 2019 at 6:21 PM Alexander Zubkov <green at qrator.net> wrote:
>
> 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 <green at qrator.net> wrote:
> >
> > 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bfd-vrf-default.patch
Type: text/x-patch
Size: 2328 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20190718/b9fdcdaf/attachment.bin>