Concept and mechanism
In the studied Junos architecture, Routing Engine and Packet Forwarding Engine have distinct responsibilities. The former performs control and management functions and maintains routing information; the latter forwards traffic according to installed information. A packet destined for the router own SSH service differs from a transfer merely crossing the device between two hosts. The routing table can retain alternatives that are not the active forwarding choice. A list of known routes therefore does not prove every route is used or that load balancing exists between them. Platform, installation, and next-hop state remain relevant to the effective path.
Guided application
In a fictional incident, SSH is slow and RE CPU is high, but batch still transfers some data. Record these observations separately. Do not conclude total device failure or complete health merely because transit exists. Compare process load, events, and application symptoms before changing routing. A change can affect management without immediately preventing every installed flow; that does not guarantee service survives any future failure. For the PM, handover should include management checks and representative-traffic checks. For APS, it should explain which commands observe each plane and their limits. One dashboard showing green can hide distinct dependencies and lead to an unnecessarily broad intervention.
Slow SSH with active transit calls for RE analysis without assuming every link failed.
Common pitfalls
Transit as total health; known route as installed; local traffic as any TCP; one state for every plane.
Related topics: Addressing and capacity · CLI, candidate, and rollback · Access, inheritance, and recovery
Identify the affected function before choosing an intervention.
Reference: Router data flow and planes · JN0-106, effective 2026-04-06; Junos OS 21.2 exam baseline