Routing on the Host has been replaced by Host Pack. Please read the Host Pack user guide instead.

This section provides an overview of configuring Cumulus Quagga, the Cumulus Networks-enhanced version of the Quagga routing software package that provides a suite of routing protocols so you can configure Routing on the Host — routing directly to your server hosts or in containers.

All BFD (bidirectional forwarding detection) and PTM (Prescriptive Topology Manager) commands do not work on server hosts because PTM is not enabled on the host.

Contents

 (Click to expand)

Configuration Files

At startup, Quagga reads a set of files to determine the startup configuration.The files and what they contain are specified below:

FileDescription
Quagga.confThe default, integrated, single configuration file for all quagga daemons.
daemonsContains the list of quagga daemons that must be started.
zebra.confConfiguration file for the zebra daemon.
ospfd.confConfiguration file for the OSPFv2 daemon.
ospf6d.confConfiguration file for the OSPFv3 daemon.
bgpd.confConfiguration file for the BGP daemon.
ripd.confConfiguration file for the RIP daemon. Cumulus Networks has not tested RIP.
ripngd.confConfiguration file for the IPv6 RIP daemon. Cumulus Networks has not tested RIPv6.
isisd.confConfiguration file for the IS-IS daemon. Cumulus Networks has not tested IS-IS.

The individual configuration files are not present unless you disable integrated-vtysh-config; see below for details.

Configuring Cumulus Quagga

Cumulus Quagga does not start by default. Before you run Cumulus Quagga, make sure all you have enabled relevant daemons that you intend to use — zebrabgpdospfdospf6dripdripngdisisd — in the /etc/quagga/daemons file.

The zebra daemon must always be enabled. The others you can enable according to how you plan to route your network — using BGP for example, instead of OSPF.

Before you start Cumulus Quagga, you need to enable the corresponding daemons (remember, you must always enable zebra). Edit /etc/quagga/daemons and set to yes each daemon you are enabling. For example, to start bgpd, you need to enable the zebra and bgpd daemons.

zebra=yes (* this one is mandatory to bring the others up)
bgpd=yes
ospfd=no
ospf6d=no
ripd=no
ripngd=no
isisd=no

In the containerized image, the zebra, bgpd, ospfd and ospf6d daemons are enabled by default. If you only intend to use BGP, for example, you will need to disable the two OSPF daemons. To disable any of these daemons, create a daemons file on the server host and enable only the daemons you intend to use in the container (remember, zebra must always be enabled). Then copy the daemons file to the container (named Quagga in the example below) by running:

vagrant@server02:~$ sudo docker cp daemons Quagga:/etc/quagga/daemons

After you copy the file to the container, start Cumulus Quagga, as described below.

Starting Quagga

On a Cumulus Linux switch or Ubuntu 16.04 host, run this command:

cumulus@switch:~$ sudo systemctl start quagga

On an Ubuntu 14.04 or 12.04 host, run this command:

root@host:~# service quagga start

For a Docker container, on the host, run:

root@host:~# docker exec Quagga /usr/lib/quagga/quagga start
Starting Quagga daemons (prio:10):. zebra. bgpd. ripd. ripngd. ospfd. ospf6d. isisd.
Starting Quagga monitor daemon: watchquagga.
Exiting from the script

Understanding Integrated Configurations

By default, Cumulus Quagga saves the configuration of all daemons in a single integrated configuration file, Quagga.conf.

You can disable this mode by running:

host(config)# no service integrated-vtysh-config

To enable the integrated configuration file mode again, run:

host(config)# service integrated-vtysh-config

If you disable the integrated configuration mode, Cumulus Quagga saves each daemon-specific configuration file in a separate file. At 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 can save the current configuration by running:

host# write mem
Building Configuration...
Integrated configuration saved to /etc/quagga/Quagga.conf
[OK]
You can use write file instead of write mem.

When the integrated configuration mode disabled, the output looks like this:

switch# write mem
Building Configuration...
Configuration saved to /etc/quagga/zebra.conf
Configuration saved to /etc/quagga/bgpd.conf
[OK]

Restoring the Default Configuration

If you need to restore the Cumulus Quagga configuration to the default running configuration, you need to delete the Quagga.conf file and restart the quagga service. You should back up Quagga.conf (or any configuration files you may remove, see the note below) before proceeding.

  1. Confirm service integrated-vtysh-config is enabled:

    cumulus@switch$ sudo vtysh -c "show run" | grep integrated
              service integrated-vtysh-config  
  2. Remove /etc/quagga/Quagga.conf:

    cumulus@switch$ sudo rm /etc/quagga/Quagga.conf
  3. Restart Cumulus Quagga. On a Cumulus Linux switch or an Ubuntu 16.04 host, run this command:

    cumulus@switch:~$ sudo systemctl restart quagga

    On an Ubuntu 12.04 or 14.04 host, run this command:

    root@host:~# service quagga restart

    For a Docker container, on the host, run:

    root@host:~# docker exec Quagga /usr/lib/quagga/quagga restart

