Home > Articles > Cisco Network Technology > General Networking > MPLS Traffic Engineering

MPLS Traffic Engineering

Chapter Description

MPLS Traffic Engineering (MPLS TE) is a growing implementation in today's service provider networks. MPLS adoption in service provider networks has increased manifold due to its inherent TE capabilities. This chapter provides you with information on the operation and configuration of MPLS TE on Cisco routers.

Configuring MPLS TE

This section introduces you to the steps involved in the configuration of Cisco routers to implement MPLS TE. The first subsection identifies the stepwise procedure involved in the configuration of Cisco routers for TE. It is then followed by a subsection depicting the actual configuration process on a topology consisting of six routers in which multiple paths can be used for TE purposes from a headend to tailend router.

MPLS TE Configuration Flowchart

The configuration of Cisco routers for MPLS TE support can be described in a systematic flowchart as depicted in the top row of Figure 9-11. It is assumed that the network is already configured with an IGP for NLRI exchange as well as MPLS forwarding on the appropriate interfaces prior to performing the following steps:

  1. Configure a loopback interface for tunnel association to the TE tunnel, as depicted in Figure 9-11.
    09fig11.gif

    Figure 9-11 MPLS TE Configuration: Step 1

  2. The next step is the first configuration performed in relevance to enabling TE on the Cisco router. Figure 9-12 outlines the configurations performed on the Cisco router to enable TE functions globally on the router as well as interfaces that are possible candidates to be chosen for TE LSP paths.
    09fig12.gif

    Figure 9-12 MPLS TE Configuration: Step 2

  3. Configure RSVP bandwidth parameters that will be used on the interface for signaling purposes and resource allocation for traffic engineered sessions. Figure 9-13 outlines the configurations that need to be performed on the interface.
    09fig13.gif

    Figure 9-13 MPLS TE Configuration: Step 3

  4. After the interfaces that can be chosen to be a part of the LSP have been enabled for TE as well as RSVP parameters configured, the next step is to configure the tunnel interface. The main configurations of the tunnel interface would be association of the tunnel interface IP address to the loopback address configured earlier, the mode of the tunnel operation, and the destination address of the tunnel endpoint, which would map to the IP address of a loopback on the tailend router as well as the process by which the tunnel LSP path is chosen. In this step, if the path chosen for the LSP is done using the IGP and CSPF, the path option is chosen to be dynamic. Figure 9-14 depicts the configuration involved in setting up the tunnel interface.
    09fig14.gif

    Figure 9-14 MPLS TE Configuration: Step 4

  5. In addition to using the IGP for LSP path setup, the user can also define an explicit-path that will be used for the TE LSP. This optional step can be performed on the headend router so that the dynamic tunnel can be chosen to be the tunnel of choice for traffic forwarding and the explicit-path tunnel or user-defined static tunnel can be the backup path. In some cases, load balancing can also be achieved between the two types. Figure 9-15 depicts the configurations to set up an explicit-path LSP.
    09fig15.gif

    Figure 9-15 MPLS TE Configuration: Step 5

  6. By default, the tunnel interface is not announced into the IGP for use in the routing table. This will have to be configured explicitly for the tunnel interface to be used as the next hop in the routing table by the IGP. Figure 9-16 outlines the configurations that will have to be performed on the headend router to enable tunnel interface use as the next-hop address in the routing table for TE.
    09fig16.gif

    Figure 9-16 MPLS TE Configuration: Step 6

  7. The final step in the configuration of MPLS TE is the configuration of the IGP for TE support. The IGP in use can be either OSPF or IS-IS. The IGP process used for TE is the same as what's defined for NLRI reachability. The configurations involved for enabling TE extensions for both these protocols are outlined in Figure 9-17.
    09fig17.gif

    Figure 9-17 MPLS TE Configuration: Step 7

Configuring Dynamic Paths and Explicit Paths with MPLS TE

Figure 9-18 outlines the layout of the devices in the network that will be used to configure MPLS TE using dynamic and explicit paths. Prior to the following configurations, the devices shown in Figure 9-18 are configured with appropriate IP addresses on the interfaces as well as OSPF as the IGP. In addition, MPLS forwarding has been enabled on all interfaces in the network, as shown in Figure 9-18.

09fig18.gif

Figure 9-18 MPLS TE Configuration Topology

