Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 30 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
30
Dung lượng
870,28 KB
Nội dung
1974_chp8ONLba.fm Page 701 Tuesday, November 14, 2006 9:58 AM 1974_chp8ONLba.fm Page 702 Tuesday, November 14, 2006 9:58 AM CHAPTER SUPPLEMENT MPLS Traffic Engineering This online supplement of Chapter deals with a few advanced traffic engineering (TE) topics Ensure that you have read Chapter 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 1974_chp8ONLba.fm Page 703 Tuesday, November 14, 2006 9:58 AM 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 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 switched network, it is possible for the failure in Layer 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 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 10.200.193.1 RSVP 10.200.194.2 RSVP 1974_chp8ONLba.fm Page 704 Tuesday, November 14, 2006 9:58 AM IP RSVP Debugging 704 show ip rsvp Commands (Continued) Example 8-1 10.200.210.1 RSVP 10.200.211.2 RSVP 10.200.212.2 RSVP 10.200.213.2 RSVP 10.200.254.5 Unknown brussels#show ip rsvp interface interface rsvp allocated i/f max flow max sub max PO10/0 ena 155M 155M 10M PO10/1 ena 155M 155M 10M PO10/2 ena 155M 155M 10M PO10/3 ena 100M 155M 155M 10M PO14/0 ena 155M 155M Tu1000 ena 0 0 Tu2000 ena 0 0 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): bits/sec Signalling: DSCP value used in RSVP msgs: 0x3F Number of refresh intervals to enforce blockade state: Authentication: disabled brussels#show ip rsvp reservation To From Pro DPort Sport Next Hop I/F Fi Serv BPS 10.200.254.5 10.200.254.2 5846 10.200.211.2 PO10/3 SE LOAD 100M 10.200.254.5 10.200.254.3 1000 420 10.200.212.2 PO10/1 SE LOAD brussels#show ip rsvp reservation detail Reservation: Tun Dest: 10.200.254.5 Tun Sender: 10.200.254.2 Tun ID: Ext Tun ID: 10.200.254.2 LSP ID: 5846 Next Hop: 10.200.211.2 on POS10/3 Label: (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: bytes, Max Pkt Size: bytes RRO: 10.200.211.2/32, Flags:0x0 (No Local Protection) Label subobject: Flags 0x1, C-Type 1, Label continues 1974_chp8ONLba.fm Page 705 Tuesday, November 14, 2006 9:58 AM 705 Chapter 8: MPLS Traffic Engineering Example 8-1 show ip rsvp Commands (Continued) Resv ID handle: 1A000413 Status: Policy: Accepted Policy source(s): MPLS/TE brussels#show ip rsvp sender detail PATH: Tun Dest: 10.200.254.5 Tun ID: Tun Sender: 10.200.254.2 Ext Tun ID: 10.200.254.2 LSP ID: 5846 Path refreshes: arriving: from PHOP 10.200.210.1 on PO10/2 every 30000 msecs sent: to NHOP 10.200.211.2 on POS10/3 Session Attr: Setup Prio: 7, Holding Prio: Flags: (0x7) Local Prot desired, Label Recording, SE Style Session Name: paris_t1 ERO: (incoming) 10.200.210.2 (Strict IPv4 Prefix, bytes, /32) 10.200.211.2 (Strict IPv4 Prefix, bytes, /32) 10.200.254.5 (Strict IPv4 Prefix, bytes, /32) ERO: (outgoing) 10.200.211.2 (Strict IPv4 Prefix, bytes, /32) 10.200.254.5 (Strict IPv4 Prefix, bytes, /32) RRO: 10.200.210.1/32, Flags:0x0 (No Local Protection) Traffic params - Rate: 100M bits/sec, Max burst: 1K bytes Min Policed Unit: bytes, Max Pkt Size 4294967295 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: 10.200.212.1 LSP ID: 5846 Bkup FilerSpec: Tun Sender: 10.200.212.1, LSP ID: 5846 Path ID handle: 45000406 Incoming policy: Accepted Policy source(s): MPLS/TE Status: Output on POS10/3 Policy status: Forwarding Handle: F5000415 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 1974_chp8ONLba.fm Page 706 Tuesday, November 14, 2006 9:58 AM 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 10.200.254.7 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 7 tunnel mpls traffic-eng bandwidth 550000 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 150000 tunnel mpls traffic-eng path-option 40 dynamic bandwidth 250000 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, 1974_chp8ONLba.fm Page 707 Tuesday, November 14, 2006 9:58 AM 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 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 not have to configure them, and they 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: ■ bandwidth ■ Setup and holding priority of ■ 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 1974_chp8ONLba.fm Page 708 Tuesday, November 14, 2006 9:58 AM 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 10.200.212.2 Loopback 10.200.254.5/32 frankfurt 10.20 0.214 POS 10/1 10.200.210.2 paris POS 10/3 10.200.211.2 brussels Example 8-3 Loopback 10.200.254.6/32 10.200.215.2 berlin 10.200.202.2 rome sydney 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:65436-65535 onehop Disabled (0 ), id-range:65336-65435 mesh Disabled (0 ), id-range:64336-65335 Periodic reoptimization: every 3600 seconds, next in 3371 seconds Periodic FRR Promotion: Not Running Periodic auto-tunnel: backup notinuse scan: Periodic auto-bw collection: every 3600 seconds, next in 2940 seconds disabled TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT brussels_t1 10.200.254.6 - PO10/3 up/up brussels_t1000 10.200.254.5 - unknown admin-down brussels_t2000 10.200.254.6 - unknown admin-down brussels_t65436 10.200.254.5 - PO10/1 up/up brussels_t65437 10.200.254.6 - PO10/1 up/up Displayed (of 5) heads, (of 0) midpoints, (of 0) tails continues 1974_chp8ONLba.fm Page 709 Tuesday, November 14, 2006 9:58 AM 709 Chapter 8: MPLS Traffic Engineering Example 8-3 Example of Backup Auto Tunnels (Continued) show mpls traffic-eng tunn els tunnel 65436 brussels#s Name: brussels_t65436 (Tunnel65436) Destination: 10.200.254.5 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: kbps (Global) Priority: 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: disabled LockDown: disabled Loadshare: bw-based auto-bw: disabled Active Path Option Parameters: State: explicit path option is active BandwidthOverride: disabled InLabel : LockDown: disabled Verbatim: disabled - OutLabel : POS10/1, 25 RSVP Signalling Info: Src 10.200.254.3, Dst 10.200.254.5, Tun_Id 65436, Tun_Instance RSVP Path Info: My Address: 10.200.254.3 Explicit Route: 10.200.212.2 10.200.213.2 10.200.254.5 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: (TE) Explicit Route: 10.200.211.2 10.200.254.5 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 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 1974_chp8ONLba.fm Page 710 Tuesday, November 14, 2006 9:58 AM Auto Tunnels 710 traffic-eng auto-tunnel backup nhop-only That way, backup auto tunnels not provide FRR node protection Backup auto tunnels not have autoroute announce enabled This ensures that they are used only for link or node protection and 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-tunn el backup mpls traffic-eng auto-tunnel primary oneh op show mpls traffic-eng tunn els brief brussels#s Signalling Summary: LSP Tunnels Process: running RSVP Process: running Forwarding: enabled auto-tunnel: backup Enabled (3 ), id-range:65436-65535 onehop Enabled (2 ), id-range:65336-65435 mesh Disabled (0 ), id-range:64336-65335 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 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_t1 10.200.254.6 - PO10/1 up/up brussels_t1000 10.200.254.5 - unknown admin-down continues 1974_chp8ONLba.fm Page 716 Tuesday, November 14, 2006 9:58 AM 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 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 [s 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 as the required bandwidth For a sub-pool tunnel, the required bandwidth must be something other than 1974_chp8ONLba.fm Page 717 Tuesday, November 14, 2006 9:58 AM 717 Chapter 8: MPLS Traffic Engineering Example 8-8 shows how to configure a bandwidth of 10000 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 int pos 4/0 paris(config)#i ip rsvp bandwidth 155000 s ub-pool 10000 paris(config-if)#i show mpls traffic-eng link -management interfaces po s 4/0 paris#s System Information:: Links Count: Link ID:: PO4/0 (10.200.210.1) Link Status: SRLGs: None Physical Bandwidth: 155000 kbits/sec Max Res Global BW: 155000 kbits/sec (reserved: 0% in, 0% out) Max Res Sub BW: 10000 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: (IGP) IGP Neighbor Count: IGP Neighbor: ID 10.200.254.3, IP 10.200.210.2 (Up) Flooding Status for each configured area [1]: IGP Area[1]: ospf area 0: flooded Example 8-9 shows the tunnel configuration for a sub-pool tunnel Example 8-9 Configuring a Sub-Pool Tunnel show running-config interf ace tunnel paris#s ! interface Tu nnel1 ip unnumbered Loop back0 tunnel destination 0.200.254.5 tunnel mode mp ls traffic-eng tunnel mpl s traffic-eng autoroute a nnounce tunnel mpls traff ic-eng priority 7 tunnel mpls traffic-eng bandwid th sub-pool 1000 tunnel m pls traffic-eng path-opti on explicit name paris-r ome tunnel mpls traffic-e ng fast-reroute ! show mpls traffic-eng tunn els tunnel paris#s Name: paris_t1 (Tunnel1) Destination: 10.200.254.5 Status: Admin: up Oper: up Path: valid Signalling: connected 1974_chp8ONLba.fm Page 718 Tuesday, November 14, 2006 9:58 AM Interarea TE Example 8-9 718 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 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 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 1974_chp8ONLba.fm Page 719 Tuesday, November 14, 2006 9:58 AM 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: next-address loose A.B.C.D Router(cfg-ip-expl-path)#n 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 Loopback 10.200.254.1 Loopback 10.200.254.2 Loopback 10.200.254.3 ABR 10.200.200.1 london 10.200.210.1 paris 10.200.212.1 brussels Loopback 10.200.254.4 TE Tunnel 10.200.213.1 Loopback 10.200.254.7 Loopback 10.200.254.6 10.200.202.2 sydney 10.200.215.2 rome Area frankfurt Loopback 10.200.254.5 10.200.215.1 ABR berlin Area 1974_chp8ONLba.fm Page 720 Tuesday, November 14, 2006 9:58 AM 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 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 to the ABR berlin Finally, the router berlin must calculate a path in area 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 unnu mbered Loopback0 tunnel d estination 10.200.254.7 t unnel mode mpls traffic-e ng tunnel mpls traffic-eng path-option 10 explicit name inter-area ! ip expli cit-path name inter-area e nable next-address loose 0.200.254.3 next-address loose 10.200.254.5 ! show mpls traffic-eng tunn el tunnel london#s Name: london_t1 (Tunnel1) Destination: 10.200.254.7 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: kbps (Global) Priority: 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: disabled LockDown: disabled Loadshare: bw-based auto-bw: disabled Active Path Option Parameters: State: explicit path option 10 is active BandwidthOverride: disabled InLabel : LockDown: disabled Verbatim: disabled - OutLabel : Ethernet0/0/0, 35 RSVP Signalling Info: Src 10.200.254.1, Dst 10.200.254.7, Tun_Id 1, Tun_Instance 18 RSVP Path Info: My Address: 10.200.200.1 Explicit Route: 10.200.200.2 10.200.210.2 10.200.254.3 10.200.254.5* Record Route: Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info: Record Route: 10.200.210.1 10.200.212.1 10.200.213.1 10.200.215.1 1974_chp8ONLba.fm Page 721 Tuesday, November 14, 2006 9:58 AM 721 Chapter 8: MPLS Traffic Engineering Example 8-10 Interarea Tunnel (Continued) 10.200.202.2 10.200.202.1 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: minutes, 28 seconds Current LSP: Uptime: 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 not support the TE IGP extensions, but they 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 unnu mbered Loopback0 tunnel d estination 10.200.254.5 t unnel mode mpls traffic-e ng 1974_chp8ONLba.fm Page 722 Tuesday, November 14, 2006 9:58 AM MPLS TE LSP Attributes 722 MPLS TE LPS ATTRIBUTES Example 8-11 Verbatim Tunnel (Continued) tunnel mpls traffic-eng a utoroute announce tunnel mpls traffic-eng path-opt ion explicit name paris -rome verbatim tunnel mpls traffic-eng fast-reroute show mpls traffic-eng tunn els tunnel paris#s Name: paris_t1 (Tunnel1) Destination: 10.200.254.5 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: kbps (Global) Priority: 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: bw-based auto-bw: disabled Active Path Option Parameters: State: explicit path option is active BandwidthOverride: disabled InLabel : LockDown: disabled Verbatim: enabled - OutLabel : POS4/0, 17 RSVP Signalling Info: Src 10.200.254.2, Dst 10.200.254.5, Tun_Id 1, Tun_Instance 5799 RSVP Path Info: My Address: 10.200.254.2 Explicit Route: 10.200.210.2 10.200.211.2 Record Route: NONE Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info: Record Route: 10.200.211.1(17) 10.200.211.2(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 1974_chp8ONLba.fm Page 723 Tuesday, November 14, 2006 9:58 AM 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 unnu mbered Loopback0 tunnel d estination 10.200.254.6 t unnel mode mpls traffic-e ng tunnel mpls traffic-eng autoroute announce tunne l mpls traffic-eng path-o ption dynamic attribute s attributes-1 tunnel mpls traffic-eng path-option explicit name paris-rom e attributes attributes-2 ! mpls traffic-eng lsp attr ibutes attributes-1 auto- bw protection fast-rerout e lockdown ! mpls traffic-e ng lsp attributes attribut es-2 bandwidth 500000 rec ord-route ! mpls traffic-eng lsp attri butes attributes-1 paris(config)#m ? 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 1974_chp8ONLba.fm Page 724 Tuesday, November 14, 2006 9:58 AM 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 Path Protection Example Figure 8-3 TE Tunnel Backup LSP 10.200.212.2 Loopback 10.200.254.5/32 frankfurt 10.20 0.214 POS 10/1 POS 10/3 10.200.211.2 brussels Loopback 10.200.254.6/32 10.200.215.2 berlin 10.200.202.2 rome sydney TE Tunnel Primary LSP The tunnel 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 unnu mbered Loopback0 tunnel d estination 10.200.254.7 t unnel mode mpls traffic-e ng tunnel mpls traffic-en g autoroute announce tunne l mpls traffic-eng path-o ption 10 explicit name to -sydney tunnel mpls traffi c-eng path-option protect 10 explicit name to-sydn ey-backup ! ! ip explicit-pa th name to-sydney enable n ext-address 10.200.211.2 next-address 10.200.215.2 next-address 10.200.202.2 ! ip explicit-path name to-sydney-backup enable continues 1974_chp8ONLba.fm Page 725 Tuesday, November 14, 2006 9:58 AM 725 Chapter 8: MPLS Traffic Engineering Example 8-13 Path Protection (Continued) next-address 10.200.212.2 next-address 10.200.214.2 next-address 10.200.202.2 ! show mpls traffic-eng tunn els tunnel brussels#s Name: brussels_t1 (Tunnel1) Destination: 10.200.254.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 10, type explicit to-sydney (Basis for Setup, path weight 3) Path Protection: Common Link(s) , Common Node(s) path protect option 10, type explicit to-sydney-backup (Basis for Protect, path weight 3) Config Parameters: Bandwidth: kbps (Global) Priority: 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: bw-based auto-bw: disabled Active Path Option Parameters: State: explicit path option 10 is active BandwidthOverride: disabled InLabel : LockDown: disabled Verbatim: disabled - OutLabel : Serial3/0, 32 RSVP Signalling Info: Src 10.100.254.3, Dst 10.200.254.7, Tun_Id 1, Tun_Instance 36 RSVP Path Info: My Address: 10.100.254.3 Explicit Route: 10.200.211.2 10.200.215.2 10.200.202.2 10.200.254.7 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: (TE) Explicit Route: 10.200.212.2 10.200.214.2 10.200.202.2 10.200.254.7 show mpls traffic-eng tun nels tunnel protection brussels#s brussels_t1 LSP Head, Tunnel1, Admin: up, Oper: up Src 10.100.254.3, Dest 10.200.254.7, Instance 36 Fast Reroute Protection: None Path Protection: Common Link(s) , Common Node(s) Primary lsp path:10.200.211.2 10.200.215.2 1974_chp8ONLba.fm Page 726 Tuesday, November 14, 2006 9:58 AM Troubleshooting MPLS TE Example 8-13 726 Path Protection (Continued) 10.200.202.2 10.200.254.7 Protect lsp path:10.200.212.2 10.200.214.2 10.200.202.2 10.200.254.7 Path Protect Parameters: Bandwidth: kbps (Global) Priority: 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) InLabel : - OutLabel : Serial2/0, 32 RSVP Signalling Info: Src 10.100.254.3, Dst 10.200.254.7, Tun_Id 1, Tun_Instance 42 RSVP Path Info: My Address: 10.100.254.3 Explicit Route: 10.200.212.2 10.200.214.2 10.200.202.2 10.200.254.7 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 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 1974_chp8ONLba.fm Page 727 Tuesday, November 14, 2006 9:58 AM 727 Chapter 8: MPLS Traffic Engineering Example 8-14 shows a tunnel that is down The TE tunnel is the tunnel 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 unnu mbered Loopback0 tunnel d estination 10.200.254.6 t unnel mode mpls traffic-e ng tunnel mpls traffic-eng autoroute announce tunn el mpls traffic-eng prior ity 7 tunnel mpls traffi c-eng bandwidth 155000 tu nnel mpls traffic-eng pat h-option 10 explicit name not-router-berlin ! ip exp licit-path name not-router -berlin enable exclude-ad dress 10.200.254.5 ! show mpls traffic-eng tunn els tunnel paris#s Name: paris_t1 (Tunnel1) Destination: 10.200.254.6 Status: Admin: up Oper: down Path: not valid Signalling: Down path option 10, type explicit not-router-berlin Config Parameters: Bandwidth: 155000 kbps (Global) Priority: 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 155000 bw-based auto-bw: disabled Shortest Unconstrained Path Info: Path Weight: (TE) Explicit Route: 10.200.210.2 10.200.211.2 10.200.215.2 10.200.254.6 History: Tunnel: Time since created: 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, 10.200.254.6 1974_chp8ONLba.fm Page 728 Tuesday, November 14, 2006 9:58 AM Troubleshooting MPLS TE 728 The debug in Example 8-15 tells you that the reservable bandwidth on LSR brussels (10.200.254.3) is too small Example 8-15 Troubleshooting MPLS TE Tunnel Path debug mpls traffic-eng pat h spf paris#d MPLS traffic-eng path calculation spf events debugging is on paris# *Apr 02:47:27.749: TE-PCALC_SPF: rrr_pcalc_node_exclude: excluding 10.200.254.5 *Apr 02:47:27.749: TE-PCALC_SPF: 10.200.254.2 aw min_bw 18446744073709551615, prev_node(NULL) *Apr 02:47:27.749: TE-PCALC_SPF: 10.200.254.2 *Apr 02:47:27.749: TE-PCALC_SPF: REJECT(max_bw too small) node 10.200.254.2, ip_address 10.200.200.2 bw 10000 *Apr 02:47:27.749: TE-PCALC_SPF: 10.200.254.3 aw min_bw 155000, prev_node(10.200.254.2) *Apr 02:47:27.749: TE-PCALC_SPF: rrr_pcalc_dump_tentitive list: *Apr 02:47:27.749: *Apr 02:47:27.753: TE-PCALC_SPF: 10.200.254.3 *Apr 02:47:27.753: TE-PCALC_SPF: REJECT(bw available too small) node(62)=(aw=2, min_bw=155000, hops=1) After you correct that problem by specifying the correct bandwidth with the ip rsvp bandwidth 155000 command on interface pos 10/1 on router brussels, you can see the next problem in Example 8-16 The attribute flags on the link with IP address 10.200.214.1 (router Frankfurt) 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)# int pos 10/1 brussels(config-if)#i ip rsvp bandwidth 155000 brussels(config-if)#i paris# *Apr 02:48:21.893: TE-PCALC_SPF: rrr_pcalc_node_exclude: excluding 10.200.254.5 *Apr 02:48:21.893: TE-PCALC_SPF: 10.200.254.2 aw min_bw 18446744073709551615, prev_node(NULL) *Apr 02:48:21.893: TE-PCALC_SPF: 10.200.254.2 *Apr 02:48:21.893: TE-PCALC_SPF: REJECT(max_bw too small) node 10.200.254.2, ip_address 10.200.200.2 bw 10000 *Apr 02:48:21.893: TE-PCALC_SPF: 10.200.254.3 aw min_bw 155000, prev_node(10.200.254.2) *Apr 02:48:21.893: TE-PCALC_SPF: rrr_pcalc_dump_tentitive list: *Apr 02:48:21.893: *Apr 02:48:21.893: TE-PCALC_SPF: 10.200.254.3 *Apr 02:48:21.893: TE-PCALC_SPF: 10.200.254.4 aw min_bw 155000, prev_node(10.200.254.3) node(62)=(aw=2, min_bw=155000, hops=1) 1974_chp8ONLba.fm Page 729 Tuesday, November 14, 2006 9:58 AM 729 Chapter 8: MPLS Traffic Engineering Troubleshooting MPLS TE Tunnel Path (Continued) Example 8-16 *Apr 02:48:21.893: TE-PCALC_SPF: rrr_pcalc_dump_tentitive list: *Apr 02:48:21.893: *Apr 02:48:21.893: TE-PCALC_SPF: 10.200.254.4 *Apr 02:48:21.893: TE-PCALC_SPF: REJ(no attribute flags) node 10.200.254.4, ip_address node(64)=(aw=3, min_bw=155000, hops=2) 10.200.214.1 *Apr 02:48:21.893: tunnel_affinity_bits 0x0, *Apr 02:48:21.893: tunnel_affinity_mask 0xFFFF, *Apr 02:48:21.893: link_attribute_flags 0xFFFF *Apr 02:48:21.893: TE-PCALC_SPF: rrr_pcalc_dump_tentitive list: After changing the affinity bits and mask on the TE tunnel to 0x00000000 and 0x00000000 respectively, the TE tunnel CSPF calculation succeeds and the TE tunnel is signaled, as you can see in Example 8-17 Example 8-17 Troubleshooting MPLS TE Tunnel Path tunnel mpls traffic-eng af finity 0x00000000 mask 0x00000000 paris(config-if)#t show mpls traffic-eng tunn els tunnel paris#s Name: paris_t1 (Tunnel1) Destination: 10.200.254.6 Status: Admin: up Oper: up Path: valid Signalling: connected path option 10, type explicit not-router-berlin (Basis for Setup, path weight 4) Config Parameters: Bandwidth: 155000 kbps (Global) Priority: 7 Affinity: 0x0/0x0 Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 155000 bw-based auto-bw: disabled Active Path Option Parameters: State: explicit path option 10 is active BandwidthOverride: disabled InLabel : LockDown: disabled Verbatim: disabled - OutLabel : POS4/0, 25 RSVP Signalling Info: Src 10.200.254.2, Dst 10.200.254.6, Tun_Id 1, Tun_Instance 715 RSVP Path Info: My Address: 10.200.254.2 Explicit Route: 10.200.210.2 10.200.212.2 10.200.214.2 10.200.254.6 Record Route: NONE 1974_chp8ONLba.fm Page 730 Tuesday, November 14, 2006 9:58 AM Troubleshooting MPLS TE Example 8-17 Troubleshooting MPLS TE Tunnel Path (Continued) Tspec: ave rate=155000 kbits, burst=1000 bytes, peak rate=155000 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=155000 kbits, burst=1000 bytes, peak rate=155000 kbits Shortest Unconstrained Path Info: Path Weight: (TE) Explicit Route: 10.200.210.2 10.200.212.2 10.200.214.2 10.200.254.6 730 ...1974_chp8ONLba.fm Page 702 Tuesday, November 14, 2006 9:58 AM CHAPTER SUPPLEMENT MPLS Traffic Engineering... change this with the following command: ip rsvp signalling refresh interval interval-value 1974_chp8ONLba.fm Page 703 Tuesday, November 14, 2006 9:58 AM 703 Chapter 8: MPLS Traffic Engineering... 8-1 show ip rsvp Commands brussels#show ip rsvp neighbor 10.200.193.1 RSVP 10.200.194.2 RSVP 1974_chp8ONLba.fm Page 704 Tuesday, November 14, 2006 9:58 AM IP RSVP Debugging 704 show ip rsvp Commands