Chapter 2. User-Space Routing Software

As described in Chapter 1, "Operating System Issues and Features—The Big Picture," user-space routing tools run as one single process (monolithic architectures) or as a set of daemons external to the kernel routines, either single-threaded or multithreaded. As long as these daemons are alive, routing information—signaling information to be more precise—can be exchanged or withdrawn and eventually populate the gateway's routing table.

The following sections introduce the most popular and useful among the publicly available routing packages, some of their peculiarities, and how to set things up and run them for the first time. Their functionality and configuration files are discussed in depth in later chapters. As mentioned in the Foreword, some familiarity with TCP/IP, installing rpm packages (Redhat Package Manager), and source-code archives is necessary. Note that rpm archives are now used by many different Linux distributions and are not limited to Redhat/Fedora.

Discussion of the routed daemon operation, of Bird, and of the eXtensible Open Router Platform (XORP) is discussed exhaustively in this chapter and nowhere else, with the exception of a small multicast XORP example in Chapter 14, "Multicast Architectures." The remaining routing engines—GateD, Zebra/Quagga, and MRTd—are used extensively throughout the entire book after their initial introduction in this chapter. In the end, whether these packages are suitable for your definition of production grade is up to you to decide; this chapter offers some guidance, though. I am also convinced that a project not being actively maintained anymore (such as the research version of GateD) does not imply that it is not robust, is outdated, or is of questionable benefit. Complex routing protocol implementations are extremely difficult to debug without large-scale deployments, and problems are often caused by wrong topological approaches, poor address planning, or a lack of understanding of the involved protocols.