Supported Platforms
Configuring IS-IS Traffic Engineering Attributes
You can configure the following IS-IS traffic engineering attributes:
- Configuring IS-IS to Use IGP Shortcuts
- Configuring IS-IS to Ignore the Metric of RSVP Label-Switched Paths
- Disabling IS-IS Support for Traffic Engineering
- Installing IPv4 Routes into the Multicast Routing Table
- Configuring IS-IS to Use Protocol Preference to Determine the Traffic Engineering Database Credibility Value
When configuring traffic engineering support, you can also configure IS-IS to use metric values greater than 63, as described in Enabling Wide IS-IS Metrics for Traffic Engineering.
Configuring IS-IS to Use IGP Shortcuts
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 label-switched paths 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 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.
For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.
Because the inet.3 routing table is present only on ingress routers, you can configure LSP shortcuts only on these routers.
For more information about configuring LSPs and MPLS, see the Junos OS MPLS Applications Configuration Guide .
Configuring IS-IS to Ignore the Metric of RSVP Label-Switched Paths
You can configure IS-IS to ignore the metric of RSVP label-switched paths (LSPs) when LDP tunneling is enabled. If you are using RSVP for traffic engineering, you can run LDP simultaneously to eliminate the distribution of external routes in the core. The LSPs established by LDP are tunneled through the LSPs established by RSVP. LDP effectively treats the traffic-engineered LSPs as single hops. Ignoring the metric of RSVP LSPs avoids mutual dependency between IS-IS and RSVP, eliminating the time period when the RSVP metric used for tunneling traffic is not up to date.
To configure IS-IS to ignore the metric of RSVP LSPs, include the ignore-lsp-metrics statement:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
For more information about configuring LSPs and MPLS, see the Junos OS MPLS Applications Configuration Guide .
Disabling IS-IS Support for Traffic Engineering
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:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
Installing IPv4 Routes into the Multicast Routing Table
You can install unicast IPv4 routes into the multicast routing table (inet.2) for multicast reverse-path forwarding (RPF) checks.
To install routes into the multicast routing table for RPF checks, include the multicast-rpf-routes statement:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
 | Note: Traffic engineering shortcuts must be enabled. |
| Note: IPv4 multicast topology must not be enabled. |
| Note: LSPs must not be advertised into IS-IS. |
Configuring IS-IS to Use Protocol Preference to Determine the Traffic Engineering Database Credibility Value
By default, Junos OS prefers IS-IS routes in the traffic engineering database over other IGP routes even if the routes of another IGP are configured with a lower, that is, more preferred, preference value. 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.
| Note: This feature is also supported for OSPFv2. For more information, see Example: Enabling OSPF Traffic Engineering Support. |
To configure IS-IS to use the configured protocol preference for IGP routes to determine the traffic engineering database credibility value, include the credibility-protocol-preference statement at the [edit protocols isis traffic-engineering] hierarchy level:
