zebra is an IP routing manager. It provides kernel routing table updates, interface lookups, and redistribution of routes between different routing protocols.
Besides the common invocation options (Common Invocation Options), the zebra specific invocation options are listed below.
Runs in batch mode. zebra parses configuration file and terminates immediately.
When zebra starts up, don’t delete old self inserted routes.
When program terminates, retain routes added by zebra.
Run zebra with a limited ecmp ability compared to what it is compiled to. If you are running zebra on hardware limited functionality you can force zebra to limit the maximum ecmp allowed to X. This number is bounded by what you compiled FRR with as the maximum number.
When Zebra starts with this option, the VRF backend is based on Linux network namespaces. That implies that all network namespaces discovered by ZEBRA will create an associated VRF. The other daemons will operate on the VRF defined by Zebra, as usual.
Configuration Addresses behaviour¶
At startup, Zebra will first discover the underlying networking objects
from the operating system. This includes interfaces, addresses of
interfaces, static routes, etc. Then, it will read the configuration
file, including its own interface addresses, static routes, etc. All this
information comprises the operational context from Zebra. But
configuration context from Zebra will remain the same as the one from
zebra.conf config file. As an example, executing the following
show running-config will reflect what was in
In a similar way, networking objects that are configured outside of the
Zebra like iproute2 will not impact the configuration context from
Zebra. This behaviour permits you to continue saving your own config
file, and decide what is really to be pushed on the config file, and what
is dependent on the underlying system.
Note that inversely, from Zebra, you will not be able to delete networking
objects that were previously configured outside of Zebra.
interface IFNAME vrf VRF¶
Up or down the current interface.
ip address ADDRESS/PREFIX¶
ipv6 address ADDRESS/PREFIX¶
no ip address ADDRESS/PREFIX¶
no ipv6 address ADDRESS/PREFIX¶
Set the IPv4 or IPv6 address/prefix for the interface.
ip address LOCAL-ADDR peer PEER-ADDR/PREFIX¶
no ip address LOCAL-ADDR peer PEER-ADDR/PREFIX¶
Configure an IPv4 Point-to-Point address on the interface. (The concept of PtP addressing does not exist for IPv6.)
local-addr has no subnet mask since the local side in PtP addressing is always a single (/32) address. peer-addr/prefix can be an arbitrary subnet behind the other end of the link (or even on the link in Point-to-Multipoint setups), though generally /32s are used.
ip address ADDRESS/PREFIX secondary¶
no ip address ADDRESS/PREFIX secondary¶
Set the secondary flag for this address. This causes ospfd to not treat the address as a distinct subnet.
description DESCRIPTION ...¶
Set description for the interface.
Enable or disables multicast flag for the interface.
no bandwidth (1-10000000)¶
Set bandwidth value of the interface in kilobits/sec. This is for calculating OSPF cost. This command does not affect the actual device configuration.
Enable/disable link-detect on platforms which support this. Currently only Linux and Solaris, and only where network interface drivers support reporting link-state via the
Static Route Commands¶
Static routing is a very fundamental feature of routing technology. It defines static prefix and gateway.
ip route NETWORK GATEWAY¶
NETWORK is destination prefix with format of A.B.C.D/M. GATEWAY is gateway for the prefix. When GATEWAY is A.B.C.D format. It is taken as a IPv4 address gateway. Otherwise it is treated as an interface name. If the interface name is
null0then zebra installs a blackhole route.
Some example configuration:
ip route 10.0.0.0/8 10.0.0.2 ip route 10.0.0.0/8 ppp0 ip route 10.0.0.0/8 null0
First example defines 10.0.0.0/8 static route with gateway 10.0.0.2. Second one defines the same prefix but with gateway to interface ppp0. The third install a blackhole route.
ip route NETWORK NETMASK GATEWAY¶
This is alternate version of above command. When NETWORK is A.B.C.D format, user must define NETMASK value with A.B.C.D format. GATEWAY is same option as above command.
ip route 10.0.0.0 255.255.255.0 10.0.0.2 ip route 10.0.0.0 255.255.255.0 ppp0 ip route 10.0.0.0 255.255.255.0 null0
These statements are equivalent to those in the previous example.
ip route NETWORK GATEWAY DISTANCE¶
Installs the route with the specified distance.
Multiple nexthop static route:
ip route 10.0.0.1/32 10.0.0.2 ip route 10.0.0.1/32 10.0.0.3 ip route 10.0.0.1/32 eth0
If there is no route to 10.0.0.2 and 10.0.0.3, and interface eth0 is reachable, then the last route is installed into the kernel.
If zebra has been compiled with multipath support, and both 10.0.0.2 and 10.0.0.3 are reachable, zebra will install a multipath route via both nexthops, if the platform supports this.
zebra> show ip route S> 10.0.0.1/32 [1/0] via 10.0.0.2 inactive via 10.0.0.3 inactive * is directly connected, eth0
ip route 10.0.0.0/8 10.0.0.2 ip route 10.0.0.0/8 10.0.0.3 ip route 10.0.0.0/8 null0 255
This will install a multihop route via the specified next-hops if they are reachable, as well as a high-metric blackhole route, which can be useful to prevent traffic destined for a prefix to match less-specific routes (e.g. default) should the specified gateways not be reachable. E.g.:
zebra> show ip route 10.0.0.0/8 Routing entry for 10.0.0.0/8 Known via "static", distance 1, metric 0 10.0.0.2 inactive 10.0.0.3 inactive Routing entry for 10.0.0.0/8 Known via "static", distance 255, metric 0 directly connected, Null0
ipv6 route NETWORK GATEWAY¶
ipv6 route NETWORK GATEWAY DISTANCE¶
These behave similarly to their ipv4 counterparts.
ipv6 route NETWORK from SRCPREFIX GATEWAY¶
ipv6 route NETWORK from SRCPREFIX GATEWAY DISTANCE¶
Install a static source-specific route. These routes are currently supported on Linux operating systems only, and perform AND matching on packet’s destination and source addresses in the kernel’s forwarding path. Note that destination longest-prefix match is “more important” than source LPM, e.g. “2001:db8:1::/64 from 2001:db8::/48” will win over “2001:db8::/48 from 2001:db8:1::/64” if both match.
Select the primary kernel routing table to be used. This only works for kernels supporting multiple routing tables (like GNU/Linux 2.2.x and later). After setting TABLENO with this command, static routes defined after this are added to the specified table.
VRF (Virtual Routing and Forwarding)¶
Currently, the user has the possibility to configure VRFs. VRF is a way to separate networking contexts on the same machine. Those networking contexts are associated with separate interfaces, thus making it possible to associate one interface with a specific VRF. VRF can be used, for example, when instantiating per enterprise networking services, without having to instantiate the physical host machine or the routing management daemons for each enterprise. As a result, interfaces are separate for each set of VRF, and routing daemons can have their own context for each VRF.
This conceptual view introduces the Default VRF case. If the user does not configure any specific VRF, then by default, the user will however configure the Default VRF. On the Zebra context, this can be done when being in configuration mode, when configuring a static route clicmd:ip route NETWORK GATEWAY.
# case without VRF configure terminal ip route 10.0.0.0 255.255.255.0 10.0.0.2 exit
Configuring VRF networking contexts can be done in various ways on FRR. The VRF
interfaces can be configured by entering in interface configuration mode :
interface IFNAME vrf VRF. Also, if the user wants to configure a static
route for a specific VRF, then a specific VRF configuration mode is available. After
entering into that mode by following command:
vrf VRF. the user can enter
the same route command as before, but this time, the route command will apply to vrf
# case with VRF configure terminal vrf r1-cust1 ip route 10.0.0.0 255.255.255.0 10.0.0.2 exit-vrf
A VRF backend mode is chosen when running Zebra.
If no option is chosen, then the Linux VRF implementation as references in https://www.kernel.org/doc/Documentation/networking/vrf.txt will be mapped over the Zebra VRF. The routing table associated to that VRF is a Linux table identifier located in the same Linux network namespace where Zebra started.
-n option is chosen, then the Linux network namespace will be
mapped over the Zebra VRF. That implies that Zebra is able to configure several
Linux network namespaces. The routing table associated to that VRF is the whole
routing tables located in that namespace. For instance, this mode matches OpenStack
Network Namespaces. It matches also OpenFastPath. The default behavior remains Linux
VRF which is supported by the Linux kernel community, see
Because of that difference, there are some subtle differences when running some commands in relationship to VRF. Here is an extract of some of those commands:
This command is available on configuration mode. By default, above command permits accessing the vrf configuration mode. This mode is available for both VRFs. It is to be noted that Zebra does not create Linux VRF. The network administrator can however decide to provision this command in configuration file to provide more clarity about the intended configuration.
This command is based on VRF configuration mode. This command is available when Zebra is run in
-nmode. This command reflects which Linux network namespace is to be mapped with Zebra VRF. It is to be noted that Zebra creates and detects added/suppressed VRFs from the Linux environment (in fact, those managed with iproute2). The network administrator can however decide to provision this command in configuration file to provide more clarity about the intended configuration.
ip route NETWORK NETMASK GATEWAY NEXTHOPVRF¶
This command is based on VRF configuration mode or in configuration mode. If on configuration mode, this applies to default VRF. Otherwise, this command applies to the VRF of the vrf configuration mode. This command is used to configure a vrf route leak across 2 VRFs. This command is only available when Zebra is launched without
ip route NETWORK NETMASK GATEWAY table TABLENO¶
This command is based on VRF configuration mode. There, this command is only available with
-ncommand. This commands permits configuring a network route in the given
TABLENOof the Linux network namespace.
ip route NETWORK NETMASK GATEWAY table TABLENO¶
This command is based on configuration mode. There, for default VRF, this command is available for all modes. The
TABLENOconfigured is one of the tables from Default Linux network namespace.
show ip route vrf VRF¶
The show command permits dumping the routing table associated to the VRF. If Zebra is launched with default settings, this will be the
TABLENOof the VRF configured on the kernel, thanks to information provided in https://www.kernel.org/doc/Documentation/networking/vrf.txt. If Zebra is launched with
-noption, this will be the default routing table of the Linux network namespace
show ip route vrf VRF table TABLENO¶
The show command is only available with
-noption. This command will dump the routing table
TABLENOof the Linux network namespace
ip route 10.0.0.0 255.255.255.0 10.0.0.2 vrf r1-cust1 table 43 show ip table vrf r1-cust1 table 43
Multicast RIB Commands¶
The Multicast RIB provides a separate table of unicast destinations which is used for Multicast Reverse Path Forwarding decisions. It is used with a multicast source’s IP address, hence contains not multicast group addresses but unicast addresses.
This table is fully separate from the default unicast table. However, RPF lookup can include the unicast table.
WARNING: RPF lookup results are non-responsive in this version of FRR, i.e. multicast routing does not actively react to changes in underlying unicast topology!
ip multicast rpf-lookup-mode MODE¶
no ip multicast rpf-lookup-mode [MODE]¶
MODE sets the method used to perform RPF lookups. Supported modes:
- Performs the lookup on the Unicast RIB. The Multicast RIB is never used.
- Performs the lookup on the Multicast RIB. The Unicast RIB is never used.
- Tries to perform the lookup on the Multicast RIB. If any route is found, that route is used. Otherwise, the Unicast RIB is tried.
- Performs a lookup on the Multicast RIB and Unicast RIB each. The result with the lower administrative distance is used; if they’re equal, the Multicast RIB takes precedence.
Performs a lookup on the Multicast RIB and Unicast RIB each. The result with the longer prefix length is used; if they’re equal, the Multicast RIB takes precedence.
The mrib-then-urib setting is the default behavior if nothing is configured. If this is the desired behavior, it should be explicitly configured to make the configuration immune against possible changes in what the default behavior is.
Unreachable routes do not receive special treatment and do not cause fallback to a second lookup.
show ip rpf ADDR¶
Performs a Multicast RPF lookup, as configured with
ip multicast rpf-lookup-mode MODE. ADDR specifies the multicast source address to look up.
> show ip rpf 192.0.2.1 Routing entry for 192.0.2.0/24 using Unicast RIB Known via "kernel", distance 0, metric 0, best * 198.51.100.1, via eth0
Indicates that a multicast source lookup for 192.0.2.1 would use an Unicast RIB entry for 192.0.2.0/24 with a gateway of 198.51.100.1.
show ip rpf¶
Prints the entire Multicast RIB. Note that this is independent of the configured RPF lookup mode, the Multicast RIB may be printed yet not used at all.
ip mroute PREFIX NEXTHOP [DISTANCE]¶
no ip mroute PREFIX NEXTHOP [DISTANCE]¶
Adds a static route entry to the Multicast RIB. This performs exactly as the
ip routecommand, except that it inserts the route in the Multicast RIB instead of the Unicast RIB.
zebra Route Filtering¶
Zebra supports prefix-list s and Route Maps s to match routes received from other FRR components. The permit/deny facilities provided by these commands can be used to filter which routes zebra will install in the kernel.
ip protocol PROTOCOL route-map ROUTEMAP¶
Apply a route-map filter to routes for the specified protocol. PROTOCOL can be any or one of
set src ADDRESS¶
Within a route-map, set the preferred source address for matching routes when installing in the kernel.
The following creates a prefix-list that matches all addresses, a route-map that sets the preferred source address, and applies the route-map to all rip routes.
ip prefix-list ANY permit 0.0.0.0/0 le 32 route-map RM1 permit 10 match ip address prefix-list ANY set src 10.0.0.1 ip protocol rip route-map RM1
zebra FIB push interface¶
Zebra supports a ‘FIB push’ interface that allows an external component to learn the forwarding information computed by the FRR routing suite. This is a loadable module that needs to be enabled at startup as described in Loadable Module Support.
In FRR, the Routing Information Base (RIB) resides inside zebra. Routing protocols communicate their best routes to zebra, and zebra computes the best route across protocols for each prefix. This latter information makes up the Forwarding Information Base (FIB). Zebra feeds the FIB to the kernel, which allows the IP stack in the kernel to forward packets according to the routes computed by FRR. The kernel FIB is updated in an OS-specific way. For example, the Netlink interface is used on Linux, and route sockets are used on FreeBSD.
The FIB push interface aims to provide a cross-platform mechanism to support scenarios where the router has a forwarding path that is distinct from the kernel, commonly a hardware-based fast path. In these cases, the FIB needs to be maintained reliably in the fast path as well. We refer to the component that programs the forwarding plane (directly or indirectly) as the Forwarding Plane Manager or FPM.
The FIB push interface comprises of a TCP connection between zebra and the FPM. The connection is initiated by zebra – that is, the FPM acts as the TCP server.
The relevant zebra code kicks in when zebra is configured with the
--enable-fpm flag. Zebra periodically attempts to connect to
the well-known FPM port. Once the connection is up, zebra starts
sending messages containing routes over the socket to the FPM. Zebra
sends a complete copy of the forwarding table to the FPM, including
routes that it may have picked up from the kernel. The existing
interaction of zebra with the kernel remains unchanged – that is, the
kernel continues to receive FIB updates as before.
The encapsulation header for the messages exchanged with the FPM is
defined by the file
fpm/fpm.h in the frr tree. The routes
themselves are encoded in Netlink or protobuf format, with Netlink
being the default.
Protobuf is one of a number of new serialization formats wherein the message schema is expressed in a purpose-built language. Code for encoding/decoding to/from the wire format is generated from the schema. Protobuf messages can be extended easily while maintaining backward-compatibility with older code. Protobuf has the following advantages over Netlink:
- Code for serialization/deserialization is generated automatically. This reduces the likelihood of bugs, allows third-party programs to be integrated quickly, and makes it easy to add fields.
- The message format is not tied to an OS (Linux), and can be evolved independently.
As mentioned before, zebra encodes routes sent to the FPM in Netlink format by default. The format can be controlled via the FPM module’s load-time option to zebra, which currently takes the values Netlink and protobuf.
The zebra FPM interface uses replace semantics. That is, if a ‘route add’ message for a prefix is followed by another ‘route add’ message, the information in the second message is complete by itself, and replaces the information sent in the first message.
If the connection to the FPM goes down for some reason, zebra sends the FPM a complete copy of the forwarding table(s) when it reconnects.
zebra Terminal Mode Commands¶
show ip route¶
Display current routes which zebra holds in its database.
Router# show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, B - BGP * - FIB route. K* 0.0.0.0/0 22.214.171.124 S 0.0.0.0/0 126.96.36.199 C* 127.0.0.0/8 lo C* 188.8.131.52/28 eth0
show ipv6 route¶
show ip prefix-list [NAME]¶
show route-map [NAME]¶
show ip protocol¶
Display whether the host’s IP forwarding function is enabled or not. Almost any UNIX kernel can be configured with IP forwarding disabled. If so, the box can’t work as a router.
Display whether the host’s IP v6 forwarding is enabled or not.
Display various statistics related to the installation and deletion of routes, neighbor updates, and LSP’s into the kernel.
show zebra fpm stats¶
Display statistics related to the zebra code that interacts with the optional Forwarding Plane Manager (FPM) component.
clear zebra fpm stats¶
Reset statistics related to the zebra code that interacts with the optional Forwarding Plane Manager (FPM) component.