Bird considers the VRF interface to be outside the VRF

[Ondrej Zajicek]

On Tue, Jul 18, 2023 at 12:25:41PM +0200, Erin Shepherd wrote:
> Bird only treats the interfaces enslaved to the VRF as part of the VRF,
> but not the VRF virtual interface itself. This means that e.g. OSPF won't
> pick up loopback addresses defined on the VRF interface itself. You have
> to additionally add a dummy interfaces with the IPs attached, which seems
> to cause some confusion of its own on the kernel side.
> 
> Ideally the VRF interfaces would be considered to be in the VRF.
> 
> I've attached a patch which fixes this; I don't think the design is quite right, and its possible I introduced some bugs, but in testing it seems to work fine

Hi

Sorry for late answer, i somehow missed/forgot your mail. You are right,
VRF interfaces are supposed to be inside respective VRFs. One can see
that from e.g. 'local' routes generated by the kernel for IP addresses of
VRF ifaces.

Your patch was mostly ok, there was just a minor issue that the code of
if_in_vrf() you used would consider VRF interfaces both inside and
outside VRFs (for protocols that are explicitly bound to 'main' VRF,
called as if_in_vrf(x, NULL)). That was surprisingly complicated to fix,
as one had to implement parsing interface type in Netlink to tell apart
regular and VRF interfaces.

The fixed code was merged:
https://gitlab.nic.cz/labs/bird/-/commit/e3c0eca95642a846ab65261424a51dd99d954017

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