6.2 Static Route Configuration and Next-Hop Resolution
Key Takeaways
A static route still requires usable next-hop resolution and route selection.
In MD-CLI, the unicast static-route key includes route-type unicast.
A floating static route needs higher numerical preference than the intended primary route for the same prefix.
A summary discard route prevents default/summary loops without overriding valid more-specific routes.
A route entered by the operator
A static route supplies destination reachability through configuration rather than a dynamic routing advertisement. It is useful for a small stub network, a default gateway, a specific policy-controlled path, or a backup. It generates no routing-protocol updates, but it still uses route-table memory, next-hop resolution, and forwarding resources.
A static route does not automatically discover every failure along its path. The directly connected interface can fail and make a route unusable, but a more distant failure may leave the local next hop reachable. Tracking mechanisms can change this behavior when configured. Do not confuse “manually configured” with “immune to topology changes” or “always active.”
Work out the next hop first
Suppose R1 has 192.0.2.1/30 on its link to R2, and R2 has 192.0.2.2/30. R2 reaches customer subnet 198.51.100.0/24. The static route on R1 points to R2's adjacent 192.0.2.2, not to R1's own address or the remote customer's host.
The /30 range is 192.0.2.0 through 192.0.2.3. Its conventional usable endpoints are .1 and .2. The next hop must be usable in the relevant routing context. A route configured in Base does not automatically provide the same route inside a VPRN.
Return traffic also needs a path. If R2 and the destination host cannot route back toward the source, adding an outbound static route on R1 alone will not produce successful two-way communication.
MD-CLI example
Enter a candidate configuration and assume the connected R1–R2 interface is already operational. The modeled route key includes both the prefix and route type.
configure private
/configure router "Base" static-routes route 198.51.100.0/24 route-type unicast next-hop "192.0.2.2" admin-state enable
compare
validate
commit
This is an illustrative configuration fragment, not captured router execution. The next-hop object is administratively enabled. The route still needs a usable connected next hop and successful selection. The fragment deliberately uses MD-CLI syntax; the current Classic hierarchy uses static-route-entry, while older releases and documentation may show static-route.
Inspect /show router route-table protocol static and /show router arp. If the route is absent, inspect administrative state, interface reachability, competing routes, and the selected routing instance. If the route appears but traffic fails, investigate neighbor resolution, filters, downstream forwarding, and the return route.
Saving after commit depends on auto-config-save. If it is disabled, /admin save persists the committed running configuration to the configured startup location.
Direct and indirect resolution
A direct next hop belongs to an operational local subnet. R1 can resolve 192.0.2.2 on the R1–R2 Ethernet segment. ARP resolves that adjacent IPv4 address to a MAC; R1 does not ARP for every destination host behind R2.
An indirect next hop is resolved recursively through other eligible route information. For example, an operator can design a route around a remote system address, provided the configuration uses the supported indirect next-hop mechanism and an underlying route can resolve it. The recursion eventually needs a usable forwarding adjacency.
Do not assume that typing a remote address into an ordinary direct-next-hop field creates recursive routing automatically. The configured next-hop type and resolution rules matter. Circular dependencies cannot create reachability: a route cannot become usable merely by resolving through itself.
Default routing
The default prefix 0.0.0.0/0 matches every IPv4 destination, but it loses to every more-specific installed match. A stub router can use a default toward its upstream provider while retaining specific connected and internal routes.
A default route is not an instruction to broadcast an unknown packet. It is a specific forwarding entry with its own next-hop eligibility. If the default next hop is unusable, there is no general guarantee that the router finds another path unless another eligible route or tracking mechanism exists.
Floating static routes
A floating static route has a numerically higher preference than the intended primary route for the same prefix. SR OS normally assigns static routes preference 5 and OSPF internal routes preference 10. A default static route would therefore defeat OSPF for an identical prefix unless its preference is raised.
For an explicit example, set the backup static path's preference to 20 while the primary internal OSPF route has preference 10. OSPF wins while eligible. If the OSPF route is withdrawn and the backup next hop is usable, the static candidate can become active. A metric of 1 on the static route does not substitute for a preference change across sources.
A floating route to a /16 is also not a backup for every more-specific /24 in the same sense. Forwarding still uses longest-prefix match; analyze the actual installed prefixes and failure condition.
Discard routes and summary safety
A discard or blackhole route intentionally drops matching traffic. One use is protecting an advertised summary against a routing loop.
Suppose R1 advertises 10.20.0.0/16 to R2 but has only 10.20.1.0/24 and 10.20.2.0/24 internally. R1 also has a default toward R2. Traffic for missing 10.20.99.7 would otherwise follow R2's summary to R1 and R1's default back to R2. A discard route for the /16 on R1 stops that loop. The valid /24 routes still win by specificity.
Discarding a summary does not recover the missing destination. It provides a deliberate failure action for addresses the summary covers without a usable specific path.
Primary reference
Nokia MD-CLI static-route example, checked October 20, 2026. Additional tracking in that manual is optional and must be configured explicitly.
Route types at a glance
| Static-route role | Selection or forwarding purpose |
|---|---|
| Specific next-hop route | Reach an explicit destination prefix through a usable neighbor |
| Default | Match destinations without a more-specific installed route |
| Floating backup | Lose to the intended primary source through higher numerical preference |
| Summary discard | Drop holes in an advertised aggregate to prevent default/summary loops |
A backup static route should lose to an eligible internal OSPF route with preference 10 for the same prefix. Which static preference achieves that?
5
1
20
0
R1 advertises a /16 summary to R2 and has a default route toward R2. Why install a discard route for that summary on R1?
To stop summary/default loops for missing components while valid more-specific routes still win
To reserve bandwidth automatically
To ARP for all addresses in the /16
To encrypt the customer payload
How is an indirect static next hop resolved under a supported recursive-resolution configuration?
By ARPing for the remote address on every port
Through eligible underlying routing information until a usable forwarding adjacency is found
By ignoring the routing table
By creating a missing physical link automatically
Sections you finish are checked off in the contents.