Jump to content

Forwarding information base

From Wikipedia, the free encyclopedia
(Redirected from Forwarding Information Base)

A forwarding information base (FIB), also known as a forwarding table or MAC table, is most commonly used in network bridging, routing, and similar functions to find the proper output network interface controller to which the input interface should forward a packet. It is a dynamic table that maps MAC addresses to ports. It is the essential mechanism that separates network switches from Ethernet hubs. Content-addressable memory (CAM) is typically used to efficiently implement the FIB, thus it is sometimes called a CAM table.

[edit]

At the data link layer, a FIB is most notably used to facilitate Ethernet bridging based on MAC addresses. Other data-link-layer technologies using FIBs include Frame Relay, Asynchronous Transfer Mode (ATM) and Multiprotocol Label Switching (MPLS).

Bridging

[edit]

The role of an Ethernet switch is to forward Ethernet frames from one port to another. The presence of a FIB is one attribute that separates a switch from a hub. Without a functional FIB, all frames received by a network switch would be echoed back out to all other ports, much like an Ethernet hub. In bridging packets between ports, a switch should only emit a frame on the port where the destination network device resides (unicast), unless the frame is for all nodes on the switch (broadcast), multiple nodes (multicast) or if the switch doesn't know where the destination device resides (unicast flood).

Switches learn the port on which they first saw a particular source address and associate that port with that address. When the bridge subsequently receives a frame with a destination address in its FIB, it sends the frame out the port stored in the FIB entry.

The FIB is a memory construct used by Ethernet switch to map a station's MAC address to the switch port the station is connected to. This allows switches to facilitate communications between connected stations at high speed.

Frame Relay

[edit]

While the exact mechanics of a forwarding table is implementation-specific, the general model for Frame Relay is that 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

[edit]

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 by virtual path identifier (VPI) and virtual circuit identifier (VCI). 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 network map one of the standard ATM end-to-end identifiers, such as an NSAP address, to the next-hop VPI/VCI.

Multiprotocol Label Switching

[edit]

MPLS has many similarities, at the forwarding level, to ATM. The label edge routers 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 which outgoing interface is to receive the MPLS packet, and what label to use when sending the packet out that interface.

Applications at the network layer

[edit]

Network layer addresses, such as IP addresses, are used on different types of media and can be handled similarly in all cases.

Forwarding

[edit]

FIBs are optimized for fast lookup of destination addresses and can improve performance of forwarding compared to using the routing information base (RIB) directly. The RIB is optimized for efficient updating by routing protocols and other control plane methods, and contain the full set of routes learned by the router. 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 routes cached in a small FIB, and various implementations moved to having FIBs in one-to-one correspondence with the RIB.[1]

Ingress filtering against denial of service

[edit]

FIBs can also play a role in an Internet best current practice (BCP) of ingress filtering. Though the simplest form of ingress filtering is to use access-control lists to drop packets with improper source addresses, the 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.[citation needed]

While the IETF document BCP 38 on ingress filtering[2] does not specify a method of implementing source address filtering, some router vendors have implemented a mechanism that employs reverse-path forwarding lookups in the router's tables to perform this check. 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 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 that employ routing information lookup, though this approach can be challenging when managing routers that 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.[3]

Quality of service

[edit]

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).[4][failed verification]

Access control and accounting

[edit]

Specific router implementations may, when a destination address or other FIB criterion is matched, specify another action to be done before forwarding (e.g., accounting or encryption), or apply an access control list that may cause the packet to be dropped.

Attacks

[edit]

CAM tables can be targeted for setting up a man-in-the-middle attack. A threat agent which has control of a device connected to an Ethernet switch can use MAC flooding to attack the switch's CAM table. If the table fills up, other traffic is treated as broadcast, unknown-unicast and multicast traffic and is forwarded to all ports making it available to the attacker.

References

[edit]
  1. ^ Wire Speed Packet Classification Without TCAM: One More Register (And A Bit Of Logic) Is Enough Q. Dong et al., ACM SIGCOMM 2006
  2. ^ P. Ferguson & D. Senie (May 2000). Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing]. doi:10.17487/RFC2827. RFC 2827.
  3. ^ F. Baker; P. Savola (March 2004). Ingress Filtering for Multihomed Networks. doi:10.17487/RFC3704. RFC 3704.
  4. ^ Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, K. Nichols et al., December 1998
[edit]