Special Delivery

Classic and Northbound Layer Configuration Model

The management interface is undergoing some upheaval right now between the classic configuration model and the model with a Northbound layer (highest layer in an SDN architecture) designed to improve flexibility and offer support for modern API-based configuration interfaces such as RESTCONF and NETCONF. I'll look at the classic configuration model first: the command-line interface (CLI) for FRR daemons, vtysh [5]. The shell is based on the classic NOS. If you use Cisco Internetwork Operating System (IOS), you will be able to find your way around quickly because the syntax is very similar. Cisco IOS supports a user EXEC mode as well as a privileged EXEC mode, in which you can use the configure terminal command to switch to the global configuration mode and subsequently to the interface-specific configuration modes and routing protocol configuration modes.

The vtysh CLI config tool also supports a privileged EXEC mode and a global configuration mode, as well as some more specific modes. Saving with the write memory command should also be familiar to some administrators. However, the way you store the saved startup configuration is different. Although IOS-based systems store the startup configuration in NVRAM, it requires the VTYSH integrated configuration file on FRR, which is enabled by default in the /etc/frr/vtysh.conf file. This kind of configuration operation gives you a summarized configuration file. Each daemon parses this file at startup and pulls the relevant components. Assuming a separate configuration file will be used for each daemon, you need to use the

no service integrated-vtysh-configuration

command. To check whether an integrated configuration file exists, you need to check /etc/frr/vtysh.conf. If the contents match

service integrated-vtysh-config

then an integrated configuration exists.

However, as is also currently à la mode with commercial manufacturers, the project seeks to use API-based configuration models to enable better support for network automation. The developers' goal is a completely programmable routing stack through the gradual integration of the YANG data model. For this purpose, a Northbound layer is used, to which the different configuration interfaces can then connect. Figure 3 shows an example of the old and new models; however, the entire process is still a work in progress because far-reaching changes in the source code are necessary.

Figure 3: Comparison of the classic configuration model (top) with the more modern configuration model (bottom) that includes optimizations for APIs, such as NETCONF and RESTCONF.

Variety of Dynamic Routing Protocols

FRR as a routing stack cannot be compared with a complete network operating system because it is specifically used to publish and receive IP-based routing information on the basis of supported dynamic routing protocols and parameterized policies. It also takes care of passing this information to the operating system kernel over the Netlink bus. It does not provide additional functions such as firewalling, network address translation (NAT), or quality of service (QoS). For this, you still need to rely on the functionality of the underlying operating system or third-party systems.

FRR's feature set includes a wide variety of dynamic routing protocols. It should be noted that BSD-based operating systems do not support all functions. A close look at the feature matrix [6] is also recommended for Linux because individual functions require a certain kernel version. However, if you observe the minimum kernel versions, all functions are basically available under Linux.

FRR can be used to set up static, policy-based, and dynamic routes. The dynamic routing protocols include both interior and exterior gateway routing protocols. Path-vector, distance-vector, and link-state protocols are available depending on the desired deployment scenario. BGP is one of the exterior gateway protocols, so it can also be used as an Internet edge router on corporate or provider networks.

However, BGP not only impresses on this interface, it also forms the basis for the Border Gateway Protocol Ethernet virtual private network (BGP EVPN), on which the virtual extensible local area network (VXLAN) runs as a data plane, offering the possibility of Layer 2 links between data centers across Layer 3 borders. Additionally, it can be combined with equal-cost multipathing (i.e., the simultaneous and equivalent use of several available links). Layer 2 linking is particularly interesting if virtual machines are running on the corresponding host. Provided the hypervisor you use supports it, the virtual machines can be migrated between sites without modifying the IP addresses, and it is possible without the restrictions known from the spanning tree method.

In particular, FRR can hold its own in terms of Interior Gateway Protocols (IGPs). If you take a look at the supported IGPs, you will find well-known protocols such as Routing Information Protocol (RIP) version 2 and Open Shortest Path First (OSPF) version 2 for IPv4, as well as their IPv6 derivatives RIPng and OSPFv3. Additionally, Intermediate System-to-Intermediate System (IS-IS) and OpenFabric – which was inspired by IS-IS but optimized for spine-leaf architectures in data centers – have found their way into the feature list.

The developers have also found a solution for integration into networks based on the Enhanced Interior Gateway Routing Protocol (EIGRP), which was initially proprietary to Cisco before being published in RFC7868. Support is still considered alpha according to the note on GitHub; however, I could not find any bugs in my tests. Additionally, an implementation of Babel, a distance-vector routing protocol, is optimized for wireless mesh networks. A list of supported protocols can be found online [6].

If FRR is to be used on large enterprise networks with multiprotocol label switching (MPLS), the Label Distribution Protocol (LDP) daemon can be used to distribute the MPLS labels. However, this requires additional configuration and support in the kernel. The virtual routing and forwarding (VRF) feature is also suitable for larger multitenant networks or routing isolation. Multiple routing instances exist that cannot see each other without deliberate route leaking [7]. Overlapping IP address blocks in different VRFs are possible.

Although all of the above protocols are suitable for unicast traffic, FRR also offers a solution for multicast traffic, for which a protocol-independent multicast (PIM) daemon is available. Also, FRR offers several functions to increase availability. For example, errors between routers can be detected more quickly with bidirectional forward detection (BFD). If several routers are used as the first hop, a First Hop Redundancy Protocol (FHRP) is required. FRR offers the Virtual Router Redundancy Protocol (VRRP) for this purpose. From the daemon for the Next Hop Resolution Protocol (NHRP), it is also possible to set up dynamic multipoint VPN solutions.

Installing FRRouting

You can obtain and install FRR from various sources. The most flexible, but also most complex, option is to clone the code from the official GitHub repository and then compile and install it yourself. This method gives you access to the latest releases. The more convenient, but not always completely up-to-date, option is to install from the operating system sources. I chose the latter method and installed FRR on an Ubuntu 20.04 server:

sudo apt update
sudo apt install frr
sudo vi /etc/sysctl.conf
net.ipv4.conf.all.forwarding = 1
net.ipv6.conf. all.forwarding = 1

The last two lines enable routing for IPv4 and IPv6 at the operating system level.