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