MPLS Traffic Engineering

Transcription

1

2 8 C H A P T E R S U P P L E M E N T MPLS Traffic Engineering This online supplement of Chapter 8 deals with a few advanced traffic engineering (TE) topics. Ensure that you have read Chapter 8 in the book before you read this supplement. This supplement first covers some Resource Reservation Protocol (RSVP) enhancements that were developed for MPLS TE, and then it discusses some bandwidth options for TE tunnels. An important new advancement is MPLS TE auto tunnels. Although they are regular TE tunnels, they are special in one way: Cisco IOS automatically creates them. As such, the operator is saved from the tedious task of having to configure many TE tunnels in the network. DiffServaware TE tunnels are briefly explained in this supplement. You will learn how they differ from the kind of TE tunnels that have been covered so far. All the TE tunnels that you have seen so far have been tunnels inside one area, or intra-area TE tunnels. Here, you learn how to implement interarea TE tunnels. This online supplement finishes with a brief overview on how to troubleshoot MPLS TE. RSVP Enhancements RFC 2961, RSVP Refresh Overhead Reduction Extensions, specifies mechanisms to reduce the number of RSVP packets sent and to enhance the scalability and reliability of RSVP. RSVP is a chatty protocol that sends periodic refreshes. This is why RSVP is often referred to as being a soft-state protocol. If no refreshes were to be received for some time, the reservation state would be removed. PATH and RESV messages are sent periodically more or less every 30 seconds. This enhancement makes RSVP more reliable by introducing acknowledgements and makes it more scalable by bundling several messages into one packet and by summarizing refresh messages. To enable RSVP refresh reduction, you need to configure the following global command: ip rsvp signalling refresh reduction The default refresh interval for RSVP messages is 30 seconds. You can change this with the following command: ip rsvp signalling refresh interval interval-value

3 703 Chapter 8: MPLS Traffic Engineering If four successive refreshes are lost, RSVP removes the state. You can change this default with the following command: ip rsvp signalling refresh misses msg-count The msg-count value is a value between 2 and 10. RSVP Hello Normally, when a link failure occurs, it is detected immediately or at least quickly. At that point, RSVP signals the problem by sending a Path Error to the head end router, and the Interior Gateway Protocol (IGP) advertises it. However, when the two label switching routers (LSR) are connected through a Layer 2 switched network, it is possible for the failure in Layer 3 communication between the two routers to remain undetected for some time, because the links on both sides remain in the up state. RSVP hellos can bring a faster means of detecting a failure between LSRs. The command to enable RSVP hellos is this: ip rsvp signalling hello Every interval, a Hello Request is sent to the neighboring router. This neighboring router responds by sending a Hello Ack back. If four intervals pass without receiving a Hello Ack, the router declares the neighbor down. The following command lets you change the interval for sending RSVP Hello packets: ip rsvp signalling hello refresh interval interval-value The interval-value is a number between 1000 and 30,000 that is in milliseconds. By default, an RSVP Hello packet is sent every 10 seconds. You can also change the number of missed acknowledgement packets before declaring the neighbor down with the following command: ip rsvp signalling hello refresh misses msg-count The msg-count value is a value between 4 and 10. IP RSVP Debugging Example 8-1 demonstrates some show ip rsvp commands that can be helpful in troubleshooting RSVP. Notice that you can use these commands to show the reserved bandwidth by TE tunnels and their attributes. Example 8-1 show ip rsvp Commands brussels#show ip rsvp neighbor RSVP RSVP

4 IP RSVP Debugging 704 Example 8-1 show ip rsvp Commands (Continued) RSVP RSVP RSVP RSVP Unknown brussels#show ip rsvp interface interface rsvp allocated i/f max flow max sub max PO10/0 ena 0 155M 155M 10M PO10/1 ena 0 155M 155M 10M PO10/2 ena 0 155M 155M 10M PO10/3 ena 100M 155M 155M 10M PO14/0 ena 0 155M 155M 0 Tu1000 ena Tu2000 ena brussels#show ip rsvp interface detail PO10/3: RSVP: Enabled Bandwidth: Curr allocated: 100M bits/sec Max. allowed (total): 155M bits/sec Max. allowed (per flow): 155M bits/sec Max. allowed for LSP tunnels using sub-pools: 10M bits/sec Set aside by policy (total): 0 bits/sec Signalling: DSCP value used in RSVP msgs: 0x3F Number of refresh intervals to enforce blockade state: 4 Authentication: disabled brussels#show ip rsvp reservation To From Pro DPort Sport Next Hop I/F Fi Serv BPS PO10/3 SE LOAD 100M PO10/1 SE LOAD 0 brussels#show ip rsvp reservation detail Reservation: Tun Dest: Tun ID: 1 Ext Tun ID: Tun Sender: LSP ID: 5846 Next Hop: on POS10/3 Label: 0 (outgoing) Reservation Style is Shared-Explicit, QoS Service is Controlled-Load Average Bitrate is 100M bits/sec, Maximum Burst is 1K bytes Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes RRO: /32, Flags:0x0 (No Local Protection) Label subobject: Flags 0x1, C-Type 1, Label 0 continues

