Network Interfaces

If you haven’t already, shutdown the bsn-gw-2 VM to setup all of the network interfaces. Go ahead and add all of the necessary vlans/vmbrs in /etc/network/interfaces on the host machine. These VLANs are 101, 102, 103, 201, 202, 301, 302, and 303 as mentioned in the diagram above. Then go ahead and remove the network adapter on the bsn-gw-2 you used for internet using “virsh edit”. Then add-in 3 network adapters for each VLAN bsn-gw-2 is attached to (102, 201, 302).

Start up the VM and console in. Make sure you change the hostname in /etc/hostname if you haven’t already. Next, we are going to start by configuring the network interfaces as we would normally, but this time we need to include a configuration for IPv6 since we are creating a dual-stack routing lab. Adding an IPv6 configuration is very simple and not much different from adding an IPv4 configuration. In my example, “ens5” is the interface directly connected to bsn-gw-1, so my configuration looks like this:

auto ens5
iface ens5 inet static
    address 10.201.0.2
    netmask 255.255.255.252

iface ens5 inet6 static
    address fd00:201::2
    netmask 64

Make sure you check which interface is connected to what–they should be in the same order you included them in virsh edit. Then add in an IPv4 and IPv6 address to each of the 3 interfaces based off of the network diagram. For the LAN interfaces, since this router will be the gateway, just give it the 1st address on the subnet. For bsn-gw-2, that means its addresses will be 192.168.2.1/24 and fdAA:2::1/64.

That configures the 3 virtual interfaces with both IPv4 and IPv6 addresses. After restarting the interfaces with “ipdown” and “ifup”, running “ip a” or “ship” will now show both the IPv4 and IPv6 addresses

Because we are using dynamic routing, we are also going to want to create a loopback address for both IPv4 and IPv6. This is done exactly the same way as with IPv4, just adding in an additional IPv6 address. Add these lines to the end of /etc/rc.local, only adjust the addresses as needed based on the network diagram:

/sbin/modprobe dummy
/sbin/ip link set name eth10 dev dummy0
ip address add 10.0.0.2/32 dev eth10
ip address add fd00::2/128 dev eth10

To apply this, either run the command “./etc/rc.local” (this just executes the script) or restart the vm (“/etc/rc.local” gets automatically executed on boot).

Routing

With all of the bsn-gw’s, we are going to be configuring both OSPF and BGP (both iBGP and eBGP), while we are only going to be using eBGP on the other 3 gateways, as in this lab they have no other local routers. As we did in previous labs, we are going to be using BIRD, but this time we are going to also need to use BIRD6 since we are creating a dual-stack environment.

BIRD 1.6, the current version used in the NEATRACK labs, has two separate config files for bird and bird6. The standard bird config, /etc/bird/bird.conf, is the one you’ve been using and will continue to use. Bird6 uses a separate config file located at /etc/bird/bird6.conf. In bird 1.6, IPv4 and IPv6 are two separate daemons, meaning that they don’t interact with each other at all and are configured entirely independently, so if one daemon stops, the other can continue to run and function normally.

We’ll start by configuring IPv4 in /etc/bird/bird.conf. The device, kernel, and direct protocols are all very similar to what you have seen in the past:

log syslog all;
router id 10.0.0.2;

protocol device {
        scan time 10;
}

protocol kernel {
        persist;
        metric 64;
        scan time 20;
        import all;
        export all;
}

protocol direct {
        interface “ens2”;
        interface “ens5”;
        interface “ens6”;
        interface “eth10”;
}

Now to configure OSPF. In my case, ens5 directly connects to bsn-gw-1, so I want to be communicating with OSPF on that interface. I then have my LAN configured as ens6, which I want to include in OSPF so that other routers know where the bsn-gw-2 LAN is, but it is configured as a stub since only hosts should be connected to the LAN. The loopback address is also included as a stubnet so that other local routers can ping the loopback address.

protocol ospf {
        import all;
        export none;
        tick 2;
        area 0.0.0.0 {
                interface "ens5" {
                        hello 6;
                        retransmit 6;
                        cost 100;
                        transmit delay 6;
                        dead 24;
                        type broadcast;
                };
                interface "ens6" {
                        stub yes;
                };
                stubnet 10.0.0.2/32;
        };
}

Next we have the filter setup to allow us to announce any local IPs in the 192.168.0.0/16 network. Remember that we are pretending those are public addresses, so with BGP we only want to announce public IPs. The next line then also allows us to reannounce any routes that are also learned through BGP. Without this, routers using BGP could only talk to networks 1 hop away, because the routes wouldn’t get shared with other peers. Finally, we reject anything else from getting advertised on BGP. This keeps private IPs from becoming routable across the Internet, which defeats the purpose of “private”.

filter lab_out {
        if net ~ 192.168.0.0/16 then accept;
        if source = RTS_BGP then accept;
        reject;
}

Last, we need to setup the actual BGP peers. Remember, you need one protocol for each peer. You’ll notice that there isn’t much difference between iBGP and eBGP configurations. Since we are using OSPF to create routes internally, we use the loopback address of each router with iBGP rather than a physical interface that could go down. This way, in a more connected internal network, there would be better redundancy with the BGP peers. As an added bonus, it also makes organization simpler when looking at an existing configuration.

Notice that we also change the source address. By default, BIRD would try to start a BGP connection from the closest physical interface to the neighbor. Since BGP checks the source address, though, we need to make sure it matches the expected neighbor IP for it to actually peer.

protocol bgp cfl_gw_1 {
        import all;
        export filter lab_out;
        local as 65001;
        neighbor 100.102.0.2 as 65003;
}

protocol bgp bsn_gw_1 {
        import all;
        export filter lab_out;
        local as 65001;
        neighbor 10.0.0.1 as 65001;
        source address 10.0.0.2;
}

protocol bgp bsn_gw_3 {
        import all;
        export filter lab_out;
        local as 65001;
        neighbor 10.0.0.3 as 65001;
        source address 10.0.0.2;
}

That’s it for the IPv4 configuration of BIRD. Luckily, the IPv6 configuration is very similar. Since we haven’t configured bird6 at all, the easiest thing to do is to actually copy the IPv4 configuration into the IPv6 configuration, then edit it as needed.