FRR is a fully featured, high performance, free software IP routing suite.
FRR implements all standard routing protocols such as BGP, RIP, OSPF, IS-IS and more (see Feature Matrix), as well as many of their extensions.
FRR is a high performance suite written primarily in C. It can easily handle full Internet routing tables and is suitable for use on hardware ranging from cheap SBCs to commercial grade routers. It is actively used in production by hundreds of companies, universities, research labs and governments.
FRR is distributed under GPLv2, with development modeled after the Linux kernel. Anyone may contribute features, bug fixes, tools, documentation updates, or anything else.
FRR is a fork of Quagga.
How to get FRR¶
The official FRR website is located at https://frrouting.org/ and contains further information, as well as links to additional resources.
Several distributions provide packages for FRR. Check your distribution’s repositories to find out if a suitable version is available.
For instructions on installing from source, refer to the developer documentation.
FRR provides IP routing services. Its role in a networking stack is to exchange routing information with other routers, make routing and policy decisions, and inform other layers of these decisions. In the most common scenario, FRR installs routing decisions into the OS kernel, allowing the kernel networking stack to make the corresponding forwarding decisions.
In addition to dynamic routing FRR supports the full range of L3 configuration, including static routes, addresses, router advertisements etc. It has some light L2 functionality as well, but this is mostly left to the platform. This makes it suitable for deployments ranging from small home networks with static routes to Internet exchanges running full Internet tables.
FRR runs on all modern *NIX operating systems, including Linux and the BSDs. Feature support varies by platform; see the Feature Matrix.
Traditional routing software is made as a one process program which provides all of the routing protocol functionalities. FRR takes a different approach. FRR is a suite of daemons that work together to build the routing table. Each major protocol is implemented in its own daemon, and these daemons talk to a middleman daemon (zebra), which is responsible for coordinating routing decisions and talking to the dataplane.
This architecture allows for high resiliency, since an error, crash or exploit in one protocol daemon will generally not affect the others. It is also flexible and extensible since the modularity makes it easy to implement new protocols and tie them into the suite. Additionally, each daemon implements a plugin system allowing new functionality to be loaded at runtime.
An illustration of the large scale architecture is given below.
+----+ +----+ +-----+ +----+ +----+ +----+ +-----+ |bgpd| |ripd| |ospfd| |ldpd| |pbrd| |pimd| |.....| +----+ +----+ +-----+ +----+ +----+ +----+ +-----+ | | | | | | | +----v-------v--------v-------v-------v-------v--------v | | | Zebra | | | +------------------------------------------------------+ | | | | | | +------v------+ +---------v--------+ +------v------+ | | | | | | | *NIX Kernel | | Remote dataplane | | ........... | | | | | | | +-------------+ +------------------+ +-------------+
All of the FRR daemons can be managed through a single integrated user interface shell called vtysh. vtysh connects to each daemon through a UNIX domain socket and then works as a proxy for user input. In addition to a unified frontend, vtysh also provides the ability to configure all the daemons using a single configuration file through the integrated configuration mode. This avoids the overhead of maintaining a separate configuration file for each daemon.
FRR is currently implementing a new internal configuration system based on YANG data models. When this work is completed, FRR will be a fully programmable routing stack.
Currently FRR supports GNU/Linux and BSD. Porting FRR to other platforms is not too difficult as platform dependent code should be mostly limited to the Zebra daemon. Protocol daemons are largely platform independent. Please let us know if you can get FRR to run on a platform which is not listed below:
Versions of these platforms that are older than around 2 years from the point of their original release (in case of GNU/Linux, this is since the kernel’s release on https://kernel.org/) may need some work. Similarly, the following platforms may work with some effort:
Recent versions of the following compilers are well tested:
- GNU’s GCC
- LLVM’s Clang
- Intel’s ICC
In General if the platform you are attempting to use is not listed above then FRR does not support being run on that platform. The only caveat here is that version 7.5 and before Solaris was supported in a limited fashion.
The following table lists all protocols cross-referenced to all operating systems that have at least CI build tests. Note that for features, only features with system dependencies are included here; if you don’t see the feature you’re interested in, it should be supported on your platform.
|Daemon / Feature||Linux||OpenBSD||FreeBSD||NetBSD|
|pbrd (Policy Routing)||Y||N||N||N|
|WAN / Carrier protocols|
|VRF / L3VPN||≥4.8 †4.3||CP||CP||CP|
|VNC (Virtual Network Control)||CP||CP||CP||CP|
|VPWS / PW||N||≥5.8||N||N|
|SSM (Source Specific)||Y||N||Y||Y|
|ASM (Any Source)||Y||N||N||N|
|EVPN BUM Forwarding||≥5.0||N||N||N|
The indicators have the following semantics:
- Y - daemon/feature fully functional
- ≥X.X - fully functional with kernel version X.X or newer
- †X.X - restricted functionality or impaired performance with kernel version X.X or newer
- CP - control plane only (i.e. BGP route server / route reflector)
- N - daemon/feature not supported by operating system
Known Kernel Issues¶
Linux < 4.11
v6 Route Replacement - Linux kernels before 4.11 can cause issues with v6 route deletion when you have ECMP routes installed into the kernel. This especially becomes apparent if the route is being transformed from one ECMP path to another.
FRR implements the following RFCs:
This list is incomplete.
- RFC 1771 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter & T. Li. March 1995.
- RFC 1965 Autonomous System Confederations for BGP. P. Traina. June 1996.
- RFC 1997 BGP Communities Attribute. R. Chandra, P. Traina & T. Li. August 1996.
- RFC 2439 BGP Route Flap Damping. C. Villamizar, R. Chandra, R. Govindan. November 1998.
- RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing. P. Marques, F. Dupont. March 1999.
- RFC 2796 BGP Route Reflection An alternative to full mesh IBGP. T. Bates & R. Chandrasekeran. June 1996.
- RFC 2842 Capabilities Advertisement with BGP-4. R. Chandra, J. Scudder. May 2000.
- RFC 2858 Multiprotocol Extensions for BGP-4. T. Bates, Y. Rekhter, R. Chandra, D.
- RFC 3107 Carrying Label Information in BGP-4. Y. Rekhter & E. Rosen. May 2001.
- RFC 3765 NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control. G.Huston, April 2001.
- RFC 4271 A Border Gateway Protocol 4 (BGP-4). Updates RFC1771. Y. Rekhter, T. Li & S. Hares. January 2006.
- RFC 4364 BGP/MPLS IP Virtual Private Networks (VPNs). Y. Rekhter. Feb 2006.
- RFC 4486 Subcodes for BGP Cease Notification Message. E. Chen, V. Gillet. April 2006.
- RFC 4659 BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN. J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur. September 2006.
- RFC 4893 BGP Support for Four-octet AS Number Space. Q. Vohra, E. Chen May 2007.
- RFC 5004 Avoid BGP Best Path Transitions from One External to Another. E. Chen & S. Sangli. September 2007 (Partial support).
- RFC 5082 The Generalized TTL Security Mechanism (GTSM). V. Gill, J. Heasley, D. Meyer, P. Savola, C. Pingnataro. October 2007.
- RFC 5575 Dissemination of Flow Specification Rules. P. Marques, N. Sheth, R. Raszuk, B. Greene, J. Mauch, D. McPherson. August 2009
- RFC 6286 Autonomous-System-Wide Unique BGP Identifier for BGP-4. E. Chen, J. Yuan, June 2011.
- RFC 6608 Subcodes for BGP Finite State Machine Error. J. Dong, M. Chen, Huawei Technologies, A. Suryanarayana, Cisco Systems. May 2012.
- RFC 6810 The Resource Public Key Infrastructure (RPKI) to Router Protocol. R. Bush, R. Austein. January 2013.
- RFC 6811 BGP Prefix Origin Validation. P. Mohapatra, J. Scudder, D. Ward, R. Bush, R. Austein. January 2013.
- RFC 7313 Enhanced Route Refresh Capability for BGP-4. K. Patel, E. Chen, B. Venkatachalapathy. July 2014.
- RFC 7606 Revised Error Handling for BGP UPDATE Messages. E. Chen, J. Scudder, P. Mohapatra, K. Patel. August 2015.
- RFC 7607 Codification of AS 0 Processing. W. Kumari, R. Bush, H. Schiller, K. Patel. August 2015.
- RFC 7611 BGP ACCEPT_OWN Community Attribute. J. Uttaro, P. Mohapatra, D. Smith, R. Raszuk, J. Scudder. August 2015.
- RFC 7999 BLACKHOLE Community. T. King, C. Dietzel, J. Snijders, G. Doering, G. Hankins. Oct 2016.
- RFC 8092 BGP Large Communities Attribute. J. Heitz, Ed., J. Snijders, Ed, K. Patel, I. Bagdonas, N. Hilliard. February 2017
- RFC 8195 Use of BGP Large Communities. J. Snijders, J. Heasley, M. Schmidt, June 2017
- RFC 8203 BGP Administrative Shutdown Communication. J. Snijders, J. Heitz, J. Scudder. July 2017.
- RFC 8212 Default External BGP (EBGP) Route Propagation Behavior without Policies. J. Mauch, J. Snijders, G. Hankins. July 2017
- RFC 8277 Using BGP to Bind MPLS Labels to Address Prefixes. E. Rosen. October 2017
- RFC 2328 OSPF Version 2. J. Moy. April 1998.
- RFC 2370 The OSPF Opaque LSA Option R. Coltun. July 1998.
- RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option P. Murphy. January 2003.
- RFC 2740 OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy. December 1999.
- RFC 3137 OSPF Stub Router Advertisement, A. Retana, L. Nguyen, R. White, A. Zinin, D. McPherson. June 2001
- RFC 2858 Multiprotocol Extensions for BGP-4. T. Bates, Y. Rekhter, R. Chandra, D. Katz. June 2000.
- RFC 4364 BGP/MPLS IP Virtual Private Networks (VPNs). Y. Rekhter. Feb 2006.
- RFC 4447 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP), L. Martini, E. Rosen, N. El-Aawar, T. Smith, and G. Heron. April 2006.
- RFC 4659 BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN. J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur. September 2006
- RFC 4762 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, M. Lasserre and V. Kompella. January 2007.
- RFC 5036 LDP Specification, L. Andersson, I. Minei, and B. Thomas. October 2007.
- RFC 5561 LDP Capabilities, B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, and JL. Le Roux. July 2009.
- RFC 5918 Label Distribution Protocol (LDP) ‘Typed Wildcard’ Forward Equivalence Class (FEC), R. Asati, I. Minei, and B. Thomas. August 2010.
- RFC 5919 Signaling LDP Label Advertisement Completion, R. Asati, P. Mohapatra, E. Chen, and B. Thomas. August 2010.
- RFC 6667 LDP ‘Typed Wildcard’ Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements, K. Raza, S. Boutros, and C. Pignataro. July 2012.
- RFC 6720 The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP), C. Pignataro and R. Asati. August 2012.
- RFC 7552 Updates to LDP for IPv6, R. Asati, C. Pignataro, K. Raza, V. Manral, and R. Papneja. June 2015.
When SNMP support is enabled, the following RFCs are also supported:
- RFC 1227 SNMP MUX protocol and MIB. M.T. Rose. May-01-1991.
- RFC 1657 Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2. S. Willis, J. Burruss, J. Chu, Editor. July 1994.
- RFC 1724 RIP Version 2 MIB Extension. G. Malkin & F. Baker. November 1994.
- RFC 1850 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. November 1995.
- RFC 2741 Agent Extensibility (AgentX) Protocol. M. Daniele, B. Wijnen. January 2000.
Italicized lists are private.
|Users & Operatorsemail@example.com|
|Technical Steering Committeefirstname.lastname@example.org|
The Development list is used to discuss and document general issues related to project development and governance. The public Slack instance and weekly technical meetings provide a higher bandwidth channel for discussions. The results of such discussions are reflected in updates, as appropriate, to code (i.e., merges), GitHub issues tracked issues, and for governance or process changes, updates to the Development list and either this file or information posted at FRR.