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 <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.
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.