5 705 Chapter 8: MPLS Traffic Engineering Example 8-1 show ip rsvp Commands (Continued) Resv ID handle: 1A Status: Policy: Accepted. Policy source(s): MPLS/TE brussels#show ip rsvp sender detail PATH: Tun Dest: Tun ID: 1 Ext Tun ID: Tun Sender: LSP ID: 5846 Path refreshes: arriving: from PHOP on PO10/2 every msecs sent: to NHOP on POS10/3 Session Attr: Setup Prio: 7, Holding Prio: 7 Flags: (0x7) Local Prot desired, Label Recording, SE Style Session Name: paris_t1 ERO: (incoming) (Strict IPv4 Prefix, 8 bytes, /32) (Strict IPv4 Prefix, 8 bytes, /32) (Strict IPv4 Prefix, 8 bytes, /32) ERO: (outgoing) (Strict IPv4 Prefix, 8 bytes, /32) (Strict IPv4 Prefix, 8 bytes, /32) RRO: /32, Flags:0x0 (No Local Protection) Traffic params - Rate: 100M bits/sec, Max. burst: 1K bytes Min Policed Unit: 0 bytes, Max Pkt Size bytes Fast-Reroute Backup info: Inbound FRR: Not active Outbound FRR: Ready -- backup tunnel selected Backup Tunnel: Tu1000 (label 0) Bkup Sender Template: Tun Sender: LSP ID: 5846 Bkup FilerSpec: Tun Sender: , LSP ID: 5846 Path ID handle: Incoming policy: Accepted. Policy source(s): MPLS/TE Status: Output on POS10/3. Policy status: Forwarding. Handle: F Path Option Selection with Bandwidth Override You configure the bandwidth that a TE tunnel requires with the tunnel mpls traffic-eng bandwidth command. This can be overridden by specifying a bandwidth on a specific path option. When the TE label switched path (LSP) is signaled by that specific path option, the bandwidth that is associated with the path option is signaled, not the configured bandwidth with the command

6 Bandwidth Protection on Backup Tunnels 706 tunnel mpls traffic-eng bandwidth. This can be handy when you are configuring several path options for a TE tunnel, when you know that each path has a specific maximum bandwidth. Alternatively, you can use it for several path options, with a decreasing bandwidth requirement for each path option, because the TE LSP did not successfully signal with the previous path option because of the lack of bandwidth. Example 8-2 shows a demonstration of this. Example 8-2 Path Option Selection with Bandwidth Override interface Tunnel1 ip unnumbered Loopback0 tunnel destination tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 7 7 tunnel mpls traffic-eng bandwidth tunnel mpls traffic-eng path-option 10 explicit name london-rome tunnel mpls traffic-eng path-option 20 explicit name london-rome-2 bandwidth tunnel mpls traffic-eng path-option 30 dynamic bandwidth tunnel mpls traffic-eng path-option 40 dynamic bandwidth 0 This tunnel first tries to establish an LSP with a bandwidth of 550 Mbps by using the path option 10. If this fails, the tunnel tries path-option 20. This path option specifies a bandwidth requirement of only 250 Mbps for the tunnel. If this fails, too, the tunnel tries the dynamic path option 30, with a bandwidth of 150 Mbps. Finally, if this fails, the tunnel tries a dynamic path option without reserving bandwidth. Bandwidth Protection on Backup Tunnels You can assign a bandwidth requirement to backup tunnels. You might deploy this in a typical scenario in which you have voice traffic that needs a guaranteed service. When the point of local repair (PLR) assigns the TE LSP to the backup tunnel, it checks whether the bandwidth of the backup tunnel is sufficient for the reroutable TE LSP. The command to assign bandwidth to the backup tunnel is tunnel mpls traffic-eng backup-bw. You can either assign the required bandwidth or configure unlimited. Unlimited indicates that the backup tunnel can carry all and every LSP, because it virtually has unlimited bandwidth. The PLR tries to optimize when assigning TE LSPs to backup tunnels to optimize the protected bandwidth, but it selects next-nexthop (NNHOP) backup tunnels before next-hop (NHOP) backup tunnels. When the PLR assigns TE LSPs to backup tunnels, it might want to check that the current choice of assigning a TE LSP to a backup tunnel is still the best choice. The condition for a change might be the bandwidth change of the backup tunnel or the appearance or disappearance of backup tunnels. The PLR can perform this check immediately if the event is the appearance or disappearance of a backup tunnel,

7 707 Chapter 8: MPLS Traffic Engineering or the PLR can perform it periodically. A TE LSP that is being assigned to a new backup tunnel is called promotion. By default, the periodic check is every 5 minutes, but you can change it with the command mpls traffic-eng fast-reroute timers promotion. When the tunnel has the command tunnel mpls traffic-eng backup-bw, it has a higher priority than tunnels without bandwidth protection. This tunnel can then preempt these other tunnels. It is said that these other tunnels are demoted. By default, Cisco IOS minimizes the number of demoted TE LSPs to provide enough bandwidth. You can change this by configuring mpls traffic-eng fastreroute backup-prot-preemption optimize-bw on the routers. The behavior then minimizes the amount of wasted bandwidth when demoting the TE LSPs. In the first behavior, larger TE LSPs are demoted, and more bandwidth is wasted. In the latter behavior, more and smaller TE LSPs are demoted. The backup tunnel indicates that bandwidth protection is desired by setting the bandwidth protection desired flag in the SESSION_ATTRIBUTE object. Auto Tunnels LSRs can automatically create auto tunnels. Therefore, you do not have to configure them, and they do not show up in the configuration of the router. However, the path calculation and the signaling of the TE LSPs are no different from regular TE tunnels. These auto tunnels have the following characteristics: 0 bandwidth Setup and holding priority of 7 Affinity bits 0x0/0xFFFF You can see the created auto tunnels with the command show mpls traffic-eng tunnels brief. Backup Auto Tunnels The sections on fast rerouting for link and node protection must have made it clear to you that to protect the TE LSPs completely, you must configure several backup tunnels. This is a tedious task, and it is easy to make errors. That is why backup auto tunnels are created automatically for TE tunnels that have fast rerouting enabled. Both NHOP and NNHOP backup auto tunnels are created to protect links and nodes. The backup auto tunnels are created as soon as the following occurs: The first RSVP RESV message is seen. A PATH message requesting protection for an established TE LSP is seen. The RRO changes.

