Content

| 5.2 |  | Cisco Express Forwarding |
| 5.2.2 |  | Comparing MLS and CEF |

MLS is a flow-based model that entails software path handling of the first packet in a given flow. This, in turn, creates a cache entry that can be used by subsequent packets in the flow for accelerated performance. Although this model works extremely well, it has been shown that in environments such as those found in the core of large enterprise networks, this model might not always prove optimal. Specifically, three areas have been identified in which a flow-based model is suboptimal.

Anytime a large number of routers are controlled by a large number of independent organizations, it is possible to encounter situations in which some devices negatively affect the stability of other devices. In this case (a peering relationship), router instability or flapping routes leads to the purging of previously cached data. In a flow-based model, the loss of cached entries requires that the first packet of a given flow be handled within the software path. In a peering situation, such as that required to support the core of an enterprise network, this means that potentially tens of thousands of flows would need to be relearned or cached by the software path to enable further hardware acceleration. However, it is difficult to scale software-based forwarding to simultaneously handle tens of thousands of concurrent flows per second. So stability, and the ability to withstand route flaps, is critical. The CEF-based forwarding model is designed to handle these situations gracefully and to minimize the impact of these events on network stability.

Another area in which a flow-based model encounters scalability challenges is with respect to the actual number of flows that could be cached in the necessary lookup tables. Recall that a flow entry can be expressed in one of several ways, including destination-ip, source-destination-ip, and ip-flow. The greater the granularity selected the more specific the flow information will be, but the lower the access and storage efficiency. For example, multiple entries are likely to map to a given entry for a destination-ip flow (for example, many clients all accessing a single server). When ip-flow mode is selected, full protocol and port information is stored in addition to the full source and destination IP addresses. This, in turn, reduces the likelihood that any two entries will be able to share a given flow entry. Although in a large percentage of the enterprise networks in existence today this is not cause for concern. As networks grow and the number of flows that must be supported increases (such as in a service-provider environment), this can lead to a situation in which the number of entries exceeds the available flow cache table space. This leads to suboptimal packet handling, in that packets not matched in the flow cache must be processed in software. One option is to change the flow mask to specify a less-specific mask, such as destination-ip. This increases cache efficiency, but it too has its limitations, beyond which software processing will be required. Although the simple answer to the problem of exceeding the size of the flow cache would appear to be increasing the number of possible entries available, in practice it is not so simple. There is a direct relationship between the speed of hardware-based forwarding and the size of the flow cache. Simply increasing the size of the flow cache does not guarantee that the appropriate lookup engine can parse the table sufficiently fast enough to forward flows in hardware at high speed. It would then seem logical to increase the speed of the lookup engine to work against the increased flow cache table. To a certain extent this approach could be made to work, but network administrators would have to continually upgrade equipment, an extremely costly and inefficient solution.

A cache-based forwarding model relies on actual traffic flows in order to establish cache entries for expedited forwarding. In a classical enterprise environment, this model has proven highly effective, because traffic patterns associate a large number of sources with a much smaller number of destinations. An example is a traditional centralized server farm, in which a large number of clients send traffic to and receive traffic from a much smaller number of servers. When comparing these traffic patterns to those of the Internet, it is far less likely to achieve the many-to-one ratio typified by the enterprise data center. Because the Internet is a global entity, it becomes increasingly difficult to maintain the flow cache and to ensure the integrity of the data therein. This means that a certain amount of cache flux must be expected in terms of the maintenance required to keep the state of the flow cache current. This is reflected in terms of CPU utilization.

With flow-cached models, a complete forwarding table must be maintained for the proper handling of first packets by the CPU or packets that for some other reason are incapable of being processed in hardware. After the CPU makes a forwarding decision (part of which involves a lookup against the routing table), an entry is made in the flow cache table, and subsequent packets are handled in hardware.

With a CEF-based mechanism, the challenges presented by flow caching models are greatly reduced, and hence scalability is greatly increased. All packets, including the first packet in a given flow, are handled in hardware. A routing table is still maintained by the router CPU, but two additional tables are created in the CEF-based model:

- Forwarding Information Base
- Adjacency Table
- NetFlow Table

The first of these tables is a copy of the forwarding information from the routing table. It is called the Forwarding Information Base (FIB) table. The FIB table contains the minimum information from the routing table necessary to forward packets. The FIB table does not contain any routing protocol information.
The second table is called the adjacency table. The adjacency table maintains a database of node adjacencies (two nodes are said to be adjacent if they can reach each other through a single Layer 2 hop) and their associated Layer 2 MAC rewrite or next hop information.
The third table is the NetFlow table, which provides network accounting data. The NetFlow table is updated in parallel with the CEF-based forwarding mechanism provided by the FIB and adjacency tables.

By performing a high-speed lookup against the FIB and adjacency, a forwarding decision along with the appropriate rewrite information can be accessed in a highly efficient and consistent manner, while also providing a mechanism offering a high degree of scalability.

Although high-end Cisco routers have offered support for CEF for several years now, some differences between the CEF implementation on Catalyst switches and Cisco routers should be pointed out. Specifically, both implementations provide the following:

- High-speed forwarding based on a “longest address match” lookup
- Equal-cost path load balancing
- Reverse Path Forwarding (RPF) checks
- Invalidation of less-specific routes

The CEF implementation on the Catalyst 6000 family also adds the following:

- Support for IP multicast
- Support for IPX forwarding
- Hardware-based forwarding of rates up to 210 Mpps in distributed CEF mode

Supported features of the CEF implementation on the Cisco routers only:

- The ability to turn off CEF-based forwarding
- CEF per-prefix and per-prefix length accounting
- Accounting data from load-sharing paths
- Per-packet load balancing

CEF is supported on Catalyst 8500 switch routers, Catalyst 3550 switches, Catalyst 2948G-L3 switches, Catalyst 4000 switches, and Catalyst 6000 switches. Cisco routers running Cisco IOS Software Release 12.2 or later also support CEF. Some routers, such as the 7500 series, supported CEF beginning with Cisco IOS Software Release 12.0.

The Catalyst 4000 switch supports CEF in the following combinations:

- With the Layer 3 Services Module
- With the Access Gateway Module
- With Supervisor Engine III or the recently released Supervisor Engine IV

The remainder of this module focuses on CEF technology in the context of Catalyst 6000 family switches. In particular, the Catalyst 4000 Supervisor Engine III multilayer switching mechanism does rely on CEF, but the architecture and Layer 2/3/4 packet flow methodology are similar, but not identical, to that of the Catalyst 6000.

For Catalyst 6000 switches, the CEF hardware requirements are Supervisor Engine 2, MSFC2, and PFC2.