The GNU Zebra Routing Software

GNU Zebra is a free and mature software package that manages TCP/IP-based routing protocols. Zebra's unique architectural foundation is based on the concept of one single process for each signaling routing protocol. Each module can run, be restarted, or be upgraded independently of the others, which greatly increases the stability of the entire system. In addition, the protocol daemons can be run just to exchange signaling information or populate the system's forwarding table via the Zebra master daemon (zebra). Particularly popular applications that use signaling information are route servers and route reflectors that distribute Border Gateway Protocol (BGP) reachability information. Chapter 10, "ISP Connectivity with BGP4: An Exterior Gateway Path-Vector Routing Protocol for Interdomain Routing," discusses these applications in depth. GNU Zebra does not support or make use of threads yet—it has its own internal cooperative user-space thread model (not really multithreaded). Zebra code constitutes the development foundation for IP Infusion's commercial ZebOS. The following list presents some useful details about the software:

Test version— 0.93a + IS-IS patch 0.0.6, free routing software distributed under the GNU General Public License (GPL)

Architecture— Modular, one daemon per routing protocol, one master control daemon (zebra)

Resources— httphttp://www.zebra.org, http://isisd.sourceforge.net, http://www.ipinfusion.com

Feature Description and Architecture of Zebra

The Zebra package is a collection of protocol daemons and supports the following dynamic routing protocols: RIPv1/v2, RIPng, OSPFv2/v3, IS-IS (experimental), and BGP4/4+. In addition, several ancillary protocols such as Internet Group Management Protocol (IGMP) and Simple Network Management Protocol (SNMP) via the SNMP multiplexing facility [SMUX RFC 1227] are implemented. It also supports the Linux and BSD IPv6 stacks as well as interaction with the kernel routing table via updates and routing information redistribution, which occurs between the dynamic routing protocol daemons (such as ospfd or ripd) and the Zebra master process (zebra). Therefore, the zebra daemon acts as a supervisor process (routing manager) to exchange routing information between the kernel routing table and the dynamic routing protocol daemons. It is possible to prohibit injection of routes into the kernel routing table if one only intends to distribute pure signaling information. On the other hand, zebra can be run in a way to retain kernel routes in case of zebra termination, maintenance, or shutdown. The steps in the following section walk you through how to accomplish that.

Installation and Startup of Zebra

Zebra is specialized software that requires a sound understanding of networking and routing protocols. To be sure that the binaries behave as anticipated, I recommend installing from sources whenever possible and comfortable with the procedure. It is not always clear which compile-time options, patches, or configuration details were used to produce binary distributions or rpm packages.

Zebra offers a variety of useful and fine-grained configuration options at compile time; therefore, a detailed installation instruction seems appropriate:

Download and extract sources and, optionally, the isisd patch from http://www.zebra.org and http://isisd.sourceforge.net.

Be warned, however, that the IS-IS code is at an early development stage. It is not suitable for production use and does not work with newer Zebra versions greater than 0.93a!

Apply the isisd patch (patch -p1 < isisd-0.0.6-zebra-0.93-pre2.patch) in the Zebra source directory. This does not work on OpenBSD yet. Type the following: /.configure --enable-isisd --enable-nssa --enable-ospf-te --enable-opaque-lsa --enable-multipath=6 --enable-vtysh --enable-tcp-zebra --enable-snmp --with-libpam --enable-netlink You can get an overview of the configuration options by typing /.configure --help. Mutipath is set to 6 to mimic Cisco multipath default behavior. For SNMP support, the Net-SNMP development package or the UCD-SNMP alternative must be present on the system. Keep in mind that problems still exist with the SMUX support. Type: make Type: make check Type: make install Append these service entries to /etc/services: zebrasrv 2600/tcp zebra 2601/tcp ripd 2602/tcp ripng 2603/tcp ospfd 2604/tcp bgpd 2605/tcp ospf6d 2606/tcp isisd 2607/tcp Edit initial config files in /usr/local/etc. Examples are installed there automatically. Fire up daemons by typing the following: /usr/local/sbin/zebra -d -k -f /usr/local/etc/zebra.conf /usr/local/sbin/ripd -d -f /usr/local/etc/ripd.conf /usr/local/sbin/ospfd -d -f /usr/local/etc/ospfd.conf Note the following interesting options for some daemons: -k, --keep_kernel Do not delete old routes that were installed by zebra. -r, --retain When the program terminates, retain added routes. -n, --no_kernel Do not install a route to the kernel. Check the help menu of the routing daemons. (For example, type ospfd --help for further details or consult the manual pages, such as zebra(8).) Check the log files for proper operation. For example, you can type less -f /var/log/zebra.log to check the zebra log. Keep in mind that you have to add the log-file location to the respective daemon configuration file. The administrator has two options to modify runtime configurations via the command-line interface (CLI): telnet localhost ,e.g. port 2604 connects to the ospfd. Zebra uses ports from 2600 to 2607 for daemon connections. You can also make use of the port aliases specified in Step 7. For example, type telnet localhost ospfd.