The following steps show how to configure dynamic paths and explicit paths with MPLS TE:

  1. Configure a loopback interface for tunnel association. This IP address can be used as the router ID in the various processes on the router (see Example 9-1).

    Example 9-1. Configure Loopback Interface for Tunnel Association

    PE1-AS1(config)#interface loopback 0
    PE1-AS1(config-if)# ip address 10.10.10.101 255.255.255.255
          
  2. Enable TE globally on the router and per interface. Because we want the headend router to take all links in the network as possible links for LSP path setup, this interface-specific configuration is performed on all links in the network topology shown in Figure 9-18. Only the configuration pertaining to PE1-AS1 is shown in Example 9-2.

    Example 9-2. Enable TE on the Router and per Interface

    PE1-AS1(config)#mpls traffic-eng tunnels
    PE1-AS1(config)#interface serial 2/0
    PE1-AS1(config-if)#mpls traffic-eng tunnels
    PE1-AS1(config-if)#interface serial 3/0
    PE1-AS1(config-if)#mpls traffic-eng tunnels
    PE1-AS1(config-if)#interface serial 4/0
    PE1-AS1(config-if)#mpls traffic-eng tunnels
          
  3. Configuring RSVP bandwidth parameters—Because we have chosen to include all interfaces in the network topology to be considered for LSP path setup, this configuration is performed on all interfaces. The chosen RSVP bandwidth configured on all interfaces is 256 K with the maximum that can be allotted to a single flow also 256 K. The configuration of headend Router PE1-AS1 is shown in Example 9-3.

    Example 9-3. Configure RSVP Parameters per Interface

    PE1-AS1(config)#interface serial 2/0
    PE1-AS1(config-if)#ip rsvp bandwidth 256 256
    PE1-AS1(config-if)#interface serial 3/0
    PE1-AS1(config-if)#ip rsvp bandwidth 256 256
    PE1-AS1(config-if)#interface serial 4/0
    PE1-AS1(config-if)#ip rsvp bandwidth 256 256
          
  4. Configuring tunnel interface parameters on the headend router—On headend Router PE1-AS1, the tunnel destination is the loopback on Router PE2-AS1 (10.10.10.103). First, dynamic tunnels are configured in which the IGP performs a CSPF calculation and identifies the appropriate LSP path. Therefore, the path-option for this tunnel creation would be dynamic. The tunnel is defined with a priority of 1 and a bandwidth requirement of 100 K. In addition, the tunnel is also provided a setup and hold priority of 1 to define that this is the most preferred tunnel LSP in the domain. See Example 9-4.

    Example 9-4. Configure Tunnel Interface Parameters on PE1-AS1

    PE1-AS1(config)#interface Tunnel0
    PE1-AS1(config-if)# ip unnumbered Loopback0
    PE1-AS1(config-if)# tunnel destination 10.10.10.103
    PE1-AS1(config-if)# tunnel mode mpls traffic-eng
    PE1-AS1(config-if)# tunnel mpls traffic-eng priority 1 1
    PE1-AS1(config-if)# tunnel mpls traffic-eng bandwidth  100
    PE1-AS1(config-if)# tunnel mpls traffic-eng path-option 1 dynamic
          
  5. Configuring dynamic tunnel announcement into IGP—In this step, the tunnel interface is configured to be added into the IGP routing table to enable traffic forwarding along the tunnel. See Example 9-5.

    Example 9-5. Announce Tunnel Interface into IGP

    PE1-AS1(config)#interface Tunnel0
    PE1-AS1(config-if)#tunnel mpls traffic-eng autoroute announce
          
  6. Configure explicit-path tunnel—In this step, an explicit-path tunnel named LSP1 is configured via P2-AS1 between PE1-AS1 and PE2-AS1. Configure the tunnel interface with appropriate parameters. The tunnel is configured with association to the same loopback address as used earlier with the same destination address on PE2-AS1. The resource requirements of the tunnel are also maintained. However, the tunnel priorities are configured to be 2 versus 1 in the prior dynamic tunnel configuration so that the dynamic tunnel is not chosen over the explicit tunnel for establishing primary LSP. Also, the path-option maps to the name of an explicit-path are configured on the headend router that maps to next-hop addresses in the LSP path. See Example 9-6.

    Example 9-6. Configure Tunnel Interface on PE1-AS1

    PE1-AS1(config)#interface Tunnel1
    PE1-AS1(config-if)# ip unnumbered Loopback0
    PE1-AS1(config-if)# tunnel destination 10.10.10.103
    PE1-AS1(config-if)# tunnel mode mpls traffic-eng
    PE1-AS1(config-if)# tunnel mpls traffic-eng priority 2 2
    PE1-AS1(config-if)# tunnel mpls traffic-eng bandwidth  100
    PE1-AS1(config-if)# tunnel mpls traffic-eng path-option 1 explicit name LSP1
          
  7. Configure the explicit-path with next-hop IP addresses of routers in the LSP path, as depicted in Example 9-7.

    Example 9-7. Configuration of Explicit LSP Path

    PE1-AS1(config)#ip explicit-path name LSP1
    PE1-AS1(cfg-ip-expl-path)#next-address 10.10.10.10
    Explicit Path name LSP1:
        1: next-address 10.10.10.10
    PE1-AS1(cfg-ip-expl-path)#next-address 10.10.10.14
    Explicit Path name LSP1:
        1: next-address 10.10.10.10
        2: next-address 10.10.10.14
    PE1-AS1(cfg-ip-expl-path)#next-address 10.10.10.103
    Explicit Path name LSP1:
        1: next-address 10.10.10.10
        2: next-address 10.10.10.14
        3: next-address 10.10.10.103
  8. Configure the tunnel interface to be announced into IGP to be the preferred path for traffic engineered traffic in the domain. See Example 9-8.

    Example 9-8. Announce Tunnel Interface into IGP

    PE1-AS1(config)#interface Tunnel1
    PE1-AS1(config-if)# tunnel mpls traffic-eng autoroute announce
          
  9. Enable IGP for MPLS TE—The configurations on Router PE1-AS1 to enable OSPF for MPLS TE are shown in Example 9-9. The router ID configured under the MPLS TE module in OSPF and IS-IS is the loopback interface on the local router. This configuration needs to be performed on all routers in the TE domain.

    Example 9-9. Configure IGP for MPLS TE

    PE1-AS1(config)#router ospf 100
    PE1-AS1(config-router)#mpls traffic-eng area 0
    PE1-AS1(config-router)#mpls traffic-eng router-id loopback 0
          

