FRR is a routing software package that provides TCP/IP based routing services with routing protocols support such as BGP, RIP, OSPF, IS-IS and more (see Supported Protocols vs. Platform). FRR also supports special BGP Route Reflector and Route Server behavior. In addition to traditional IPv4 routing protocols, FRR also supports IPv6 routing protocols. With an SNMP daemon that supports the AgentX protocol, FRR provides routing protocol MIB read-only access (SNMP Support).
FRR uses an advanced software architecture to provide you with a high quality, multi server routing engine. FRR has an interactive user interface for each routing protocol and supports common client commands. Due to this design, you can add new protocol daemons to FRR easily. You can use FRR library as your program’s client user interface.
FRR is distributed under the GNU General Public License.
FRR is a fork of Quagga.
Today, TCP/IP networks are covering all of the world. The Internet has been deployed in many countries, companies, and to the home. When you connect to the Internet your packet will pass many routers which have TCP/IP routing functionality.
A system with FRR installed acts as a dedicated router. With FRR, your machine exchanges routing information with other routers using routing protocols. FRR uses this information to update the kernel routing table so that the right data goes to the right place. You can dynamically change the configuration and you may view routing table information from the FRR terminal interface.
Adding to routing protocol support, FRR can setup interface’s flags, interface’s address, static routes and so on. If you have a small network, or a stub network, or xDSL connection, configuring the FRR routing software is very easy. The only thing you have to do is to set up the interfaces and put a few commands about static routes and/or default routes. If the network is rather large, or if the network structure changes frequently, you will want to take advantage of FRR’s dynamic routing protocol support for protocols such as RIP, OSPF, IS-IS or BGP.
Traditionally, UNIX based router configuration is done by ifconfig and route commands. Status of routing table is displayed by netstat utility. Almost of these commands work only if the user has root privileges. FRR has a different system administration method. There are two user modes in FRR. One is normal mode, the other is enable mode. Normal mode user can only view system status, enable mode user can change system configuration. This UNIX account independent feature will be great help to the router administrator.
Currently, FRR supports common unicast routing protocols, that is BGP, OSPF, RIP and IS-IS. Upcoming for MPLS support, an implementation of LDP is currently being prepared for merging. Implementations of BFD and PIM-SSM (IPv4) also exist, but are not actively being worked on.
The ultimate goal of the FRR project is making a production-grade, high quality, featureful and free IP routing software suite.
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. There is a daemon for each major supported protocol as well as a middleman daemon (Zebra) which serves as the broker between these daemons and the kernel.
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.
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 | | ........... |
| | | | | |
+-------------+ +------------------+ +-------------+
The multi-process architecture brings extensibility, modularity and maintainability. At the same time it also brings many configuration files and terminal interfaces. Each daemon has its own configuration file and terminal interface. When you configure a static route, it must be done in the Zebra configuration file. When you configure BGP network it must be done in the bgpd configuration file. This can become difficult to manage. To resolve the problem, FRR provides integrated user interface shell called vtysh. vtysh connects to each daemon with UNIX domain socket and then works as a proxy for user input.
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:
The following table lists all protocols cross-refrenced to all operating systems that have at least CI build tests. Note that for features, only features with system dependencies are included here.
Daemon / Feature | Linux | OpenBSD | FreeBSD | NetBSD | Solaris |
---|---|---|---|---|---|
FRR Core | |||||
zebra | Y | Y | Y | Y | Y |
VRF | ≥4.8 | N | N | N | N |
MPLS | ≥4.5 | Y | N | N | N |
pbrd (Policy Routing) | Y | N | N | N | N |
WAN / Carrier protocols | |||||
bgpd (BGP) | Y | Y | Y | Y | Y |
VRF / L3VPN | ≥4.8 †4.3 | CP | CP | CP | CP |
EVPN | ≥4.18 †4.9 | CP | CP | CP | CP |
VNC (Virtual Network Control) | CP | CP | CP | CP | CP |
Flowspec | CP | CP | CP | CP | CP |
ldpd (LDP) | ≥4.5 | Y | N | N | N |
VPWS / PW | N | ≥5.8 | N | N | N |
VPLS | N | ≥5.8 | N | N | N |
nhrpd (NHRP) | Y | N | N | N | N |
Link-State Routing | |||||
ospfd (OSPFv2) | Y | Y | Y | Y | Y |
Segment Routing | ≥4.12 | N | N | N | N |
ospf6d (OSPFv3) | Y | Y | Y | Y | Y |
isisd (IS-IS) | Y | Y | Y | Y | Y |
Distance-Vector Routing | |||||
ripd (RIPv2) | Y | Y | Y | Y | Y |
ripngd (RIPng) | Y | Y | Y | Y | Y |
babeld (BABEL) | Y | Y | Y | Y | Y |
eigrpd (EIGRP) | Y | Y | Y | Y | Y |
Multicast Routing | |||||
pimd (PIM) | ≥4.18 | N | Y | Y | Y |
SSM (Source Specific) | Y | N | Y | Y | Y |
ASM (Any Source) | Y | N | N | N | N |
The indicators have the following semantics:
FRR implements the following RFCs:
Note
This list is incomplete.
When SNMP support is enabled, the following RFCs are also supported:
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.
Italicized lists are private.
Topic | List |
---|---|
Development | dev@lists.frrouting.org |
Users & Operators | frog@lists.frrouting.org |
Announcements | announce@lists.frrouting.org |
Security | security@lists.frrouting.org |
Technical Steering Committee | tsc@lists.frrouting.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.
For information on reporting bugs, please see Reporting Bugs.