An engineer at a regional ISP is asked why a core router forwards millions of packets per second for ordinary subscriber traffic, yet a sudden flood of malformed packets requiring Routing Engine processing can noticeably slow the router's control-plane responsiveness. What architectural reason best explains this difference in behavior?
Select an answer to reveal the explanation.
Short Explanation
The forwarding plane is built like a factory assembly line - purpose-made hardware doing one repetitive job extremely fast. The Routing Engine is more like a general office with a CPU that can do lots of different things, but not at that same blistering, dedicated pace. So when something forces traffic off the fast assembly line and up into that office - like a flood of malformed packets - things slow down there in a way they wouldn't on the hardware path.
Full Explanation
Junos deliberately separates a purpose-built, hardware-accelerated forwarding plane from a general-purpose control plane precisely because these two workloads have very different performance profiles: the Packet Forwarding Engine uses dedicated forwarding hardware capable of sustaining millions of packets per second for traffic it can resolve directly from its programmed tables, while the Routing Engine relies on a general-purpose CPU to run routing protocols, configuration, and any exception-traffic processing. A flood of malformed or unusual packets that cannot be resolved by the forwarding hardware gets punted to the Routing Engine as exception traffic, and because the Routing Engine's CPU has finite general-purpose capacity, a large enough flood can noticeably degrade its responsiveness even while ordinary transit traffic keeps flowing normally through the forwarding plane. The distractors describe protections or equivalences that do not exist by default: the two planes do not share the same hardware, prioritization of subscriber traffic over malformed traffic is not automatic without specific protective mechanisms configured, and malformed packets are not automatically dropped before reaching any component - some categories require Routing Engine evaluation to be identified as invalid in the first place. This is exactly why control-plane protection is a real operational concern for ISPs facing traffic floods. A useful check during any suspected flood is comparing forwarding-plane traffic levels, which typically remain healthy, against Routing Engine CPU utilization, which is what actually reflects an exception-traffic overload.