Verification of MPLS TE Tunnel Creation

The following steps outline the various commands that can be entered on PE1-AS1 (after the just mentioned configuration) to determine if the TE tunnel has been created successfully on the router (headend):

  1. Perform a show mpls traffic-eng tunnels brief on the headend Routers PE1-AS1 and P1-AS1 in the LSP path, as well as the tailend Router PE2-AS1 to verify the tunnel state is up/up. The output of the command also gives us information on the LSP path in the tunnel setup. UP IF defines the upstream interface for the tunnel, and DOWN IF defines the downstream interface for the tunnel. See Example 9-10.

    Example 9-10. show mpls traffic-eng tunnels brief on Tunnel LSP Path Routers

    PE1-AS1#show mpls traffic-eng tunnels brief
    Signalling Summary:
        LSP Tunnels Process:            running
        RSVP Process:                   running
        Forwarding:                     enabled
        Periodic reoptimization:        every 3600 seconds, next in 3206 seconds
        Periodic FRR Promotion:         Not Running
        Periodic auto-bw collection:    every 300 seconds, next in 206 seconds
    TUNNEL NAME                      DESTINATION      UP IF     DOWN IF   STATE/PROT
    PE1-AS1_t0                       10.10.10.103     -         Se3/0     up/up
    
             PE1-AS1_t1                       10.10.10.103     -         Se2/0     up/up
    Displayed 2 (of 2) heads, 0 (of 0) midpoints, 0 (of 0) tails
    _________________________________________________________________________________
    P1-AS1#show mpls traffic-eng tunnels brief
    Signalling Summary:
        LSP Tunnels Process:            running
        RSVP Process:                   running
        Forwarding:                     enabled
        Periodic reoptimization:        every 3600 seconds, next in 2951 seconds
        Periodic FRR Promotion:         Not Running
        Periodic auto-bw collection:    every 300 seconds, next in 251 seconds
    TUNNEL NAME                      DESTINATION      UP IF     DOWN IF   STATE/PROT
    PE1-AS1_t0                       10.10.10.103     Se2/0     Se4/0     up/up
    Displayed 1 (of 1) heads, 1 (of 1) midpoints, 0 (of 0) tails
    _________________________________________________________________________________
    PE2-AS1#show mpls traffic-eng tunnels brief
    Signalling Summary:
        LSP Tunnels Process:            running
        RSVP Process:                   running
        Forwarding:                     enabled
        Periodic reoptimization:        every 3600 seconds, next in 2857 seconds
        Periodic FRR Promotion:         Not Running
        Periodic auto-bw collection:    every 300 seconds, next in 157 seconds
    TUNNEL NAME                      DESTINATION      UP IF     DOWN IF   STATE/PROT
    PE1-AS1_t0                       10.10.10.103     Se3/0     -         up/up
    
             PE1-AS1_t1                       10.10.10.103     Se2/0     -         up/up
          
  2. A view of the actual parameters of the tunnel can be retrieved by performing a show mpls traffic-eng tunnels destination ip-address (only Tunnel 0 depicted in Example 9-8) or a show mpls traffic-eng tunnels tunnel interface-number. As illustrated in Example 9-11, the output shows the status of the tunnel and the information about the parameters associated with the tunnel. In addition, it shows the preferred path chosen by the CSPF process under the explicit-path field in the output of the command, as shaded in Example 9-11.

    Example 9-11. MPLS TE Verification: Tunnel Parameters

    PE1-AS1#show mpls traffic-eng tunnels destination 10.10.10.103
    
             Name: PE1-AS1_t0                               
             (Tunnel0) Destination: 10.10.10.103
      
             Status:
        
             Admin: up         Oper: up     Path: valid       Signalling: connected
    
        
             path option 1, type dynamic (Basis for Setup, path weight 20)
    
      Config Parameters:
        Bandwidth: 100      kbps (Global)  Priority: 1  1   Affinity: 0x0/0xFFFF
        Metric Type: TE (default)
        AutoRoute:  enabled   LockDown: disabled  Loadshare: 100      bw-based
        auto-bw: disabled
      Active Path Option Parameters:
        State: dynamic path option 1 is active
        BandwidthOverride: disabled  LockDown: disabled  Verbatim: disabled
    
      InLabel  :  -
      OutLabel : Serial3/0, 26
      RSVP Signalling Info:
           Src 10.10.10.101, Dst 10.10.10.103, Tun_Id 0, Tun_Instance 71
        RSVP Path Info:
          My Address: 10.10.10.101
          Explicit Route: 10.10.10.2 10.10.10.6 10.10.10.103
          Record   Route:   NONE
          Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits
        RSVP Resv Info:
          Record Route:     NONE
          Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits
      History:
        Tunnel:
          Time since created: 3 hours, 42 minutes
          Time since path change: 33 minutes, 26 seconds
        Current LSP:
          Uptime: 33 minutes, 26 seconds
    _________________________________________________________________________________
    PE1-AS1#show mpls traffic-eng tunnels tunnel 0
    
    
             Name: PE1-AS1_t0                               
             (Tunnel0) Destination: 10.10.10.103
      
             Status:
        
             Admin: up         Oper: up     Path: valid       Signalling: connected
    
        
             path option 1, type dynamic (Basis for Setup, path weight 20)
    
      Config Parameters:
        Bandwidth: 100      kbps (Global)  Priority: 1  1   Affinity: 0x0/0xFFFF
        Metric Type: TE (default)
        AutoRoute:  enabled   LockDown: disabled  Loadshare: 100      bw-based
        auto-bw: disabled
      Active Path Option Parameters:
        State: dynamic path option 1 is active
        BandwidthOverride: disabled  LockDown: disabled  Verbatim: disabled
    
      InLabel : -
      OutLabel : Serial3/0, 26
      RSVP Signalling Info:
           Src 10.10.10.101, Dst 10.10.10.103, Tun_Id 0, Tun_Instance 71
        RSVP Path Info:
          My Address: 10.10.10.101
          Explicit Route: 10.10.10.2 10.10.10.6 10.10.10.103
          Record   Route:   NONE
          Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits
        RSVP Resv Info:
          Record   Route:   NONE
          Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits
      Shortest Unconstrained Path Info:
        
             Path Weight: 20 (TE)
        
             Explicit Route: 10.10.10.2 10.10.10.6 10.10.10.103
      History:
        Tunnel:
          Time since created: 3 hours, 42 minutes
          Time since path change: 33 minutes, 47 seconds
        Current LSP:
          Uptime: 33 minutes, 47 seconds
  3. Verify that the next hop to the destination IP address points to the tunnel interfaces in the IGP routing table. Only routes to network 10.10.10.103 (destination) pointing to the tunnel interface as the next hop are shown for brevity. See Example 9-12. Because we have two tunnels configured on Router PE1-AS1 (dynamic and explicit) with the same parameters, the traffic to destination 10.10.10.103 is load balanced equally among the two paths, as shown in Example 9-12, because the bandwidths configured on the TE tunnels are the same. Traffic from PE1-AS1 to PE2-AS1 is equally load balanced across the two tunnels.

    Example 9-12. Verify Next-Hop Mapping to Tunnel Interface (Truncated)

    PE1-AS1#show ip route 10.10.10.103
    Routing entry for 10.10.10.103/32
      Known via "ospf 100", distance 110, metric 97, type intra area
      Routing Descriptor Blocks:
      * directly connected, via Tunnel0
          Route metric is 97, traffic share count is 1
        directly connected, via Tunnel1
          Route metric is 97, traffic share count is 1
  4. By performing an extended ping to the destination loopback address on PE2-AS1, we see that the packets are load balanced across the two tunnel paths. See Example 9-13.

    Example 9-13. Extended Ping Verification for MPLS TE Tunnel Path

    PE2-AS1#ping
    Protocol [ip]:
    Target IP address: 10.10.10.103
    Repeat count [5]: 2
    Datagram size [100]:
    Timeout in seconds [2]:
    Extended commands [n]: y
    Source address or interface: 10.10.10.101
    Type of service [0]:
    Set DF bit in IP header? [no]:
    Validate reply data? [no]:
    Data pattern [0xABCD]:
    Loose, Strict, Record, Timestamp, Verbose[none]: r
    Number of hops [ 9 ]: 4
    Loose, Strict, Record, Timestamp, Verbose[RV]:
    Sweep range of sizes [n]:
    Type escape sequence to abort.
    Sending 2, 100-byte ICMP Echos to 10.10.10.103, timeout is 2 seconds:
    Reply to request 0 (28 ms).  Received packet has options
     Total option bytes= 40, padded length=40
     Record route:
       
             (10.10.10.103)
       
             (10.10.10.6)
       
             (10.10.10.2)
       
             (10.10.10.101) <*>
    End of list
    
    Reply to request 1 (28 ms). Received packet has options
     Total option bytes= 40, padded length=40
     Record route:
       
             (10.10.10.103)
       
             (10.10.10.14)
       
             (10.10.10.10)
       
             (10.10.10.101) <*>
    End of list

