Enabling Indirect Next Hops

The 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 IBGP can send routing information about indirectly connected routes, the 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 the task of route resolution to determine the best directly connected next hop and install the route to the Packet Forwarding Engine.

By default, the 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 2 illustrates the route to forwarding next-hop bindings with indirect next hop disabled.

You can enable the 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 3 illustrates the route to forwarding next-hop bindings with indirect next hop enabled.

To enable indirectly connected next hops, include the indirect-next-hop statement:

Note: When virtual private LAN service (VPLS) is configured on the routing device, the indirect-next-hop statement is not supported at the [edit routing-options forwarding-table] hierarchy level.

To disable indirectly connected next hops, include the no-indirect-next-hop statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.