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