8 Auto Tunnels 708 Look at Figure 8-1. Assuming that backup auto tunnels is only enabled on the router brussels and one TE tunnel is set up from the router brussels to the router rome, brussels creates one NHOP and NNHOP backup auto tunnel, protecting the link brussels-berlin and the node berlin. Example 8-3 shows an example of these two backup auto tunnels. To enable backup auto tunnels, configure the global command mpls traffic-eng auto-tunnel backup. Figure 8-1 Backup Auto Tunnels Example NNHOP Backup Tunnel NHOP Backup Tunnel POS 10/ frankfurt Loopback / Loopback /32 paris POS 10/ brussels berlin rome sydney Example 8-3 Example of Backup Auto Tunnels mpls traffic-eng auto-tunnel backup brussels#show mpls traffic-eng tunnels brief Signalling Summary: LSP Tunnels Process: running RSVP Process: running Forwarding: enabled auto-tunnel: backup Enabled (2 ), id-range: onehop Disabled (0 ), id-range: mesh Disabled (0 ), id-range: Periodic reoptimization: every 3600 seconds, next in 3371 seconds Periodic FRR Promotion: Not Running Periodic auto-tunnel: backup notinuse scan: every 3600 seconds, next in 2940 seconds Periodic auto-bw collection: disabled TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT brussels_t PO10/3 up/up brussels_t unknown admin-down brussels_t unknown admin-down brussels_t PO10/1 up/up brussels_t PO10/1 up/up Displayed 5 (of 5) heads, 0 (of 0) midpoints, 0 (of 0) tails continues

9 709 Chapter 8: MPLS Traffic Engineering Example 8-3 Example of Backup Auto Tunnels (Continued) brussels#show mpls traffic-eng tunnels tunnel Name: brussels_t65436 (Tunnel65436) Destination: Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type explicit dynamic_tunnel65436 (Basis for Setup, path weight 11) Config Parameters: Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: disabled LockDown: disabled Loadshare: 0 bw-based auto-bw: disabled Active Path Option Parameters: State: explicit path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : - OutLabel : POS10/1, 25 RSVP Signalling Info: Src , Dst , Tun_Id 65436, Tun_Instance 1 RSVP Path Info: My Address: Explicit Route: Record Route: NONE Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Shortest Unconstrained Path Info: Path Weight: 1 (TE) Explicit Route: History: Tunnel: Time since created: 11 minutes, 24 seconds Time since path change: 11 minutes, 25 seconds Current LSP: Uptime: 11 minutes, 25 seconds By default, high tunnel numbers (65,436 to 65,535) are chosen for the backup auto tunnels. If you wish, you can change the range for the backup auto tunnels with the command mpls traffic-eng auto-tunnel backup tunnel-num min num max num. For every link that at least one TE tunnel crosses with fast rerouting enabled, an NHOP backup auto tunnel is created to protect the link. For every node that at least one TE tunnel crosses with fast rerouting enabled, an NNHOP backup auto tunnel is created to protect the node. You can specify that you want only NHOP backup auto tunnels to be created with the command mpls

10 Auto Tunnels 710 traffic-eng auto-tunnel backup nhop-only. That way, backup auto tunnels do not provide FRR node protection. Backup auto tunnels do not have autoroute announce enabled. This ensures that they are used only for link or node protection and do not attract traffic. Primary Auto Tunnels Primary auto tunnels are one-hop-only tunnels that the LSR creates automatically for each link where MPLS TE is enabled. These tunnels have autoroute announce enabled, so they attract IP traffic. Because these are one-hop tunnels, the outgoing label is always implicit NULL. No label is imposed upon the traffic that is forwarded into the tunnel. The global command to enable primary auto tunnels is mpls traffic-eng auto-tunnel primary onehop. Because these tunnels are one-hop only, they map exactly to the link. As such, the routing is no different from when these primary tunnels are not there. Primary auto tunnels request FRR protection. Therefore, when primary auto tunnels are combined with backup auto tunnels, the primary auto tunnels are protected by NHOP backup auto tunnels, providing FRR link protection. Example 8-4 shows primary auto tunnels. Because two outgoing links (pos 10/1 and pos 10/3) are enabled for MPLS TE, there are two primary auto tunnels. Because backup auto tunnels is also enabled, there is one backup auto tunnel for each primary auto tunnel. Example 8-4 Primary Auto Tunnels mpls traffic-eng auto-tunnel backup mpls traffic-eng auto-tunnel primary onehop brussels#show mpls traffic-eng tunnels brief Signalling Summary: LSP Tunnels Process: running RSVP Process: running Forwarding: enabled auto-tunnel: backup Enabled (3 ), id-range: onehop Enabled (2 ), id-range: mesh Disabled (0 ), id-range: Periodic reoptimization: every 3600 seconds, next in 1086 seconds Periodic FRR Promotion: Not Running Periodic auto-tunnel: primary establish scan: every 10 seconds, next in 9 seconds primary rm active scan: disabled backup notinuse scan: every 3600 seconds, next in 1678 seconds Periodic auto-bw collection: disabled TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT brussels_t PO10/1 up/up brussels_t unknown admin-down continues