Final Configurations for Dynamic and Explicit Tunnels with MPLS TE

Example 9-14 and Example 9-15 outline the final configurations for all devices in Figure 9-18 for implementation of dynamic and explicit tunnels from PE1-AS1 to PE2-AS1.

Example 9-14. Final Configurations for PE1-AS1 and PE2-AS1 to Implement Dynamic and Explicit Tunnels

   hostname PE1-AS1

   !

   ip cef

   !

   mpls traffic-eng tunnels

   !

   interface Loopback0
 
   ip address 10.10.10.101 255.255.255.255

   !

   interface Tunnel0
 
   ip unnumbered Loopback0
 
   tunnel destination 10.10.10.103
 
   tunnel mode mpls traffic-eng
 
   tunnel mpls traffic-eng autoroute announce
 
   tunnel mpls traffic-eng priority 1 1
 
   tunnel mpls traffic-eng path-option 1 dynamic
 
   tunnel MPLS traffic-eng bandwidth 100

   !

   interface Tunnel1
 
   ip unnumbered Loopback0
 
   tunnel destination 10.10.10.103
 
   tunnel mode mpls traffic-eng
 
   tunnel mpls traffic-eng autoroute announce
 
   tunnel mpls traffic-eng priority 2 2
 
   tunnel mpls traffic-eng path-option 1 explicit name LSP1
 
   tunnel MPLS traffic-end bandwidth 100

   !

   interface Serial2/0
 
   ip address 10.10.10.9 255.255.255.252
 
   mpls traffic-eng tunnels
 
   tag-switching ip
 
   fair-queue 64 256 48
 
   ip rsvp bandwidth 1000

   !

   interface Serial3/0
 
   ip address 10.10.10.1 255.255.255.252

   mpls traffic-eng tunnels

   mpls ip

   ip rsvp bandwidth 1000

   !

   interface Serial4/0
 
   ip address 10.10.10.17 255.255.255.252
 
   mpls traffic-eng tunnels
 
   MPLS ip
 
   ip rsvp bandwidth 1000

   !

   router ospf 100
 
   mpls traffic-eng router-id Loopback0
 
   mpls traffic-eng area 0
 
   network 10.0.0.0 0.255.255.255 area 0

   !

   ip explicit-path name LSP1 enable
 
   next-address 10.10.10.10
 
   next-address 10.10.10.14
 
   next-address 10.10.10.103

   !

   end
