Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Example: Enabling IS-IS Traffic Engineering Support

IGP Shortcuts

Link-state protocols, such as OSPF and IS-IS, use the shortest-path-first (SPF) algorithm to compute the shortest-path tree to all nodes in the network. The results of such computations can be represented by the destination node, next-hop address, and output interface, where the output interface is a physical interface. Label-switched paths (LSPs) can be used to augment the SPF algorithm, for the purposes of resolving BGP next hops. On the node performing the calculations, LSPs appear to be logical interfaces directly connected to remote nodes in the network. If you configure the interior gateway protocol (IGP) to treat LSPs the same as a physical interface and use the LSPs as a potential output interface, the SPF computation results are represented by the destination node and output LSP, effectively using the LSP as a shortcut through the network to the destination.

As an illustration, begin with a typical SPF tree (see Figure 1).

Figure 1: Typical SPF Tree, Sourced from Router A

If an LSP connects Router A to Router D and if IGP shortcuts are enabled on Router A, you might have the SPF tree shown in Figure 2.

Figure 2: Modified SPF Tree, Using LSP A–D as a Shortcut

• Use IGP path A–B–D.
• Use LSP A–D.

Router A decides between the two choices by comparing the IGP metrics for path A–B–D with the LSP metrics for LSP A–D. If the IGP metric is lower, path A–B–D is chosen (Figure 1). If the LSP metric is lower, LSP A–D is used (Figure 2). If both metrics are equal, LSP A–D is chosen because LSPs are preferred over IGP paths.

Note that Routers E and F are also reachable through LSP A–D, because they are downstream from Router D in the SPF tree.

Assuming that another LSP connects Router A to Router E, you might have the SPF tree shown in Figure 3.

Figure 3: Modified SPF Tree, Using LSP A–D and LSP A–E as Shortcuts

Example: Enabling IS-IS Traffic Engineering Support

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

• Requirements
• Overview
• Configuration
• Verification

Requirements

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

Overview

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 4 shows the topology used in this example.

Figure 4: IS-IS Shortcuts Topology

In this example, Device C has an external BGP (EBGP) peer session with Device G in autonomous system (AS) 65520. In order to enable its internal BGP (IBGP) peers to access subnets in AS 65520, Device G 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.

Tip: 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 4. The section Step-by-Step Procedure describes the steps on Device A.

Configuration

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.

Step-by-Step Procedure

1. Configure the interfaces.
   [edit interfaces]user@A# set fe-1/2/0 unit 0 family inet address 10.0.0.1/30user@A# set fe-1/2/0 unit 0 family isouser@A# set fe-1/2/0 unit 0 family mplsuser@A# set fe-1/2/1 unit 0 family inet address 10.0.0.5/30user@A# set fe-1/2/1 unit 0 family isouser@A# set fe-1/2/1 unit 0 family mplsuser@A# set lo0 unit 0 family inet address 192.168.0.1/32user@A# set lo0 unit 0 family iso address 49.0002.0192.0168.0001.00
2. Enable a signaling protocol on the interfaces.
   [edit protocols rsvp]user@A# set interface lo0.0user@A# set interface fe-1/2/0.0user@A# set interface fe-1/2/1.0
3. Enable MPLS on the interfaces.
   [edit protocols mpls]user@A# set interface fe-1/2/0.0user@A# set interface fe-1/2/1.0
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.

   [edit protocols mpls]user@A# set label-switched-path test_path to 192.168.0.3user@A# set label-switched-path test_path no-cspfuser@A# set label-switched-path test_path primary through_Euser@A# set path through_E 192.168.0.5 strict
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.

   [edit protocols mpls]user@A# set traffic-engineering bgp-igp
6. Configure internal BGP (IBGP) peering among the devices.
   [edit protocols bgp group int]user@A# set type internaluser@A# set local-address 192.168.0.1user@A# set neighbor 192.168.0.5user@A# set neighbor 192.168.0.6user@A# set neighbor 192.168.0.2user@A# set neighbor 192.168.0.3
7. Enable IS-IS on the interfaces, and set the link metric.
   [edit protocols isis]user@A# set interface fe-1/2/0.0 level 1 disableuser@A# set interface fe-1/2/1.0 level 1 disableuser@A# set interface lo0.0
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.

   [edit protocols isis]user@A# set traffic-engineering family inet shortcuts
9. Configure the router ID and the autonomous system (AS) number.
   [edit routing-options]user@A# set router-id 192.168.0.1user@A# set autonomous-system 1

Results

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.

Verification

Confirm that the configuration is working properly.

• Verifying the Next Hops
• Checking the RSVP Sessions
• Checking the Paths with Different Traffic Engineering Settings

Verifying the Next Hops

Purpose

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

Action

From operational mode, enter the show route command.

inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.0/30        *[Direct/0] 4d 09:07:26
                    >    via fe-1/2/0.0
10.0.0.1/32        *[Local/0] 4d 09:07:26
                         Local via fe-1/2/0.0
10.0.0.4/30        *[Direct/0] 4d 09:07:28
                    >    via fe-1/2/1.0