11 711 Chapter 8: MPLS Traffic Engineering Example 8-4 Primary Auto Tunnels (Continued) brussels_t unknown admin-down brussels_t PO10/3 up/up brussels_t PO10/1 up/up brussels_t PO10/3 up/up brussels_t PO10/1 up/up brussels_t PO10/3 up/up Displayed 8 (of 8) heads, 0 (of 0) midpoints, 0 (of 0) tails Example 8-5 shows that the primary auto tunnel has autoroute announce on and that the backup auto tunnel protects it. Notice that the outgoing label is implicit NULL for the primary auto tunnel. Example 8-5 Protection of Primary Auto Tunnel brussels#show mpls traffic-eng tunnels tunnel Name: brussels_t65336 (Tunnel65336) Destination: Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type explicit dynamic_tunnel65336 (Basis for Setup, path weight 1) Config Parameters: Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based auto-bw: disabled Active Path Option Parameters: State: explicit path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : - OutLabel : POS10/3, implicit-null RSVP Signalling Info: Src , Dst , Tun_Id 65336, Tun_Instance 1 RSVP Path Info: My Address: Explicit Route: Record Route: NONE Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info: Record Route: (0) Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Shortest Unconstrained Path Info: Path Weight: 1 (TE) Explicit Route: History: Tunnel:

12 Auto Tunnel Mesh Groups 712 Example 8-5 Protection of Primary Auto Tunnel (Continued) Time since created: 1 minutes, 17 seconds Time since path change: 1 minutes, 17 seconds Current LSP: Uptime: 1 minutes, 17 seconds brussels#show mpls traffic-eng tunnels tunnel protection brussels_t65336 LSP Head, Tunnel65336, Admin: up, Oper: up Src , Dest , Instance 1 Fast Reroute Protection: Requested Outbound: FRR Ready Backup Tu65437 to LSP nhop Tu65437: out i/f: PO10/1, label: 25 LSP signalling info: Original: out i/f: PO10/3, label: implicit-null, nhop: With FRR: out i/f: Tu65437, label: implicit-null LSP bw: 0 kbps, Backup level: any-unlim, type: any pool By default, high numbers (65,336 to 65,435) are chosen for the primary auto tunnels. If you want to, you can change the range for the primary auto tunnels with the command mpls traffic-eng auto-tunnel primary tunnel-num min num max num. Because primary auto tunnels are one-hop tunnels, only NHOP backup tunnels, not NNHOP backup tunnels, can protect them. Auto Tunnel Mesh Groups The feature Auto Tunnel Mesh Groups makes it possible to build a mesh of TE tunnels between LSRs, with minimal configuration. LSRs are configured to be part of a mesh group by means of an access list. The TE tunnels are not created individually, but an auto-template interface is created. All TE tunnels that are part of the mesh group inherent their features from this template. (This means they are cloned from the template interface.) The great benefit of this feature is that when a new LSR is configured to be part of this mesh, you do not need to configure TE tunnels to all the other LSRs, which are part of the mesh. The TE tunnels are created automatically as they are cloned from the template interface. To make an LSR member of a mesh group, you must perform the following three steps: Enable auto tunnel mesh groups. Create an access list. Create the auto-template.

13 713 Chapter 8: MPLS Traffic Engineering You must globally enable mesh groups with the command mpls traffic-eng auto-tunnel mesh. The access list is a standard access list, indicating MPLS TE router IDs (tunnel destination IP addresses) of LSRs that are part of the mesh group. The router must try to establish auto tunnels to the LSRs for which their MPLS TE router ID matches the access list. The auto-template interface is an interface that you must configure on the router and assign the TE features of bandwidth, affinity, and so on to. After the TE tunnels are created, their characteristics are cloned from this interface. Example 8-6 shows a mesh group. The brussels, paris, and london routers are part of an auto tunnel mesh group. Each router is the head end of two TE tunnels, one toward each other router in the mesh group. Example 8-6 Auto Tunnel Mesh Group mpls traffic-eng auto-tunnel mesh interface Auto-Template1 ip unnumbered Loopback0 tunnel destination access-list 99 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng path-option 1 dynamic access-list 99 permit paris#show mpls traffic-eng tunnels brief Signalling Summary: LSP Tunnels Process: running RSVP Process: running Forwarding: enabled auto-tunnel: backup Disabled (0 ), id-range: onehop Disabled (0 ), id-range: mesh Enabled (2 ), id-range: Periodic reoptimization: every 3600 seconds, next in 3291 seconds Periodic FRR Promotion: Not Running Periodic auto-bw collection: every 300 seconds, next in 291 seconds TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT paris_t Et1/1 up/up paris_t PO4/0 up/up london_t Et1/1 - up/up london_t Et1/1 PO4/0 up/up brussels_t PO4/0 Et1/1 up/up brussels_t PO4/0 - up/up Displayed 2 (of 2) heads, 2 (of 2) midpoints, 2 (of 2) tails paris#show mpls traffic-eng auto-tunnel mesh

14 Automatic Automatic Bandwidth Bandwidth Adjustment for TE Tunnels 714 Example 8-6 Auto Tunnel Mesh Group (Continued) Auto-Template1: Using access-list 99 to clone the following tunnel interfaces: Destination Interface Tunnel Tunnel64337 Mesh tunnel interface numbers: min max By default, high numbers (64,336 to 65,335) are chosen for the mesh group auto tunnels. If you wish, you can change the range for the mesh group auto tunnels with the command mpls trafficeng auto-tunnel mesh tunnel-num min num max num. Automatic Bandwidth Adjustment for TE Tunnels The required bandwidth for a TE tunnel is 0, or a value you configure on the tunnel head end router. You can also let Cisco IOS decide dynamically what the required bandwidth of the tunnel is. This is done by letting the head end router sample the average output load of the TE tunnel during a period of time. The command to configure this on the TE tunnel interface is as follows: Router(config)#mpls traffic-eng auto-bw [collect-bw] [frequency sec] [max-bw n][minbw n] The default interval is 300 seconds, or 5 minutes. You can change it by configuring a different frequency. To limit the range of bandwidth, you can specify a minimum and maximum amount of bandwidth in kilobits per seconds to apply to the tunnel. The collect-bw keyword enables you to specify that the average output rate should be collected without having Cisco IOS actually changing the bandwidth of the TE tunnel. You can run the TE tunnels like this for days or weeks before letting the head end routers change the bandwidth automatically. Example 8-7 shows a TE tunnel where bandwidth adjustment is enabled. Note that the configuration on the TE tunnel interface (the mpls traffic-eng bandwidth command) changes to reflect the actual bandwidth reserved. This change is in the running configuration, but not in startup configuration. Example 8-7 Configuration of Automatic Bandwidth Adjustment interface Tunnel1 ip unnumbered Loopback0 tunnel destination tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce

