Introduction to the Quagga Routing Suite

JAKMA_LAYOUT_Layout 1 3/27/14 12:18 PM Page 42

Paul Jakma and David Lamparter

Abstract Off-the-shelf routing products are often constrained by being designed to meet specific 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 implementations 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

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 protocol 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. through a protocol called ZServ. Zserv is versioned and List 1 shows the gist of a simple signal handler, timer, and intended to be stable. The vtysh command line tool communi- read IO thread. The timer thread runs after 5 s and is passed cates with other processes via a simple string passing proto- a handle to external state, and must reschedule itself as col, where the strings are essentially identical to the required. The provided signal handler will actually run in nor- commands entered. mal process context, as only a small library stub runs in actual

IEEE Network • March/April 2014 43 JAKMA_LAYOUT_Layout 1 3/27/14 12:18 PM Page 44

static int timer_count; int timer (struct thread *thread){ int_count = THREAD_ARG(thread); through a single tree, saving memory. The bgp_adj_out refer- printf(“run %d of timer\n”, (_count)++); thread_add_timer(master, timer, count, 5); ences the attribute set represented, and a list of bgp_info } objects advertising that attribute set and containing further, more specific information. The bgp_adj_in references only voidsighup(void){ peer and attribute information, which is all that is necessary to printf(“processed hup\n”); be able to clean up routes when they are removed or when a } BGP peer is disconnected. struct quagga_signal_t sigs[] = { Relatively heavy use is made in bgpd of normalizing data { .signal = SIGHUP, .handler = &sighup, }, structures through interlinking and sharing of objects, particu- }; larly in the RIB. The lifetimes of these shared objects are int read_thread (struct thread *t) { managed with manual reference counting and garbage collec- int sock = THREAD_FD(t); tion. This allows memory use to be minimized. However, this int msg = read_msg (sock); obviously comes at the cost of increased complexity and thread_add_read (master,read_thread, increased scope for bugs. NULL, sock); A further overview of the zebra, ospfd, and ripd, daemons return msg; may be found in [8]. } Extensions void setup (void) { Quagga’s design, with functionality distributed across separate signal_init (master, array_size(sigs), sigs); processes, facilitates both the addition of new protocols as thread_add_timer (master, timer, well as the extension of individual protocols. For example, the &timer_count, 5); zclient version of olsrd [9] demonstrates the former quite suc- thread_add_read (master, read_thread, cinctly, integrating an existing implementation of OLSR [10] NULL, sock); in only 390 lines of C code, as does the recent addition of a } Babel [11, 12] implementation to Quagga. More interesting in an academic context is probably modifi- Listing 1. Example, cooperative threads. cation of existing routing protocol implementations with relative ease. An extreme example of this is the U.S. Naval Research Laboratory’s implementation of OSPF mobile ad signal context. Therefore, this signal handler is not restricted hoc network (MANET) [13, 14] extensions, almost turning in what it can do, as normal UNIX signal context code is. The Quagga’s OSPF implementation inside out. Ongoing protocol read thread will be called when the given socket becomes developments also find their way into Quagga as the result of ready to read. thesis projects, as in the case of OSPFv3 auto-configuration [15, 16], or efforts by the larger community, as with BGP Other IPC Mechanisms SIDR security extensions [17], which are seeing involvement The zebra daemon contains functionality to allow zebra to from the U.S. National Institute of Science and Technology manage FIBs in forwarding planes other than the kernel. The (NIST) [18]. protocol is described in fpm/fpm.h in the sources. This allows There have also been efforts to implement multiprotocol zebra to connect to agents managing other forwarding planes label switching (MPLS) for Quagga, dating as far back as 1999 via a socket. The ospfd daemon, implementing OSPFv2, offers [19]. Unfortunately, these have only recently come to fruition, an OSPF-API IPC interface to allow its database of OSPF and will need further effort to reach maturity. A major factor link state announcements (LSAs), the LSDB, to be queried. in this has been the need for system support below Quagga This interface also allows opaque LSAs to be injected into the for performing label switching. It is reasonable to assume here OSPF network via ospfd. that, unlike with IP routing, a lack of demand for label switching with general-purpose systems accounts for some of the Internal Overview troubles here. Recent developments, in particular MPLS sup- The bgpd BGP daemon internally hangs all its data structure port in Linux’s OpenvSwitch and on BSD systems, hopefully off a global bgp_master singleton object. This contains some herald progress here. global configuration data and holds references to the event The RouteFlow project [20] makes OpenFlow-capable handling subsystem and work queues and the main listening hardware available as a forwarding plane to Quagga as a stan- socket, and then references a list of all the BGP instances. dards-based interface. This combines the customizability of Each BGP instance in turn holds configuration data and ref- open source software with the abilities of specialized hard- erences a special “self peer”; a list of configured peers; a list ware, combining the best of both worlds. of peer groups, each of which references a special peer to hold configuration data for the group and a list of peers in the group; as well as a set of RIB tables for each address family Scaling, Performance and Reliability (AFI; e.g., IP, IPv6) and subsequent-address family (SAFI; There is a balance to be struck between runtime performance, e.g. unicast, multicast), as shown in Fig. 2. memory usage, CPU usage, and reliability through isolation. As shown in Fig. 3, each BGP RIB table is headed by a There are trade-offs to be made between the use of complex bgp_table object, which contains some basic descriptive infor- indices, separate processes and IPC, data sharing, and internal mation. The routing table itself is composed of a binary tree threading, which all have an impact on runtime performance, of bgp_node objects, each of which contains the prefix it is reliability, and scalability, and may result in tension between describing, and maintains references to lists of advertisements them. received and advertised for this prefix through the bgp_adj_in Scaling of memory may be achieved though increased data and bgp_adj_out objects. These conceptually correspond to sharing. This is easiest within one process. For example, BGP the Adj-RIB-In and Adj-RIB-Out of [6], and together they attributes that are identical between different routes can be allow the three notionally distinct RIBs of BGP to be indexed shared, and routes that are queued to be sent to different

