HI all, currently i'm playing with Bird & VRF on Linux Kernel >4.9. I try to investigate if it is possible to build up an system which use Bird/BGP to populate the VRF/Tables. I tried to run on bird instance and use the described feature of running it in the default context and build up peerings within the sample VRF. As i can configure bird to try to build the Peerings with the correct interfaces/VRFs it seems no packet is send "through" the VRF or the listen socket is not working in this scenario (refused). My question is, is Bird capable to cope with the VRF Implementation in newer Linux Kernels? Has any one tried this? Regards, tim -- Tim Weippert http://weiti.org - weiti@weiti.org GPG Fingerprint - E704 7303 6FF0 8393 ADB1 398E 67F2 94AE 5995 7DD8
On Wed, May 10, 2017 at 12:42:23PM +0200, Tim Weippert wrote:
HI all,
currently i'm playing with Bird & VRF on Linux Kernel >4.9. I try to investigate if it is possible to build up an system which use Bird/BGP to populate the VRF/Tables.
I tried to run on bird instance and use the described feature of running it in the default context and build up peerings within the sample VRF.
As i can configure bird to try to build the Peerings with the correct interfaces/VRFs it seems no packet is send "through" the VRF or the listen socket is not working in this scenario (refused).
My question is, is Bird capable to cope with the VRF Implementation in newer Linux Kernels? Has any one tried this?
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. 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. 4) Some specific protocols (e.g. pipe) could be associated with multiple VRFs. Any comments? -- 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, 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@weiti.org GPG Fingerprint - E704 7303 6FF0 8393 ADB1 398E 67F2 94AE 5995 7DD8
participants (2)
-
Ondrej Zajicek -
Tim Weippert