Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuring Packet Forwarding Behavior

Understanding Indirect Next Hops

Junos OS supports the concept of an indirect next hop for all routing protocols that support indirectly connected next hops, also known as third-party next hops.

Because routing protocols such as internal BGP (IBGP) can send routing information about indirectly connected routes, Junos OS relies on routes from intra-AS routing protocols (OSPF, IS-IS, RIP, and static) to resolve the best directly connected next hop. The Routing Engine performs route resolution to determine the best directly connected next hop and installs the route to the Packet Forwarding Engine.

By default, Junos OS does not maintain the route for indirect next hop to forwarding next-hop binding on the Packet Forwarding Engine forwarding table. As a result, when a rerouting event occurs, potentially thousands of route to forwarding next-hop bindings must be updated, which increases the route convergence time. Figure 1 illustrates the route to forwarding next-hop bindings with indirect next hop disabled.

Figure 1: Route to Forwarding Next-Hop BindingsRoute to Forwarding Next-Hop Bindings

You can enable Junos OS to maintain the indirect next hop to forwarding next-hop binding on the Packet Forwarding Engine forwarding table. As a result, fewer route to forwarding next-hop bindings need to be updated, which improves the route convergence time. Figure 2 illustrates the route to forwarding next-hop bindings with indirect next hop enabled.

Figure 2: Route to Forwarding Indirect Next-Hop BindingsRoute to Forwarding Indirect Next-Hop Bindings

Example: Optimizing Route Reconvergence by Enabling Indirect Next Hops on the Packet Forwarding Engine

This example shows how to use indirect next hops to promote faster network convergence (for example, in BGP networks) by decreasing the number of forwarding table changes required when a change in the network topology occurs.

Requirements

No special configuration beyond device initialization is required before configuring this example.

Overview

In this example, several devices are connected over unequal-cost paths. From Device R1 to Device R2, the path through Device R3 has a higher IGP metric than the path through Device R4. Device R1 has an internal BGP connection to Device R2. Device R0 injects multiple routes into the network, and Device R1 advertises those routes to Device R2. Because Device R2 is not directly connected to Device R1, Device R2’s forwarding table contains indirect next hops. An interior gateway protocol, in this case OSPF, is running on the internal links among Devices R1, R2, R3, and R4. Each router is advertising its loopback interface IPv4 address.

On Device R2, the indirect-next-hop statement enables Junos OS to maintain the indirect next hop to forwarding next-hop binding on the Packet Forwarding Engine forwarding table. As a result, fewer route to forwarding next-hop bindings need to be updated, which improves the route convergence time if a path fails.

Topology

Figure 3 shows the sample network.

Figure 3: Sample Topology for Indirect Next Hops
Topology

The CLI Quick Configuration section shows the full configuration on all of the devices in Figure 3. Otherwise, the example focuses on Device R0, Device R1, and Device R2.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device R0

Device R1

Device R2

Device R3

Device R4

Device R5

Configuring Device R0

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device R0:

  1. Configure the interfaces, including multiple routes that can be injected into the network for demonstration purposes.

  2. Configure a static default route for network reachability.

  3. If you are done configuring the device, commit the configuration.

Configuring Device R1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device R1:

  1. Configure the interfaces, including multiple routes that can be injected into the network for demonstration purposes.

  2. Configure BGP.

  3. Configure OSPF.

  4. Configure the routing policies.

  5. Configure a set of static routes to the set of interfaces configured on Device R0.

  6. Configure the autonomous system (AS) identifier.

  7. If you are done configuring the device, commit the configuration.

Configuring Device R2

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device R2:

  1. Configure the interfaces, including multiple routes that can be injected into the network for demonstration purposes.

  2. Configure BGP.

  3. Configure OSPF.

  4. Configure the routing policies.

  5. Configure the AS identifier.

  6. Enable indirect next hops in the forwarding plane.

  7. If you are done configuring the device, commit the configuration.

Results

Confirm your configuration by issuing the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Device R0

Device R1

Device R2

Configure Device R3, Device R4, and Device R5, as shown in CLI Quick Configuration.

Verification

Confirm that the configuration is working properly.

Verifying That the Routes Have the Expected Indirect-Next-Hop Flag

Purpose

Make sure that Device R2 is configured to maintain the indirect next hop to forwarding next-hop binding on the Packet Forwarding Engine forwarding table.

Action
Meaning

The 0x3 flag in the output indicates that Device R2 is configured to maintain the indirect next hop to forwarding next-hop binding on the Packet Forwarding Engine forwarding table. When the indirect-next-hop statement is deleted or deactivated from the configuration, this flag changes to 0x2. Junos MX series routers with Trio Modular Port Concentrator (MPC) chipset supports indirect-next-hop by default and can not be disabled. Thus, even if indirect-next-hop is not configured under forwarding-options, the feature will work by default. Thus, 0x3 flag is not applicable for Trio Modular Port Concentrator (MPCs).

Note:

The show krt indirect-next-hop command is hidden and is therefore undocumented. The show krt indirect-next-hop command is shown here because this is the only command that verifies the indirect next-hop feature. The best verification method is, of course, monitoring network performance during reconvergence after a path failure.