15 715 Chapter 8: MPLS Traffic Engineering Example 8-7 Configuration of Automatic Bandwidth Adjustment tunnel mpls traffic-eng bandwidth 435 tunnel mpls traffic-eng path-option 1 explicit name paris-rome tunnel mpls traffic-eng fast-reroute tunnel mpls traffic-eng auto-bw frequency 30 paris#show mpls traffic-eng tunnels tunnel 1 Name: paris_t1 (Tunnel1) Destination: Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type explicit paris-rome (Basis for Setup, path weight 2) Config Parameters: Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 435 bw-based auto-bw: (30/144) 0 Bandwidth Requested: 435 Active Path Option Parameters: State: explicit path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled brussels#show mpls traffic-eng link-management admission-control pos 10/3 System Information:: Tunnels Count: 3 Tunnels Selected: 1 TUNNEL ID UP IF DOWN IF PRIORITY STATE BW (kbps) _805 PO10/2 PO10/3 7/7 Resv Admitted 435 RG NOTE The traffic is not policed if the rate of the traffic that is going into the tunnel is higher than the signaled bandwidth of the tunnel. This is true for an automatic bandwidth adjusted tunnel and for any other TE tunnel. DiffServ-Aware TE The TE tunnels that have been discussed so far are also called global pool TE tunnels. Sub-pool tunnels are another kind. Sub-pool tunnels are differentiated from global pool TE tunnels in the fact that the traffic they carry requires a stricter quality of service. This traffic is such that, for example, it needs a strict delay or jitter along the total path or requires that no more than 20 percent of the link bandwidth carries this traffic to ensure the correct level of quality of service (QoS) on

16 DiffServ-Aware TE 716 the links. This 20 percent is then the sub-pool of the global pool of bandwidth that is reservable on a link. This traffic might be voice traffic or leased line traffic with specific QoS requirements. You might have TE-enabled links that do not meet this QoS requirement and are therefore not entitled to carry sub-pool tunnels even though they can still carry global pool tunnels. Because the sub-pool tunnels can be routed in a different way from the global pool tunnels, they can guarantee a particular QoS level. However, because the traffic needing this QoS requirement is routed into a special sub-pool tunnel, it can inherit a particular DiffServ value. The Experimental (EXP) bits in the labels of the traffic that is going into the sub-pool versus the global pool tunnels can be set differently on the head end routers. You can use policy-based routing or Modular QoS Command Line Interface (MQC) to perform this task. Then you can use the EXP bits value on the routers to provide the proper QoS treatment on every link. For example, you can ensure that the sub-pool TE traffic uses one particular DiffServ queue that no other traffic does. To recap: The proper usage of sub-pool tunnels entails the following: The traffic that is requiring the guaranteed QoS treatment is steered into the sub-pool tunnels at the head end router. The EXP bits are set to a particular value for the traffic using the sub-pool tunnels. The sub-pool bandwidth values are set to a relative small value of the total bandwidth value on the links. By default, the interfaces that are enabled for MPLS TE and used for global pool tunnels have reservable bandwidth advertised only for the global pool tunnels. You must use the ip rsvp bandwidth command with the sub-pool keyword on the TE-enabled links to advertise bandwidth for sub-pool tunnels: ip rsvp bandwidth kbps [sub-pool kpbs] To configure the TE tunnel to be a sub-pool tunnel instead of a global pool tunnel, you must configure the following command on the tunnel interface and specify the required bandwidth in kbps: tunnel mpls traffic-eng bandwidth sub-pool bandwidth For a global pool tunnel, you can specify 0 as the required bandwidth. For a sub-pool tunnel, the required bandwidth must be something other than 0.

17 717 Chapter 8: MPLS Traffic Engineering Example 8-8 shows how to configure a bandwidth of kpbs for sub-pool tunnels on an interface. The IGP then advertises this available sub-pool bandwidth. Example 8-8 Configuring Bandwidth for Sub-Pool Tunnels paris(config)#int pos 4/0 paris(config-if)#ip rsvp bandwidth sub-pool paris#show mpls traffic-eng link-management interfaces pos 4/0 System Information:: Links Count: 2 Link ID:: PO4/0 ( ) Link Status: SRLGs: None Physical Bandwidth: kbits/sec Max Res Global BW: kbits/sec (reserved: 0% in, 0% out) Max Res Sub BW: kbits/sec (reserved: 0% in, 0% out) MPLS TE Link State: MPLS TE on, RSVP on, admin-up, flooded Inbound Admission: allow-all Outbound Admission: allow-if-room Admin. Weight: 1 (IGP) IGP Neighbor Count: 1 IGP Neighbor: ID , IP (Up) Flooding Status for each configured area [1]: IGP Area[1]: ospf 1 area 0: flooded Example 8-9 shows the tunnel configuration for a sub-pool tunnel. Example 8-9 Configuring a Sub-Pool Tunnel paris#show running-config interface tunnel 1 interface Tunnel1 ip unnumbered Loopback0 tunnel destination tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 7 7 tunnel mpls traffic-eng bandwidth sub-pool 1000 tunnel mpls traffic-eng path-option 1 explicit name paris-rome tunnel mpls traffic-eng fast-reroute paris#show mpls traffic-eng tunnels tunnel 1 Name: paris_t1 (Tunnel1) Destination: Status: Admin: up Oper: up Path: valid Signalling: connected

