Junos Static Routes and Qualified Next Hops Explained

Static routing is the workhorse of the network edge: stub sites, point-to-point uplinks and default routes are almost always built from static routes because they are simple and predictable. On Junos OS a static route is defined under routing-options and has a global preference (administrative distance) of 5, which makes it preferred over any dynamic route unless you change it. This article explains basic Junos static route configuration and the qualified-next-hop feature that gives you deterministic failover between two upstreams.

Basic Junos Static Route Configuration

Junos routes are configured with set commands under edit routing-options static. A route becomes active only when its next hop is reachable:

set interfaces ge-1/2/0 unit 0 family inet address 172.16.1.1/24
set routing-options static route 192.168.47.0/24 next-hop 172.16.1.2

The provider router R1 reaches the customer prefix 192.168.47.0/24 through the point-to-point link. On the customer side you typically configure a default route pointing back at the provider:

set routing-options static route 0.0.0.0/0 next-hop 172.16.1.1

IPv6 works the same way: set routing-options static route 2001:db8:2::/48 next-hop 2001:db8:1:1::2 and a default route ::/0 on the stub side.

When a Static Route Is Considered Active

The single most important behaviour of a Junos static route is that it is not installed in the forwarding table until its next hop resolves. If 172.16.1.2 is not reachable through a connected interface, or through another route that resolves to a connected interface, the static route stays in the routing table marked Unusable and never reaches the forwarding table. Nothing is advertised, nothing is used, and the configuration looks perfectly correct — which is why "the static route is missing" is usually a reachability problem one hop away.

Junos gives you several ways to influence that resolution:

set routing-options static route 10.10.10.0/24 next-hop 192.0.2.1 resolve
set routing-options static route 10.10.10.0/24 next-hop 192.0.2.1 no-readvertise
set routing-options static route 203.0.113.0/24 discard
set routing-options static route 203.0.113.0/24 reject
set routing-options static route 0.0.0.0/0 next-hop 172.16.1.1 retain
set routing-options static route 198.51.100.0/24 next-hop 172.16.1.2 passive

• resolve — allows an indirect next hop: the route becomes active when the next hop is resolvable through another route in the table, not only when it is directly connected. Use it when the next hop sits behind a transit subnet.
• no-readvertise — marks the route so that it is not re-advertised into a routing protocol by policy, useful for management or test prefixes.
• discard — installs a blackhole route: traffic is dropped with no ICMP response. Standard for summarising unallocated space inside a customer aggregate.
• reject — similar, but returns an ICMP unreachable, which makes the blackhole visible to troubleshooting.
• retain — keeps the route in the forwarding table even when the routing protocol process or the next hop's route is temporarily unavailable, which prevents a micro-loop during reconvergence.
• passive — installs the route only for advertisement purposes; it is not used for forwarding.

Route Preference and Metrics

The global default preference for static routes is 5, lower (better) than OSPF (10) and BGP (170). You can raise it when a static route must act as a backup to a dynamic route, e.g. a floating static default that only appears when BGP disappears:

set routing-options static route 0.0.0.0/0 next-hop 172.16.1.1 preference 200

The preference numbers worth keeping in mind when you build floating statics are Direct 0, Static 5, OSPF internal 10, OSPF external 150, IS-IS 15/18, RIP 100 and BGP 170. A floating static therefore needs a preference higher than the protocol it backs up — 200 for a BGP-backed default, 110 for an OSPF-backed one — so that it only wins when the dynamic route is gone. Preference is compared before anything else: a route with better preference is installed regardless of path length, which is what makes this technique deterministic.

Qualified Next Hops for Deterministic Failover

When one destination has several next hops, Junos picks one for the forwarding table; without extra configuration the choice can look random. The qualified-next-hop statement lets you assign a different preference and metric to each next hop so the best path is always chosen, and the route automatically switches when that next hop becomes unreachable:

set routing-options static route 192.168.47.0/24 next-hop 172.16.1.2
set routing-options static route 192.168.47.0/24 qualified-next-hop 192.168.2.2 preference 25

Here the primary next hop 172.16.1.2 keeps the default preference, while the backup 192.168.2.2 is marked preference 25. The router installs the lower-preference path and fails over to the qualified next hop only when the primary is unreachable. Qualified next hops can also carry BFD settings so failure detection is faster than interface hold timers — useful when the two next hops share the same physical link.

Qualified Next Hop Versus Plain Multiple Next Hops

The distinction matters more than the syntax suggests. Listing two plain next hops on the same prefix gives you load balancing, not failover: both paths are installed as equal-cost multipath when both resolve, and traffic is spread across them. Adding a qualified-next-hop with its own preference turns the same two addresses into an active/standby pair, because the preference attached to the qualified hop is used as the route's preference when that hop is the installed one. A third option is to configure two qualified next hops with different preferences and no plain next hop at all, which is the cleanest way to express "send everything to A, and to B only if A disappears":

set routing-options static route 192.168.47.0/24 qualified-next-hop 172.16.1.2 preference 5
set routing-options static route 192.168.47.0/24 qualified-next-hop 192.168.2.2 preference 25
set routing-options static route 192.168.47.0/24 qualified-next-hop 198.51.100.2 preference 50

With this configuration you get a deterministic three-tier ladder: the 5 wins whenever it resolves, 25 takes over when the first hop fails, and 50 is the last resort. Each step is visible in show route detail, and each step can carry its own metric so that any protocol redistributing the route inherits a sensible value.

Preference and Metric: Which One Does What