____________________________________________________________________________
hostname PE2-AS1

   !

   ip cef

   !

   mpls traffic-eng tunnels

   !

   interface Loopback0
 
   ip address 10.10.10.103 255.255.255.255

   !

   interface Serial2/0
 
   ip address 10.10.10.14 255.255.255.252

   mpls traffic-eng tunnels

   mpls ip

   ip rsvp bandwidth 1000

   !

   interface Serial3/0
 
   ip address 10.10.10.6 255.255.255.252
 
   mpls traffic-eng tunnels
 
   mpls ip
 
   ip rsvp bandwidth 1000

   !

   interface Serial4/0
 
   ip address 10.10.10.22 255.255.255.252
 
   mpls traffic-eng tunnels
 
   mpls ip

   ip rsvp bandwidth 1000

   !

   router ospf 100

   mpls traffic-eng router-id Loopback0
 
   mpls traffic-eng area 0
 
   network 10.0.0.0 0.255.255.255 area 0

   !

   end

Example 9-15. Final Configurations for P1-AS1, P2-AS1, and P3-AS1 to Implement Dynamic and Explicit Tunnels

   hostname P1-AS1

   !

   ip cef

   !

   mpls traffic-eng tunnels

   !

   interface Loopback0
 
   ip address 10.10.10.102 255.255.255.255

   !

   interface Serial2/0
 
   ip address 10.10.10.2 255.255.255.252

   mpls traffic-eng tunnels
 
   mpls ip
 
   ip rsvp bandwidth 1000

   !

   interface Serial3/0
 
   ip address 10.10.10.26 255.255.255.252
 
   mpls traffic-eng tunnels
 
   mpls ip

   ip rsvp bandwidth 1000

   !

   interface Serial4/0
 
   ip address 10.10.10.5 255.255.255.252
 
   mpls traffic-eng tunnels
 
   mpls ip

   ip rsvp bandwidth 1000

   !

   router ospf 100
 
   mpls traffic-eng router-id Loopback0
 
   mpls traffic-eng area 0
 
   network 10.0.0.0 0.255.255.255 area 0

   !

   end
__________________________________________________________________________
hostname P2-AS1

   !

   ip cef

   !

   mpls traffic-eng tunnels

   !

   interface Loopback0
 
   ip address 10.10.10.104 255.255.255.255

   !

   interface Serial2/0
 
   ip address 10.10.10.10 255.255.255.252
 
   mpls traffic-eng tunnels
 
   MPLS ip
 
   ip rsvp bandwidth 1000

   !

   interface Serial3/0
 
   ip address 10.10.10.13 255.255.255.252
 
   mpls traffic-eng tunnels
 
   mpls ip
 
   ip rsvp bandwidth 1000

   !

   router ospf 100
 
   mpls traffic-eng router-id Loopback0
 
   mpls traffic-eng area 0
 
   network 10.0.0.0 0.255.255.255 area 0

   !

   end
