traffic-engineering (Protocols IS-IS)
Statement introduced before Junos OS Release 7.4.
Support for the family statement introduced in Junos OS Release 9.3.
Support for the credibility-protocol-preference statement introduced in Junos OS Release 9.4.
Support for the multipath statement introduced in Junos OS Release 9.6.
Support for the lsp-equal-cost statement introduced in Junos OS Release 9.6.
Statement introduced in Junos OS Release 12.1 for the QFX Series.
Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series.
Support for inet-mpls and inet6-mpls statements introduced in Junos OS Release 17.2 for MX Series, PTX Series, QFX5100 switches, and QFX10000 line switches.
Support for inet-mpls and inet6-mpls statements introduced in Junos OS Release 17.3 for QFX5110 and QFX5200 switches.
Support for igp-topology statement introduced in Junos OS Release 17.4R1 for MX Series, and PTX Series.
Configure traffic engineering properties for IS-IS.
IS-IS always performs shortest-path-first (SPF) calculations to determine next hops. For prefixes reachable through a particular next hop, IS-IS places that next hop for that prefix in the inet.0 routing table. In addition, for routers running MPLS, IS-IS installs the prefix for IPv4 routes in the inet.3 routing table as well. The inet.3 table, which is present on the ingress router, contains the host address of each MPLS label-switched path (LSP) egress router. BGP uses this routing table to resolve next-hop addresses.
If you enable IS-IS traffic engineering shortcuts and if there is a label-switched path to a point along the path to that prefix, IS-IS installs the prefix in the inet.3 routing table and uses the LSP as a next hop. The net result is that for BGP egress routers for which there is no LSP, BGP automatically uses an LSP along the path to reach the egress router.
In Junos OS Release 9.3 and later, IS-IS traffic engineering shortcuts support IPv6 routes. LSPs to be used for shortcuts continue to be signaled using IPv4. However, by default, shortcut routes calculated through IPv6 routes are added to the inet6.3 routing table. The default behavior is for only BGP to use LSPs in its calculations. If you configure MPLS so that both BGP and interior gateway protocols use LSPs for forwarding traffic, shortcut routes calculated through IPv6 are added to the inet6.0 routing table. IS-IS ensures that the IPv6 routes running over the IPv4 MPLS LSP are correctly de-encapsulated at the tunnel egress by pushing an extra IPv6 explicit null label between the IPv6 payload and the IPv4 transport label.
RSVP LSPs with a higher preference than IS-IS routes are not considered during the computation of traffic engineering shortcuts.
To configure IS-IS so that it uses LSPs as shortcuts when installing information in the inet.3 or inet6.3 routing table, include the following statements:
For IPv4 traffic, include the inet statement. For IPv6 traffic, include the inet6 statement.
To configure IPv4 MPLS or IPv6 MPLS shortcuts explicitly for segment routing, include the inet-mpls statement for IPv4 MPLS traffic and the inet6-mpls statement for IPv6 MPLS traffic.
To configure load balancing across multiple LSPs, include the multipath statement.
When traffic engineering shortcuts are used, RSVP first looks at the metric2 value, which is derived from the IGP cost. After this, RSVP considers the LSP metric value. So, if a certain path changes for an LSP and the cost changes, not all LSPs are used to load- balance the network.
When a route with an improved metric is added to the IS-IS internal routing table, IS-IS flushes all next-hop information (including LSP next-hop information) for a route. This is undesirable, because certain equal-cost multipath (ECMP) combinations can be lost during route calculation. To override this default behavior for load balancing, include the lsp-equal-cost statement to retain the equal cost path information in the routing table.
Because the inet.3 routing table is present only on ingress routers, you can configure LSP shortcuts only on these routers.
IS-IS traffic engineering support is enabled.
By default, IS-IS supports traffic engineering by exchanging basic information with the traffic engineering database. To disable this support, and to disable IS-IS shortcuts if they are configured, include the disable statement.
The traffic engineering database assigns a credibility value to each IGP and prefers the routes of the IGP with the highest credibility value. In Junos OS Release 9.4 and later, you can configure IS-IS to take protocol preference into account to determine the traffic engineering database credibility value. When protocol preference is used to determine the credibility value, IS-IS routes are not automatically preferred by the traffic engineering database, depending on your configuration. For example, OSPF routes have a default preference value of 10, whereas IS-IS Level 1 routes have a default preference value of 15. When protocol preference is enabled, the credibility value is determined by deducting the protocol preference value from a base value of 512. Using default protocol preference values, OSPF has a credibility value of 502, whereas IS-IS has a credibility value of 497. Because the traffic engineering database prefers IGP routes with the highest credibility value, OSPF routes are now preferred.
This feature is also supported for OSPFv2.
When a route with an improved metric is added to the IS-IS internal routing table, IS-IS flushes all next-hop information (including LSP next-hop information) for a route. This is undesirable, because certain equal-cost multipath (ECMP) path combinations can be lost during route calculation. To override this default IS-IS behavior, include the lsp-equal-cost statement for load balancing, so that the equal cost path information is retained in the routing table.
It is important to understand how IGP shortcuts affect the protocol and routing table relationship. The IGP performs SPF calculations to subnets downstream of LSP egress points, but the results of these calculations are entered into the inet.3 table only. At the same time, the IGP performs its traditional SPF calculations and enters the results of these calculations into the inet.0 table. The result is that although the IGP is making entries into the inet.3 table, BGP is still the only protocol with visibility into that table for the purposes of route resolution. Therefore, forwarding to AS-internal destinations still uses the inet.0 IGP routes, and the LSPs are only used for BGP next-hop resolution. If you want the LSPs to be used for IGP next-hop resolution, you must configure traffic-engineering bgp-igp.
The remaining statements are explained separately. See CLI Explorer.
Required Privilege Level
routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.