You can configure either Bidirectional Forwarding Detection (BFD) or Response Time Reporter (RTR) probes to further control when a static route is installed in the routing table. Using either BFD or RTR, static route installation is based on two factors: whether the next hop to the specified destination is resolved, and whether an IP service running above the static route application is currently available.
Next-hop verification is useful for static route configurations in which the layer 2 and layer 3 interfaces are up and the next hop to the specified destination is available, but the IP services that run above the static route are currently unavailable. When the upper-layer IP services are unavailable, the router does not install the static route in its routing table.
Static routes on E Series routers can use BFD to verify the availability of the next hop and obtain the state of the IP service. For additional information about BFD, see JunosE IP Services Configuration Guide.
If you specify the bfd-liveness-detection keyword with a minimum receive interval, minimum transmit interval, or multiplier when you issue the ip route command to establish a static route, the router verifies the next-hop status and installs the static route in the routing table under the following conditions:
![]() | Note: BFD next-hop verification does not currently function in a multi-hop configuration. |
You can further control the installation of static routes by specifying the last-resort keyword, which is valid when you use the bfd-liveness-detection keyword in the ip route command. The last-resort keyword instructs the router to install the static route in the routing table even if the specified BFD operation is unreachable, provided that no other static route to the same network prefix is available.
The static route is removed from the routing table if the next hop is no longer reachable and reinstalled when the route becomes reachable again.
You can enable BFD on a static route using the ip route command with the bfd-liveness-detection keyword.
You can use the following optional keywords along with the bfd-liveness-detection keyword:
You can change parameters at any time without stopping or restarting the existing session; BFD automatically adjusts to the new parameter value. However, no changes to BFD parameters take place until the values resynchronize with each BFD peer.
To enable BFD on a static route with:
Use the no version to remove the static route from the routing table and thereby remove BFD from that static route.
To enable BFD next hop verification between two adjacent peers, you configure each peer as follows:
Static routes on E Series routers can use RTR probes configured as echo (ping) types to verify the availability of the next hop and obtain the state of the IP service. For more information about using RTR, see Response Time Reporter.
If you specify the verify rtr keywords with an RTR operation number when you issue the ip route command to establish a static route, the router verifies the next-hop status and installs the static route in the routing table only if both of the following conditions are met:
You can further control the installation of static routes by specifying the last-resort keyword, which is valid only when you use the verify rtr keywords in the ip route command. The last-resort keyword instructs the router to install the static route in the routing table even if the specified RTR operation is unreachable, provided that no other static route to the same network prefix is available.
You can establish a static route and associate it with a configured RTR operation using the ip route command with the verify rtr keyword.
The verify rtr keyword instructs the router to install the static route in the routing table only if the next hop to the specified destination address is resolved and if the specified RTR operation is currently reachable. When you use the verify rtr keyword, you must also specify the number of the associated RTR operation.
Optionally, you can include the last-resort keyword when you use the verify rtr keyword to instruct the router to install the static route in the routing table even if the specified RTR operation is currently unreachable, provided that no other static route to the same network prefix is available.
To establish a static route and associate it with a configured RTR operation:
Use the no version to remove a static route from the routing table.
This topic describes how to configure the RTR next-hop verification feature. Although this configuration example uses Fast Ethernet interfaces, E Series routers support next-hop verification on any type of lower-layer interface.
This example uses the following software and hardware components:
![]() |
|
Figure 1 shows a sample configuration that illustrates the next-hop verification feature. In this example, two Fast Ethernet interfaces are configured between a remote system and an E Series router: Fast Ethernet interface 4/0 and Fast Ethernet interface 4/1. At any given time, only one of these interfaces forwards IP traffic, even though the associated layer 2 interfaces may be up concurrently.
On the E Series router, Fast Ethernet interfaces 4/0 and 4/1 are configured as unnumbered IP interfaces. In addition, each interface has an RTR probe configured as an echo type that sends requests over the interface to determine its availability. RTR 10 sends requests over Fast Ethernet interface 4/0, and RTR 11 sends requests over Fast Ethernet interface 4/1.
In this example, both RTR 10 and RTR 11 use the IP address of the remote system (10.1.1.2) as the target address. When you configure multiple RTR entries to use the same target address, you must set the receive-interface attribute to specify the interface on which the probe expects to receive responses. (See Step 4c.) This action enables the router to map incoming responses to the proper RTR entry, even when multiple RTR entries have the same target address.
Figure 1: Sample Configuration for Next-Hop Verification

The ip route command is issued for each interface with the verify rtr and last-resort keywords to establish the necessary static routes. (See Steps 6 and 7.) This command causes the results described in Table 1, based on the status of the associated RTR operations.
Table 1: Next-Hop Verification Results for Sample Configuration
RTR 10 Status | RTR 11 Status | Results |
|---|---|---|
Up | Up | The router installs an equal-cost multipath (ECMP) route to 10.1.1.2 in the routing table, using Fast Ethernet interfaces 4/0 and 4/1 as the next hops. |
Up | Down | The router installs a route to 10.1.1.2, using Fast Ethernet interface 4/0 as the next hop. |
Down | Up | The router installs a route to 10.1.1.2, using Fast Ethernet interface 4/1 as the next hop. |
Down | Down | Although both RTR operations are down, the last-resort keyword instructs the router to install an ECMP route to 10.1.1.2, using Fast Ethernet interfaces 4/0 and 4/1 as the next hops. When all of the RTR operations associated with your static routes are down, you can control which route is installed in the routing table by including the last-resort keyword in the ip route verify rtr command only for the route that you want to install. |
To configure the next-hop verification example shown in Figure 1:
You must configure the RTR probe as an echo type to use next-hop verification. For information, see Configuring the Probe Type for RTR.
You must set the receive-interface attribute when multiple RTR operations use the same target address. For information, see Setting the Receiving Interface for the RTR Entry.
You must configure both the test-failure and test-completion reaction conditions to use next-hop verification. For information, see Setting the Reaction Conditions for the RTR Probe.
This command creates a static route and installs it in the routing table only if RTR 10 is currently reachable or if no other static route to IP destination address 10.1.1.2 is usable.
This command creates a static route and installs it in the routing table only if RTR 11 is currently reachable or if no other static route to IP destination address 10.1.1.2 is usable.
When both RTR 10 and RTR 11 are unreachable, you can control which static route is installed in the routing table by including the last-resort keyword in the ip route verify rtr command only for the route that you want to install.
![]() | Note: For detailed information about the commands for configuring RTR probes, see Response Time Reporter. |