- 1 Building the Unicast Routing Table
- 2 Relationship between the routing table and forwarding information base
- 3 Multicast Routing Tables
- 4 References
In routing, the control plane is the part of the router architecture that is concerned with drawing the network map, and the "traffic rules" of the paths certain traffic should take, or must not take. Control plane functions, such as participating in routing protocols, run in the control element.
The map and rules are stored in what is formally called a routing information base (RIB), or, more commonly and informally, a routing table. Minimally, the RIB contains a list of ordered pairs of <destination, outgoing interface>
Control plane logic also can define certain packets to be discarded, as well as preferential treatment of certain packets for which a high quality of service is defined by such mechanisms as differentiated services.
RIBs are designed for efficient updating by sources of routing information, but not for the fastest lookup of destination. A table, or sometimes hardware, optimized for fast lookup is populated from the RIB, but is called a Forwarding Information Base (FIB). See Forwarding plane for FIB design and use.
Building the Unicast Routing Table
A major function of the control plane is deciding which routes go into the main routing table. "Main" refers to the table that holds the unicast routes that are active. If the router also does multicast routing, there may be an additional routing table for multicast routes. Several routing protocols such as OSPF and BGP maintain internal data bases of candidate routes that they will promote if a route fails or routing policy is changed.
Several different information sources may provide information on a route to a given destination, but the router must select the "best" route to install into the routing table. In some cases, there may be multiple routes of equal "quality", and the router may install all of them and load-share across them.
Sources of Routing Information
There are three general sources of routing information:
Local Interface Information
Routers forward traffic that enters on an input interface and leaves on an output interface, subject to filtering and other local rules. While routers usually forward from one physical (e.g., Ethernet, serial) to another physical interface, it is also possible to define multiple logical interfaces on a physical interface. A physical Ethernet interface, for example, can have logical interfaces in several virtual LANs defined by IEEE 802.1q VLAN headers.
When an interface has an address configured in a subnet, such as 192.0.2.1 in the 192.0.2.0/24 (i.e., subnet mask 255.255.255.0) subnet, and that interface is considered "up" by the router, the router thus has a directly connected route to 192.0.2.0/24. If a routing protocol offered another router's route to that same subnet, the routing table installation software will normally ignore the dynamic route and prefer the directly connected route.
There also may be software-only interfaces on the router, which it treats as if they were locally connected. For example, most implementations have a "null" software-defined interface. Packets having this interface as a next hop will be discarded, which can be a very efficient way to filter traffic. Routers usually can route traffic faster than they can examine it and compare it to filters, so, if the criterion for discarding is the packet's destination address, "blackholing" the traffic will be more efficient than explicit filters.
Other software defined interfaces that are treated as directly connected, as long as they are active, are interfaces associated with tunneling protocols such as generic routing encapsulation (GRE) or Multi-Protocol Label Switching (MPLS).
A static route is a hard-coded path to a destination. A static route, minimally, has a destination address, a prefix length or subnet mask, and a definition where to send packets for the route. Depending on the implementations, static routes may be preferred to dynamic routes, sometimes preferred, or less preferred.
The term "quasi-static" routing refers to a sequence of static routes to the same destination or set of destinations, with preferences assigned to the various routes. One application of quasi-static routing is called a "floating static route:, where the static route is less preferred than a route from any routing protocol. The static route, which might use a dialup link or other slow medium, activates only when the dynamic routing protocol(s) cannot provide a route to the destination,
That definition can refer to a local interface on the router, or a next-hop address that could be on the far end of a subnet to which the router is connected. The next-hop address could also be on a subnet that is directly connected, and, before the router can determine if the static route is usable, it must do a recursive lookup of the next hop address in the local routing table. If the next-hop address is reachable, the static route is usable, but if the next-hop is unreachable, the route is ignored.
Static routes that are more preferred than any dynamic route also can be very useful, especially when using traffic engineering principles to make certain traffic go over a specific path with an engineered quality of service.
Dynamic routing protocols
See routing protocols. The routing table manager, according to implementation and configuration rules, may select a particular route or routes from those advertised by various routing protocols.
Installing Unicast Routes
Different implementations have different sets of preferences for routing information, and these are not standardized among IP routers. It is fair to say that subnets on directly connected active interfaces are always preferred. Beyond that, however, there will be differences.
Implementers generally have a numerical preference, which Cisco calls an "administrative distance", for route selection. The lower the preference, the more desirable the route. Cisco's IOS implementation makes exterior BGP the most preferred source of dynamic routing information, while Nortel RS makes intra-area OSPF most preferred.
The general order of selecting routes to install is:
- If the route is not in the routing table, install it.
- If the route is "more specific" than an existing route, install it in addition to the existing routes. "More specific" means that it has a longer address prefix.
- If the route is of equal specificity to a route already in the routing table, but comes from a more preferred source of routing information, replace the route in the table.
- If the route is of equal specificity to a route in the routing table, comes from a source of the same preference,
- Discard it if the route has a higher metric than the existing route
- Replace the existing route if the new route has a lower metric
- (optional) If the routes are of equal metric and the router supports load-sharing, add the new route and designate it as part of a load-sharing group. Typically, implementations will support a maximum number of routes that load-share to the same destination. If that maximum is already in the table, the new route is usually dropped.
Relationship between the routing table and forwarding information base
See forwarding plane for more detail, but each implementation has its own means of updating the forwarding information base with new routes installed in the routing table. If the FIB is in one-to-one correspondence with the RIB, the new route is installed in the FIB after it is in the RIB. If the FIB is smaller than the RIB, and the FIB uses a hash table or other data structure that does not easily update, the existing FIB might be invalidated and replaced with a new one computed from the updated RIB.
Multicast Routing Tables
Multicast routing builds on unicast routing. Each multicast group to which the local router can route has a multicast routing table entry with a next hop for the group, rather than for a specific destination as in unicast routing.
There can be multicast static routes as well as learning dynamic multicast routes from a protocol such as Protocol-Independent Multicast (PIM).
- Yang, L.; R. Dantu & T. Anderson et al. (April 2004), Forwarding and Control Element Separation (ForCES) Framework, Internet Engineering Task Force, RFC 3746
- Configuring IP Routing Protocol-Independent Features,Cisco Systems,July 2006
- Nortel Ethernet Routing Switch 8600 Configuring IP Routing Operations, Nortel Networks, January 2007