Re: bfd does not work in a vrf
Hello Yes, this is currently not implemented properly, i forgot about it. Would require some substantial work. There are two possibilities: - Multiple BFD instances, each in VRF, with proper dispatch of BFD requests to instances based on VRF. - One BFD instance, with multiple listening sockets, each with appropriate VRF. That would require more work. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
Hello, I made small fix for myself, that allow bfd to work in one VRF, defined in the configuration: --- a/proto/bfd/packets.c +++ b/proto/bfd/packets.c @@ -413,6 +413,7 @@ bfd_open_rx_sk(struct bfd_proto *p, int multihop, int af) sk->type = SK_UDP; sk->subtype = af; sk->sport = !multihop ? BFD_CONTROL_PORT : BFD_MULTI_CTL_PORT; + sk->vrf = p->p.vrf; sk->data = p; sk->rbsize = BFD_MAX_LEN; It works, but I suppose vrf change should be handled somehow in bfd_reconfigure also. Not sure if reopening socket is enough or it would be better to call bfd_shutdown() and bfd_start(). On Tue, Jul 16, 2019 at 3:40 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
Hello
Yes, this is currently not implemented properly, i forgot about it. Would require some substantial work. There are two possibilities:
- Multiple BFD instances, each in VRF, with proper dispatch of BFD requests to instances based on VRF.
- One BFD instance, with multiple listening sockets, each with appropriate VRF. That would require more work.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@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."
On Wed, Jul 17, 2019 at 12:05:49PM +0200, Alexander Zubkov wrote:
Hello,
I made small fix for myself, that allow bfd to work in one VRF, defined in the configuration:
--- a/proto/bfd/packets.c +++ b/proto/bfd/packets.c @@ -413,6 +413,7 @@ bfd_open_rx_sk(struct bfd_proto *p, int multihop, int af) sk->type = SK_UDP; sk->subtype = af; sk->sport = !multihop ? BFD_CONTROL_PORT : BFD_MULTI_CTL_PORT; + sk->vrf = p->p.vrf; sk->data = p;
sk->rbsize = BFD_MAX_LEN;
It works, but I suppose vrf change should be handled somehow in bfd_reconfigure also. Not sure if reopening socket is enough or it
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. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
On Wed, Jul 17, 2019 at 2:47 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Wed, Jul 17, 2019 at 12:05:49PM +0200, Alexander Zubkov wrote:
Hello,
I made small fix for myself, that allow bfd to work in one VRF, defined in the configuration:
--- a/proto/bfd/packets.c +++ b/proto/bfd/packets.c @@ -413,6 +413,7 @@ bfd_open_rx_sk(struct bfd_proto *p, int multihop, int af) sk->type = SK_UDP; sk->subtype = af; sk->sport = !multihop ? BFD_CONTROL_PORT : BFD_MULTI_CTL_PORT; + sk->vrf = p->p.vrf; sk->data = p;
sk->rbsize = BFD_MAX_LEN;
It works, but I suppose vrf change should be handled somehow in bfd_reconfigure also. Not sure if reopening socket is enough or it
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. :) It adds vrf parameter to the bfd_request and bfd_request_session funciton. Not sure though that I passed vrf correctly from all protocols.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@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."
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@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/cf7ff99513728e4e405508e5ccd75222... -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
On Wed, Jul 17, 2019 at 4:46 PM Ondrej Zajicek <santiago@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@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/cf7ff99513728e4e405508e5ccd75222...
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@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."
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@qrator.net> wrote:
On Wed, Jul 17, 2019 at 4:46 PM Ondrej Zajicek <santiago@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@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/cf7ff99513728e4e405508e5ccd75222...
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@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."
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@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@qrator.net> wrote:
On Wed, Jul 17, 2019 at 4:46 PM Ondrej Zajicek <santiago@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@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/cf7ff99513728e4e405508e5ccd75222...
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@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."
On Thu, Jul 18, 2019 at 04:23:00PM +0200, Alexander Zubkov wrote:
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.
Hi I would rather keep it in the current state until we would have some better / generic solution. The issue with BFD is analogous with other protocols, e.g. OSPF - if OSPF is configured for VRF on all interfaces, then it is enabled for all interfaces inside the VRF, but when it is configured without VRF on all interfaces, then it is enabled for all interfaces, regardless whether they are a part of any VRF or not. Therefore, we need a way to specify that a protocol is root/master/outer-VRF only, e.g. 'vrf root' option. Implementation would be easy, just not sure what is a proper term for that. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
Hi, Yes, I see the problem. Yes, probably using some "default" vrf name would be better. Looks like Linux uses word "default" to identify the main table also. At least iproute2 tools. "ip route show vrf default" works for me. And I see the reference in the man. For example: This command allows applications that are VRF unaware to be run against a VRF other than the default VRF (main table). A command can be run against the default VRF by passing the "default" as the VRF name. This is useful if the current shell is associated with another VRF (e.g, Management VRF). But it works for some commands only. "ip vrf pids default" does not work, and it does not show it in vrf list. But if somebody named the vrf "default", it would have problems anyway with some commands. So I think this name could be "occupied". On Tue, Jul 23, 2019 at 3:43 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Thu, Jul 18, 2019 at 04:23:00PM +0200, Alexander Zubkov wrote:
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.
Hi
I would rather keep it in the current state until we would have some better / generic solution. The issue with BFD is analogous with other protocols, e.g. OSPF - if OSPF is configured for VRF on all interfaces, then it is enabled for all interfaces inside the VRF, but when it is configured without VRF on all interfaces, then it is enabled for all interfaces, regardless whether they are a part of any VRF or not.
Therefore, we need a way to specify that a protocol is root/master/outer-VRF only, e.g. 'vrf root' option. Implementation would be easy, just not sure what is a proper term for that.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@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."
On Tue, Jul 23, 2019 at 07:08:48PM +0200, Alexander Zubkov wrote:
Hi,
Yes, I see the problem. Yes, probably using some "default" vrf name would be better. Looks like Linux uses word "default" to identify the main table also. At least iproute2 tools. "ip route show vrf default" works for me. And I see the reference in the man. For example:
Hi Yes, 'default' seems OK. This BIRD patch should fix the issue by allowing option 'vrf default' to restrict protocol to a set of iface not associated with any VRF: https://gitlab.labs.nic.cz/labs/bird/commit/18f70a6229f586d5e4f387075be42d7a... -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
participants (2)
-
Alexander Zubkov -
Ondrej Zajicek