Route Caches, Routing Tables, Forwarding Tables, and the ISO Context

UNIX gateways provide a forwarding table (forwarding information base, or FIB in ISO-speak) and generally a derived route cache that contains the best available next hop for a particular destination prefix/aggregate. The implementation of route caches is platform-specific. When a routing lookup occurs, the cache table is consulted first and as a fallback mechanism, the FIB is then consulted (see Figure 8-1). This triggers the lookup result to be placed in the cache and speed up future lookups. You can also see the FIB as an internal data structure representing the commonly known routing or forwarding table.

Figure 8-1. UNIX FIB (Forwarding Information Base)

[View full size image]
graphics/08fig01.gif


Very well, but how is the FIB populated?

Dynamic routing protocols internally operate based on a Routing Information Base (RIB) that has awareness of preference/administrative distance. The "essence" (a single best prefix entry among several possible candidates) of these protocol daemon RIBs is presented to the operating system via a protocol master daemon such as zebra or gated in a consolidated metric-only fashion (see Figure 8-2). This prefix is often referred to as active route. Under the hood, these controller daemons interact with forwarding information base data structures via the routing socket interface or the ioctl() interface. Therefore, the forwarding table is a collection of active routes. Once again, as a tribute to established practice (or sloppiness), I use forwarding table and routing table interchangeable, although it would be more accurate to relate the forwarding table with the FIB and the routing table with the RIB.

Figure 8-2. UNIX FIB (Forwarding Information Base) and Dynamic Signaling Daemons

graphics/08fig02.gif


Figure 8-2 shows a schematic representation of the connection of two routing engines (GateD and Zebra) via unicast or multicast mechanisms such as Open Shortest Path First (OSPF), Routing Information Protocol (RIP), or Border Gateway Protocol (BGP). OSPF facilitates its own link-state database (LSDB), RIP maintains the RIP database, and BGP feeds network layer reachability information (NLRI) into its own table structure (the BGP table). These protocol daemons directly exchange signaling information over IP networks. Finally, Internet Control Message Protocol (ICMP) redirects, as well as manual route instructions via route and ifconfig commands, alter the FIB structures (metric-aware only), too.

IP router implementations sometimes vary in terms of how they deal with equal-cost routes in the FIB and how they present these entries in the forwarding table. Linux provides a unique implementation of ECMP?actually the only one among the open-source UNIX operating systems. The BSD designers followed the philosophy that ifconfig and static routes should be sufficient to bring systems up in a network; everything beyond that core functionality is left to dynamic routing protocols on purpose. Last but not least, the Internet Router Discovery Protocol (IRDP) operation as sketched in Figure 8-1 is based on router advertisement and router solicitation ICMP type 9/10 code 0 query messages (RFC 1256) and can place default routes in the FIB as well.

In Cisco IOS Software, the view changes in that the forwarding/routing table is the output of the show ip route command, including the lowest-cost paths or duplicate equal-cost paths. The dynamic routing protocol instances have their own database structures on UNIX and Cisco IOS Software that feed the forwarding table, such as the OSPF LSDB or BGP table as previously mentioned (see Figure 8-2). Figure 8-3 differentiates between a "pre-Cisco Express Forwarding (CEF) scenario" and a CEF scenario (state of the art). CEF is recommended for all modern deployments. For an in-depth look at CEF operation and the CEF-MPLS (Multiprotocol Label Switching) relationship, consult Cisco.com.

Figure 8-3. Cisco IOS FIB (Forwarding Information Base)

[View full size image]
graphics/08fig03.jpg


Linux differs in the way that it supports multiple simultaneous routing tables, essentially offering differentiated policy routing (ip route list table #). This is also the reason why the zebra master daemon on Linux offers a show table and a table config mode command. At the time of this writing, the zebra master daemon is able only to assign zebra static routes to designated routing tables. Unfortunately, this is not the case for the dynamic protocol daemons (a nice-to-have feature for policy routing on Linux).