The user can forward packets of a static route to an indirect next-hop over a tunnel programmed in TTM by configuring the following static route tunnel binding command:
config>router>static-route-entry {ip-prefix/prefix-length} [mcast] indirect {ip-
address}
tunnel-next-hop
resolution {any|disabled|filter}
resolution-filter
[no] ldp
[no] rsvp-te
[no] lsp <name1>
[no] lsp <name2>
.
.
[no] lsp <namen>
exit
[no] sr-isis
[no] sr-ospf
[no] sr-te
[no] lsp <name1>
[no] lsp <name2>
.
.
[no] lsp <namen>
exit
[no] disallow-igp
exit
exit
If the tunnel-next-hop context is configured and resolution is set to disabled, the binding to the tunnel is removed and resolution resumes in RTM to IP next-hops.
If the resolution is set to any, any supported tunnel type in the static route context is selected following TTM preference.
The following tunnel types are supported in a static route context: LDP, RSVP-TE, Segment Routing (SR) Shortest Path, and Segment Routing Traffic Engineering (SR-TE):
LDP
The ldp value instructs the code to search for an LDP LSP with a FEC prefix corresponding to the address of the indirect next-hop. Both LDP IPv4 FEC and LDP IPv6 FEC can be used as the tunnel next-hop. However, only an indirect next-hop of the same family (IPv4 or IPv6) as the prefix of the route can use an LDP FEC as the tunnel next-hop. In other words, an IPv4 (IPv6) prefix can only be resolved to an LDP IPv4 (IPv6) FEC.
RSVP-TE
The rsvp-te value instructs the code to search for the set of lowest metric RSVP-TE LSPs to the address of the indirect next-hop. The LSP metric is provided by MPLS in the tunnel table. The static route treats a set of RSVP-TE LSPs with the same lowest metric as an ECMP set.
The user has the option of configuring a list of RSVP-TE LSP names to be used exclusively instead of searching in the tunnel table. In that case, all LSPs must have the same LSP metric in order for the static route to use them as an ECMP set. Otherwise, only the LSPs with the lowest common metric value are selected.
A P2P auto-lsp that is instantiated via an LSP template can be selected in TTM when resolution is set to any. However, it is not recommended to configure an auto-lsp name explicitly under the rsvp-te node as the auto-generated name can change if the node reboots, which blackholes the traffic of the static route.
SR shortest path
When the sr-isis or sr-ospf value is enabled, an SR tunnel to the indirect next-hop is selected in the TTM from the lowest preference ISIS or OSPF instance, and if many instances have the same lowest preference, it is selected from the lowest numbered IS-IS or OSPF instance. Both SR-ISIS IPv4 and SR-ISIS IPv6 tunnels can be used as tunnel next-hops. However, only an indirect next-hop of the same family (IPv4 or IPv6) as the prefix of the route can use an SR-ISIS tunnel as a tunnel next-hop. In other words, an IPv4 (IPv6) prefix can only be resolved to a SR-ISIS IPv4 (IPv6).
SR-TE
The sr-te value instructs the code to search for the set of lowest metric SR-TE LSPs to the address of the indirect next-hop. The LSP metric is provided by MPLS in the tunnel table. The static route treats a set of SR-TE LSPs with the same lowest metric as an ECMP set.
The user has the option of configuring a list of SR-TE LSP names to be used exclusively instead of searching in the tunnel table. In that case, all LSPs must have the same LSP metric in order for the static route to use them as an ECMP set. Otherwise, only the LSPs with the lowest common metric value are selected.
Realize that the resolution filter, under static-route-entry, does not validate the provided lsp-name type of the LSP against the requested filter context protocol type.
If one or more explicit tunnel types are specified using the resolution-filter option, only these tunnel types are selected again following the TTM preference.
The user must set resolution to filter to activate the list of tunnel-types configured under resolution-filter.
If disallow-igp is enabled, the static route is not activated using IP next-hops in RTM if no tunnel next-hops are found in TTM.