If for some reason service integrated-vtysh-config is not configured, then you should remove all the configuration files (such as zebra.conf or ospf6d.conf) instead of Quagga.conf in step 2 above.

Configuring Cumulus Quagga in a Container

If you're using Cumulus Quagga with containers, you have three ways to configure Cumulus Quagga:

  • Directly from the host, outside the container
  • By creating a Quagga.conf file on the host and copying it into the container
  • Logging into the container and using vtysh, the Cumulus Quagga CLI

To configure Cumulus Quagga inside the container directly from the host, run the following command with the appropriate settings for your network:

root@host:/etc/apt/sources.list.d# docker exec Quagga /usr/bin/vtysh -c 'configure t' -c 'router bgp 65030' -c 'neighbor 2.1.1.1 remote-as external'

You can configure Cumulus Quagga with a custom Quagga.conf file on the host and copy it into the container, as containers do not contain text editors such as vi or nano. Create the Quagga.conf file, copy it into container and restart Cumulus Quagga:

root@host:~# docker cp Quagga.conf Quagga:/etc/quagga/Quagga.conf
root@host:~# docker exec Quagga /usr/lib/quagga/quagga restart 

The reload command does not work at this time.

Finally you can log into the container to configure Cumulus Quagga using vtysh:

root@host:/etc/apt/sources.list.d# docker exec -it Quagga /bin/bash
root@host:/# vtysh

Hello, this is Quagga (version 0.99.23.1+cl3u2).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

host# config t
host(config)#

When you log into to privileged container, the prompt does not change.

Configure Cumulus Quagga as you would for a host, described above. 

To stop and remove all containers (a container must be stopped before it can be removed):

root@host:/etc/apt/sources.list.d# docker stop $(docker ps -a -q)

Remove all containers:

root@host:/etc/apt/sources.list.d# docker rm $(docker ps -a -q)

Interface IP Addresses

Quagga 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 Cumulus Quagga. For more information, see Configuring IP Addresses.

Using the vtysh Modal CLI

Cumulus Quagga provides a CLI – vtysh – for configuring and displaying the state of the protocols. It is invoked by running:

root@host:~# vtysh

Hello, this is Quagga (version 0.99.23.1+cl3.0).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

host#

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:

host# configure terminal
host(config)#

The prompt displays the mode the CLI is in. For example, when the interface-specific commands are invoked, the prompt changes to:

host(config)# interface swp1
host(config-if)#

When the routing protocol specific commands are invoked, the prompt changes to:

host(config)# router ospf
host(config-router)#

At any level, ”?” displays the list of available top-level commands at that level:

host(config-if)# ?
bandwidth    Set bandwidth informational parameter
description  Interface specific description
end          End current mode and change to enable mode
exit         Exit current mode and down to previous mode
ip           Interface Internet Protocol config commands
ipv6         Interface IPv6 config commands
isis         IS-IS commands
link-detect  Enable link detection on interface
list         Print command list
mpls-te      MPLS-TE specific commands
multicast    Set multicast flag to interface
no           Negate a command or set its defaults
ospf         OSPF interface commands
quit         Exit current mode and down to previous mode
shutdown     Shutdown the selected interface

?-based completion is also available to see the parameters that a command takes:

host(config-if)# bandwidth ?
<1-10000000>  Bandwidth in kilobits
host(config-if)# ip ?
address  Set the IP address of an interface
irdp     Alter ICMP Router discovery preference this interface
ospf     OSPF interface commands
rip      Routing Information Protocol
router   IP router interface commands

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:

host# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP,
       > - selected route, * - FIB route

K>* 0.0.0.0/0 via 192.168.0.2, eth0
C>* 192.0.2.11/24 is directly connected, swp1
C>* 192.0.2.12/24 is directly connected, swp2
B>* 203.0.113.30/24 [200/0] via 192.0.2.2, swp1, 10:43:05
B>* 203.0.113.31/24 [200/0] via 192.0.2.2, swp1, 10:43:05
B>* 203.0.113.32/24 [200/0] via 192.0.2.2, swp1, 10:43:05
C>* 127.0.0.0/8 is directly connected, lo
C>* 192.168.0.0/24 is directly connected, eth0

To run the same command at a config level, you prepend do to it:

host(config-router)# do show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP,
       > - selected route, * - FIB route

K>* 0.0.0.0/0 via 192.168.0.2, eth0
C>* 192.0.2.11/24 is directly connected, swp1
C>* 192.0.2.12/24 is directly connected, swp2
B>* 203.0.113.30/24 [200/0] via 192.0.2.2, swp1, 10:43:05
B>* 203.0.113.31/24 [200/0] via 192.0.2.2, swp1, 10:43:05
B>* 203.0.113.32/24 [200/0] via 192.0.2.2, swp1, 10:43:05
C>* 127.0.0.0/8 is directly connected, lo
C>* 192.168.0.0/24 is directly connected, eth0

Running single commands with vtysh is possible using the -c option of vtysh:

root@host:~# vtysh -c 'sh ip route'
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP,
       > - selected route, * - FIB route

