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
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.
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:
Do not delete old routes that were installed by zebra.
When the program terminates, retain added routes.
Do not install a route to the kernel.
The administrator has two options to modify runtime configurations via the command-line interface (CLI):
telnet localhost <port> ,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.
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.
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 188.8.131.52 (AllSPFRouters), which fails if there is no default route or other route to a general multicast prefix such as 184.108.40.206/4 covering that address. If you encounter this problem, add a static route for that prefix.
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.
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.