Juniper Networks
Log in
|
How to Buy
|
Contact Us
|
United States (Change)
Choose Country
Close

Choose Country

North America

  • United States

Europe

  • Deutschland - Germany
  • España - Spain
  • France
  • Italia - Italy
  • Россия - Russia
  • United Kingdom

Asia Pacific

  • Asean Region (Vietnam, Indonesia, Singapore, Malaysia)
  • Australia
  • 中国 - China
  • India
  • 日本 - Japan
  • 대한민국 - Korea
  • 台灣 - Taiwan
Solutions
Products & Services
Company
Partners
Support
Education
Community
Security Intelligence Center

Technical Documentation

Support
Technical Documentation
Content Explorer New
 
Enterprise MIBs
 
EOL Documentation
 
Feature Explorer Login required New
 
File Format Help
 
Glossary
 
Portable Libraries
 
 
Home > Support > Technical Documentation > JunosE Software > Next-Hop Verification for Static Routes Overview
Print
Rate and give feedback:  Feedback Received. Thank You!
Rate and give feedback: 
Close
This document helped resolve my issue.  Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  
E-mail: 
Submitting...
 

Related Documentation

  • IP Routing Information Tables Overview
  • Response Time Reporter
  • Monitoring the Status of IP Static Routes in the Routing Table
  • frequency
  • interface fastEthernet
  • interface loopback
  • ip address
  • ip route
  • ip unnumbered
  • no ip interface
  • receive-interface
  • rtr
  • rtr reaction-configuration test-completion
  • rtr reaction-configuration test-failure
  • rtr schedule
  • rtr schedule life
  • rtr schedule restart-time
  • samples-of-history-kept
  • type
 

Next-Hop Verification for Static Routes Overview

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.

  • BFD Next-Hop Verification Overview
  • Enabling BFD on a Static Route
  • Configuring BFD Next-Hop Verification
  • RTR Next-Hop Verification Overview
  • Establishing an IP Static Route and Associating it with a Configured RTR Operation
  • Example: Configuring the RTR Next-Hop Verification Feature

BFD Next-Hop Verification Overview

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:

  • You configure the static routes with the actual next hop address and not just interface details.
  • The BFD protocol is operational on both ends of the verification.
  • The next hop is adjacent to the router (that is, only one hop away).

    Note: BFD next-hop verification does not currently function in a multi-hop configuration.

  • The next hop to the specified IP destination address is resolved.

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.

Enabling BFD on a Static Route

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:

  • The minimum-interval keyword to specify a value in the range 100–65535 milliseconds. This keyword defines both the minimum receive interval and minimum transmit interval using the same value.
  • The minimum-receive-interval keyword to specify a minimum receive interval value in the range 100–65535 milliseconds.
  • The minimum-transmit-interval keyword to specify a minimum transmit interval value in the range 100–65535 milliseconds.
  • The multiplier keyword to specify a multiplier number in the range 1–255.
  • The last-resort keyword to instruct the router to install the static route in the routing table even if the specified BFD operation is currently unreachable, provided that no other static route to the same network prefix is available.

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:

  • Next-hop address and last resort.
    host1(config)#ip route 192.56.15.23 255.255.255.0 192.66.0.1 verify bfd-liveness-detection minimum-interval 800 multiplier 2 last-resort
  • Next-hop address and interface.
    host1(config)#ip route 192.56.15.24 255.255.255.0 192.66.0.2 fast 6/0 verify bfd-liveness-detection
  • Next-hop address with different receive and transmit intervals.
    host1(config)#ip route 192.56.15.23 255.255.255.0 192.66.0.1 verify bfd-liveness-detection minimum-receive-interval 800 minimum-transmit-interval 300 multiplier 2 last-resort

Use the no version to remove the static route from the routing table and thereby remove BFD from that static route.

Configuring BFD Next-Hop Verification

To enable BFD next hop verification between two adjacent peers, you configure each peer as follows:

  1. Configure peer A with the next hop address of peer B along with the desired intervals and keyword options.
    host1(config)#ip route 192.1.1.0 255.255.255.0 192.1.2.1 verify bfd-liveness-detection minimum-interval 500 multiplier 3 last-resort
  2. Configure peer B with the next hop address of peer A along with the desired intervals and keyword options.
    host1(config)#ip route 192.1.2.1 255.255.255.0 192.1.1.0 verify bfd-liveness-detection minimum-interval 300 multiplier 3

RTR Next-Hop Verification Overview

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:

  • The next hop to the specified IP destination address is resolved.
  • The specified RTR operation is currently reachable.

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.

Establishing an IP Static Route and Associating it with a Configured RTR Operation

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:

  • Issue the ip route command with the verify rtr keyword in Global Configuration mode.
    host1(config)#ip route 10.1.1.5 255.255.255.0 10.1.1.5 fastEthernet 1/0 verify rtr 5 last-resort

    Use the no version to remove a static route from the routing table.

Example: Configuring the RTR Next-Hop Verification Feature

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.

  • Requirements
  • Overview
  • Configuring RTR Next-Hop Verification

Requirements

