Open source routing software projects have been receiving attention lately as viable and inexpensive platforms for mid-level 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 the 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).
To characterise 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. 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.
The Cisco router did a better job of getting its packets through the router with less delay than the Quagga router. We saw a 630-microsec latency measurement for the Cisco 2621, compared with a 1,615-microsec latency for Quagga running on a Dell 1550. Keep in mind that increased latency results in decreased TCP throughput overall.
The Nortel box forwarded packets flawlessly at line rate for all packet sizes. Quagga running on the Dell 2850 combination hit close to line rate - 915Mbps - with 1,518-byte packets but could only forward 100Mbps with 64-byte packets. The packet-loss tests reflected the results of the throughput tests for the Nortel and Quagga systems. The Nortel router's latency was very low - 4 microsec. Quagga on the Dell 2850 had a 224 microsec average latency.
To see how our Quagga/Dell installation fared in maintaining its routing table, we ran an OSPF-based routeflapping test in order to stress the router. The router had to change the routing table after receiving a huge number of changes at once from the routing protocol. We ran this test against both Quagga combinations and the Cisco 2621. The Nortel 5520 doesn't support OSPF in the configuration we had in the lab.
The Quagga platform accepts about 500 routes via OSPF. The Cisco 2621 was able to accept more than 2,000 routes. But as the lowest common denominator, we used a maximum of 500 routes for all our route flap tests. All the routers were able to recover from the flapped routes, which is worth noting. We've seen some routing implementations crash or begin dropping a significant number of packets after a route flap event. That being said, the Cisco 2621 handled the route changes quicker. The Quagga installation took five to 10 seconds compared with Cisco's three seconds.
If you are interested in using Quagga as a platform to develop new routing features - such as a firewall or intrusion detection - go for it. Quagga performed respectfully in all areas of our tests and should be a stable development platform in terms of function and performance. We didn't evaluate the extensibility of the Quagga code, however, so you'll have to determine whether Quagga is right for your development environment.
If you are interested in running Quagga in your production network, you'll need to consider its performance limitations. Quagga probably will perform better with faster hardware than we used in our tests, but that also raises the price bar, possibly negating a very important open source advantage. You must also consider the necessary port density required for your network, as performance will degrade at least linearly as you add more ports, and most servers have a limited number of NIC slots available.
John Bass is technical director of the Centennial Networking Lab of North Carolina State University.
A good choice for a development network or similar, in larger networks Quagga will need more powerful hardware, which could negate the cost benefits of taking the open source route.