18 Interarea TE 718 Example 8-9 Configuring a Sub-Pool Tunnel (Continued) path option 1, type explicit paris-rome (Basis for Setup, path weight 2) Config Parameters: Bandwidth: 1000 kbps (Sub) Priority: 7 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 1000 bw-based auto-bw: disabled Active Path Option Parameters: State: explicit path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled NOTE For more information on QoS with MPLS, refer to Chapter 12, MPLS and Quality of Service. Interarea TE Up until now, all TE tunnels discussed here have been TE tunnels in one area of a link state routing protocol. The reason is that routers have only the complete picture of the area they are in, because a link state routing protocol has a link state database per area. A router in an area does not have the complete view of the network outside of that area. So far, the path option for a TE tunnel has been either a dynamic one or a complete explicit path, where all the hops of the TE tunnel had to be specified. Also available was a semi-dynamic TE tunnel path option whereby you could use an explicit path and exclude certain IP addresses. One more possibility exists. This fourth possibility, loose next hops, will be used for interarea TE. Loose next hops are specified as loose next-addresses in an explicit path option. An explicit path option with loose next hops is a list of IP addresses of LSRs that the TE tunnel must cross. However, the list does not need to be the complete list of all the LSRs that the TE tunnel will cross. The list of LSRs is only the LSRs that the TE tunnel must cross. The missing LSRs in between can be any LSRs that the head end router finds to be on a feasible path toward the loose next hop in the list. The solution to build a TE tunnel that can span multiple areas is to specify the area border routers (ABRs) as loose next hops in the explicit path. The head end router of the TE tunnel must dynamically build a path to the first ABR that is specified in the explicit path. This path becomes the explicit route object (ERO) carried in the RSVP Path messages. That ABR must expand the loose route from itself to the next ABR that is specified in the explicit path, and so on. Therefore, the ABR turns a loose route into an explicit one. When areas have multiple ABRs between them, you can specify different path options with different loose next hops so that you can have backup paths in case one ABR fails. However, you have one big disadvantage of using an interarea TE tunnel. Because the head end router does not have the TE database of the other areas, it cannot

19 719 Chapter 8: MPLS Traffic Engineering deduce which prefixes are behind the tail end router, if the tail end router is in another area than the head end router. Therefore, autoroute announce is not supported on interarea TE tunnels. Other features that are not supported on interarea tunnels are setting of the affinity bits on the tunnel, forwarding adjacency, and reoptimization. These limits are the result of the inability of the head end router to look inside other areas. The TE features of the links are advertised only inside an area. To configure an interarea TE tunnel, you must specify the IP addresses of the ABRs in the explicit path as a loose next hop with the following command: Router(cfg-ip-expl-path)#next-address loose A.B.C.D. Figure 8-2 shows an example of an interarea TE tunnel in an OSPF domain with three areas. Figure 8-2 Interarea TE Tunnel Area 1 Loopback Loopback Loopback ABR london paris brussels Loopback TE Tunnel frankfurt Loopback Loopback Loopback sydney rome Area 2 ABR berlin Area 0

20 Interarea TE 720 The TE tunnel head end router is router london in area 1, and the tail end router is router sydney in area 2. The two area border routers are brussels and berlin. These two ABRs are configured as loose next hops in the explicit path for the interarea TE tunnel. It is the task of router london to calculate a path to the ABR brussels, and it is the task of router brussels to calculate a path in OSPF area 0 to the ABR berlin. Finally, the router berlin must calculate a path in area 2 toward the tail end router sydney. Example 8-10 shows the configuration of this interarea TE tunnel on router london. Example 8-10 Interarea Tunnel interface Tunnel1 ip unnumbered Loopback0 tunnel destination tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 10 explicit name inter-area ip explicit-path name inter-area enable next-address loose next-address loose london#show mpls traffic-eng tunnel tunnel 1 Name: london_t1 (Tunnel1) Destination: Status: Admin: up Oper: up Path: valid Signalling: connected path option 10, type explicit inter-area (Basis for Setup, path weight 21) Config Parameters: Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: disabled LockDown: disabled Loadshare: 0 bw-based auto-bw: disabled Active Path Option Parameters: State: explicit path option 10 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : - OutLabel : Ethernet0/0/0, 35 RSVP Signalling Info: Src , Dst , Tun_Id 1, Tun_Instance 18 RSVP Path Info: My Address: Explicit Route: * Record Route: Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info: Record Route:

