CEF: how a packet gets from the RIB to the wire without touching the processor
Every mechanism has a step-by-step animation, the configuration explained line by line and the exam notes. Where a parameter changes the outcome, you get a simulator in which you change it yourself.
TL;DR
Cisco Express Forwarding switches packets with two tables built in advance: the FIB, a copy of the routing table reduced to the best route per prefix, with the next hop resolved down to an interface, and the adjacency table, with the L2 header pre-written for every neighbor. For every packet, a single longest-prefix lookup, one header copied, TTL−1 and done — the processor is never touched. The exceptions (glean, receive, punt, drop) go up to the processor or are dropped, and they explain almost every incident. The FIB underpins per-flow load sharing, MPLS (LFIB, push / swap / pop), fast convergence (hierarchical FIB, BGP PIC), uRPF and NetFlow. On large platforms the FIB is copied to every line card, into TCAM: dCEF.
How to read the notes: red = critical for the exam, green = theory, blue = numbers, yellow = pitfalls, cyan = differences between platforms (IOS-XE, IOS-XR, NX-OS) and standards. In the animations, the configuration lines used in the current step are highlighted automatically; the ← → arrows change the step when the animation is selected.
The analogy, in short
Think of a postal sorting center: instead of every letter going to the manager with the atlas (the processor with the routing table), the hall has shelves pre-labeled "truck 3, ramp B" (FIB) and outer envelopes already written for every driver (adjacency). The sorter picks the shelf with the most precise description and puts the letter in the envelope — without asking anyone.
The model holds up to §8. At §9 (uRPF, NetFlow) it still works, but hardware, multicast and fragmentation have no equivalent; see the full analogy and its limits in §12.