Re: Bird 2.0.0 & VRF & Best Practices

17 Dec 2017

      On Sun, Dec 17, 2017 at 08:00:16PM +0100, Tim Weippert wrote:
...
Hi List,
i tried Bird 2.0.0, Kernel 4.14.6, Archlinux, VRF separated BGP Peerings.
I get an Config running, where i had an BGP Peering in Global Space and
one in a VRF. As the VRF Config seems "complex" i though maybe i do
something wrong or even more complex as really needed.
I had the following setup:
VM1 - ens10 <----> ens10 - VM2 (Global Space, BGP Peering)
VM1 - VRF RED - ens11 <----> ens11 - VRF RED VM2 ( VRF Peering)
The following is my working config for the Peering "inside" the VRF:
# VRF RED Tests
ipv4 table T_VRF_RED;
protocol kernel K_VRF_RED {
        vrf "red";
        kernel table 100;
        scan time 20;
ipv4 {
                table T_VRF_RED;
                import all;
                export all;
        };
}
protocol direct C_VRF_RED {
        vrf "red";
        ipv4 { table T_VRF_RED; };
interface "ens11";
        interface "red"; # Think this can be ommitted ...
}
protocol static S_VRF_RED {
        vrf "red";
        ipv4 { table T_VRF_RED; };
route 10.10.1.0/24 blackhole;
}
protocol bgp B_VRF_RED {
        vrf "red";
        local 172.16.10.[1|2] as 65100;
        neighbor 172.16.10.[2|1] as 65100;
        multihop;
# regular IPv4 unicast (1/1)
        ipv4 {
                table T_VRF_RED;
                import all;
                export where source ~ [ RTS_STATIC, RTS_BGP ];
        };
}
I tried several configs (with protocol direct, without) but this seems
the only one, i get working Peerings with resolveable next hops.
Is this as intended? Per VRF Kernel, Direct, BGP (Static only in my
test) Protocol to get an working VRF aware / separated routing 
instance?
Or is there something i misunderstand or can be simplified?
Hi. Your config is OK, just 'direct' protocol does not need 'interface'
sections (should work on all interfaes in VRF by default).

It is essentially the same as without VRFs - if you use multihop BGP
(IBGP by default), you need some routes to resolve next hops (from
Direct, OSPF, or some other source). As your neighbor is on the same net,
it should also work to switch BGP to 'direct' mode and ditch Direct
protocol, if you don't need resolvable routes.

The main cumbersome think is that it is necessary to use 'table' option
in all protocols. We will likely have per-VRF default tables in the
future.

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

Re: Bird 2.0.0 & VRF & Best Practices

Ondrej Zajicek