10.0.0.5/32        *[Local/0] 4d 09:07:28
                         Local via fe-1/2/1.0
10.0.0.8/30        *[IS-IS/18] 01:42:24, metric 20
                    > to 10.0.0.6 via fe-1/2/1.0
10.0.0.12/30       *[IS-IS/18] 01:42:24, metric 30
                    > to 10.0.0.6 via fe-1/2/1.0
10.0.0.16/30       *[IS-IS/18] 01:42:24, metric 20
                    > to 10.0.0.2 via fe-1/2/0.0
10.0.0.20/30       *[IS-IS/18] 01:42:24, metric 30
                    > to 10.0.0.2 via fe-1/2/0.0
10.0.0.24/30       *[IS-IS/18] 01:42:24, metric 30
                    > to 10.0.0.6 via fe-1/2/1.0
10.0.0.28/30       *[IS-IS/18] 01:42:24, metric 30
                      to 10.0.0.6 via fe-1/2/1.0
                    > to 10.0.0.2 via fe-1/2/0.0
10.2.0.0/32        *[BGP/170] 02:22:30, localpref 100, from 192.168.0.3
                      AS path: 2 I, validation-state: unverified
                    > to 10.0.0.2 via fe-1/2/0.0, label-switched-path test_path
10.2.1.1/32        *[BGP/170] 02:20:23, localpref 100, from 192.168.0.3
                      AS path: 2 I, validation-state: unverified
                    > to 10.0.0.2 via fe-1/2/0.0, label-switched-path test_path
10.3.0.0/32        *[BGP/170] 02:22:30, localpref 100, from 192.168.0.3
                      AS path: 2 I, validation-state: unverified
                    > to 10.0.0.2 via fe-1/2/0.0, label-switched-path test_path
10.3.1.1/32        *[BGP/170] 02:20:23, localpref 100, from 192.168.0.3
                      AS path: 2 I, validation-state: unverified
                    > to 10.0.0.2 via fe-1/2/0.0, label-switched-path test_path
192.168.0.1/32     *[Direct/0] 4d 09:08:47
                    >    via lo0.0
192.168.0.2/32     *[IS-IS/18] 01:42:24, metric 10
                    > to 10.0.0.6 via fe-1/2/1.0
192.168.0.3/32     *[IS-IS/18] 01:42:24, metric 20
                    > to 10.0.0.6 via fe-1/2/1.0
192.168.0.4/32     *[IS-IS/18] 01:42:24, metric 30
                    > to 10.0.0.6 via fe-1/2/1.0
                      to 10.0.0.2 via fe-1/2/0.0
192.168.0.5/32     *[IS-IS/18] 01:42:24, metric 10
                    > to 10.0.0.2 via fe-1/2/0.0
192.168.0.6/32     *[IS-IS/18] 01:42:24, metric 20
                    > to 10.0.0.2 via fe-1/2/0.0
192.168.0.7/32     *[BGP/170] 02:20:23, localpref 100, from 192.168.0.3
                      AS path: 2 I, validation-state: unverified
                    > to 10.0.0.2 via fe-1/2/0.0, label-switched-path test_path

inet.3: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.12/30       *[IS-IS/18] 01:41:21, metric 30
                    > to 10.0.0.2 via fe-1/2/0.0, label-switched-path test_path
10.0.0.24/30       *[IS-IS/18] 01:41:21, metric 30
                    > to 10.0.0.2 via fe-1/2/0.0, label-switched-path test_path
10.0.0.28/30       *[IS-IS/18] 01:41:21, metric 30
                    > to 10.0.0.2 via fe-1/2/0.0, label-switched-path test_path
192.168.0.3/32     *[RSVP/7/1] 01:41:21, metric 20
                    > to 10.0.0.2 via fe-1/2/0.0, label-switched-path test_path
                    [IS-IS/18] 01:41:21, metric 20
                    > to 10.0.0.2 via fe-1/2/0.0, label-switched-path test_path
192.168.0.4/32     *[IS-IS/18] 01:41:21, metric 30
                    > to 10.0.0.2 via fe-1/2/0.0, label-switched-path test_path

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

49.0002.0192.0168.0001/72                
                   *[Direct/0] 4d 09:08:47
                    >    via lo0.0

mpls.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0                  *[MPLS/0] 4d 09:10:00, metric 1
                         Receive
1                  *[MPLS/0] 4d 09:10:00, metric 1
                         Receive
2                  *[MPLS/0] 4d 09:10:00, metric 1
                         Receive
13                 *[MPLS/0] 4d 09:10:00, metric 1
                         Receive

Meaning

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 10.0.0.24/30, BGP also uses the LSP in its routes to 10.2.0.0 and 10.3.0.0.

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

Checking the RSVP Sessions

Purpose

Display information about RSVP sessions

Action

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

Ingress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
192.168.0.3     192.168.0.1     Up       0  1 FF       -   299776 test_path
Total 1 displayed, Up 1, Down 0

