Flexible software routing with open source FRR

Special Delivery

Configuring FRR

Before I go into the configuration example in more detail, some preparation is required. You need to enable the desired routing protocol in /etc/frr/daemons, which is ready after reloading. Use

show watchfrr

in the VTYSH shell to check which daemons are active.

Discussing the configurations of all supported dynamic routing protocols is well beyond the scope of this article, so I am limiting myself to a simple example for an eBGP link between two routers. Each of the two routers announces the IP address of the respective loopback interface to the opposite router over eBGP. To do this, you assign IP addresses to the loopback interfaces in line with the IP addresses shown in Figure 4 on the underlying Ubuntu 20.04 server; then, you give the ens33 interface an IP address on the transfer network. To do this, you generate the YAML files for Netplan (Listings 1 and 2) to obtain a bootable configuration, which is enabled by

sudo netplan apply

Listing 1

FRR1 Netplan YAML Config

network:
  ethernets:
    ens33:
      dhcp4: no
      addresses:
        - 192.0.2.0/31
    lo:
      addresses:
        - 192.168.1.1/32
  version: 2
  renderer: networkd

Listing 2

FRR2 Netplan YAML Config

network:
  ethernets:
    ens33:
      dhcp4: no
      addresses:
        - 192.0.2.1/31
    lo:
      addresses:
        - 192.168.2.2/32
  version: 2
  renderer: networkd

Figure 4: An external BGP (eBGP) session between the hosts FRR1 and FRR2. Each of the two routers announces its loopback IP address over BGP.

Now that the hosts can reach each other on transfer network 192.0.2.0/31, the FRR configuration can take place. I used VTYSH for the parameterization work. Listing 3 shows the configuration components for eBGP. This example is only to illustrate functionality; it is not intended for production use.

Listing 3

BGP Config Snippets

01 #FRR1
02 router bgp 65540
03   neighbor LAB peer-group
04   neighbor LAB remote-as 65541
05   neighbor LAB password t0ps3cr3t
06   neighbor 192.0.2.1 peer-group LAB
07   ...
08   address-family ipv4 unicast network 192.168.1.1/32
09   exit-address-family
10 #FRR2
11 router bgp 65541
12   neighbor LAB peer-group
13   neighbor LAB remote-as 65540
14   neighbor LAB password t0ps3cr3t
15   neighbor 192.0.2.0 peer-group LAB
16   ...
17   address-family ipv4 unicast network 192.168.2.2/32
18   exit-address-family

Now I'll walk through the configuration from Listing 3 with FRR1. In the first step, you need a BGP neighborhood. To do this, line 2 parameterizes autonomous system (AS) 65540; then, line 3 creates the LAB peer group, so you can apply the peer configuration to other BGP peers. The remote AS 65541 is used in line 4. To harden the peering, line 5 configures an MD5 password, then line 6 binds neighbor 192.0.2.1 (FRR2) to the LAB peer group, so it inherits the appropriate parameters. Once peering is in place between the routers, line 8 enters the address family and configures the host route 192.168.1.1/32 for publication.

After the configuration is complete on FRR2, you can check the peering status with

show ip bgp summary

which is familiar from classic network operating systems. To query the routes learned by BGP, type

show ip route bgp

The output shows you a host route of 192.168.2.2/32 on FRR1.

Conclusions

FRR offers a flexible routing stack for anything from lab environments to production data center networks. FRR also makes a good impression when facing Pentest-Tools for routing protocols such as Routopsy. The large number of routing protocols supported means that FRR can be integrated into many networks but with a downside: Parameterization – especially in combination with additional functions such as a network address translation – seems fragmented in some cases because of the strong dependence on the underlying kernel.

Infos