Use the integrated Zebra shell vtysh by typing vtysh. vtysh expects its configuration to reside in /usr/local/etc/vtysh.conf. This path can be altered at compile time. If you want PAM (Pluggable Authentication Module, primarily used on Linux platforms) support in vtysh, use the configuration option --with-libpam at compile time. This requires the PAM development package to be present on the system.

If you encounter strange or esoteric problems during execution, use a sniffer, keep an eye on the logging and debugging output, and keep the following caveats in mind.

CAUTION

Zebra does not (yet) compile on OpenBSD with the isisd patch applied! Although currently Linux is the development platform for the IS-IS extension, this combination works nicely on FreeBSD as well. isisd is a young project with a couple of essential features still missing.

CAUTION

There appears to exist a bug in the way some older BSD Unices deal with default multicasting. The kernel in BSD tries to do a route lookup on the multicast destination 224.0.0.5 (AllSPFRouters), which fails if there is no default route or other route to a general multicast prefix such as 224.0.0.0/4 covering that address. If you encounter this problem, add a static route for that prefix.

NOTE

A great number of problems reported to the newsgroups of the Zebra community are problems essentially caused by a lack of understanding of the BGP, RIP, or OSPF protocols; awkward topologies; screwed address layouts; or just wrong uses for these protocols. This is especially true for OSPF-related questions. These problems cannot be attributed to code instability or lack of standard compliance, although minor bugs still exist.

The Development Roadmap of Zebra
Zebra is rather slowly approaching the 1.0 version. Packaged releases are infrequent, so you are better off retrieving the sources from the Concurrent Versions System (CVS) repository. Due to the maturity, scalability, stability, architecture, and Cisco-like handling, I consider this and its fork Quagga the dominating open-source solution for future software routing. Anyone who can configure Cisco IOS software can configure Zebra, too, almost without ever reading the thorough manual (well, "almost"). This package, together with Quagga and GateD, is used for most of the example labs throughout this book. This is why no example lab is provided here.

The Quagga Project
In 2003, a group of developers decided to pursue a Zebra code fork later named the Quagga Project (http://www.quagga.net). The protagonists of the Quagga Project opted for a fork to provide a more dynamic release cycle, greater community involvement, rapid acceptance of community feedback, and quick incorporation of critical patches. Changes to Zebra will be incorporated into Quagga as well. The Quagga website provides much more documentation and example configurations than the Zebra website. Installation and configuration work exactly as described in the Zebra section. However, Quagga supports additional configuration options that you can display by typing ./configure --help. I am using the following sequence in my setups:

./configure --enable-vtysh --enable-netlink --enable-snmp

--enable-tcp-zebra --enable-nssa --enable-opaque-lsa

--enable-ospf-te --enable-multipath=6 --with-libpam

--enable-vty-group=quagga --enable-rtadv

This requires that a quagga group and quagga user are configured on the system (present in /etc/passwd and /etc/groups).

With regard to the configuration examples, it should not make a difference whether you are using Quagga or Zebra. However, many bugs have been fixed in Quagga that are still present in the Zebra code. Some innovations such as route servers are only present in Quagga code. Note that recently another IS-IS daemon was integrated into Quagga that is different from the code available for Zebra (but is actually based on it).