Egress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Ingress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Egress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
192.168.0.3     192.168.0.1     Up       0  1 FF  299776   299808 test_path
Total 1 displayed, Up 1, Down 0

Ingress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Egress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
192.168.0.3     192.168.0.1     Up       0  1 FF  299808        3 test_path
Total 1 displayed, Up 1, Down 0

Ingress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Egress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
192.168.0.3     192.168.0.1     Up       0  1 FF       3        - test_path
Total 1 displayed, Up 1, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Meaning

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

Purpose

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.

Action

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.

   [edit protocols mpls]user@A# set traffic-engineering bgpuser@A# commit
2. Use the show route forwarding-table command to check the paths when traffic-engineering bgp (the default) is configured.
   user@A> show route forwarding-table destination 10.2.1.1

   Routing table: default.inet
   Internet:
   Destination        Type RtRef Next hop           Type Index NhRef Netif
   10.2.1.1/32        user     0                    indr 262145     6
                                 10.0.0.2          Push 299776  1013     2 fe-1/2/0.0

   user@A> show route forwarding-table destination 192.168.0.3

   Routing table: default.inet
   Internet:
   Destination        Type RtRef Next hop           Type Index NhRef Netif
   192.168.0.3/32     user     1 10.0.0.6           ucst   938    11 fe-1/2/1.0

3. Use the traceroute command to check the paths when traffic-engineering bgp (the default) is configured.
   user@A> traceroute 10.2.1.1

   traceroute to 10.2.1.1 (10.2.1.1), 30 hops max, 40 byte packets
    1  10.0.0.2 (10.0.0.2)  11.086 ms  1.587 ms  1.603 ms
        MPLS Label=299776 CoS=0 TTL=1 S=1
    2  10.0.0.18 (10.0.0.18)  1.455 ms  1.477 ms  1.442 ms
        MPLS Label=299808 CoS=0 TTL=1 S=1
    3  10.0.0.29 (10.0.0.29)  2.240 ms  1.045 ms  1.243 ms
    4  10.2.1.1 (10.2.1.1)  1.363 ms  1.389 ms  1.374 ms

   user@A> traceroute 192.168.0.3

   traceroute to 192.168.0.3 (192.168.0.3), 30 hops max, 40 byte packets
    1  10.0.0.6 (10.0.0.6)  1.759 ms  1.872 ms  2.281 ms
    2  bb03-cclab-lo0.spglab.juniper.net (192.168.0.3)  2.119 ms  2.157 ms  1.598 ms
   

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.

   [edit protocols mpls]user@A# set traffic-engineering bgp-igpuser@A# commit
5. Use the show route forwarding-table command to check the paths when traffic-engineering bgp-igp is configured.
   user@A> show route forwarding-table destination 10.2.1.1

   Routing table: default.inet
   Internet:
   Destination        Type RtRef Next hop           Type Index NhRef Netif
   10.2.1.1/32        user     0                    indr 262145     6
                                 10.0.0.2          Push 299776  1013     2 fe-1/2/0.0

   user@A> show route forwarding-table destination 192.168.0.3

   Routing table: default.inet
   Internet:
   Destination        Type RtRef Next hop           Type Index NhRef Netif
   192.168.0.3/32     user     1 10.0.0.2          Push 299776  1013     8 fe-1/2/0.0
   

6. Use the traceroute command to check the paths when traffic-engineering bgp-igp is configured.
   user@A> traceroute 10.2.1.1

   traceroute to 10.2.1.1 (10.2.1.1), 30 hops max, 40 byte packets
    1  10.0.0.2 (10.0.0.2)  2.348 ms  1.475 ms  1.434 ms
        MPLS Label=299776 CoS=0 TTL=1 S=1
    2  10.0.0.18 (10.0.0.18)  1.507 ms  2.307 ms  1.911 ms
        MPLS Label=299808 CoS=0 TTL=1 S=1
    3  10.0.0.29 (10.0.0.29)  1.743 ms  1.645 ms  1.940 ms
    4  10.2.1.1 (10.2.1.1)  2.041 ms  1.977 ms  2.233 ms
   

   user@A> traceroute 192.168.0.3

   traceroute to 192.168.0.3 (192.168.0.3), 30 hops max, 40 byte packets
    1  10.0.0.2 (10.0.0.2)  1.721 ms  2.558 ms  2.229 ms
        MPLS Label=299776 CoS=0 TTL=1 S=1
    2  10.0.0.18 (10.0.0.18)  2.505 ms  1.462 ms  1.408 ms
        MPLS Label=299808 CoS=0 TTL=1 S=1
    3  bb03-cclab-lo0.spglab.juniper.net (192.168.0.3)  1.371 ms  1.422 ms  1.351 ms
   
   

Meaning

When traffic-engineering bgp is configured, the first trace is to a destination belonging to the BGP-learned 10.2.0.0/16 prefix, and follows the LSP. The second trace is to the IS-IS-learned 192.168.0.3 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 192.168.0.3 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 10.2.1.1 continues to follow the LSP. The second trace to 192.168.0.3 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.