oreilly.comSafari Books Online.Conferences.



Running Zebra on a Unix Machine
An Alternative for a Real Router?

by Iljitsch van Beijnum, author of BGP

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

Enter Zebra

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

Related Reading

Building Reliable Networks with the Border Gateway Protocol
By Iljitsch van Beijnum

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 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 is done using the command network mask, but this is done differently for OSPF: network area 0. In Zebra, the address range is represented using prefix format (for example, for both BGP and OSPF.

Zebra's Advantages

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 would be:

access-list 169 permit ip

Zebra's access list syntax is much simpler, but also less powerful:

access-list test1 permit

This matches or any more specific prefix. The only other option is to use the exact-match keyword and then the access list line matches just 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 ge 20 le 24

Pages: 1, 2

Next Pagearrow

Sponsored by: