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 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
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.
+---------------+ points +--------------+
| | | | a set +----> | | | | |
|---------------| of FE | |--------------|
| | | | Selection | | | | | |
|---------------| Entries | |--------------|
| | | |------------+ | |<----+
|---------------| |--------------| |
| | +--------------| | | | | |
+---------------+ | +--------------+ |
points to an |
adjacency entry |
| cefAdjTable |
| +---------------+ may point |
+->| | | | to a set |
|---------------| of FE |
| | | | Selection |
|---------------| Entries |
| | | |----------------+
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
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
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