In the open networking industry, there are often opportunities to innovate or optimize technology that can then be used by others in the open community at large. FRRouting is exactly that. As an open source software designed by Cumulus Networks and other contributors, FRRouting (FRR) was created to streamline the routing protocol stack and to make engineers’ lives that much easier. Because of FRR’s enhanced flexibility, we've leveraged it in the connectivity component of NetQ. Read on as we go into detail about what FRR is, how it was developed and how it is used in Cumulus Networks' NetQ.
What is FRRouting?
FRRouting was developed by a group of contributing companies in the open networking space. It is an IP routing protocol suite for Unix and Linux platforms. FRR includes protocol daemons for BGP, IS-IS, LDP, OSPF, PIM, and RIP.
It is also a key component of Cumulus Networks' NetQ to help ensure that BGP unnumbered can run on the host, allowing for advertising and addressing services directly on the host.
Since the FRR open source project was forked from Quagga, another routing protocol suite for Linux, FRR includes the fundamentals that made Quagga so popular as well as many enhancements that greatly improve on that foundation.
The benefits of FRRouting
FRR was created to provide layer 3 connectivity throughout a data center, from the spine switches and leaf switches all the way down to hosts, virtual machines and containers. It is designed to streamline the routing protocol stack.
Businesses can use FRR for connecting hosts, virtual machines, and containers to the network; advertising network service endpoints; network switching and routing; and Internet access/peering routers.
- Simplified, modern data center design
- Subnet freedom and mobility
- Enhanced redundancy and flexibility
- Stateless load balancing with anycast
FRR contributions to the Linux community
The FRRouting project was a collaborative project with contributors including 6WIND, Architecture Technology Corporation, Big Switch Networks, Cumulus Networks, LabN Consulting, NetDEF (OpenSourceRouting), Orange, Volta Networks and others.
These same contributors developed many new innovations to the protocol including, as detailed in the Linux Foundation blog:
- 32-bit route tags were added to BGP and OSPFv2/v3, improving route policy maintenance and increasing interoperability in multivendor environments.
- Update-groups and nexthop tracking enable BGP to scale to ever-increasing environments.
- BGP add-path provides users with the ability to advertise service reachability in richly connected networks.
- The addition of RFC 5549 to BGP provides IPv4 connectivity using IPv6 native infrastructure, enabling customers to build IPv6-centric networks.
- Virtual routing and forwarding (VRF) enables BGP users to operate isolated routing domains such as those used by web application infrastructures, hosting providers, and Internet service providers.
- EVPN type 5 routes allow customers with layer 2 data centers to exchange subnet information using BGP EVPN.
- PIM-SM and MSDP enable enterprise applications that rely on IP multicast to use FRR.
- Static LSPs along with LDP enable architects to use MPLS to engineer network data flow.
- An overhaul of the CLI infrastructure and new unit test infrastructure improves the ongoing development and quality of FRR.
- Enabling IETF NVO3 network virtualization control allows users to build standards-based interoperable network virtualization overlays.
- The protocol additions above are augmented by SnapCraft packaging and support for JSON outputs, both of which improve the operationalization of FRR.
FRR in NetQ
FRR is used in the connectivity piece of the Cumulus Networks NetQ in order to enable BGP unnumbered and OSPF on the host. Using FRR as its routing suite, NetQ works together with another piece of software from Cumulus Networks to advertise containers into the routed fabric. This connectivity technology works in concert with Docker Engine and FRR, listening to the Docker Engine events stream and advertising and withdrawing individual container IP addresses from the routed fabric built by FRR.
The result greatly simplifies automation and the use of unnumbered interfaces to ease addressing, connectivity and the announcement of services through software — all without manually configuring complex protocols. FRR can be deployed either as a bare metal application or inside a container for maximum deployment flexibility.
To learn more about the FRRouting project, check out their website.