A campus engineer explains the hardware switching path on the city core. Which components correctly describe optimized CEF forwarding versus a software punt?
Select an answer to reveal the explanation.
Short Explanation
Hardware CEF is the express conveyor that already knows the exit chute (FIB) and the next-hop label (adjacency). A punt is yanking the package off the belt so a person at the CPU desk can figure it out slowly—fine for exceptions, terrible as the main plan.
Full Explanation
Optimized CEF forwarding on the city core uses the FIB plus adjacency information so packets can be switched in hardware or via the fast CEF path without per-packet process switching. A software punt, by contrast, sends packets to the CPU for slower process handling when features, exceptions, or incomplete state require it. Explaining the hardware switching path correctly means stating that hardware CEF leans on FIB and adjacency, while punts are the slower CPU exception path—not the preferred steady-state for ordinary civic application traffic.
Claiming hardware CEF ignores the FIB and floods every frame like an unmanaged hub describes neither CEF nor responsible campus forwarding. Preferring software punts for all civic VoIP because they guarantee EF treatment confuses QoS marking/queuing with punt behavior; punts hurt performance and do not magically create expedited forwarding. Restricting adjacency tables to wireless APs and denying their use by CEF on routers or switches is false—adjacency is integral to CEF on routing and switching platforms.
Exam caveat: hardware CEF = FIB + adjacency fast path; punt = CPU exception path. QoS EF is orthogonal and not a reason to prefer punts.
Operational check: verify CEF/hardware forwarding for representative civic flows, investigate punt reasons if CPU spikes, and ensure adjacency/FIB completeness so voice and data stay on the optimized path.