An engineer configures a static route on a co-op's aggregation router, but the next-hop IP address typed in isn't on any subnet directly attached to that router, it's only reachable through another route already sitting in the table. What must happen before this static route can actually be used to forward traffic?

When a static route's configured next-hop isn't itself directly reachable, Junos performs recursive next-hop resolution: it looks up the configured next-hop address as though it were a destination, following that lookup, potentially through more than one intermediate route, until it lands on a route with a directly connected, physical next-hop and outgoing interface, and only then can the original static route actually be installed and used for forwarding. Claiming the route becomes active immediately misunderstands the requirement; a static route with an unresolvable next-hop doesn't become usable just because the address is syntactically well-formed, since the router still has to prove it can actually reach that address before trusting the route. Claiming Junos automatically substitutes a default route ignores that the router never silently replaces what was explicitly configured with something unrelated; recursive resolution finds a path to the specific next-hop given, it doesn't invent a fallback in its place. Claiming the route is silently dropped at commit time is also wrong, since an unresolvable next-hop doesn't fail configuration syntax checking; the statement commits successfully and simply sits inactive in the routing table until resolution succeeds. A caveat is that recursive resolution depends on the resolving route staying valid, so if that underlying route disappears, the static route relying on it goes inactive too, even though nothing about the static route itself changed. An operational check is viewing the route's detail output to confirm it shows as active with a resolved, directly connected next-hop rather than sitting unresolved.