JAKMA_LAYOUT_Layout 1 3/27/14 12:18 PM Page 42 Introduction to the Quagga Routing Suite Paul Jakma and David Lamparter Abstract Off-the-shelf routing products are often constrained by being designed to meet spe- cific needs, in terms of both software and hardware. Networking professionals may face problems that require customization of software, or additional processing facilities or data storage, which are not provided for by those products. The Quag- ga Routing Suite provides implementations of several common routing protocols, distributed over multiple processes communicating via IPC, and support for their development, with source code provided under a modification-friendly license. Quagga can help networking professionals build such custom solutions, in combi- nation with other open source software packages. Quagga also provides a path for network researchers to increase the visibility of their work, making it available to a wider community for potential testing and use, increasing the impact of that research. ff-the-shelf routing products are often con- The community of operators, vendors, non-profits, and strained by design to meet specific needs, researchers around Quagga provide a forum for increasing the whether in terms of software or hardware. The visibility of work, and a potential path to wider testing and software may offer no means to customize the deployment of proposed modifications to routing protocols or OOrouting functionality, there may be little means for data gath- new routing protocols. ering or processing, and so on. The hardware may not have Herein we examine the history of the Quagga project. We any storage capabilities or sufficient spare capacity for addi- give some overviews of different aspects of the architecture of tional data processing. Quagga, in terms of how its various processes communicate; Networking professionals and researchers sometimes face the features provided by its support library; the internal archi- problems that go beyond the capabilities of such routing prod- tecture of its BGP process, and extension mechanisms avail- ucts. They may wish to combine routing functionality with able. We then consider the tensions that exist in the scalability, existing open source software packages, but be constrained on performance, and reliability of the code in Quagga, and give how many separate devices can be deployed. Researchers and some concrete examples of evaluations and issues. Next, we operators might wish to log routing protocol announcements, give an overview of possible uses and applications of Quagga. process them, and make them available, and hence require Finally, we consider the possible impact of researchers pre- storage and scripting capacities that are not available in exist- senting and attempting to contribute their work to the wider ing routing products. Researchers may wish to extend routing Quagga community, and how to do so. protocols, but not want to have to write complete implemen- tations from scratch. The Quagga Routing Suite [1] is a package of History UNIX/Linux software implementing a number of common The code in Quagga started out with a project called “GNU network routing protocols, including the Routing Informa- Zebra,” created in 1996 by Kunihiro Ishiguro. GNU Zebra tion Protocol (RIP) [2, 3] , Open Shortest Path First (OSPF) was released under the Free Software Foundation’s GNU [4, 5], Border Gateway Protocol (BGP) [6], and Intermedi- General Public Licence version 2 (GPLv2). Under this license, ate System to Intermediate System (IS-IS) [7]. The package it and its source code were free to all to use, distribute, exam- also includes a routing information management process to ine, and modify, as long as they passed on the same rights to act as an intermediary between the various routing proto- others if they distributed the code. cols and the active routes installed with the kernel. A library By 2000 GNU Zebra had relatively feature complete provides support for configuration and an interactive com- OSPFv2, RIP, and BGP implementations, thanks to the mand line interface. Quagga is available under the terms of efforts of Kunihiro Ishiguro and a few others. Kunihiro Ishig- the GPLv2 licence. uro continued development of this code base with a corporate Quagga thus provides a useful addition to the toolbox of body, IPInfusion, as a proprietary project under the moniker networking professionals. Its existing routing protocols can be ZebOS. Development of the GPL GNU Zebra slowed some- extended to enable experimentation, logging, or custom pro- what in 2001 and 2002. cessing. The libraries and kernel daemon provide a framework As a result, in 2002, the Quagga project was created as a for easier development of a new routing protocol daemon. It fork of the GNU Zebra code base. The GNU Zebra commu- can be combined with arbitrary other available software pack- nity largely and quickly moved over to Quagga. The Quagga ages to allow a wide range of functionality to be integrated project has acted as a focal point for a growing number of into a single device as well as imaginative solutions to net- contributors, from academia, for-profit corporations, and working problems. industry funded non-profits. Quagga has seen support added 42 0890-8044/14/$25.00 © 2014 IEEE IEEE Network • March/April 2014 JAKMA_LAYOUT_Layout 1 3/27/14 12:18 PM Page 43 IPv4 IPv6 Interactive vtysh zebra FIB/kernel arbitration command line babeld BABEL wireless mesh protocol bgpd BGPv4+ bgpd ospfd isisd isisd IS-IS BGP-RIB LSDB ospfd ospf6d OSPFv2 and OSPFv3 Protocol daemons ripd ripngd RIPv1/v2, and RIPng zebra Table 1. Quagga daemons. RIB for various routing protocol extensions (e.g., to BGP and OSPF) as well as for additional protocols such as IS-IS. A number of companies have integrated Quagga into more User space cohesive commercial routing products. Architecture Kernel Overview Packet Quagga consists of a set of processes communicating via IPC, FIB forwarding as shown in Fig. 1. Network routing protocols such as BGP, OSPF, and IS-IS are run in processes such as bgpd, ospfd, ospf6d, isisd, and so on. One daemon process, called “zebra” (a name inherited from GNU Zebra), acts as an intermediary Figure 1. Quagga architecture. between the kernel’s forwarding plane and these routing pro- tocol processes. An additional interactive command line tool called vtysh allows these processes to be monitored and their Support Library configuration modified. The bundled daemons and the proto- A C support library provides several facilities, both general cols they implement are shown in Table 1. and networking-related. Due to its heritage, the library is The zebra process maintains a shadow copy of packet for- named libzebra. Table 2 provides an overview of the modules warding related state, such as the network interfaces and the in the library. The application programming interface (API) table of currently active routes. The latter is often referred to for this library is generally kept stable, and incompatible as the forwarding information base (FIB). Typically, the ker- changes to it are strongly discouraged. nel manages packet forwarding, so the kernel maintains these. The library provides a bounded stream data structure in However, it would be possible to customize zebra to interact lib/stream.{c,h}. This allows network messages to be mar- with other forwarding engines, such as dedicated hardware, if shalled and demarshalled in a safe way, with logical mistakes needed. A forwarding plane manager protocol is provided to caught, ensuring the process is safely terminated rather than help facilitate this. corrupted. Network protocol clients are strongly encouraged The zebra process also gathers routing information from to make use of this abstraction for all external I/O, as it can the routing protocol processes and stores these, together with significantly reduce the impact of security critical bugs. its shadow copy of the FIB, in its own routing information The style of multiprocessing in the existing Quagga code is base (RIB). The zebra process may also have static routes to use distinct processes with IPC between them, and non-pre- configured into its RIB. The zebra process is then responsible emptive cooperative threads within each process. The configu- for selecting the best route from all those available for a desti- ration, UI, and IPC modules in the library rely on the nation and updating the FIB to use the best route. Addition- cooperative thread subsystem to function. The if network ally, information about the current best routes may be interface state module can be kept automatically updated with distributed to the protocol daemons. the underlying system if used with the zclient module. The zebra process also keeps the routing daemons The cooperative threads facility provides support for a informed of changes in network interface state if applicable. number of types of tasks. Timer tasks may be specified with The BGP routing protocol is somewhat unusual, in that it is either second or millisecond precision, and are responsible for possible for active BGP speakers to not be involved in for- rescheduling themselves as and when required. Read and warding packets. For example, BGP route servers may act as write tasks may be set up to run when a file descriptor hubs for other routers, offloading some route selection work becomes ready. Events are tasks that are run as soon as possi- to them; or BGP speakers may be involved in network man- ble. Background tasks are similar, but scheduled with a lower agement, reacting to events by injecting special routes (e.g., priority. The cooperative threads module keeps detailed usage to counter-act denial of service attacks). For this reason the statistics on the tasks run, which can be queried using the bgpd daemon may be run on its own, without any zebra dae- interactive interfaces. Abstractions for time keeping are also mon. Routing processes communicate with the zebra process provided by this module.