__________________________________________________________________________
hostname P3-AS1

   !

   ip cef

   !

   mpls traffic-eng tunnels

   !

   interface Loopback0
 
   ip address 10.10.10.105 255.255.255.255

   !

   interface Serial2/0
 
   ip address 10.10.10.18 255.255.255.252
 
   mpls traffic-eng tunnels
 
   mpls ip
 
   ip rsvp bandwidth 1000

   !

   interface Serial3/0
 
   ip address 10.10.10.25 255.255.255.252
 
   no ip directed-broadcast
 
   mpls traffic-eng tunnels
 
   mpls ip

   ip rsvp bandwidth 1000

   !

   interface Serial4/0
 
   ip address 10.10.10.21 255.255.255.252
 
   mpls traffic-eng tunnels
 
   mpls ip
 
   ip rsvp bandwidth 1000

   !

   router ospf 100
 
   mpls traffic-eng router-id Loopback0
 
   mpls traffic-eng area 0
 
   network 10.0.0.0 0.255.255.255 area 0

   !

   end

Unequal Cost Load Balancing Across Multiple TE Tunnels

In this section, we will configure another tunnel via the path PE1-AS1, P3-AS1, and PE2-AS1 with bandwidth requirements of 50 kbps versus 100 kbps. In every five packets, load balancing is performed so that two packets are sent on Tunnel 0, two on Tunnel 1, and one packet on Tunnel 2. In this case, if the source and destination of the tunnel interfaces are the same, the traffic between the sites performs unequal cost load balancing among the various tunnels between Routers PE1-AS1 and PE2-AS1. The configuration on PE1-AS1 (headend router) for another explicit LSP path setup via the path PE1-AS1, P3-AS1, and PE2-AS1 is shown in Example 9-16.

Example 9-16. Unequal Cost Load Balancing Configuration on PE1-AS1

PE1-AS1(config)#interface Tunnel2
PE1-AS1(config-if)# ip unnumbered Loopback0
PE1-AS1(config-if)# tunnel destination 10.10.10.103
PE1-AS1(config-if)# tunnel mode mpls traffic-eng
PE1-AS1(config-if)# tunnel mpls traffic-eng autoroute announce
PE1-AS1(config-if)# tunnel mpls traffic-eng priority 3 3
PE1-AS1(config-if)# tunnel mpls traffic-eng bandwidth  50
PE1-AS1(config-if)# tunnel mpls traffic-eng path-option 1 explicit name LSP2

PE1-AS1(config)#ip explicit-path name LSP2 enable
PE1-AS1(cfg-ip-expl-path)# next-address 10.10.10.18
Explicit Path name LSP2:
    1: next-address 10.10.10.18
PE1-AS1(cfg-ip-expl-path)# next-address 10.10.10.22
Explicit Path name LSP2:
    1: next-address 10.10.10.18
    2: next-address 10.10.10.22
PE1-AS1(cfg-ip-expl-path)# next-address 10.10.10.103
Explicit Path name LSP2:
    1: next-address 10.10.10.18
    2: next-address 10.10.10.22
    3: next-address 10.10.10.103
PE1-AS1(cfg-ip-expl-path)#end

After the configuration is performed, the output of the routing table entry for 10.10.10.103/32 shows the unequal cost load balancing in effect (see Example 9-17).

Example 9-17. Verification of Unequal Cost Load Balancing

PE1-AS1#show ip route 10.10.10.103
Routing entry for 10.10.10.103/32
  Known via "ospf 100", distance 110, metric 97, type intra area
  Routing Descriptor Blocks:
  * directly connected, via Tunnel0
      Route metric is 97, traffic share count is 2
    directly connected, via Tunnel1
      Route metric is 97, traffic share count is 2
    directly connected, via Tunnel2
      Route metric is 97, traffic share count is 1

Therefore, the final configuration for PE1-AS1 includes, in addition to Example 9-14, the configuration shown in Example 9-18.

Example 9-18. Additional Configuration on PE1-AS1 for Unequal Cost Load Balancing

   interface Tunnel2
 
   ip unnumbered Loopback0
 
   no ip directed-broadcast
 
   tunnel destination 10.10.10.103
 
   tunnel mode mpls traffic-eng
 
   tunnel mpls traffic-eng autoroute announce
 
   tunnel mpls traffic-eng priority 3 3
 
   tunnel mpls traffic-eng bandwidth  50
 
   tunnel mpls traffic-eng path-option 1 explicit name LSP2

MPLS TE Fast ReRoute Link Protection

Fast ReRoute (FRR) is a procedure used in conjunction with MPLS TE to reroute around a link in the case of link failure. Protection in networks can be provided by SONET, optical protection, or, more recently, MPLS FRR. With MPLS FRR, we can implement both link and node protection. In addition, different protection policies can be applied to different classes of traffic traversing the MPLS backbone. In FRR operation, a backup tunnel is configured to be used if the primary tunnel LSP fails. The backup tunnel must be configured so that the LSP can get to the next-hop LSR downstream without attempting to use the failed link.

The configuration for implementing FRR for link protection is simple to implement. If you use a subset of the network shown in Figure 9-18 to implement link protection, as illustrated in Figure 9-19, you can configure a backup tunnel on the LSR P1-AS1. If the primary tunnel from PE1-AS1 via P1-AS1 to PE2-AS1 fails due to link failure between P1-AS1 and PE2-AS1, the backup tunnel is used to forward traffic.