This example uses the following software and hardware components:

  • JunosE Release 7.1.0 or higher-numbered releases
  • E Series router (ERX7xx models, ERX14xx models, the ERX310 router, the E120 router, or the E320 router)
  • ASIC-based line modules that support Fast Ethernet or Gigabit Ethernet
  • Before you configure IP, you must create the lower-layer interfaces over which IP traffic flows.
  • All IP configurations will be removed from the interface when you issue the no ip interface command in Interface Configuration mode.

Overview

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

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.

Configuring RTR Next-Hop Verification

Step-by-Step Procedure

To configure the next-hop verification example shown in Figure 1:

  1. Configure a loopback interface, and assign an IP address and mask to the interface.
    host1(config)#interface loopback 0 host1(config-if)#ip address 10.1.1.1 255.255.255.255 host1(config-if)#exit
  2. Configure Fast Ethernet port 4/0 with an unnumbered primary IP interface associated with the loopback interface configured in Step 1.
    host1(config)#interface fastEthernet 4/0 host1(config-if)#ip unnumbered loopback 0 host1(config-if)#exit
  3. Repeat Step 2 for Fast Ethernet port 4/1.
    host1(config)#interface fastEthernet 4/1 host1(config-if)#ip unnumbered loopback 0 host1(config-if)#exit
  4. Define probe RTR 10 for Fast Ethernet interface 4/0.
    1. Assign an operation number to the RTR probe, and access RTR Configuration mode. For information, see Configuring the Probe Type for RTR.
      host1(config)#rtr 10 host1(config-rtr)#
    2. Configure the RTR probe as an echo type, and set the IP destination address and source interface.

      You must configure the RTR probe as an echo type to use next-hop verification. For information, see Configuring the Probe Type for RTR.

      host1(config-rtr)#type echo protocol ipIcmpEcho 10.1.1.2
      source fastEthernet 4/0
    3. Specify the interface on which the RTR probe expects to receive responses.

      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.

      host1(config-rtr)#receive-interface fastEthernet 4/0
    4. (Optional) Configure optional probe characteristics, such as the frequency and samples-of-history kept. For information, see Configuring the Probe Characteristics for RTR.
      host1(config-rtr)#frequency 1 host1(config-rtr)#samples-of-history-kept 0
    5. Exit RTR Configuration mode.
      host1(config-rtr)#exit
    6. Enable the probe to react to the test-failure event and the test-completion event.

      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.

      host1(config)#rtr reaction-configuration 10 test-failure 3 host1(config)#rtr reaction-configuration 10 test-completion
    7. Schedule the probe operation. For information, see Scheduling the RTR Probe.
      host1(config)#rtr schedule 10 life 3 host1(config)#rtr schedule 10 restart-time 1 host1(config)#rtr schedule 10 start now
  5. Repeat Step 4 to define RTR 11 for Fast Ethernet interface 4/1.
    host1(config)#rtr 11 host1(config-rtr)#type echo protocol ipIcmpEcho 10.1.1.2
    source fastEthernet 4/1
    host1(config-rtr)#receive-interface fastEthernet 4/1 host1(config-rtr)#frequency 1 host1(config-rtr)#samples-of-history-kept 0 host1(config-rtr)#exit host1(config)#rtr reaction-configuration 11 test-failure 3 host1(config)#rtr reaction-configuration 11 test-completion host1(config)#rtr schedule 11 life 3 host1(config)#rtr schedule 11 restart-time 1 host1(config)#rtr schedule 11 start now
  6. Establish a static route associated with RTR 10.

    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.

    host1(config)#ip route 10.1.1.2 255.255.255.255 10.1.1.2 fastEthernet 4/0 verify rtr 10 last-resort
  7. Establish a static route associated with RTR 11.

    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.

    host1(config)#ip route 10.1.1.2 255.255.255.255 10.1.1.2 fastEthernet 4/1 verify rtr 11 last-resort

    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.

 

Related Documentation

  • IP Routing Information Tables Overview
  • Response Time Reporter
  • Monitoring the Status of IP Static Routes in the Routing Table
  • frequency
  • interface fastEthernet
  • interface loopback
  • ip address
  • ip route
  • ip unnumbered
  • no ip interface
  • receive-interface
  • rtr
  • rtr reaction-configuration test-completion
  • rtr reaction-configuration test-failure
  • rtr schedule
  • rtr schedule life
  • rtr schedule restart-time
  • samples-of-history-kept
  • type
 

Published: 2012-06-20

 
  • About Juniper
  • Investor Relations
  • Press Releases
  • Newsletters
  • Juniper Offices
  • Green Networking
  • Resources
  • How to Buy
  • Partner Locator
  • Image Library
  • Visio Templates
  • Security Center
  • Community
  • Forums
  • Blogs
  • Junos Central
  • Social Media
  • Developers
  • Support
  • Technical Documentation
  • Knowledge Base (KB)
  • Software Downloads
  • Product Licensing
  • Contact Support
Site Map / RSS Feeds / Careers / Accessibility / Feedback / Privacy & Policy / Legal Notices
Copyright© 1999-2012 Juniper Networks, Inc. All rights reserved.
Help
|
My Account
|
Log Out