44 IEEE Network • March/April 2014 JAKMA_LAYOUT_Layout 1 3/27/14 12:18 PM Page 45

linklist

hash Hash table BGP peers can be shared. However, this also intro- Basic data duces risks to reliability, as it is easy for code to structures make mistakes in managing the lifetime of shared pqueue Priority queue data objects. It may also reduce runtime performance by adding overheads. vector Vector/growable array Reliability may be increased by using separate IP header and Fletcher (TCP, IS-IS) processes communicating through IPC. Failures in checksum one process need not cause other processes to fail; checksums for example, the OSPF daemon can crash without Checksums/ affecting BGP. However, this may come at the cost hashes jhash Jenkins’ hash of needing to copy more data around, which has runtime costs and may affect memory scaling. md5 MD5 cryptographic checksum (obsolete) Scaling of runtime may be achieved through increased multiprocessing. One option is the use of if Network interface state fully preemptive threads; however, these can reduce reliability through increased opportunities for race prefix Network address prefix conditions. It may also be achieved through the use Networking of separate processes, at the cost of IPC. data Bounded and checked, network stream Clearly, there is a tension between these differ- structures byte-order aware, packet buffer ent goals. The sweet spot may change in time, as relative costs of CPU, memory, and programmer Longest-matching prefix lookup table table time change. Quagga’s current design, using one support daemon per routing protocol along with one daemon acting as RIB/FIB manager, originated in the command 1990s. Memory was more expensive then, and com- Configuration Configuration and monitoring command puters had few CPU execution contexts. The ever and UI definition support increasing transistor counts of Moore’s law were vty generally spent on increasing the sequential speed of those few execution contexts. A small fixed num- buffer Low-level buffer for output. ber of processes that were able to maximize data network Basic read/write convenience functions sharing made sense in this context. I/O Today, things have changed. Increasing transistor Convenience functions for socket budgets are being spent on adding ever more exe- sockopt cution contexts rather than increased sequential operations speed. Memory has also gotten cheaper, although access time has gotten more expensive. The single filter IP address/prefix access-list filters process per routing protocol model arguably is no longer appropriate, as it results in a fixed number Filtering plist IP prefix list filters of execution contexts and thus does not make use of large numbers of cores. routemap Match/action filtering In particular, bgpd has significant scaling problems with large numbers of peers, which became thread Event, I/O and timer co-operative threads apparent with, for example, route servers at IXPs. Cooperative Efforts were made before to increase the granulari- sigvent Signal handlers ty of its internal cooperative threading, but this threads offered only a little respite. Other efforts have been workqueue Work queues made, sponsored by Euro-IX, to fully thread bgpd, with some success. However, those changes have daemon Process daemonisation been wide-ranging, and to date have not been merged back into mainstream Quagga. Threading log Logging, to UI and/or file bgpd so that peer communication and initial route Process processing is handled by threads has been reported memory Memory allocation, debug & tracking to have significant performance benefits [21]. A support more dynamic allocation of work to threads in bgpd pid_output Locked PID file writing could give additional performance gains [22]. There is also perhaps room to experiment with privs Least-privilege support, on certain systems dividing bgpd into separate processes that communicate via IPC. This might also require revamping the configuration and interactive control/monitor- agentx SNMP AgentX interface ing modules to support the case where a single routing protocol has its functionality distributed IPC smux SNMP SMUX interface (obsolete) over multiple processes. Such functionality would also benefit other protocols. For example, ospfd is zclient ZServ client interface also starting to have its scalability tested heavily by Quagga library functionality. a few users with very large numbers of LSAs in Table 2. their OSPF, such as where they inject very large numbers (> 20,000) of external routes into OSPF.