K>* 0.0.0.0/0 via 192.168.0.2, eth0
C>* 192.0.2.11/24 is directly connected, swp1
C>* 192.0.2.12/24 is directly connected, swp2
B>* 203.0.113.30/24 [200/0] via 192.0.2.2, swp1, 11:05:10
B>* 203.0.113.31/24 [200/0] via 192.0.2.2, swp1, 11:05:10
B>* 203.0.113.32/24 [200/0] via 192.0.2.2, swp1, 11:05:10
C>* 127.0.0.0/8 is directly connected, lo
C>* 192.168.0.0/24 is directly connected, eth0

Running a command multiple levels down is done thus:

root@host:~# vtysh -c 'configure terminal' -c 'router ospf' -c 'area 0.0.0.1 range 10.10.10.0/24'

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:

root@host:~# vtysh -c 'sh ip r'
% Ambiguous command.

A command or feature can be disabled by prepending the command with no. For example:

host(config-router)# no area 0.0.0.1 range 10.10.10.0/24

The current state of the configuration can be viewed using the show running-config command:

 Click here to see the output ...
host# show running-config
Building configuration...

Current configuration:
!
hostname quagga
log file /media/node/zebra.log
log file /media/node/bgpd.log
log timestamp precision 6
!
service integrated-vtysh-config
!
password xxxxxx
enable password xxxxxx
!
interface eth0
ipv6 nd suppress-ra
link-detect
!
interface lo
link-detect
!
interface swp1
ipv6 nd suppress-ra
link-detect
!
interface swp2
ipv6 nd suppress-ra
link-detect
!
router bgp 65000
bgp router-id 0.0.0.9
bgp log-neighbor-changes
bgp scan-time 20
network 29.0.1.0/24
timers bgp 30 90
neighbor tier-2 peer-group
neighbor 192.0.2.2 remote-as 65000
neighbor 192.0.2.2 ttl-security hops 1
neighbor 192.0.2.2 advertisement-interval 30
neighbor 192.0.2.2 timers 30 90
neighbor 192.0.2.2 timers connect 30
neighbor 192.0.2.2 next-hop-self
neighbor 192.0.2.12 remote-as 65000
neighbor 192.0.2.12 next-hop-self
neighbor 203.0.113.1 remote-as 65000
!
ip forwarding
ipv6 forwarding
!
line vty
exec-timeout 0 0
!
end

If you attempt to configure a routing protocol that has not been started, vtysh silently ignores those commands.

Example vtysh Commands

This section illustrates various vtysh commands for use when configuring Cumulus Quagga.

Actionvtysh Command
Display the routing table
host# show ip route
Show the running configuration
host# show running-config
Create a new neighbor
host(config)# router bgp 65002
host(config-router)# neighbor 14.0.0.22 remote-as 65007
Redistribute routing information from static route entries
host(config)# router bgp 65002
host(config-router)# redistribute static
Define a static route (for static routes, you only need to enable the zebra daemon)
host(config)# ip route 155.1.2.20/24 br2 45
Configure an IPv6 interface
host(config)# int br3
host(config-if)# ipv6 address  3002:2123:1234:1abc::21/64
Configure MTU in IPv6 network discovery for an interface
host(config)# int swp3
host(config-if)# ipv6 nd mtu 9000
Log OSPF adjacency changes
host(config)# router ospf
host(config-router)# router-id 2.0.0.21
host(config-router)# log-adjacency-changes
Set OSPF interface priority
host(config)# int swp3
host(config-if)# ip ospf priority  120
Configure timing for OSPF SPF calculations
host(config)# router ospf6
host(config-ospf6)# timer throttle spf 40 50 60
Configure hello packet intervals (in seconds)
host(config)# int swp4
host(config-if)# ipv6 ospf6 hello-interval  60
Display OSPF debugging status
host# show debugging ospf
Display BGP information
host# show ip bgp summary

Reloading the Cumulus Quagga Configuration

If you make a change to your routing configuration, you need to reload so your changes take place. Quagga reload enables you to apply only the modifications you make to your Cumulus Quagga configuration, synchronizing its running state with the configuration in /etc/quagga/Quagga.conf. This is useful for optimizing the automation of Cumulus Quagga in your environment or to apply changes made at runtime.

Quagga reload only applies to an integrated service configuration, where your Cumulus Quagga configuration is stored in a single Quagga.conf file instead of one configuration file per Quagga daemon (like zebra or bgpd).

To reload your Quagga configuration after you've modified /etc/quagga/Quagga.conf, on a Cumulus Linux switch, run:

cumulus@switch:~$ sudo systemctl reload quagga

On an Ubuntu host, run this command:

root@host:~# service quagga reload

Examine the running configuration and verify that it matches the config in /etc/quagga/Quagga.conf:

root@host:~# vtysh -c 'show run'

Debugging

If the running configuration is not what you expected, please submit a support request and supply the following information:

  • The current running configuration (run sudo vtysh -c 'show run' and output the contents to a file)
  • The contents of /etc/quagga/Quagga.conf
  • The contents of the /var/log/quagga/ directory