21 721 Chapter 8: MPLS Traffic Engineering Example 8-10 Interarea Tunnel (Continued) Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Shortest Unconstrained Path Info: Path Weight: UNKNOWN Explicit Route: UNKNOWN History: Tunnel: Time since created: 15 minutes, 10 seconds Time since path change: 1 minutes, 28 seconds Current LSP: Uptime: 1 minutes, 29 seconds Selection: reoptimization Prior LSP: ID: path option 10 [16] Removal Trigger: label reservation removed Notice that the Shortest Unconstrained Path Info cannot show anything because the TE database is missing a piece of the topology for the complete path of this tunnel. The ERO is the path up to the first ABR. The next loose hop is indicated by the star next to the IP address. You can see the complete path that the TE tunnel takes by looking at the Record Route section in the output. You can also use a verbatim TE tunnel (see the next section) if the TE tunnel spans multiple IGP areas. With verbatim, the TE topology database verification is completely omitted at the head end router. RSVP is used to signal the LSP and the path must then be completely specified as an explicit path. Verbatim Verbatim is an option for an explicit TE tunnel LSP whereby the tunnel head end router bypasses the TE topology database verification before signaling the TE LSP via RSVP. This is useful when some TE nodes do not support the TE IGP extensions, but they do support RSVP with the TE extensions. Because the TE topology database is not verified, the verbatim option cannot be used for dynamic TE tunnels, but only for TE tunnels that have the explicitly routed path option. Example 8-11 shows an example of a verbatim TE tunnel. Example 8-11 Verbatim Tunnel interface Tunnel1 ip unnumbered Loopback0 tunnel destination tunnel mode mpls traffic-eng

22 MPLS TE LSP Attributes 722 MPLS TE LPS ATTRIBUTES Example 8-11 Verbatim Tunnel (Continued) tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng path-option 1 explicit name paris-rome verbatim tunnel mpls traffic-eng fast-reroute paris#show mpls traffic-eng tunnels tunnel 1 Name: paris_t1 (Tunnel1) Destination: Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type explicit (verbatim) paris-rome (Basis for Setup, path weight 0) Config Parameters: Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based auto-bw: disabled Active Path Option Parameters: State: explicit path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: enabled InLabel : - OutLabel : POS4/0, 17 RSVP Signalling Info: Src , Dst , Tun_Id 1, Tun_Instance 5799 RSVP Path Info: My Address: Explicit Route: Record Route: NONE Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info: Record Route: (17) (0) Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Shortest Unconstrained Path Info: Path Weight: UNKNOWN Explicit Route: UNKNOWN MPLS TE LSP Attributes You can assign LSP attributes to a TE tunnel per path option. Therefore, depending on the path that the TE tunnel takes, the attributes of the TE LSP (hence, the TE tunnel) can change. The attributes that the path option assigns take precedence over any configured attributes on the tunnel interface.

23 723 Chapter 8: MPLS Traffic Engineering Example 8-12 demonstrates the usage of LSP attributes. Two path options are configured for tunnel 1, each with a set of attributes. In addition, you can see which attributes you can use. Example 8-12 LSP Attributes interface Tunnel1 ip unnumbered Loopback0 tunnel destination tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng path-option 1 dynamic attributes attributes-1 tunnel mpls traffic-eng path-option 2 explicit name paris-rome attributes attributes-2 mpls traffic-eng lsp attributes attributes-1 auto-bw protection fast-reroute lockdown mpls traffic-eng lsp attributes attributes-2 bandwidth record-route paris(config)#mpls traffic-eng lsp attributes attributes-1 paris(config-lsp-attr)#? Attribute List configuration commands: affinity Specify attribute flags for links comprising LSP auto-bw Specify automatic bandwidth configuration bandwidth Specify LSP bandwidth exit Exit from attribute list configuration mode list Re-list all of the attribute list entries lockdown Lockdown the LSP--disable reoptimization no Disable a specific attribute priority Specify LSP priority protection Enable failure protection record-route Record the route used by the LSP Path Protection The protection schemes covered so far (link and node protection) are local. Recently, a global protection scheme was added to MPLS TE: Path Protection. In MPLS TE Path Protection, one TE LSP backs up another. This backup or protection TE LSP is established in advance by the same head end LSR to back up the primary TE LSP. As soon as the head end knows that there is failure along the path of the primary TE LSP, it switches the traffic onto the backup TE LSP. The head end is aware of a failure along the path when it receives a PathErr from an LSR along the primary TE LSP. The further away the failure from the head end LSR, the longer it takes for the PathErr to reach the head end LSR. This means that the switchover from primary to backup TE LSP on the head end LSR is a bit slower than the local switchover that happens with link or node protection.

24 Path Protection 724 It is, however, still faster than rerouting the primary TE LSP onto another path. That is because this involves resignaling the LSP, whereas with path protection, the backup TE LSP is already established at the time of the failure. Each path option of a TE tunnel can be backed up by a protection LSP. The configuration needed is a path option with the protect keyword. Look at Figure 8-3 to see an example of path protection. Figure 8-3 Path Protection Example TE Tunnel 1 Backup LSP POS 10/ frankfurt Loopback / Loopback /32 POS 10/3 brussels berlin rome sydney TE Tunnel 1 Primary LSP The tunnel 1 has one primary and one backup LSP. Example 8-13 shows the tunnel configuration for Figure 8-3. Example 8-13 Path Protection interface Tunnel1 ip unnumbered Loopback0 tunnel destination tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng path-option 10 explicit name to-sydney tunnel mpls traffic-eng path-option protect 10 explicit name to-sydney-backup ip explicit-path name to-sydney enable next-address next-address next-address ip explicit-path name to-sydney-backup enable continues

25 725 Chapter 8: MPLS Traffic Engineering Example 8-13 Path Protection (Continued) next-address next-address next-address brussels#show mpls traffic-eng tunnels tunnel 1 Name: brussels_t1 (Tunnel1) Destination: Status: Admin: up Oper: up Path: valid Signalling: connected path option 10, type explicit to-sydney (Basis for Setup, path weight 3) Path Protection: 1 Common Link(s), 1 Common Node(s) path protect option 10, type explicit to-sydney-backup (Basis for Protect, path weight 3) Config Parameters: Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based auto-bw: disabled Active Path Option Parameters: State: explicit path option 10 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : - OutLabel : Serial3/0, 32 RSVP Signalling Info: Src , Dst , Tun_Id 1, Tun_Instance 36 RSVP Path Info: My Address: Explicit Route: Record Route: NONE Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Shortest Unconstrained Path Info: Path Weight: 3 (TE) Explicit Route: brussels#show mpls traffic-eng tunnels tunnel 1 protection brussels_t1 LSP Head, Tunnel1, Admin: up, Oper: up Src , Dest , Instance 36 Fast Reroute Protection: None Path Protection: 1 Common Link(s), 1 Common Node(s) Primary lsp path:

