This section provides an overview of configuring FRRouting, the routing software package that provides a suite of routing protocols so you can configure routing on your switch.
FRRouting does not start by default in Cumulus Linux. Before you run FRRouting, make sure all you have enabled relevant daemons that you intend to use —
pimd — in the
Cumulus Networks has not tested RIP, RIPv6, IS-IS and Babel.
Before you start FRRouting, you need to enable the corresponding daemons. Edit the
/etc/frr/daemons file and set to yes each daemon you are enabling. For example, to enable BGP, set both
bgpd to yes:
Enable and Start FRRouting
Once you enable the appropriate daemons, then you need to enable and start the FRRouting service.
All the routing protocol daemons (
pimd) are dependent on
zebra. When you start
systemd determines whether
zebra is running; if
zebra is not running, it starts
zebra, then starts the dependent service, such as
In general, if you restart a service, its dependent services also get restarted. For example, running
systemctl restart frr.service restarts any of the routing protocol daemons that are enabled and running.
For more information on the
systemctl command and changing the state of daemons, read Managing Application Daemons.
By default in Cumulus Linux, FRRouting saves the configuration of all daemons in a single integrated configuration file,
You can disable this mode by running the following command in the
vtysh FRRouting CLI:
To enable the integrated configuration file mode again, run:
If you disable the integrated configuration mode, FRRouting saves each daemon-specific configuration file in a separate file. At a minimum for a daemon to start, that daemon must be enabled and its daemon-specific configuration file must be present, even if that file is empty.
You save the current configuration by running:
write fileinstead of
When the integrated configuration mode disabled, the output looks like this:
Restore the Default Configuration
If you need to restore the FRRouting configuration to the default running configuration, you need to delete the
frr.conf file and restart the
frr service. You should back up
frr.conf (or any configuration files you may remove, see the note below) before proceeding.
service integrated-vtysh-configis enabled:
If for some reason you disabled
service integrated-vtysh-config, then you should remove all the configuration files (such as
ospf6d.conf) instead of
frr.conf in step 2 above.
Interface IP Addresses and VRFs
FRRouting inherits the IP addresses and any associated routing tables for the network interfaces from the
/etc/network/interfaces file. This is the recommended way to define the addresses; do not create interfaces using FRRouting. For more information, see Configuring IP Addresses and Virtual Routing and Forwarding - VRF.
FRRouting vtysh Modal CLI
FRRouting provides a CLI –
vtysh – for configuring and displaying the state of the protocols. It is invoked by running:
vtysh provides a Cisco-like modal CLI, and many of the commands are similar to Cisco IOS commands. By modal CLI, we mean that there are different modes to the CLI, and certain commands are only available within a specific mode. Configuration is available with the
configure terminal command, which is invoked thus:
The prompt displays the mode the CLI is in. For example, when the interface-specific commands are invoked, the prompt changes to:
When the routing protocol specific commands are invoked, the prompt changes to:
At any level, ”?” displays the list of available top-level commands at that level:
?-based completion is also available to see the parameters that a command takes:
Displaying state can be done at any level, including the top level. For example, to see the routing table as seen by
zebra, you use:
To run the same command at a config level, you prepend
do to it:
Running single commands with
vtysh is possible using the
-c option of
Running a command multiple levels down is done thus:
Notice that the commands also take a partial command name (for example,
sh ip route above) as long as the partial command name is not aliased:
A command or feature can be disabled in FRRouting by prepending the command with
no. For example:
The current state of the configuration can be viewed using the
show running-config command:
If you attempt to configure a routing protocol that has not been started,
vtysh silently ignores those commands.
Alternately, if you do not want to use a modal CLI to configure FRRouting, you can use a suite of Cumulus Linux-specific commands instead.
Reload the FRRouting Configuration
If you make a change to your routing configuration, you need to reload FRRouting so your changes take place. FRRouting reload enables you to apply only the modifications you make to your FRRouting configuration, synchronizing its running state with the configuration in
/etc/frr/frr.conf. This is useful for optimizing automation of FRRouting in your environment or to apply changes made at runtime.
FRRouting reload only applies to an integrated service configuration, where your FRRouting configuration is stored in a single
frr.conf file instead of one configuration file per FRRouting daemon (like
To reload your FRRouting configuration after you've modified
Examine the running configuration and verify that it matches the config in
If the running configuration is not what you expected, submit a support request and supply the following information:
- The current running configuration (run
net show configurationand output the contents to a file)
- The contents of
- The contents of
By default, Cumulus Linux configures FFR with syslog severity level 6 (informational). Log output is written to the
To write debug messages to the log file, you must run the
log syslog debug command to configure FRR with syslog severity 7 (debug); otherwise, when you issue a debug command such as,
debug bgp neighbor-events, no output is sent to
However, when you manually define a log target with the
log file /var/log/frr/debug.log command, FRR automatically defaults to severity 7 (debug) logging and the output is logged to
In FRRouting, Cumulus Linux stores obfuscated passwords for BGP and OSPF (ISIS, OSPF area, and BGP neighbor passwords). All passwords in configuration files and those displayed in show commands are obfuscated. The obfuscation algorithm protects passwords from casual viewing. The system can retrieve the original password when needed.
If you change the hostname, either through NCLU or with the
hostname command in
vtysh, the switch can have two hostnames in the FRR configuration. For example:
Accidentally configuring the same numbered BGP neighbor using both the
neighbor x.x.x.x and
neighbor swp# interface commands results in two neighbor entries being present for the same IP in the configuration and operationally. You can correct this issue by updating the configuration and restarting the FRR service.