09fig19.jpg

Figure 9-19 MPLS FRR Network Topology, Configuration, and Verification

Configuration of the tunnel (Tunnel0 on PE1-AS1) to be protected from a link failure includes the tunnel mpls traffic-eng fast-reroute command under the tunnel interface configuration on the headend router (PE1-AS1) to enable FRR protection on the tunnel. In addition, a backup tunnel, Tunnel100, is configured on the downstream LSR (in our case, P1-AS1) to reroute traffic if the link between P1-AS1 and PE2-AS1 fails. Configuration is performed following the procedure shown in the earlier sections with an explicit path from P1-AS1 to PE2-AS1 via P3-AS1. Finally, this tunnel (Tunnel100) on P1-AS1 is associated to the link to be protected by using the command mpls traffic-eng backup-path tunnel tunnel100 under the interface to be protected (Serial 4/0 on P1-AS1).

Verification of FRR capabilities can be performed by issuing the show mpls traffic-eng fast-reroute database detail command on the downstream LSR configured with a backup tunnel, as shown in Figure 9-19.

Implementing MPLS VPNs over MPLS TE

MPLS was initially adopted due to its inherent properties to deliver VPNs. However, in recent years, MPLS TE has gained popularity due to the robust TE capabilities it provides. In this section, we will discuss the configurations involved in the implementation of MPLS VPN over TE tunnels. TE tunnels can be configured between PE to PE routers as well as from PE to provider core or P routers. The configurations involved in both of these implementations of MPLS TE in the provider core are introduced. The network used to implement MPLS VPN over TE tunnels is shown in Figure 9-20.

09fig20.gif

Figure 9-20 MPLS VPN Over TE Network Topology/Configuration

For simplicity, the OSPF PE-CE connectivity implementation is used on both PE Routers PE1-AS1 and PE2-AS1 in Figure 9-20. For this section, the IGP used in the core is OSPF with process-id 100. The process-id for the PE to CE connections is configured under OSPF 1. All networks are in area 0.

The configurations on Routers P1-AS1, CE1-A, and CE2-A are illustrated in Figure 9-20. Configurations for PE1-AS1 and PE2-AS1 are illustrated in Example 9-19. A tunnel is already configured with a dynamic path-option between PE1-AS1 and PE2-AS1.

Example 9-19. PE1-AS1 and PE2-AS1 Configuration: MPLS VPN Over TE with PE to PE Tunnels

   hostname PE1-AS1

   !

   ip cef

   !

   ip vrf VPNoverTE
 
   rd 1:100
 
   route-target export 1:100
 
   route-target import 1:100

   !

   mpls traffic-eng tunnels

   !

   interface Loopback0
 
   ip address 10.10.10.101 255.255.255.255

   !

   interface Tunnel0
 
   ip unnumbered Loopback0
 
   tunnel destination 10.10.10.103
 
   tunnel mode mpls traffic-eng
 
   tunnel mpls traffic-eng autoroute announce
 
   tunnel mpls traffic-eng priority 1 1
 
   tunnel mpls traffic-eng bandwidth  100
 
   tunnel mpls traffic-eng path-option 1 dynamic

   !

   interface Serial2/0
 
   ip vrf forwarding VPNoverTE
 
   ip address 172.16.1.1 255.255.255.252

   !

   interface Serial3/0
 
   ip address 10.10.10.1 255.255.255.252
 
   mpls traffic-eng tunnels
 
   mpls ip
 
   ip rsvp bandwidth 256 256

   !

   router ospf 1 vrf VPNoverTE
 
   redistribute bgp 100 metric 10 subnets
 
   network 172.16.1.0 0.0.0.3 area 0

   !

   router ospf 100
 
   mpls traffic-eng router-id Loopback0
 
   mpls traffic-eng area 0
 
   network 10.10.10.0 0.0.0.3 area 0
 
   network 10.10.10.101 0.0.0.0 area 0

   !

   router bgp 100
 
   bgp router-id 10.10.10.101
 
   neighbor 10.10.10.103 remote-as 100
 
   neighbor 10.10.10.103 update-source Loopback0
 
   no auto-summary
 
   !
 
   address-family vpnv4
 
   neighbor 10.10.10.103 activate
 
   neighbor 10.10.10.103 send-community extended
 
   exit-address-family
 
   !
 
   address-family ipv4 vrf VPNoverTE
 
   redistribute ospf 1 vrf VPNoverTE metric 2

   exit-address-family

   !

   end