The two parameters on a qualified next hop are easy to confuse. Preference is compared between candidates for the same prefix and decides which next hop is installed in the forwarding table; it is the failover control. Metric is the value carried with the route once it is installed; it does not influence local selection among the static candidates but it is what other protocols and other routers see when the route is redistributed or re-advertised. A practical rule: use preference to express the failover order, and use metric when the static route feeds a policy that exports it, for example into OSPF as an external route with a controlled metric.

set routing-options static route 192.168.47.0/24 qualified-next-hop 172.16.1.2 preference 5 metric 10
set routing-options static route 192.168.47.0/24 qualified-next-hop 192.168.2.2 preference 25 metric 100

Adding BFD to a Qualified Next Hop

Interface down events are slow by definition — an optical link takes time to declare itself dead, and a path failure behind a switch can be invisible for seconds. Bidirectional forwarding detection gives a sub-second trigger, and it can be attached directly to a qualified next hop so that only the failover path is affected.

set routing-options static route 192.168.47.0/24 qualified-next-hop 172.16.1.2 preference 5
set routing-options static route 192.168.47.0/24 qualified-next-hop 172.16.1.2 bfd-liveness-detection minimum-interval 300
set routing-options static route 192.168.47.0/24 qualified-next-hop 172.16.1.2 bfd-liveness-detection multiplier 3
set routing-options static route 192.168.47.0/24 qualified-next-hop 192.168.2.2 preference 25
set routing-options static route 192.168.47.0/24 qualified-next-hop 192.168.2.2 bfd-liveness-detection minimum-interval 300
set routing-options static route 192.168.47.0/24 qualified-next-hop 192.168.2.2 bfd-liveness-detection multiplier 3

With 300 ms intervals and a multiplier of 3, failure is declared after roughly 900 ms of missed packets, and the static route moves to the standby hop without waiting for a link-state event. BFD is most valuable when both next hops are reachable over the same physical link — the case where interface state cannot distinguish a working primary from a silent one, such as a carrier-side routing failure or a static route pointing at a firewall cluster.

Tagging Static Routes and Redistributing Them

A static route that exists only to be redistributed is much easier to manage with a tag. Adding tag to the route lets a policy-statement match it explicitly instead of relying on protocol static, which would also match every other static route on the box.

set routing-options static route 192.168.47.0/24 next-hop 172.16.1.2 tag 4711
set policy-options policy-statement EXPORT-STATIC term CUSTOMER-47 from tag 4711
set policy-options policy-statement EXPORT-STATIC term CUSTOMER-47 then accept
set protocols ospf export EXPORT-STATIC

Set a community on the exported route when the other side needs to classify it, and remember that the tag travels with the route inside the local routing table but is not carried in OSPF or BGP by default — a policy must map it to a metric or a community if it has to survive the boundary.

IPv6 and Dual-Stack Statics

IPv6 statics use the same hierarchy with a different family in the prefix. The one IPv6-specific detail worth knowing is that a next hop may be a link-local address (fe80::), in which case you must also tell Junos which interface to resolve it through:

set routing-options static route 2001:db8:2::/48 next-hop 2001:db8:1:1::2
set routing-options static route ::/0 next-hop fe80::1
set routing-options static route ::/0 next-hop fe80::1 interface ge-1/2/0.0

On a dual-stack edge, configure the IPv4 and IPv6 defaults as a pair and give them the same preference so that failover behaviour is symmetrical; a common mistake is to leave the IPv6 default with the default preference 5 while the IPv4 default is a floating 200, which produces an edge that fails over in one family and not the other.

Verification

show route 192.168.47.0/24
show route protocol static
show route table inet.0
show route 192.168.47.0/24 detail
show route forwarding-table destination 192.168.47.0/24
show configuration routing-options static | display set

The asterisk in the output marks the active route; the Preference column shows the per-route preference, and you can confirm the qualified next hop is installed only as a backup. If a static route is not active, verify the next hop is reachable and there is no route with a lower preference competing for the same prefix — the same reasoning used when troubleshooting Junos IRB/ARP reachability. Static routes pair naturally with commit-confirmed change management, described in our Junos commit confirmed guide. For switching-side VLAN and IRB design see our Junos VLAN configuration examples.

show route detail is the command that answers the failover question directly: it lists the active next hop, the qualified next hops and their states, so you can see that the preference-25 hop is present but not selected. Then confirm the data plane agrees with the control plane with show route forwarding-table, which shows the actually installed next hop — if the two disagree, you are looking at a stale forwarding entry rather than a routing decision.

Troubleshooting Inactive Static Routes

• Next hop not reachable. The most common cause. Check that the next hop address is inside a connected subnet on an up interface, or add resolve if it is indirect.
• Next hop equal to the local interface address. Junos rejects a next hop that matches the local address; a /31 or /32 link needs the peer address, not the local one.
• Competing route with better preference. A connected or dynamically learned route for the same prefix wins; check with show route 192.168.47.0/24 detail | match Preference.
• Interface down. A static route whose next hop sits behind a down interface stays hidden until the interface comes back, even with retain configured on the next-hop route.
• Route exists but traffic is dropped. That is a discard or reject route, or a firewall filter — not a routing problem.
• Wrong family. An IPv6 route configured with an IPv4 next hop is rejected at commit; check the commit error output rather than the show output.

Best Practices for Static Route Design

• Use qualified next hops with explicit preferences rather than relying on Junos's selection among equal next hops.
• Give every floating static a preference that is clearly worse than the protocol it backs up, and document the number in the description.
• Attach BFD to qualified next hops when the two paths share a physical link or the transit is a carrier network.
• Tag static routes that are redistributed so the export policy stays readable as the network grows.
• Keep the static table small; anything that needs more than a handful of entries is usually better served by a routing protocol.
• Verify with show route detail and show route forwarding-table, not just with show route.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/static-routing/topics/topic-map/config_static-routes.html