IEEE Network • March/April 2014 45 JAKMA_LAYOUT_Layout 1 3/27/14 12:18 PM Page 46

peer self bgp master Quagga can also be used with virtualization (KVM/QEMU, OpenVZ, VMWare, etc.) to cheaply simulate network scenarios for educational or research purposes. A number of peers research papers have used Quagga as part of simulations of existing routing systems, or to help evaluate proposed modifications to those systems in this way. As an example, [26] used bgp Quagga to evaluate a system to integrate IGP and BGP infor- peer group peers mation from across a network in a central controller to provide scalable routing. Furthermore, the code may also be adapted and used with other software, according to the terms of the GPLv2 licence (e.g., integrating portions of bgpd code rib (per AFI/SAFI) into ns-2) [27]. Also, it is quite feasible to run many instances of the Quag- ga BGP daemon simply as regular processes and have them Figure 2. High-level overview of bgpd. connect locally to each other, and thus build virtual BGP networks without the overhead of system-level virtualization. The Quagga sources provide a script, in “tools/multiple-bgpd.sh,” An open question is how badly a many-process approach giving an example of how to do this. This can greatly simplify would affect memory scaling and how the trade-offs would the testing or evaluation of BGP scenarios. One or more of compare with the fully threaded approach. these bgpd processes could also connect with external BGP However, sometimes there are relatively clear gains to be speakers, so this can be used also to help evaluate other BGP made. The initial implementation of Dijkstra’s shortest path implementations. algorithm in ospfd in GNU Zebra, and inherited by Quagga, was based on a simple ordered linked list to maintain the dis- covered vertices. Its performance was quite adequate with Community small networks, the low-overhead making it more than com- There is a community around Quagga where users seek advice petitive with other implementations. However, beyond small from each other, and contributors propose and discuss modifi- networks, ospfd would perform poorly [8], scaling with O(n2) cations. The community is centered around the website at in runtime on graphs with n nodes and O(n) edges [23]. http://www.quagga.net and its mailing lists. Discussions about Replacing the ordered linked-list with a priority queue in usage and other general matters take place on the quagga- Quagga vastly improved the scalability of the Dijkstra SPF users [28] email list. The quagga-dev [29] list is used for dis- algorithm, allowing ospfd to run in O(n log n) time, and with cussions on the development of Quagga. lower constant factors than other implementations [23]. Modifications are generally made by consensus after a review process curated by the maintainers of Quagga. The maintainers may be reached privately via maintainers@quag- Applications ga.net; however, only matters that genuinely require privacy GNU Zebra and, later, Quagga have found use in a number of will be answered there; support and development queries areas, both commercial and academic. As Quagga is supported should be directed to the appropriate email lists mentioned on a number of standard UNIX/Linux systems, it can be run above. on a breadth of hardware, from small embedded routers to large hardware. Its GPL licence guarantees the freedom to Contributing Back modify the source code. Quagga may be useful in situations Many people who modify Quagga intend for their modifica- where standard router offerings do not suffice, say because tions to stay private, which is perfectly acceptable under the more CPU power or memory is required than is available with GPL licence as long as the result is not redistributed. Howev- standard router hardware, or where a more flexible, powerful, er, for anyone who intends to use and work on Quagga for or customizable software environment is needed than offered extended periods of time and make ongoing modifications, it by traditional router software environments. is generally easier to stay synchronized with changes in the One application is using BGP as a route server, acting as a public Quagga if their own modifications are incorporated hub for the processing of BGP routes and hence avoiding the into it. need for all the clients of the route server to connect with Others may be open to having their modifications integrat- each other. Quagga has facilities to allow it to maintain a sep- ed with the public Quagga, but may not have the time to do arate BGP-RIB for each client, and thus apply policy sepa- so. This appears to happen often with research projects, rately from the perspective of each client. With these where time is only budgeted for research goals, and little or client-specific BGP RIBs, a route server is able to consider none for contributing the code to the community. However, every route from every client in the context of every other contributing back to Quagga can have a research impact, par- client. This does, however, have scaling limitations, which are ticularly in the longer term. Merely presenting a modification further exacerbated with a single-process/thread bgpd. Further back to the Quagga community will gain the research some details on this feature are in the Quagga documentation. additional visibility with network operators and other Another common use is data logging of routing protocols. researchers. Doing what is required to have the changes inte- The MRTv2 format is supported for dumping BGP state and grated into Quagga will give it even longer-term visibility, and activity for later analysis. Projects such as the University of get that code to a still wider audience of network operators. Oregon Route Views Archive Project [24] and the RIPE That wider audience of operators potentially may test or even Routing Information Service [25] use GNU Zebra and Quag- deploy that work. Such use may potentially lead to additional ga to monitor and archive Internet BGP updates from a num- research opportunities in the future. ber of observation points around the Internet. These are then In short, contributing back to Quagga and engaging with available for anyone to download and analyze. The results of the community may help increase the impact of those research many research papers came from data logged this way. projects that involve extending Quagga.

