CentOS 7
This document describes installation from source. If you want to build an RPM, see Packaging Red Hat .
CentOS 7 restrictions:
- MPLS is not supported on CentOS 7 with default kernel. MPLS requires Linux Kernel 4.5 or higher (LDP can be built, but may have limited use without MPLS)
Install required packages
sudo yum install git autoconf automake libtool make \ readline-devel texinfo net-snmp-devel groff pkgconfig \ json-c-devel pam-devel bison flex pytest c-ares-devel \ python-devel python-sphinx libcap-devel \ elfutils-libelf-devel libunwind-devel protobuf-c-devel
The libunwind library is optional but highly recommended, as it improves backtraces printed for crashes and debugging. However, if it is not available for some reason, it can simply be left out without any loss of functionality.
FRR depends on the relatively new libyang library to provide YANG/NETCONF support. Unfortunately, most distributions do not yet offer a libyang package from their repositories. Therefore we offer two options to install this library.
Option 1: Binary Install
The FRR project builds some binary libyang packages.
RPM packages are at our RPM repository.
DEB packages are available as CI artifacts here.
libyang version 2.0.0 or newer is required to build FRR, version 2.1.128 or newer is recommended.
The libyang development packages need to be installed in addition to the libyang core package in order to build FRR successfully. Make sure to download and install those from the link above alongside the binary packages.
Depending on your platform, you may also need to install the PCRE development package. Typically this is libpcre2-dev or pcre2-devel .
Option 2: Source Install
Ensure that the libyang build requirements are met before continuing. Usually this entails installing cmake and libpcre2-dev or pcre2-devel .
git clone https://github.com/CESNET/libyang.git cd libyang git checkout v2.1.128 mkdir build; cd build cmake -D CMAKE_INSTALL_PREFIX:PATH=/usr \ -D CMAKE_BUILD_TYPE:String="Release" .. make sudo make install
Get FRR, compile it and install it (from Git)
This assumes you want to build and install FRR from source and not using any packages
Add frr groups and user
sudo groupadd -g 92 frr sudo groupadd -r -g 85 frrvty sudo useradd -u 92 -g 92 -M -r -G frrvty -s /sbin/nologin \ -c "FRR FRRouting suite" -d /var/run/frr frr
Download Source, configure and compile it
(You may prefer different options on configure statement. These are just an example.)
git clone https://github.com/frrouting/frr.git frr cd frr ./bootstrap.sh ./configure \ --bindir=/usr/bin \ --sbindir=/usr/lib/frr \ --sysconfdir=/etc/frr \ --libdir=/usr/lib/frr \ --libexecdir=/usr/lib/frr \ --localstatedir=/var/run/frr \ --with-moduledir=/usr/lib/frr/modules \ --enable-snmp=agentx \ --enable-multipath=64 \ --enable-user=frr \ --enable-group=frr \ --enable-vty-group=frrvty \ --disable-ldpd \ --enable-fpm \ --with-pkg-git-version \ --with-pkg-extra-version=-MyOwnFRRVersion \ SPHINXBUILD=/usr/bin/sphinx-build make make check sudo make install
Create empty FRR configuration files
sudo mkdir /var/log/frr sudo mkdir /etc/frr sudo touch /etc/frr/zebra.conf sudo touch /etc/frr/bgpd.conf sudo touch /etc/frr/ospfd.conf sudo touch /etc/frr/ospf6d.conf sudo touch /etc/frr/isisd.conf sudo touch /etc/frr/ripd.conf sudo touch /etc/frr/ripngd.conf sudo touch /etc/frr/pimd.conf sudo touch /etc/frr/nhrpd.conf sudo touch /etc/frr/eigrpd.conf sudo touch /etc/frr/babeld.conf sudo chown -R frr:frr /etc/frr/ sudo touch /etc/frr/vtysh.conf sudo chown frr:frrvty /etc/frr/vtysh.conf sudo chmod 640 /etc/frr/*.conf
Install daemon config file
sudo install -p -m 644 tools/etc/frr/daemons /etc/frr/ sudo chown frr:frr /etc/frr/daemons
Edit /etc/frr/daemons as needed to select the required daemons
Look for the section with watchfrr_enable=. and zebra=. etc. Enable the daemons as required by changing the value to yes
Enable IP & IPv6 forwarding
Create a new file /etc/sysctl.d/90-routing-sysctl.conf with the following content:
# Sysctl for routing # # Routing: We need to forward packets net.ipv4.conf.all.forwarding=1 net.ipv6.conf.all.forwarding=1
Load the modified sysctl’s on the system:
sudo sysctl -p /etc/sysctl.d/90-routing-sysctl.conf
Install frr Service
sudo install -p -m 644 tools/frr.service /usr/lib/systemd/system/frr.service
Register the systemd files
sudo systemctl preset frr.service
Enable required frr at startup
sudo systemctl enable frr
Reboot or start FRR manually
sudo systemctl start frr
© Copyright 2017, FRR. Revision 482f082a .
Introduction
So I had this idea when looking at FRRouting. As it’s a Linux package, you can install it on a box running KVM/Libvirt, then you can enable BGP and redistribute the connected networks. This makes spinning up new virtual networks on the hypervisor very easy as you do not need to rely on static routes and as soon as you spin up a new virtual network it’s advertising to the rest of your network.
What is FRRouting (FRR)
FRRouting (FRR) is a fork of Quagga. It’s used in Cumulus networks OS as the routing suite.
This guide is based on an install of CentOS 7.5.
Step 1 Install FRR
Install the latest FRR rpm from https://github.com/FRRouting/frr/releases.
yum install -y https://github.com/FRRouting/frr/releases/download/frr-5.0.1/frr-5.0.1-2018070501.el7.centos.x86_64.rpm
Edit the daemons file and change the routing protocols you want from no to yes (you must always enable zebra) in this case zebra and bgpd.
vi /etc/frr/daemons
Start FRR and set to start on boot.
systemctl enable frr && systemctl start frr
Check status of FRR — should show as active (running).
systemctl status frr
Step 2 configure FRR and BGP
open the FRR shell by typing the command.
vtysh
Enter configuration mode.
This step is optional this command puts all the FRR configuration into one file.
service integrated-vtysh-config
Configure BGP on the KVM host.
I am configuring a route-map used to prevent some routes from being redistributed also will tag a BGP community for all the permitted routes you do not need to do this but it gives you more control and tagging the route helps with visibility.
ip prefix-list PL_BGP_DENY_CONNECTED seq 5 permit 10.25.10.0/24
route-map RM_BGP_REDISTRIBUTED_CONNECTED deny 10
match ip address prefix-list PL_BGP_DENY_CONNECTED
route-map RM_BGP_REDISTRIBUTED_CONNECTED permit 9999
set community 65010:10100
Here we are configuring the BGP process AS/router id/tuning the timers from the default to 2/6 and configuring the neighbour.
router bgp 65010
bgp router-id 10.25.10.100
bgp log-neighbor-changes
timers bgp 2 6
neighbor 10.25.10.1 remote-as 65000
Now to configure the redistribute connected command and set the route map we have created.
address-family ipv4 unicast
redistribute connected route-map RM_BGP_REDISTRIBUTED_CONNECTED
exit-address-family
Exit and save the configuration.
Step 3 Verify BGP is up and that we have routes
Here we can see that the BGP session is up.
Below we can see that have two connected virtual networks in BGP and are receiving a default route from the router we are connected to.
Building a Networking Virtual Lab part 3: Install Vagrant on CentOS 7
Introduction This is part three of Building a Networking Virtual Lab. Vagrant can be used to build a virtual lab on top of KVM/Libvirt. Step 1 Vagrant CentOS packages to install Install the latest Vagrant rpm from https://releases.hashicorp.com/vagrant/. yum install -y https://releases.hashicorp.com/
Feb 26, 2018 1 min read
Building a Networking Virtual Lab part 2: Install VNC with XFCE on CentOS 7
Introduction This is part two of Building a Networking Virtual Lab. VNC can be used to manage your Hypervisor via the Virtual Machine Manager GUI. Step 1 Install VNC/XFCE CentOS packages yum install epel-release –y yum groupinstall xfce -y yum install tigervnc-server -y yum -y groupinstall X11 -y Step
Feb 26, 2018 1 min read
Building a Networking Virtual Lab part 1: Install KVM/Libvirt on CentOS 7
Introduction I have split this guide into three parts. Part one deals with installing KVM/Libvirt. Part two installs VNC to connect to your remote host to use Virtual Machine Manager (VMM), Useful if you are accessing the hypervisor via a Windows or Mac computer, Linux has an installable version
Installation
This section covers the basics of building, installing and setting up FRR.
From Packages
The project publishes packages for Red Hat, Centos, Debian and Ubuntu on the GitHub releases. page. External contributors offer packages for many other platforms including *BSD, Alpine, Gentoo, Docker, and others. There is currently no documentation on how to use those but we hope to add it soon.
From Snapcraft
In addition to traditional packages the project also builds and publishes universal Snap images, available at https://snapcraft.io/frr.
From Source
Building FRR from source is the best way to ensure you have the latest features and bug fixes. Details for each supported platform, including dependency package listings, permissions, and other gotchas, are in the developer’s documentation. This section provides a brief overview on the process.
Getting the Source
FRR’s source is available on the project GitHub page.
git clone https://github.com/FRRouting/frr.git
When building from Git there are several branches to choose from. The master branch is the primary development branch. It should be considered unstable. Each release has its own branch named stable/X.X , where X.X is the release version.
In addition, release tarballs are published on the GitHub releases page here.
Build Configuration
FRR has an excellent configure script which automatically detects most host configurations. There are several additional configure options to customize the build to include or exclude specific features and dependencies.
First, update the build system. Change into your FRR source directory and issue:
./bootstrap.sh
This will install any missing build scripts and update the Autotools configuration. Once this is done you can move on to choosing your configuration options from the list below.
Enable the alternate malloc library. In some cases this is faster and more efficient, in some cases it is not.
Do not build any documentation, including this one.
From the documentation build html docs as well in addition to the normal output.
Do not build zebra daemon. This generally only be useful in a scenario where you are building bgp as a standalone server.
Do not build ripd.
Do not build ripngd.
Do not build ospfd.
Do not build ospf6d.
Do not build bgpd.
Do not build ldpd.
Do not build nhrpd.
Do not build eigrpd.
Do not build babeld.
Do not build watchfrr. Watchfrr is used to integrate daemons into startup/shutdown software available on your machine. This is needed for systemd integration, if you disable watchfrr you cannot have any systemd integration.
Build with all warnings converted to errors as a compile option. This is recommended for developers only.
Turn off building of pimd. On some BSD platforms pimd will not build properly due to lack of kernel support.
Turn off building of vrrpd. Linux is required for vrrpd support; other platforms are not supported.
Turn off building of pbrd. This daemon currently requires linux in order to function properly.
Turn on building of sharpd. This daemon facilitates testing of FRR and can also be used as a quick and easy route generator.
Do not build staticd. This daemon is necessary if you want static routes.
Do not build bfdd.
Make bgpd which does not make bgp announcements at all. This feature is good for using bgpd as a BGP announcement listener.
Turn off bgpd’s ability to use VNC.
Turn off BGP BMP support
This option is deprecated as it is superseded by the -F (profile) command line option which allows adjusting the setting at startup rather than compile time.
Enable system defaults to work as if in a Data Center. See defaults.h for what is changed by this configure option.
Enable SNMP support. By default, SNMP support is disabled.
Disable support for OSPF-API, an API to interface directly with ospfd. OSPF-API is enabled if –enable-opaque-lsa is set.
Disable installation of the python ospfclient and building of the example OSPF-API client.
Do not build isisd.
Do not build fabricd.
Enable IS-IS topology generator.
Enable the support of Linux Realms. Convert tag values from 1-255 into a realm value when inserting into the Linux kernel. Then routing policy can be assigned to the realm. See the tc man page. This option is currently not compatible with the usage of nexthop groups in the linux kernel itself.
Disable IRDP server support. This is enabled by default if we have both struct in_pktinfo and struct icmphdr available to us.
Disable support IPV6 router advertisement in zebra.
Pass the -rdynamic option to the linker driver. This is in most cases necessary for getting usable backtraces. This option defaults to on if the compiler is detected as gcc, but giving an explicit enable/disable is suggested.
Controls backtrace support for the crash handlers. This is autodetected by default. Using the switch will enforce the requested behaviour, failing with an error if support is requested but not available. On BSD systems, this needs libexecinfo, while on glibc support for this is part of libc itself.
Turn on some options for compiling FRR within a development environment in mind. Specifically turn on -g3 -O0 for compiling options and add inclusion of grammar sandbox.
Build without SNMP support.
Build without VTYSH.
Build with FPM module support.
Set timeout value for FRR service. The time of restarting or reloading FRR service should not exceed this value. This number can be from 0-999. Additionally if this parameter is not passed or setting X = 0, FRR will take default value: 2 minutes.
Alpine Linux does not allow non-numeric characters in the version string. With this option, we provide a way to strip out these characters for APK dev package builds.
Remove the “configuerd with” field that has all of the build configuration arguments when reporting the version string in show version command.
Add extra version field, for packagers/distributions
Add git information to MOTD and build version string
Compile FRR with up to X way ECMP supported. This number can be from 0-999. For backwards compatibility with older configure options when setting X = 0, we will build FRR with 64 way ECMP. This is needed because there are hardcoded arrays that FRR builds towards, so we need to know how big to make these arrays at build time. Additionally if this parameter is not passed in FRR will default to 16 ECMP.
Turn on the ability of FRR to access some shell options( telnet/ssh/bash/etc. ) from vtysh itself. This option is considered extremely unsecure and should only be considered for usage if you really really know what you are doing. This option is deprecated and will be removed on Feb 1, 2024.
Code coverage reports from gcov require adjustments to the C and LD flags. With this option, gcov instrumentation is added to the build and coverage reports are created during execution. The check-coverage make target is also created to ease report uploading to codecov.io. The upload requires the COMMIT (git hash) and TOKEN (codecov upload token) environment variables be set.
Build with configuration rollback support. Requires SQLite3.
Build the ConfD northbound plugin. Look for the libconfd libs and headers in dir .
Build the Sysrepo northbound plugin.
Enable the gRPC northbound plugin.
Enable the ZeroMQ handler.
Use libpam for PAM support in vtysh.
Turn on the usage of PCRE Posix libs for regex functionality.
Turn on the usage of PCRE2 Posix libs for regex functionality.
Set hardcoded rpaths in the executable [default=yes].
Enable Lua scripting [default=no].
You may specify any combination of the above options to the configure script. By default, the executables are placed in /usr/local/sbin and the configuration files in /usr/local/etc . The /usr/local/ installation prefix and other directories may be changed using the following options to the configuration script.
Enable the creation of a .ccls file in the top level source directory.
Some development environments (e.g., LSP server within emacs, et al.) can utilize ccls to provide highly sophisticated IDE features (e.g., semantically accurate jump-to definition/reference, and even code refactoring). The –enable-ccls causes configure to generate a configuration for the ccls command, based on the configured FRR build environment.
—prefix
Install architecture-independent files in prefix [/usr/local].
Look for configuration files in dir [ prefix /etc]. Note that sample configuration files will be installed here.
Configure zebra to use dir for local state files, such as pid files and unix sockets.
Look for Lua scripts in dir [ prefix /etc/frr/scripts].
Look for YANG modules in dir [ prefix /share/yang]. Note that the FRR YANG modules will be installed here.
Set StrongSWAN vici interface socket path [/var/run/charon.vici].
The former —enable-systemd option does not exist anymore. Support for systemd is now always available through built-in functions, without depending on libsystemd.
Python dependency, documentation and tests
FRR’s documentation and basic unit tests heavily use code written in Python. Additionally, FRR ships Python extensions written in C which are used during its build process.
To this extent, FRR needs the following:
- an installation of CPython, preferably version 3.2 or newer (2.7 works but is end of life and will stop working at some point.)
- development files (mostly headers) for that version of CPython
- an installation of sphinx for that version of CPython, to build the documentation
- an installation of pytest for that version of CPython, to run the unit tests
The sphinx and pytest dependencies can be avoided by not building documentation / not running make check , but the CPython dependency is a hard dependency of the FRR build process (for the clippy tool.)
Least-Privilege Support
Additionally, you may configure zebra to drop its elevated privileges shortly after startup and switch to another user. The configure script will automatically try to configure this support. There are three configure options to control the behaviour of FRR daemons.
Switch to user user shortly after startup, and run as user `user in normal operation.
Switch real and effective group to group shortly after startup.
Create Unix Vty sockets (for use with vtysh) with group ownership set to group . This allows one to create a separate group which is restricted to accessing only the vty sockets, hence allowing one to delegate this group to individual users, or to run vtysh setgid to this group.
The default user and group which will be configured is ‘frr’ if no user or group is specified. Note that this user or group requires write access to the local state directory (see —localstatedir ) and requires at least read access, and write access if you wish to allow daemons to write out their configuration, to the configuration directory (see —sysconfdir ).
On systems which have the ‘libcap’ capabilities manipulation library (currently only Linux), FRR will retain only minimal capabilities required and will only raise these capabilities for brief periods. On systems without libcap, FRR will run as the user specified and only raise its UID to 0 for brief periods.
Linux Notes
There are several options available only to GNU/Linux systems. If you use GNU/Linux, make sure that the current kernel configuration is what you want. FRR will run with any kernel configuration but some recommendations do exist.
CONFIG_NETLINK
Kernel/User Netlink socket. This enables an advanced interface between the Linux kernel and zebra ( Kernel Interface ).
CONFIG_RTNETLINK
This makes it possible to receive Netlink routing messages. If you specify this option, zebra can detect routing information updates directly from the kernel ( Kernel Interface ).
CONFIG_IP_MULTICAST
This option enables IP multicast and should be specified when you use ripd ( RIP ) or ospfd ( OSPFv2 ) because these protocols use multicast.
Linux sysctl settings and kernel modules
There are several kernel parameters that impact overall operation of FRR when using Linux as a router. Generally these parameters should be set in a sysctl related configuration file, e.g., /etc/sysctl.conf on Ubuntu based systems and a new file /etc/sysctl.d/90-routing-sysctl.conf on Centos based systems. Additional kernel modules are also needed to support MPLS forwarding.
IPv4 and IPv6 forwarding
The following are set to enable IP forwarding in the kernel:
net.ipv4.conf.all.forwarding=1 net.ipv6.conf.all.forwarding=1
MPLS forwarding
Basic MPLS support was introduced in the kernel in version 4.1 and additional capability was introduced in 4.3 and 4.5. For some general information on Linux MPLS support, see https://www.netdevconf.org/1.1/proceedings/slides/prabhu-mpls-tutorial.pdf. The following modules should be loaded to support MPLS forwarding, and are generally added to a configuration file such as /etc/modules-load.d/modules.conf :
# Load MPLS Kernel Modules mpls_router mpls_iptunnel
The following is an example to enable MPLS forwarding in the kernel, typically by editing /etc/sysctl.conf :
# Enable MPLS Label processing on all interfaces net.mpls.conf.eth0.input=1 net.mpls.conf.eth1.input=1 net.mpls.conf.eth2.input=1 net.mpls.platform_labels=100000
Make sure to add a line equal to net.mpls.conf..input for each interface ‘’ used with MPLS and to set labels to an appropriate value.
VRF forwarding
Kernel support for VRFs was introduced in 4.3, but there are known issues in versions up to 4.15 (for IPv4) and 5.0 (for IPv6). The FRR CI system doesn’t perform VRF tests on older kernel versions, and VRFs may not work on them. If you experience issues with VRF support, you should upgrade your kernel version.
Building
Once you have chosen your configure options, run the configure script and pass the options you chose:
./configure \ --prefix=/usr \ --localstatedir=/var/run/frr \ --sbindir=/usr/lib/frr \ --sysconfdir=/etc/frr \ --enable-pimd \ --enable-watchfrr \ .
After configuring the software, you are ready to build and install it in your system.
make && sudo make install
If everything finishes successfully, FRR should be installed. You should now skip to the section on Basic Setup .
© Copyright 2017, FRR. Revision 482f082a .
frr (FRRouting)
BGP/OSPFv2/OSPFv3/ISIS/RIP/RIPng/PIM routing daemon FRRouting (FRR) is free software which manages TCP/IP based routing protocols. It supports BGP4, BGP4+, OSPFv2, OSPFv3, IS-IS, RIPv1, RIPv2, RIPng, PIM, LDP, EIGRP, Babel, BFD, Policy Routing, as well as the IPv6 versions of these. FRRouting (frr) is a fork of Quagga.
Details for frr (FRRouting)
License
- GPL-2.0+
Last updated
- 14 January 2023 — latest/stable
- 14 January 2023 — latest/stable