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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Routing with Quagga

    Cisco and Juniper have implemented routing protocols to help your router find the optimum path. On Linux, you can use software like Quagga, with its Zebra daemon, to help automate this process.

  • Creating a redundant array of inexpensive links
    The Fault Tolerant Router daemon uses multipath routing among multiple Internet connections to keep you connected, even when some connections go down.
  • Open source multipoint VPN with VyOS
    The VyOS Linux distribution puts network routing, firewall, and VPN functionality together and presents a fully working dynamic multipoint VPN router as an alternative or addition to a Cisco DMVPN mesh.
  • Autoconfiguring IPv6 Clients

    Most clients on a network need both an address and some environmental information such as a name server or a web proxy. This article investigates whether a recent operating system on an IPv6-only LAN can handle this.

  • Layer 3 SDN
    Calico chooses an unusual approach for software-defined networking, relying on open standards like BGP. We look at the distinctions and advantages of Calico.
comments powered by Disqus