Running Zebra on a Unix Machine
by Iljitsch van Beijnum, author of
If there is one thing I hate when reading a technical book, it's errors in the examples. A misplaced word or two in the text can be distracting, but in an example, it is often deadly. So when I set out to write BGP, I vowed to do everything I could to avoid this problem.
Unfortunately, there is no way to guarantee that errors weren't introduced during the later stages in the writing and publishing process, but as the writer, at least I could make sure the examples were correct when I put them in the manuscript. For this purpose, I had to create the actual configuration I wanted to use for each example, using my trusty-old Cisco 2500 at home. But I couldn't do this on a single router: I also needed BGP peers (neighbors) for my router to talk to. I had never been a great fan of host-based routers, but I figured anything that could talk BGP would do as something for my Cisco to talk to, at least for the basic examples. (Then I'd only need to scavenge routers elsewhere for the more complex ones.)
So, the first step was to install the Zebra routing software on my FreeBSD box. Zebra (the brainchild of Kunihiro Ishiguro) is a set of daemons, each implementing a single routing protocol. There are daemons for RIP, RIPng, OSPF, OSPFv6, and BGP, and an extra daemon called
zebra that handles the interactions between the different protocols and the kernel routing table. The RIPng and OSPFv6 daemons support IPv6 routing within a single organization's network, and the BGP daemon implements the multiprotocol extensions in order to support IPv6 interdomain routing. (For more on IPv6, see Silvia Hagen's recently released book, IPv6 Essentials.)
Zebra is completely IPv6-aware: connecting to (for instance) the
bgpd with the command
telnet localhost 2605 works just as well when using the IPv6 loopback address
::1 as it does when using the IPv4 loopback address
127.0.0.1. Managing a program running on the local host by telnetting to it may seem bizarre at first, but this makes it possible for Zebra to closely emulate the Cisco user interface. This meant I could get to work right away: most of the BGP commands are the same as those on a Cisco router, and there's always help in the form of the question mark, which shows a list of possible completions for partially entered commands. And changing the running configuration on the fly is much more efficient than having to edit configuration files and restart the daemon.
One thing is a bit odd, though: in Zebra, each of the daemons must be configured separately. However, the
vtysh utility handles configuration, so this isn't a huge imposition. Whenever Zebra must be configured differently from Cisco's IOS, the Zebra way usually makes more sense. For instance, on a Cisco, enabling BGP routing for the address range
192.0.2.64/26 is done using the command
network 192.0.2.64 mask 255.255.255.192, but this is done differently for OSPF:
network 192.0.2.64 0.0.0.63 area 0. In Zebra, the address range is represented using prefix format (for example,
192.0.2.64/26) for both BGP and OSPF.
Zebra closely mimics Cisco IOS behavior, even in cases where this behavior is largely arbitrary. Let me give you an example. BGP routes can have a metric, or "Multi Exit Discriminator" (MED), to use the right term. In other routing protocols, such as OSPF, the metric is the primary mechanism to select routes: the one with the lowest metric is preferred. In BGP, the metric or MED is optional, and is only used to differentiate between two or more routes that are otherwise identical, such as in the case where a customer connects to the same ISP over two links. If one of the links is faster, the customer can set a low metric on this link and a higher one on the other link to make sure the ISP sends traffic over the faster link. But the MED is optional, so what should happen if there is a MED for one route, but no MED for another? Cisco routers consider a missing MED to be the best possible one (zero).
So does Zebra. (In both IOS and Zebra this behavior can be changed with the
bgp bestpath med missing-as-worst command, to better conform to IETF guidelines.) This close similarity makes
Zebra relatively easy to work with for someone who learned about routers on Cisco equipment (like
me). Conversely, experience with Zebra is a good starting point when learning IOS. However,
this doesn't mean Zebra is an "IOS emulator." Since Zebra just implements routing protocols and not the underlying packet forwarding, filtering routes is done differently than in IOS. Until a few years ago, Cisco only implemented two filtering mechanisms for packet filtering that can also be applied to route filtering: standard access lists and extended access lists. The syntax for using extended access lists to filter routes is rather convoluted. For instance, an extended access list that matches all routes with prefix lengths of 20 to 24 bits in
192.168.0.0/16 would be:
access-list 169 permit ip 192.168.0.0 0.0.255.255 255.255.240.0 0.0.15.0
Zebra's access list syntax is much simpler, but also less powerful:
access-list test1 permit 192.168.0.0/16
192.168.0.0/16 or any more specific prefix. The only other option is to use the exact-match keyword and then the access list line matches just
192.168.0.0/16 and nothing else. Fortunately, route filtering that uses access lists is a thing of past. IOS and Zebra now both implement prefix lists, which are as powerful as Cisco's extended access lists, but with the simplicity of Zebra's:
ip prefix-list test2 permit 192.168.0.0/16 ge 20 le 24
Pages: 1, 2