46 IEEE Network • March/April 2014 JAKMA_LAYOUT_Layout 1 3/27/14 12:18 PM Page 47

bgp table Contribution Process Getting a modification integrated into Quagga peer requires presenting the modifications for considera- tion and building a consensus on the fitness for inclusion. This may require engaging with others in bgp node bgp adj in attr the community, particularly for more complex modifications. The process for this is detailed in the Development section of the website, but is relatively struct prefix bgp adj out peer informal. To start the process: • Prepare the modifications as one or more change- sets, in diff -uwb format, preferably as git com- attr mits. • Email the change-sets to the quagga-dev list for bgp node bgp node review. Anyone in the Quagga community may offer reviews and are encouraged to do so. The reviewers bgp advertise may sometimes ask that the change-sets be further modified. If the changes are complex or subtle, fur- bgp node bgp node ther explanation may be asked for. The rationale for the change-sets may be challenged. The review process may sometimes feel adversarial, but try not to take this as a personal slight. Some changes bgp info asked for may even seem trivial (e.g., style issues), but the reviewer may ask for them to avoid an accu- mulation of trivial issues out of a long-term concern Figure 3. BGP routing table overview. for the code-base. Submitting a change for inclusion is the start of a process that sometimes may take time, engagement, and possibly further work to refine the changes to the quagga-dev email list for discussion rather than changes before they can be accepted. ignoring the advice. For modifications that are likely to be substantive, it is a good idea to try to involve the community in discussion earlier in the development process rather than later. Doing all design Conclusion and coding in private risks the Quagga community disagreeing Quagga can be a useful addition to the toolkit of network- with aspects of the direction taken. When the modification is ing professionals, in both commercial and research settings. finally presented to the community, this may lead to reviews It provides a hackable platform for solving networking prob- requesting major changes, requiring time the contributor for lems. There is a diverse community around it, ranging from which a developer may not have planned. These risks can be network operators to routing platform vendors to academic reduced by instead conducting design discussions in public on researchers, among others. This community is open and the quagga-dev list prior to the bulk of the coding work. Some consensus-based. Everyone is welcome and encouraged to general tips for successfully contributing to Quagga: step forward and contribute, be it through development of • Try to separate changes into logically consistent, distinct the code, updates to the documentation, code reviews, help- change-sets, with each change-set as small as possible. ing with infrastructure, or suggesting improvements to pro- Avoid mixing unrelated changes into one change-set. cesses. • Give a rationale with the change-set, so the reviewer can Quagga is what you make of it. See you there! understand: –The abstract motivation for the change: What problem is References fixed? What feature is added? [1] Quagga Software Routing Suite, http://www.quagga.net/. –The general method by which the change-set addresses the [2] G. Malkin, “RIP Version 2,” IETF RFC 2453, Nov. 1998, updated by RFC 4822, http://www.ietf.org/rfc/rfc2453.txt. problem or adds the feature. [3] G. Malkin and R. Minnear, “RIPng for IPv6,” proposed std. IETF RFC –The confidence that can be had in the change: What test- 2080, Jan. 1997, http://www.ietf.org/rfc/rfc2080.txt. ing was done? [4] J. Moy, “OSPF Version 2,” IETF RFC 2328, Apr. 1998, updated by RFCs • Providing test-cases and/or unit tests can greatly help make a 5709, 6549, 6845, and 6860, http://www.ietf.org/rfc/rfc2328.txt. [5] R. Coltun et al., “OSPF for IPv6,” proposed std. IETF RFC 5340, July 2008, case for a change. updated by RFCs 6845 and 6860, http://www.ietf.org/rfc/rfc5340.txt. • The review and integration process sometimes takes time, [6] Y. Rekhter, T. Li, and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” and potentially requires multiple rounds of refinement of draft std. IETF RFC 4271, Jan. 2006, updated by RFCs 6286, 6608, and the work and review. This is especially true for larger con- 6793, http://www.ietf.org/rfc/rfc4271.txt. [7] D. Oran, “OSI IS-IS Intra-Domain Routing Protocol,” informational IETF RFC tributions. Account for this in project plans as far as possi- 1142, Feb. 1990, http://www.ietf.org/rfc/rfc1142.txt. ble. [8] Y.-D. Lin, R.-H. Hwang, and F. Baker, Computer Networks: An Open Those wishing to modify Quagga are strongly encouraged to Source Approach, McGraw-Hill, 2012, http://highered.mcgraw- read the “HACKING” [30] document first. This is included in hill.com/sites/0073376248/. [9] C. Franke, “OLSRd, quagga zclient Enabled Version,” 2011, http://git. the Quagga sources as HACKING.tex and is also available in nowhere.ws/?p=olsrd-zclient.git;a=summary. PDF form on the main website. It contains guidance on the [10] T. Clausen and P. Jacquet, “Optimized Link State Routing Protocol established development practices, styles, and processes for (OLSR),” experimental IETF RFC 3626, Oct. 2003, http://www.ietf.org/ Quagga. Contributors to Quagga are strongly encouraged to rfc/rfc3626.txt [11] J. Chroboczek, “The Babel Routing Protocol,” experimental IETF RFC follow it wherever possible. If a practice seems outdated, non- 6126, Apr. 2011, http: //www.ietf.org/rfc/rfc6126.txt. optimal, or unnecessary, the best course of action is to edit [12] “Babel — A Loop-Avoiding Distance-Vector Routing Protocol,” http:// and update the document, and then submit those proposed www.pps. univ-paris-diderot.fr/~jch/software/babel/.

