Forwarding information base
||It has been suggested that CAM Table be merged into this article. (Discuss) Proposed since April 2014.|
A forwarding information base (FIB), also known as a forwarding table, is most commonly used in network bridging, routing, and similar functions to find the proper interface to which the input interface should forward a packet.
- 1 Applications at data link layer
- 2 Applications at network layer
- 3 References
- 4 External Links
Besides Ethernet bridging based on MAC layer addresses, other data-link-layer technologies using forwarding tables include frame relay and Asynchronous Transfer Mode (ATM) switches, and multiprotocol label switching (MPLS). ATM has both link-local addresses and addresses that have end-to-end significance in the ATM domain.
MAC layer bridges learn the interface on which they first saw a particular source address, and associate that interface with that address. When the bridge subsequently receives a frame with a destination address in its forwarding table, it sends the frame out the interface stored in the forwarding table.
If the bridge has not seen the address yet, it treats the frame as if it were a broadcast and floods it out all active interfaces except for the interface on which it was received.
While the exact mechanics of a forwarding table is implementation-specific, the general model is that frame relay switches have statically defined forwarding tables, one per interface. When a frame with a given data link connection identifier (DLCI) is received on one interface, the table associated with that interface gives the outgoing interface, and the new DLCI to insert into the frame's address field.
Asynchronous Transfer Mode
ATM switches have link-level forwarding tables much like those used in frame relay. Rather than a DLCI, however, interfaces have forwarding tables that specify the outgoing interface, virtual path identifier, and virtual circuit identifier. These tables may be configured statically, or they can be distributed by the private network-to-network interface (PNNI) protocol. When PNNI is in use, the ATM switches at the edges of the ATM "cloud" will map one of the standard ATM end-to-end identifiers, such as an NSAP, to the next-hop VPI/VCI.
Multiprotocol Label Switching
MPLS, which has been called "ATM without cells", has many similarities, at the forwarding level, to ATM. The label edge routers (LER) at the edges of an MPLS cloud map between the end-to-end identifier, such as an IP address, and a link-local label. At each MPLS hop, there is a forwarding table that tells the label switched router (LSR) which outgoing interface is to receive the MPLS packet, and what label to use when sending the packet out that interface.
Applications at network layer
In contrast to routing tables, FIBs are optimized for fast lookup of destination addresses. Earlier implementations cached only a subset of the routes most frequently used in actual forwarding, and this worked reasonably well for enterprises where there is a meaningful most-frequently-used subset. Routers used for accessing the entire Internet, however, experienced severe performance degradation in refreshing a small cache, and various implementations moved to having FIBs in one-to-one correspondence with the RIB. RIBs are optimized for efficient updating by routing protocols and other control plane methods, and contain the full set of routes learned by the router.
FIBs may also be implemented with fast hardware lookup mechanisms, such as ternary content addressable memory (TCAM). TCAM, however, is quite expensive, and tends to be used more in edge routers with relatively small numbers of routes than in routers that must carry full Internet routing tables, with supplementary internal routes.
In ingress filtering against denial of service
FIBs can also play a role in an Internet best current practice (BCP) of ingress filtering. Though the simplest form of implementing ingress filtering is to use access lists to drop packets with improper source addresses, use of access lists becomes difficult on routers with a large number of adjacent networks, and traditional access lists are not used in high-performance router forwarding paths.
While the IETF document BCP 38 on ingress filtering does not specify a method of implementing source address filtering, some router vendors have implemented a mechanism which employs lookups in the router's tables to perform this check. (See also reverse path filtering.) This is often implemented as a lookup in the FIB of the source address of the packet. If the interface has no route to the source address, the packet is assumed to be part of a denial of service attack, using a false or spoofed source address, and the router discards the packet.
When the router is multihomed, ingress filtering becomes more complex. There are perfectly reasonable operational scenarios in which a packet could arrive on one interface, but that specific interface might not have a route to the source address. For the routers near the edge of the Internet, packet filters can provide a simpler and more effective solution than methods which employ routing information lookup, though this approach can be challenging when managing routers which are reconfigured often. Ingress filtering for multihomed routers will accept the packet if there is a route back to its source address from any interface on the router. For this type of filtering, the router may also maintain an adjacency table, also organized for fast lookup, that keeps track of the router interface addresses that are on all directly connected routers.
In quality of service
IP differentiated services provides an additional method to select outgoing interfaces, based on a field that indicates the forwarding priority of the packet, as well as the preference of the packet to be dropped in the presence of congestion.
Routers that support differentiated service not only have to look up the output interface for the destination address, but need to send the packet to the interface that best matches the differentiated services requirements. In other words, as well as matching the destination address, the FIB has to match differentiated services code points (DSCP).
FIB information for additional processing
Specific router implementations may, when a destination address or other FIB criterion is matched, specify other action to be done before forwarding (e.g., accounting or encryption), or applying an access control list that may cause the packet to be dropped.
- Interview with the author (of an MPLS-based VPN article), G. Pildush
- Wire Speed Packet Classification Without TCAM: One More Register (And A Bit Of Logic) Is Enough Q. Dong et al., ACM SIGCOMM 2006
- RAM lookup FIB & prefixes > /24, R. Whittle, Internet Research Task Force (IRTF) Routing Research Group mailing list, 2007
- Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, RFC2827, P. Ferguson & D. Senie, May 2000
- Ingress Filtering for Multihomed Networks, RFC 3704, F. Baker & P. Savola,March 2004
- Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, K. Nichols et al.,December 1998
RIBs and FIBs (aka IP Routing Table and CEF Table), Ivan Pepelnjak. http://blog.ipspace.net/2010/09/ribs-and-fibs.html