Open source routing software projects have been receiving attention lately as viable, inexpensive platforms for midlevel routing deployments. But are they practical for enterprise network managers used to the performance levels and feature bells and whistles served up by commercial router vendors?

That is the question we explore in this initial test of open source router software. Most open source router software spawns from one of two projects - Zebra and eXtensible Open Router Platform (XORP). Because the Zebra project has been dormant since mid-2004, we tested its descendant, Quagga, which is updated about every quarter. (We plan to test a XORP-based product later this year.)

Overall, we found running Quagga on modest Dell servers yields performance numbers that would make the combination a formidable platform for a purpose-built routing application. If you're looking to run Quagga as a router in your production network, however, you may require a higher port density. This requires a server with more horsepower, which is more expensive. This additional cost may offset somewhat Quagga's low-cost appeal.

Quagga runs on GNU/Linux 2.4.x and higher, FreeBSD 4.x and higher, NetBSD 1.6 and higher, OpenBSD 2.5 and higher, and Solaris 8 and higher. It supports Routing Information Protocol and RIPv2, RIPng, Open Shortest Path First (OSPF), OSPFv2, OSPFv3, IPv6, Internet Group Management Protocol and IGMPv2, and Border Gateway Protocol 4.

Quagga's basic architecture consists of a Zebra daemon that handles updates to the Unix-based routing tables, and additional daemons for OSPF, RIP and BGP. Quagga has a unified configuration file for all daemons, which is easier to maintain than the original Zebra implementation that has separate configuration files for each daemon. The syntax of the Quagga configuration files is very much Cisco-esque. Quagga lets the user change IP addresses from the configuration file and command line; there is no need to configure IP addresses outside the router. The command-line interface is easy to use and intuitive (assuming some Cisco experience).

Measuring performance

To characterize IP packet-forwarding capabilities of the Quagga software running on two Dell machines, we ran throughput, packet loss and latency tests using a Spirent Smartbits 6000 results with 3301A 10/100/1000Mbps Ethernet interfaces interfaces (see How we did it at www.nwdocfinder.com/5523). We compared a Cisco 2621 router (running IOS v12.1) with Quagga running on a rack-mounted Dell 1550 server (with single 933MHz Pentium III CPU, 256MB of RAM and two 10/100 Ethernet network interface cards (NIC)). We also compared a Nortel 5520 switch with packet-forwarding capability with Quagga running on a Dell 2850 server (with dual 3.6GHz Xeon CPUs with 1GB of RAM and two 10/100/1000 Ethernet NICs).

Quagga running on the Dell 1550 performed at line rate (100Mbps) with packets larger than 256 bytes. For 64-byte packets, the Quagga box was able to forward 31Mbps of traffic. The Cisco 2621 didn't do very well in the forwarding tests, but we expected that, because it's an older entry-level router with a small processor (an MPC860 processor clocked at 66MHz), one that an open source router might be targeted to replace. The Cisco 2621 was able to forward 30Mbps worth of 1,518-byte packets and fell to 4.3Mbps with 64-byte packets.