Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Example: Enabling IS-IS Traffic Engineering Support

This example shows how to configure IS-IS so that it uses label-switched paths as shortcuts.


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


MPLS traffic engineering maps certain data flows to established label-switched paths (LSPs) rather than to data links calculated by the interior gateway protocol (IGP) to be part of the best (shortest) path. Fundamental to this function is the determination of what traffic is to be mapped to an LSP. Traffic is mapped to an LSP at the tunnel's ingress label switching router (LSR) by designating the egress LSR as the next-hop router for certain destination prefixes.

It is important to understand that the LSP does not constitute an entire route to a destination. Rather, the LSP is a next-hop segment of the route. Therefore, packets can only be mapped to an LSP if the egress LSR is considered to be a feasible next-hop candidate during the route resolution process.

Figure 1 shows the topology used in this example.

Figure 1: IS-IS Shortcuts TopologyIS-IS Shortcuts Topology

In this example, Device C has an external BGP (EBGP) peer session with Device G in autonomous system (AS) 2. In order to enable its internal BGP (IBGP) peers to access subnets in AS 2, Device C runs IS-IS passively on its interface connecting to Device G. IS-IS has information about the external subnets and enters routes to these subnets in the inet.0 routing table. BGP, when resolving the next-hop addresses of AS-external routes, uses the IGP route.


An alternative to passively running IS-IS on the interface would be to use a next-hop self policy.

Device A has an LSP to Device C. The path is configured to always go through Device E, rather than going through Device B.

Interior gateway protocol (IGP) shortcuts, also called traffic-engineering shortcuts, provide a tool by which the link-state IGP (OSPF or IS-IS) in an AS can consider an LSP in its shortest-path-first (SPF) calculations. If using passive external interfaces, the IGP views an LSP as a single data link toward the destinations beyond the LSP egress device.

When you use traffic-engineering bgp (which is the default) and IGP shortcuts, the traffic engineering solution is used for BGP AS-external route resolution only. However, traffic to AS-internal destinations can also be mapped to LSPs. To accomplish this, traffic-engineering bgp-igp is enabled. Thus, RSVP installs the MPLS prefixes into the inet.0 table rather than the inet.3 table. As a result, the MPLS LSPs are installed in the forwarding table.

This approach finds practical application whenever heavy traffic is routed to specific destinations within an AS, such as server farms.

An important point about IGP shortcuts, whether used alone or in conjunction with traffic-engineering BGP-IGP, is that IGP adjacencies are never formed across the LSPs. The IGP sees the LSP as a single data link, but does not view the egress router as a potential peer and does not forward hello messages across the LSP. Also, RSVP messages are never forwarded over LSPs, preventing the possibility of an LSP being inadvertently built within another LSP.

CLI Quick Configuration shows the configuration for all of the devices in Figure 1. The section #configuration424__isis-shortcuts-step-by-step describes the steps on Device A.



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 A

Device B

Device C

Device D

Device E

Device F

Device G

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 CLI User Guide.

To configure IS-IS traffic-engineering shortcuts:

  1. Configure the interfaces.

  2. Enable a signaling protocol on the interfaces.

  3. Enable MPLS on the interfaces.

  4. Configure the label-switched path.

    A single LSP, named test_path, is configured from Device A to Device C. The LSP explicit route object (ERO) is specified to use a strict hop through Device E, so that the LSP takes a different path from the OSPF shortest path of A–B–C. The LSP is signaled using RSVP, but no CSPF is running.

  5. Configure traffic engineering for both BGP and IGP destinations.

    When IGP shortcuts are also enabled, the IGP can use the LSP in its calculations. The results of the calculations are entered into the inet.0 table.

  6. Configure internal BGP (IBGP) peering among the devices.

  7. Enable IS-IS on the interfaces, and set the link metric.

  8. Configure IS-IS to use MPLS LSPs as next hops for the IPv4 address family.

    It is only necessary to enable IGP shortcuts on the ingress router because that is the router performing the shortest-path-first (SPF) calculations.

    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.

  9. Configure the router ID and the autonomous system (AS) number.


From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.


Confirm that the configuration is working properly.

Verifying the Next Hops


Verify that the MPLS LSP is used as the next hop in the expected routes.


From operational mode, enter the show route command.


IS-IS chooses the LSP as the shortest path to destinations downstream of the LSP egress device. Additionally, because the IGP uses the LSP to reach external subnet, BGP also uses the LSP in its routes to and

If next-hop self were used at Device C, BGP would still choose the LSP over the IGP path.

Checking the RSVP Sessions


Display information about RSVP sessions


From operational mode, enter the show rsvp session brief command.


On all four routing devices, the ingress and egress IP addresses of the LSP are shown. The path is shown as an ingress path at Device A, and packets forwarded on the LSP are assigned a label of 299776. At Device E, the LSP is transit, and packets arriving with a label of 299776 are given an outgoing label of 299808. The labels have significance only between neighboring label-switched routers (LSRs). Device F swaps incoming label 299808 for outgoing label 3. Device C, the egress, pops label 3 and routes the received packet by standard IP longest-match route lookup.

Checking the Paths with Different Traffic Engineering Settings


Check the paths used for IGP and BGP routes when traffic-engineering bgp-igp is used and when traffic-engineering bgp (the default) is used.


  1. Configure traffic-engineering bgp.

    This removes traffic-engineering bgp-igp from the configuration because only one MPLS traffic engineering setting can be configured in each routing instance.

  2. Use the show route forwarding-table command to check the paths when traffic-engineering bgp (the default) is configured.

  3. Use the traceroute command to check the paths when traffic-engineering bgp (the default) is configured.

  4. Configure traffic-engineering bgp-igp.

    This removes traffic-engineering bgp from the configuration because only one MPLS traffic engineering setting can be configured in each routing instance.

  5. Use the show route forwarding-table command to check the paths when traffic-engineering bgp-igp is configured.

  6. Use the traceroute command to check the paths when traffic-engineering bgp-igp is configured.


When traffic-engineering bgp is configured, the first trace is to a destination belonging to the BGP-learned prefix, and follows the LSP. The second trace is to the IS-IS-learned route (Device C’s loopback interface address), and follows the IS-IS route. These results correspond to what we observe in the forwarding table. The forwarding table is built based on routes in inet.0 only. BGP can look into inet.3 and select an LSP as the best path to the next hop of a BGP prefix, and can add a route into inet.0 utilizing that LSP. An entry is then made to the forwarding table from the inet.0 route. No other protocol, by default, can consult inet.3, and the inet.3 routes are not entered into inet.0. Therefore, the forwarding entry for is created from the only route to that destination in inet.0: the IS-IS route.

When traffic-engineering bgp-igp is configured, the first trace to continues to follow the LSP. The second trace to also follows the LSP. These results correspond to what we observe in the forwarding table, which shows that the LSP is used for IGP next-hop resolution.