Cisco Express Forwarding (CEF) describes a high speed switching mechanism that a router uses to forward packets from the inbound to the outbound interface. CEF uses two sets of data structures or tables, which it stores in router memory: Forwarding information base (FIB) - Describes a database of information used to make forwarding decisions. It is conceptually similar to a routing table or route-cache, although its implementation is different. Adjacency - Two nodes in the network are said to be adjacent if they can reach each other via a single hop across a link layer. CEF path is a valid route to reach to a destination IP prefix. Multiple paths may exist out of a router to the same destination prefix. CEF Load balancing capability share the traffic to the destination IP prefix over all the active paths. After obtaining the prefix in the CEF table with the longest match, output forwarding follows the chain of forwarding elements. Forwarding element (FE) may process the packet, forward the packet, drop or punt the packet or it may also pass the packet to the next forwarding element in the chain for further processing. Forwarding Elements are of various types but this MIB only represents the forwarding elements of adjacency and label types. Hence a forwarding element chain will be represented as a list of labels and adjacency. The adjacency may point to a forwarding element list again, if it is not the last forwarding element in this chain. For the simplest IP forwarding case, the prefix entry will point at an adjacency forwarding element. The IP adjacency processing function will apply the output features, add the encapsulation (performing any required fixups), and may send the packet out. If loadbalancing is configured, the prefix entry will point to lists of forwarding elements. One of these lists will be selected to forward the packet. Each forwarding element list dictates which of a set of possible packet transformations to apply on the way to the same neighbour. The following diagram represents relationship between three of the core tables in this MIB module. cefPrefixTable cefFESelectionTable + | | | | a set + | | | | | Selection | | | | | | | | | | | | | | + + | | points to an | adjacency entry | | | | cefAdjTable | | + +->| | | | to a set | | | | | | Selection | | | | | | | | | + Some of the Cisco series routers (e.g. 7500 & 12000) support distributed CEF (dCEF), in which the line cards (LCs) make the packet forwarding decisions using locally stored copies of the same Forwarding information base (FIB) and adjacency tables as the Routing Processor (RP). Inter-Process Communication (IPC) is the protocol used by routers that support distributed packet forwarding. CEF updates are encoded as external Data Representation (XDR) information elements inside IPC messages. This MIB reflects the distributed nature of CEF, e.g. CEF has different instances running on the RP and the line cards. There may be instances of inconsistency between the CEF forwarding databases(i.e between CEF forwarding database on line cards and the CEF forwarding database on the RP). CEF consistency checkers (CC) detects this inconsistency. When two databases are compared by a consistency checker, a set of records from the first (master) database is looked up in the second (slave). There are two types of consistency checkers, active and passive. Active consistency checkers are invoked in response to some stimulus, i.e. when a packet cannot be forwarded because the prefix is not in the forwarding table or in response to a Management Station request. Passive consistency checkers operate in the background, scanning portions of the databases on a periodic basis. The full-scan checkers are active consistency checkers which are invoked in response to a Management Station Request. If 64-bit counter objects in this MIB are supported, then their associated 32-bit counter objects must also be supported. The 32-bit counters will report the low 32-bits of the associated 64-bit counter count (e.g., cefPrefixPkts will report the least significant 32 bits of cefPrefixHCPkts). The same rule should be applied for the 64-bit gauge objects and their assocaited 32-bit gauge objects. If 64-bit counters in this MIB are not supported, then an agent MUST NOT instantiate the corresponding objects with an incorrect value; rather, it MUST respond with the appropriate error/exception condition (e.g., noSuchInstance or noSuchName). Counters related to CEF accounting (e.g., cefPrefixPkts) MUST NOT be instantiated if the corresponding accounting method has been disabled. This MIB allows configuration and monitoring of CEF related objects.