Bird & VRF on Linux

Tim Weippert weiti at weiti.org
Mon May 15 09:28:36 CEST 2017


On Wed, May 10, 2017 at 02:08:00PM +0200, Ondrej Zajicek wrote:
> On Wed, May 10, 2017 at 12:42:23PM +0200, Tim Weippert wrote:

[ ... ]

> Hi
> 
> There is small thread about it:
> 
> http://bird.network.cz/pipermail/bird-users/2017-March/011055.html
> 
> The offered patch is in Git in master branch, but not in the last
> released 1.6.x branch.

Will look on the patch. Seems i missed this conversation completely :)
 
> I thought about full VRF support for BIRD, my ideas are like:
> 
> 1) VRFs defined in BIRD config. They are matched with VRF devices in kernel.
> 
> 2) Instead of having one pool of interfaces, interfaces are automatically
> split to VRFs based on kernel scan.
> 
> 3) Protocols (and routing tables) have option 'vrf', which assigns them
> to appropriate VRF, which means they only consider interfaces from that
> VRFs, resolve neighbors inside that VRFs and their sockets are bound to
> that VRFs.

That sounds perfect for separation of VRF's and be able to had Peerings
inside an VRF.

> 4) Some specific protocols (e.g. pipe) could be associated with multiple
> VRFs.

That is good, as with this (if i'm undestand it correct) 
route leaking from one VRF to another should be possible (If the next-hops 
are equal/routeable or rewritten). 

Or with "global" pipes it should be also possible to write directly in
the kernel routing tables associated to an VRF.

> Any comments?

Maybe we can check if the "global" approach described in the vrf kernel
document (vrf.txt) with l3mdev accept works too.

Addtional with VPN Support in Bird 2.X (maybe) it would be nice to use
this in conjunction with the VRF code for L3VPN Services.

regards, 
tim

-- 
Tim Weippert
http://weiti.org - weiti at weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8


More information about the Bird-users mailing list