26 Troubleshooting MPLS TE 726 Example 8-13 Path Protection (Continued) Protect lsp path: Path Protect Parameters: Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) InLabel : - OutLabel : Serial2/0, 32 RSVP Signalling Info: Src , Dst , Tun_Id 1, Tun_Instance 42 RSVP Path Info: My Address: Explicit Route: Record Route: NONE Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Cisco IOS does not make sure that the primary TE LSP and backup TE LSP are diverse when using dynamaic path options. Both LSPs might share many links or nodes, which defeats the purpose of path protection. Therefore, you must make sure that the paths of the primary TE LSP and backup TE LSP are diverse, or as diverse as possible. You do this by configuring an explicit path option for both the primary TE LSP and the backup TE LSP. The command show mpls traffic-eng tunnels tunnel-interface [brief] protection shows the number of common links and nodes between the primary and backup TE LSPs. Troubleshooting MPLS TE The most frequent problem with MPLS TE is a tunnel that is not set up. The tunnel interface does not come up if the TE tunnel LSP is not set up. That is easy enough to notice. But why does the TE tunnel not come up? Much can already be seen by looking at the tunnel with the command show mpls traffic-eng tunnel tunnel tunnel-number. Other common troubleshooting techniques involve looking at the TE database and enabling debug ip rsvp signaling and debug mpls trafficeng path spf.

27 727 Chapter 8: MPLS Traffic Engineering Example 8-14 shows a tunnel that is down. The TE tunnel is the tunnel 1 on the router paris, with the router rome being the tail end of the TE LSP. The path option of the tunnel only specifies to exclude the router berlin from the path CSPF calculation. Example 8-14 Troubleshooting MPLS TE Tunnel Path paris# interface Tunnel1 ip unnumbered Loopback0 tunnel destination tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 7 7 tunnel mpls traffic-eng bandwidth tunnel mpls traffic-eng path-option 10 explicit name not-router-berlin ip explicit-path name not-router-berlin enable exclude-address paris#show mpls traffic-eng tunnels tunnel 1 Name: paris_t1 (Tunnel1) Destination: Status: Admin: up Oper: down Path: not valid Signalling: Down path option 10, type explicit not-router-berlin Config Parameters: Bandwidth: kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: bw-based auto-bw: disabled Shortest Unconstrained Path Info: Path Weight: 4 (TE) Explicit Route: History: Tunnel: Time since created: 1 days, 51 minutes Time since path change: 51 seconds Prior LSP: ID: path option 10 [676] Removal Trigger: path error Last Error: PCALC:: No path to destination,

28 Troubleshooting MPLS TE 728 The debug in Example 8-15 tells you that the reservable bandwidth on LSR brussels ( ) is too small. Example 8-15 Troubleshooting MPLS TE Tunnel Path paris#debug mpls traffic-eng path spf MPLS traffic-eng path calculation spf events debugging is on paris# *Apr 5 02:47:27.749: TE-PCALC_SPF: rrr_pcalc_node_exclude: excluding *Apr 5 02:47:27.749: TE-PCALC_SPF: aw 0 min_bw , prev_node(null) *Apr 5 02:47:27.749: TE-PCALC_SPF: *Apr 5 02:47:27.749: TE-PCALC_SPF: REJECT(max_bw too small) node , ip_address bw *Apr 5 02:47:27.749: TE-PCALC_SPF: aw 2 min_bw , prev_node( ) *Apr 5 02:47:27.749: TE-PCALC_SPF: rrr_pcalc_dump_tentitive list: *Apr 5 02:47:27.749: node(62)=(aw=2, min_bw=155000, hops=1) *Apr 5 02:47:27.753: TE-PCALC_SPF: *Apr 5 02:47:27.753: TE-PCALC_SPF: REJECT(bw available too small) After you correct that problem by specifying the correct bandwidth with the ip rsvp bandwidth command on interface pos 10/1 on router brussels, you can see the next problem in Example The attribute flags on the link with IP address (router Frankfurt) do not match with the affinity bits and mask that are configured on the TE tunnel. Example 8-16 Troubleshooting MPLS TE Tunnel Path brussels(config-if)# brussels(config-if)#int pos 10/1 brussels(config-if)#ip rsvp bandwidth paris# *Apr 5 02:48:21.893: TE-PCALC_SPF: rrr_pcalc_node_exclude: excluding *Apr 5 02:48:21.893: TE-PCALC_SPF: aw 0 min_bw , prev_node(null) *Apr 5 02:48:21.893: TE-PCALC_SPF: *Apr 5 02:48:21.893: TE-PCALC_SPF: REJECT(max_bw too small) node , ip_address bw *Apr 5 02:48:21.893: TE-PCALC_SPF: aw 2 min_bw , prev_node( ) *Apr 5 02:48:21.893: TE-PCALC_SPF: rrr_pcalc_dump_tentitive list: *Apr 5 02:48:21.893: node(62)=(aw=2, min_bw=155000, hops=1) *Apr 5 02:48:21.893: TE-PCALC_SPF: *Apr 5 02:48:21.893: TE-PCALC_SPF: aw 3 min_bw , prev_node( )