IEEE Network • March/April 2014 47 JAKMA_LAYOUT_Layout 1 3/27/14 12:18 PM Page 48

[13] “OSPF MANET Designated Routers (OSPF-MDR) Implementation,” [24] D. Mayer, “University of Oregon Route Views Archive Project,” http:// http://www.nrl.navy.mil/itd/ncs/products/ospf-manet. routeviews.org/. [14] R. Ogier and P. Spagnolo, “Mobile Ad Hoc Network (MANET) Extension [25] “RIPE Routing Information Service (RIS),” https://www.ripe.net/data- of OSPF Using Connected Dominating Set (CDS) Flooding,” experimental tools/stats/ris. IETF RFC 5614, Aug. 2009, updated by RFC 7038, http://www.ietf. [26] M. Caesar et al., “Design and Implementation of a Routing Control Plat- org/rfc/rfc5614.txt. form,” Proc. 2nd Conf. Symp. Networked Systems Design & Implementa- [15] “OSPFv3 Auto-Configuration for quagga,” [16] A. Lindem and J, arkko, tion, vol. 2, Berkeley, CA, USENIX Assn.,, 2005, http://dl.acm. “OSPFv3 Auto-Configuration,” http://tools.ietf.org/html/draft-ietf-ospf- org/citation.cfm?id=1251203.1251205, pp. 15–28. ospfv3-autoconfig [27] X. A. Dimitropoulos and G. F. Riley, “Efficient Large-Scale BGP Simula- [17] M. Lepinski and S. Kent, “An Infrastructure to Support Secure Internet tions,” Computer Networks, vol. 50, no. 122006, Network Modelling Routing,” informational IETF RFC 6480, Feb. 2012, http://www.ietf.org/ and Simulation, rfc/rfc6480.txt. http://www.sciencedirect.com/science/article/pii/S1389128605003269 [18] “BGP Secure Routing Extension (BGP-SRx),” http://www- [28] “Quagga Users Email List,” http://lists.quagga.net/mailman/listinfo/quagga- x.antd.nist.gov/bgpsrx/. users. [19] J. Leu, “MPLS for Linux,” http://sourceforge.net/apps/mediawiki/mpls- [29] “Quagga Development Email List,” http://lists.quagga.net/mailman/listin- linux/index.php?title=Main_Page#History. fo/ quagga-dev. [20] M. R. Nascimento et al., “Virtual Routers as a Service: The RouteFlow [30] “Quagga HACKING Document,” http://www.nongnu.org/quagga/docs/ Approach Leveraging Software-Defined Networks,” Proc. 6th Int’l. Conf. HACKING.pdf. Future Internet Technologies, ACM, 2011, http://doi.acm.org/10. 1145/2002396.2002405, pp. 34–37. Biographies [21] K. Wang, L. Gao, and M. Lai, “A Scalable Multithreaded BGP Architec- PAUL JAKMA ([email protected]) is currently writing up a Ph.D. thesis at the Uni- ture for Next Generation Router,” Proc. Int’l. Conf. Human-Centric Comput- versity of Glasgow, United Kingdom, on the topic of scalable Internet routing. ing 2011 and Embedded and Multimedia Computing 2011, ser. Lecture He was one of the founders of the Quagga Routing Suite, and an active main- Notes in Electrical Engineering, J. J. Park et al., Eds., Springer Nether- tainer of it until 2009. He has a broad interest in networking, particularly at lands, vol. 102, 2011, http://dx.doi.org/10.1007/978-94-007-2105- the data and control plane level. 0_36, pp. 395–404. [22] S. Grover, A. Dhanotia, and G. Byrd, “A Canonical Multicore Architec- DAVID LAMPARTER works for the Network Device Education Foundation (NetDEF) ture for Network Routers,” Architectures for Networking and Communica- and has been a maintainer of the Quagga Routing Suite for two years. He is tions Systems (ANCS), 2011 7th ACM/IEEE Symp., IEEE Computer Soc., working toward a Master's degree in computer science, and is active in IETF 2011, http://dx.doi.org/10.1109/ANCS.2011.30, pp. 134–44. Working Groups around IPv6 home network deployment. In his free time, he [23] V. Eramo et al., “Optimization in the Shortest Path First Computation for has helped make the Chaos Communication Congress's network work for the the Routing Software GNU Zebra,” IEICE Trans. Commun., vol. E88-B, no. past few years. 6, June 2005, http://search.ieice.org/bin/summary.php?id= e88-b_6_2644, pp. 2644–49.

48 IEEE Network • March/April 2014