Forwarding information base: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Caesar Schinas
m (Robot: Changing template: TOC-right)
imported>Caesar Schinas
m (Bot: Delinking years)
Line 36: Line 36:
FIBs can also play a role in an Internet Best Current Practice 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.  
FIBs can also play a role in an Internet Best Current Practice 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<ref>[http://www.ietf.org/rfc/rfc2827.txt Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing], RFC2827, P. Ferguson & D. Senie, [[May]] [[2000]]</ref> 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. 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.
While the IETF document BCP 38 on ingress filtering<ref>[http://www.ietf.org/rfc/rfc2827.txt Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing], RFC2827, P. Ferguson & D. Senie, [[May]] 2000</ref> 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. 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 are conceptually simpler, than methods which employ routing information lookup, though packet filtering requires more maintenance than [[unicast reverse path filtering]]. Ingress filtering for multihomed routers<ref>[http://www.ietf.org/rfc/rfc3704.txt Ingress Filtering for Multihomed Networks],RFC 3704, F. Baker & P. Savola,March 2004</ref> 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.
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 are conceptually simpler, than methods which employ routing information lookup, though packet filtering requires more maintenance than [[unicast reverse path filtering]]. Ingress filtering for multihomed routers<ref>[http://www.ietf.org/rfc/rfc3704.txt Ingress Filtering for Multihomed Networks],RFC 3704, F. Baker & P. Savola,March 2004</ref> 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.

Revision as of 06:28, 9 June 2009

This article is developing and not approved.
Main Article
Discussion
Definition [?]
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

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 send a packet to be transmitted by the router.

In contrast to Routing Information Bases (RIB), also known as 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 [1]. 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 [2].

Applications for Data Link and other Link-Local Technologies

A link-local technology, such as Medium Access Control (MAC) protocols on local area networks, has an address that has no significance beyond a single medium. In contrast, network layer addresses, such as IP, are conceptually similar on all media in the routing domain.

Besides IEEE 802.1 bridging of MAC layer addresses, other link-local technologies using forwarding tables include Frame Relay and Asynchronous Transfer Mode switches, and Multiprotocol Label Switching. ATM has both link-local addresses and addresses that have end-to-end significance in the ATM domain.

Bridging

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 floods it out all active interfaces, except received interface. As is also done with broadcast frames.

Frame Relay

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, an ATM routing protocol with considerable similarity to the Open Shortest Path First (OSPF) used for IP routing.

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"[3], has many similarities, at the forwarding level, to ATM. The Label Edge Routers (LSR) 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 in Network Layer Routing

FIBs in Ingress Filtering against Denial of Service

FIBs can also play a role in an Internet Best Current Practice 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[4] 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. 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 are conceptually simpler, than methods which employ routing information lookup, though packet filtering requires more maintenance than unicast reverse path filtering. Ingress filtering for multihomed routers[5] 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.

FIBs in Differentiated Services/Quality of Service Routing

IP Differentiated Services provides an additional method to select outgoing interfaces, based on a field [6] 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.

References

  1. [http://ieeexplore.ieee.org/iel5/8454/26643/01189046.pdf Wire Speed Packet Classification Without TCAM: One More Register (And A Bit Of Logic) Is Enough] Q. Dong et al, ACM SIGCOMM 2006
  2. RAM lookup FIB & prefixes > /24, R. Whittle, Internet Research Task Force (IRTF) Routing Research Group mailing list, 2007
  3. Interview with the author (of an MPLS-based VPN article),G. Pildush
  4. Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, RFC2827, P. Ferguson & D. Senie, May 2000
  5. Ingress Filtering for Multihomed Networks,RFC 3704, F. Baker & P. Savola,March 2004
  6. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,RFC 2474, K. Nichols et al.,December 1998