A fleet garage installs a static network route whose next hop is not on a directly connected subnet. What must the router be able to do for that static to forward?
Select an answer to reveal the explanation.
Short Explanation
If the next hop isn’t sitting on the local driveway, the router has to look it up again — a recursive lookup — until it finds a real exit. No recursion, no delivery.
Full Explanation
If a fleet garage static network route lists a next hop that is not on a directly connected subnet, the router must recursively resolve that next hop through another matching route until it determines an exit interface and Layer 2 adjacency. Recursion is normal: the static says “send to 10.9.9.1,” and a connected or other route must explain how to reach 10.9.9.1. Without a resolvable path to the next hop, the static remains configured but cannot forward, which is a common municipal troubleshooting miss when someone points a static at a core address that itself depends on an IGP entry.
Ignoring recursive resolution and sending frames to a random MAC cannot produce correct delivery and would break Ethernet forwarding discipline. Static routes do not automatically convert into BGP aggregates; that confuses static installation with redistribution and summarization features. Disabling CEF so process switching “invents” a connected next hop is neither required nor a valid design fix for an unresolved next hop—fix the resolve path instead.
Exam caveat: recursive statics can create dependency chains; if the resolving route disappears, the static fails closed. Avoid recursive loops where route A depends on B and B depends on A. Prefer next hops that resolve via connected or highly stable routes on civic cores. Operational check: manually look up the next hop in the routing table, confirm an exit interface and adjacency can be derived, then test forwarding to the remote garage prefix only after that recursion succeeds end to end.