___________________________________________________________________________________
hostname PE2-AS1

   !

   ip cef

   !

   ip vrf VPNoverTE
 
   rd 1:100
 
   route-target export 1:100
 
   route-target import 1:100

   !

   mpls traffic-eng tunnels

   !

   interface Loopback0
 
   ip address 10.10.10.103 255.255.255.255

   !

   interface Serial3/0
 
   ip address 10.10.10.6 255.255.255.252
 
   mpls traffic-eng tunnels
 
   mpls ip
 
   ip rsvp bandwidth 256 256

   !

   interface Serial4/0
 
   ip vrf forwarding VPNoverTE
 
   ip address 172.16.2.1 255.255.255.252

   !

   router ospf 1 vrf VPNoverTE
 
   redistribute bgp 100 metric 2 subnets
 
   network 172.16.2.0 0.0.0.3 area 0

   !

   router ospf 100
 
   mpls traffic-eng router-id Loopback0
 
   mpls traffic-eng area 0
 
   network 10.10.10.4 0.0.0.3 area 0
 
   network 10.10.10.103 0.0.0.0 area 0

   !

   router bgp 100
 
   bgp router-id 10.10.10.103
 
   neighbor 10.10.10.101 remote-as 100
 
   neighbor 10.10.10.101 update-source Loopback0
 
   !
 
   address-family vpnv4
 
   neighbor 10.10.10.101 activate
 
   neighbor 10.10.10.101 send-community extended
 
   exit-address-family
 
   !
 
   address-family ipv4 vrf VPNoverTE
 
   redistribute ospf 1 vrf VPNoverTE metric 2
 
   exit-address-family

   !

   end

Verification of MPLS VPN over TE with PE to PE Tunnels

Figure 9-21 outlines the various verification steps for identifying the operation of MPLS VPNs over TE with PE to PE tunnels.

09fig21.jpg

Figure 9-21 MPLS VPN over TE Verification—PE to PE Tunnels

Figure 9-21 illustrates the routing tables on CE routers in which the CE routers learn the routes from the remote CEs via the MPLS backbone and place them in their local routing tables as OSPF IA routes, though all CE routes are in area 0 because sham-links are not configured.

Figure 9-21 also shows the routing table on the respective PE routers for the VRF VPNoverTE to check for route propagation in the MPLS VPN domain. As can be derived from the output, the appropriate VPN routes obtained from the remote CEs are learned from the next hop that maps to the remote PE loopback.

A closer look at the prefix 172.16.1.102 (loopback0 on CE2-A), learned across the MPLS domain one PE1-AS1, indicates a next-hop address of the remote PE loopback 10.10.10.103 (lo0 on PE2-AS1). In the global routing table, if this VPN forwards traffic over the MPLS TE tunnel configured on PE1-AS1, the next-hop address of 10.10.10.103 must point to the tunnel interface (Tunnel0) as shown in Figure 9-21 by the output of show ip route 10.10.10.103 on PE1-AS1. In addition, note that in the label-stack imposed on the packets in the MPLS domain when implementing MPLS VPN over TE (one label for MPLS VPN and the top label for TE), the top label maps to the label assigned by RSVP for the traffic engineered LSP path. Therefore, the out-label value in the output of show MPLS traffic-eng tunnels tunnel0 (16) maps to the top label in the label stack, as highlighted in the output of show ip cef vrf VPNoverTE 172.16.1.102 in Figure 9-21.

For final verification of connectivity, an extended ping is performed between loopback interfaces on CE routers, as shown in Figure 9-21.

Configuration of MPLS VPN over TE with PE to P Tunnels

In the preceding section, MPLS VPN was configured over TE tunnels in which the TE tunnel was configured between the two PE routers in the MPLS domain. Another possibility that might arise while deploying MPLS VPN over a TE enabled domain is a tunnel existing between a PE router and a provider core router. In our existing setup, the tunnel interface, Tunnel 0, configured on the PE Router PE1, is changed so that the destination of the tunnel is the loopback address on P1 or 10.10.10.102/32 (see Example 9-20). This configuration might be used in conjunction with FRR to enable link protection in the SP backbone for MPLS forwarded traffic belonging to a customer.

Example 9-20. Configuration on PE1-AS1: Tunnel Destination Changed to 10.10.10.102/32

PE1-AS1(config)#interface tunnel 0
PE1-AS1(config-if)# tunnel destination 10.10.10.102

If no other changes in configuration are made on any router, the CE routers no longer have connectivity to one another because the LSP is broken, as shown in Example 9-21.

Example 9-21. CE1-AS1 Cannot Reach CE2 Because LSP Is Broken

CE1-AS1#ping 172.16.1.102 source 172.16.1.101
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.102, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

To enable a complete LSP, MPLS is enabled on the tunnel interface on PE1-AS1. Also, P1-AS1 is configured to accept directed hellos, as shown in Example 9-22.

Example 9-22. Enabling MPLS on the Tunnel Interface and Configuring Directed-Hello Accept on P1-AS1

PE1-AS1(config)#interface tunnel 0
PE1-AS1(config-if)#mpls ip
__________________________________________________________________________________
P1-AS1(config)#mpls ldp discovery targeted-hello accept

Because the P1-AS1 router can accept directed hellos from neighbors who are not directly connected, the LSP is now established using the tunnel. This is shown in Figure 9-22 where the next hop for the remote CE loopback interfaces point to the interface tunnel 0 on PE1-AS1.

09fig22.gif

Figure 9-22 MPLS VPN Over TE Verification—PE to P Tunnels

Connectivity between CE routers is verified using extended pings between loopback interfaces on CE routers, as shown in Figure 9-22.

5. Command Reference | Next Section Previous Section