1974_chp8ONLba

8/10/2019 1974_chp8ONLba

1/30

8/10/2019 1974_chp8ONLba

2/30

C HAPTERS UPPLEMENT

8

This online supplement of Chapter 8 deals with a few advanced traffic engineering (TE) topic

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 wer

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 tunnelthey 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. DiffServ

aware TE tunnels are briefly explained in this supplement. You will learn how they differ fro

the kind of TE tunnels that have been covered so far. All the TE tunnels that you have seen s

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 ho

to troubleshoot MPLS TE.

RSVP EnhancementsRFC 2961, RSVP Refresh Overhead Reduction Extensions, specifies mechanisms to reduc

the number of RSVP packets sent and to enhance the scalability and reliability of RSVP. RSV

is a chatty protocol that sends periodic refreshes. This is why RSVP is often referred to as bein

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 periodicallymore or less every 30

seconds. This enhancement makes RSVP more reliable by introducing acknowledgements an

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 glob

command:

iiiipppprrrrssssvvvvppppssssiiiiggggnnnnaaaalllllllliiiinnnnggggrrrreeeeffffrrrreeeesssshhhhrrrreeeedddduuuuccccttttiiiioooonnnn

The default refresh interval for RSVP messages is 30 seconds. You can change this with the

following command:

iiiipppprrrrssssvvvvppppssssiiiiggggnnnnaaaalllllllliiiinnnnggggrrrreeeeffffrrrreeeesssshhhhiiiinnnntttteeeerrrrvvvvaaaallllinterval-value

MPLS Traffic Engineering

8/10/2019 1974_chp8ONLba

3/30

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:

iiiipppprrrrssssvvvvppppssssiiiiggggnnnnaaaalllllllliiiinnnnggggrrrreeeeffffrrrreeeesssshhhhmmmmiiiisssssssseeeessssmsg-count

The msg-countvalue 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:

iiiipppprrrrssssvvvvppppssssiiiiggggnnnnaaaalllllllliiiinnnngggghhhheeeelllllllloooo

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:

iiiipppprrrrssssvvvvppppssssiiiiggggnnnnaaaalllllllliiiinnnngggghhhheeeelllllllloooorrrreeeeffffrrrreeeesssshhhhiiiinnnntttteeeerrrrvvvvaaaallllinterval-value

The interval-valueis a number between 1000 and 30,000 that is in milliseconds. By default, anRSVP 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:

iiiipppprrrrssssvvvvppppssssiiiiggggnnnnaaaalllllllliiiinnnngggghhhheeeelllllllloooorrrreeeeffffrrrreeeesssshhhhmmmmiiiisssssssseeeessssmsg-count

The msg-countvalue is a value between 4 and 10.

IP RSVP DebuggingExample 8-1 demonstrates some show ip rsvpcommands 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 rsvpCommands

brussels#sssshhhhoooowwwwiiiipppprrrrssssvvvvppppnnnneeeeiiiigggghhhhbbbboooorrrr

10.200.193.1 RSVP

10.200.194.2 RSVP

8/10/2019 1974_chp8ONLba

4/30

8/10/2019 1974_chp8ONLba

5/30


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

Resv ID handle: 1A000413.

Status:

Policy: Accepted. Policy source(s): MPLS/TE

brussels#sssshhhhoooowwwwiiiipppprrrrssssvvvvppppsssseeeennnnddddeeeerrrrddddeeeettttaaaaiiiillll

PATH:

Tun Dest: 10.200.254.5 Tun ID: 1 Ext Tun ID: 10.200.254.2

Tun Sender: 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: 7

Flags: (0x7) Local Prot desired, Label Recording, SE Style

Session Name: paris_t1

ERO: (incoming) 10.200.210.2 (Strict IPv4 Prefix, 8 bytes, /32)

10.200.211.2 (Strict IPv4 Prefix, 8 bytes, /32)


ERO: (outgoing)



RRO:

10.200.210.1/32, Flags:0x0 (No Local Protection)

Traffic params - Rate: 100M bits/sec, Max. burst: 1K bytes

Min Policed Unit: 0 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

Example 8-1 show ip rsvpCommands (Continued)

8/10/2019 1974_chp8ONLba

6/30

Bandwidth Protection on Backup Tunnels

tunnel mpls traffic-eng bandwidth. This can be handy when you are configuring several pa

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 requiremen

each path option, because the TE LSP did not successfully signal with the previous path opti

because of the lack of bandwidth. Example 8-2 shows a demonstrationof this.

This tunnel first tries to establish an LSP with a bandwidth of 550 Mbps by using the path op

10. If this fails, the tunnel tries path-option 20. This path option specifies a bandwidth requirem

of only 250 Mbps for the tunnel. If this fails, too, the tunnel tries the dynamic path option 30, w

a bandwidth of 150 Mbps. Finally, if this fails, the tunnel tries a dynamic path option withou

reserving bandwidth.

Bandwidth Protection on Backup Tunnels

You can assign a bandwidth requirement to backup tunnels. You might deploy this in a typic

scenario in which you have voice traffic that needs a guaranteed service. When the point of l

repair (PLR) assigns the TE LSP to the backup tunnel, it checks whether the bandwidth of th

backup tunnel is sufficient for the reroutable TE LSP. The command to assign bandwidth to t

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 an

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-n

hop (NNHOP) backup tunnels before next-hop (NHOP) backup tunnels. When the PLR assi

TE LSPs to backup tunnels, it might want to check that the current choice of assigning a TE

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

perform this check immediately if the event is the appearance or disappearance of a backup tun

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 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 250000

tunnel mpls traffic-eng path-option 30 dynamic bandwidth 150000

tunnel mpls traffic-eng path-option 40 dynamic bandwidth 0

8/10/2019 1974_chp8ONLba

7/30


or the PLR can perform it periodically. A TE LSP that is being assigned to a new backup tunnel is

calledpromotion. 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 prioritythan 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 fast-

reroute 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 TunnelsLSRs 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/10/2019 1974_chp8ONLba

8/30

Auto Tunnels

Look at Figure 8-1. Assuming that backup auto tunnels is only enabled on the router brussels

one TE tunnel is set up from the router brussels to the router rome, brussels creates one NHOP

NNHOP backup auto tunnel, protecting the link brussels-berlin and the node berlin. Example

shows an example of these two backup auto tunnels. To enable backup auto tunnels, configure

global command mpls traffic-eng auto-tunnel backup.

Figure 8-1 Backup Auto Tunnels Example

Example 8-3 Example of Backup Auto Tunnels

mpls traffic-eng auto-tunnel backup

brussels#sssshhhhoooowwwwmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggttttuuuunnnnnnnneeeellllssssbbbbrrrriiiieeeeffff

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: every 3600 seconds, next in 2940 seconds

Periodic auto-bw collection: 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




Displayed 5 (of 5) heads, 0 (of 0) midpoints, 0 (of 0) tails

frankfurt

brusselsparis berlin

POS 10/1

POS 10/3

10.200.212.2

10.200.210.2 10.200.211.2 10.200.215.2 10.200.202.2

Loopback 010.200.254.5/32

10.200.214.2

Loopback 010.200.254.6/32

rome sydney

NNHOP Backup Tunnel

NHOP Backup Tunnel

contin

8/10/2019 1974_chp8ONLba

9/30


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 minnummaxnum.

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

brussels#sssshhhhoooowwwwmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggttttuuuunnnnnnnneeeellllssssttttuuuunnnnnnnneeeellll66665555444433336666

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: 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 10.200.254.3, Dst 10.200.254.5, Tun_Id 65436, Tun_Instance 1

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: 1 (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

Example 8-3 Example of Backup Auto Tunnels (Continued)

8/10/2019 1974_chp8ONLba

10/30

Auto Tunnels

traffic-eng auto-tunnel backup nhop-only. That way, backup auto tunnels do not provide F

node protection.

Backup auto tunnels do not have autoroute announce enabled. This ensures that they are used

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 li

where MPLS TE is enabled. These tunnels have autoroute announce enabled, so they attract

traffic. Because these are one-hop tunnels, the outgoing label is always implicit NULL. No l

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 tunnel

one-hop only, they map exactly to the link. As such, the routing is no different from when th

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 show

primary auto tunnels. Because two outgoing links (pos 10/1 and pos 10/3) are enabled for MP

TE, there are two primary auto tunnels. Because backup auto tunnels is also enabled, there is

backup auto tunnel for each primary auto tunnel.

Example 8-4 Primary Auto Tunnels

mmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggaaaauuuuttttoooo----ttttuuuunnnnnnnneeeellllbbbbaaaacccckkkkuuuupppp

mmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggaaaauuuuttttoooo----ttttuuuunnnnnnnneeeellllpppprrrriiiimmmmaaaarrrryyyyoooonnnneeeehhhhoooopppp

brussels#sssshhhhoooowwwwmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggttttuuuunnnnnnnneeeellllssssbbbbrrrriiiieeeeffffSignalling Summary:



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 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



brussels_t1000 10.200.254.5 - unknown admin-downconti

8/10/2019 1974_chp8ONLba

11/30


Example 8-5 shows that the primary auto tunnel 65336 has autoroute announce on and that the

backup auto tunnel 65437 protects it. Notice that the outgoing label is implicit NULL for the

primary auto tunnel.








Example 8-5 Protection of Primary Auto Tunnel



Status:


path option 1, type explicit __dynamic_tunnel65336 (Basis for Setup, path weight 1)

Config Parameters:



AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based

auto-bw: disabled




InLabel : -

OutLabel : POS10/3, implicit-null



RSVP Path Info:

My Address: 10.200.254.3

Explicit Route: 10.200.211.2 10.200.254.5

Record Route: NONE


RSVP Resv Info:

Record Route: 10.200.211.2(0)

Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits


Path Weight: 1 (TE)

Explicit Route: 10.200.211.2 10.200.254.5

History:

Tunnel:

Example 8-4 Primary Auto Tunnels (Continued)

8/10/2019 1974_chp8ONLba

12/30

Auto Tunnel Mesh Groups

By default, high numbers (65,336 to 65,435) are chosen for the primary auto tunnels. If you w

to, you can change the range for the primary auto tunnels with the command mpls traffic-en

auto-tunnel primary tunnel-num minnummaxnum.

Because primary auto tunnels are one-hop tunnels, only NHOP backup tunnels, not NNHOP

backup tunnels, can protect them.

Auto Tunnel Mesh GroupsThe feature Auto Tunnel Mesh Groups makes it possible to build a mesh of TE tunnels betw

LSRs, with minimal configuration. LSRs are configured to be part of a mesh group by mean

an access list. The TE tunnels are not created individually, but an auto-templateinterface is

created. All TE tunnels that are part of the mesh group inherent their features from this temp

(This means they are cloned from the template interface.) The great benefit of this feature is

when a new LSR is configured to be part of this mesh, you do not need to configure TE tunne

all the other LSRs, which are part of the mesh. The TE tunnels are created automatically as t

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.



Current LSP:


brussels#sssshhhhoooowwwwmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggttttuuuunnnnnnnneeeellllssssttttuuuunnnnnnnneeeellll66665555333333336666pppprrrrooootttteeeeccccttttiiiioooonnnn

brussels_t65336

LSP Head, Tunnel65336, Admin: up, Oper: up

Src 10.200.254.3, Dest 10.200.254.5, 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: 10.200.211.2

With FRR: out i/f: Tu65437, label: implicit-null LSP bw: 0 kbps, Backup level: any-unlim, type: any pool

Example 8-5 Protection of Primary Auto Tunnel (Continued)

8/10/2019 1974_chp8ONLba

13/30


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 ofbandwidth, 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

mmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggaaaauuuuttttoooo----ttttuuuunnnnnnnneeeellllmmmmeeeesssshhhh

!!!!

iiiinnnntttteeeerrrrffffaaaacccceeeeAAAAuuuuttttoooo----TTTTeeeemmmmppppllllaaaatttteeee1111

iiiippppuuuunnnnnnnnuuuummmmbbbbeeeerrrreeeeddddLLLLooooooooppppbbbbaaaacccckkkk0000

ttttuuuunnnnnnnneeeellllddddeeeessssttttiiiinnnnaaaattttiiiioooonnnnaaaacccccccceeeessssssss----lllliiiisssstttt99999999

ttttuuuunnnnnnnneeeellllmmmmooooddddeeeemmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnngggg

ttttuuuunnnnnnnneeeellllmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggaaaauuuuttttoooorrrroooouuuutttteeeeaaaannnnnnnnoooouuuunnnncccceeee

ttttuuuunnnnnnnneeeellllmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggppppaaaatttthhhh----ooooppppttttiiiioooonnnn1111ddddyyyynnnnaaaammmmiiiicccc

!!!!

aaaacccccccceeeessssssss----lllliiiisssstttt99999999ppppeeeerrrrmmmmiiiitttt11110000....222200000000....222255554444....00000000....0000....0000....3333

paris#sssshhhhoooowwwwmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggttttuuuunnnnnnnneeeellllssssbbbbrrrriiiieeeeffff

Signalling Summary:



Forwarding: enabled

auto-tunnel:

backup Disabled (0 ), id-range:65436-65535

onehop Disabled (0 ), id-range:65336-65435

mesh Enabled (2 ), id-range:64336-65335



Periodic auto-bw collection: every 300 seconds, next in 291 seconds


paris_t64336 10.200.254.1 - Et1/1 up/up

paris_t64337 10.200.254.3 - PO4/0 up/up

london_t64336 10.200.254.2 Et1/1 - up/up

london_t64337 10.200.254.3 Et1/1 PO4/0 up/up

brussels_t64336 10.200.254.1 PO4/0 Et1/1 up/up

brussels_t64337 10.200.254.2 PO4/0 - up/up


paris#sssshhhhoooowwwwmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggaaaauuuuttttoooo----ttttuuuunnnnnnnneeeellllmmmmeeeesssshhhh

8/10/2019 1974_chp8ONLba

14/30

Automatic Bandwidth Adjustment for TE Tunnels

By default, high numbers (64,336 to 65,335) are chosen for the mesh group auto tunnels. If y

wish, you can change the range for the mesh group auto tunnels with the command mpls tra

eng auto-tunnel mesh tunnel-num minnummaxnum.


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 tu

is. This is done by letting the head end router sample the average output load of the TE tunn

during a period of time. The command to configure this on the TE tunnel interface is as follo

Router(config)#mmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggaaaauuuuttttoooo----bbbbwwww[ccccoooolllllllleeeecccctttt----bbbbwwww] [ffffrrrreeeeqqqquuuueeeennnnccccyyyysec] [mmmmaaaaxxxx----bbbbwwwwn][bbbbwwwwn]

The default interval is 300 seconds, or 5 minutes. You can change it by configuring a differen

frequency. To limit the range of bandwidth, you can specify a minimum and maximum amoun

bandwidth in kilobits per seconds to apply to the tunnel. The collect-bwkeyword enables yo

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 we

before letting the head end routers change the bandwidth automatically. Example 8-7 shows a

tunnel where bandwidth adjustment is enabled. Note that the configuration on the TE tunnel

interface (the mpls traffic-eng bandwidthcommand) changes to reflect the actual bandwidt

reserved. This change is in the running configuration, but not in startup configuration.

Auto-Template1:

Using access-list 99 to clone the following tunnel interfaces:

Destination Interface

----------- ---------

10.200.254.1 Tunnel64336

10.200.254.3 Tunnel64337

Mesh tunnel interface numbers: min 64336 max 65335

Example 8-7 Configuration of Automatic Bandwidth Adjustment

!!!!

iiiinnnntttteeeerrrrffffaaaacccceeeeTTTTuuuunnnnnnnneeeellll1111


ttttuuuunnnnnnnneeeellllddddeeeessssttttiiiinnnnaaaattttiiiioooonnnn11110000....222200000000....222255554444....5555



Example 8-6 Auto Tunnel Mesh Group (Continued)


8/10/2019 1974_chp8ONLba

15/30


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, forexample, 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

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#sssshhhhoooowwwwmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggttttuuuunnnnnnnneeeellllssssttttuuuunnnnnnnneeeellll1111

Name: paris_t1 (Tunnel1) Destination: 10.200.254.5

Status:


path option 1, type explicit paris-rome (Basis for Setup, path weight 2)

Config Parameters:



AutoRoute: enabled LockDown: disabled Loadshare: 435 bw-based auto-bw: (30/144) 0 Bandwidth Requested: 435




brussels#sssshhhhoooowwwwmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnngggglllliiiinnnnkkkk----mmmmaaaannnnaaaaggggeeeemmmmeeeennnnttttaaaaddddmmmmiiiissssssssiiiioooonnnn----ccccoooonnnnttttrrrroooollllppppoooossss11110000////3333

System Information::

Tunnels Count: 3

Tunnels Selected: 1

TUNNEL ID UP IF DOWN IF PRIORITY STATE BW (kbps)

10.200.254.2 1_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.

Example 8-7 Configuration of Automatic Bandwidth Adjustment

8/10/2019 1974_chp8ONLba

16/30

DiffServ-Aware TE

the links. This 20 percent is then the sub-pool of the global pool of bandwidth that is reserva

on a link. This traffic might be voice traffic or leased line traffic with specific QoS requireme

You might have TE-enabled links that do not meet this QoS requirement and are therefore no

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, t

can guarantee a particular QoS level. However, because the traffic needing this QoS requirem

is routed into a special sub-pool tunnel, it can inherit a particular DiffServ value. The Experime

(EXP) bits in the labels of the traffic that is going into the sub-pool versus the global pool tun

can be set differently on the head end routers. You can use policy-based routing or Modular Q

Command Line Interface (MQC) to perform this task. Then you can use the EXP bits value on

routers to provide the proper QoS treatment on every link. For example, you can ensure that

sub-pool TE traffic uses one particular DiffServ queue that no other traffic does. To recap: Th

proper usage of sub-pool tunnels entails the following:

The traffic that is requiring the guaranteed QoS treatment is steered into the sub-pool tun

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 v

on the links.

By default, the interfaces that are enabled for MPLS TE and used for global pool tunnels hav

reservable bandwidth advertised only for the global pool tunnels. You must use the ip rsvp

bandwidthcommand with the sub-poolkeyword on the TE-enabled links to advertise bandw

for sub-pool tunnels:

iiiipppprrrrssssvvvvppppbbbbaaaannnnddddwwwwiiiiddddtttthhhhkbps[ssssuuuubbbb----ppppoooooooollllkpbs]

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

kbps:

ttttuuuunnnnnnnneeeellllmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggbbbbaaaannnnddddwwwwiiiiddddtttthhhhssssuuuubbbb----ppppoooooooollllbandwidth

For a global pool tunnel, you can specify 0 as the required bandwidth. For a sub-pool tunnel

required bandwidth must be something other than 0.

8/10/2019 1974_chp8ONLba

17/30


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-9 shows the tunnel configuration for a sub-pool tunnel.

Example 8-8 Configuring Bandwidth for Sub-Pool Tunnels

paris(config)#iiiinnnnttttppppoooossss4444////0000paris(config-if)#iiiipppprrrrssssvvvvppppbbbbaaaannnnddddwwwwiiiiddddtttthhhh111155555555000000000000ssssuuuubbbb----ppppoooooooollll11110000000000000000

paris#sssshhhhoooowwwwmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnngggglllliiiinnnnkkkk----mmmmaaaannnnaaaaggggeeeemmmmeeeennnnttttiiiinnnntttteeeerrrrffffaaaacccceeeessssppppoooossss4444////0000

System Information::

Links Count: 2

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: 1 (IGP)

IGP Neighbor Count: 1

IGP Neighbor: ID 10.200.254.3, IP 10.200.210.2 (Up)

Flooding Status for each configured area [1]:

IGP Area[1]: ospf 1 area 0: flooded

Example 8-9 Configuring a Sub-Pool Tunnelparis#sssshhhhoooowwwwrrrruuuunnnnnnnniiiinnnngggg----ccccoooonnnnffffiiiiggggiiiinnnntttteeeerrrrffffaaaacccceeeettttuuuunnnnnnnneeeellll1111

!!!!






ttttuuuunnnnnnnneeeellllmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggpppprrrriiiioooorrrriiiittttyyyy77777777

ttttuuuunnnnnnnneeeellllmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggbbbbaaaannnnddddwwwwiiiiddddtttthhhhssssuuuubbbb----ppppoooooooollll1111000000000000

ttttuuuunnnnnnnneeeellllmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggppppaaaatttthhhh----ooooppppttttiiiioooonnnn1111eeeexxxxpppplllliiiicccciiiittttnnnnaaaammmmeeeeppppaaaarrrriiiissss----rrrroooommmmeeee

ttttuuuunnnnnnnneeeellllmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggffffaaaasssstttt----rrrreeeerrrroooouuuutttteeee

!!!!



Status:


8/10/2019 1974_chp8ONLba

18/30

Interarea TE

Interarea TE

Up until now, all TE tunnels discussed here have been TE tunnels in one area of a link state rou

protocol. The reason is that routers have only the complete picture of the area they are in, beca

a link state routing protocol has a link state database per area. A router in an area does not ha

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 p

where all the hops of the TE tunnel had to be specified. Also available was a semi-dynamic T

tunnel path option whereby you could use an explicit path and exclude certain IP addresses.

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 p

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 cr

The list of LSRs is only the LSRs that the TE tunnel must cross. The missing LSRs in between

be any LSRs that the head end router finds to be on a feasible path toward the loose next hop

the list.

The solution to build a TE tunnel that can span multiple areas is to specify the area border rou

(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 becothe explicit route object (ERO) carried in the RSVP Path messages. That ABR must expand

loose route from itself to the next ABR that is specified in the explicit path, and so on. Theref

the ABR turns a loose route into an explicit one. When areas have multiple ABRs between th

you can specify different path options with different loose next hops so that you can have bac

paths in case one ABR fails. However, you have one big disadvantage of using an interarea T

tunnel. Because the head end router does not have the TE database of the other areas, it cann

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



auto-bw: disabled




NOTE For more information on QoS with MPLS, refer to Chapter 12, MPLS and Quality

Service.

Example 8-9 Configuring a Sub-Pool Tunnel (Continued)

8/10/2019 1974_chp8ONLba

19/30


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 anarea.

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)#nnnneeeexxxxtttt----aaaaddddddddrrrreeeesssssssslllloooooooosssseeeeA.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

Loopback 0

10.200.254.1

Loopback 0

10.200.254.2

Loopback 0

10.200.254.3

london brussels

ABR

Loopback 0

10.200.254.4

frankfurt

ABR

paris

Area 1

Area 0Area 2

TE Tunnel 1

10.200.200.1 10.200.210.1

Loopback 0

10.200.254.7

Loopback 0

10.200.254.6

Loopback 0

10.200.254.5

sydney berlinrome

10.200.202.2 10.200.215.2 10.200.215.1

10.200.212.1

10.200.213.1

8/10/2019 1974_chp8ONLba

20/30

Interarea TE

The TE tunnel head end router is router london in area 1, and the tail end router is router syd

in area 2. The two area border routers are brussels and berlin. These two ABRs are configure

loose next hops in the explicit path for the interarea TE tunnel. It is the task of router london

calculate a path to the ABR brussels, and it is the task of router brussels to calculate a path in O

area 0 to the ABR berlin. Finally, the router berlin must calculate a path in area 2 toward theend router sydney. Example 8-10 shows the configuration of this interarea TE tunnel on rout

london.

Example 8-10 Interarea Tunnel

!!!!





ttttuuuunnnnnnnneeeellllmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggppppaaaatttthhhh----ooooppppttttiiiioooonnnn11110000eeeexxxxpppplllliiiicccciiiittttnnnnaaaammmmeeeeiiiinnnntttteeeerrrr----aaaarrrreeeeaaaa

!!!!iiiippppeeeexxxxpppplllliiiicccciiiitttt----ppppaaaatttthhhhnnnnaaaammmmeeeeiiiinnnntttteeeerrrr----aaaarrrreeeeaaaaeeeennnnaaaabbbblllleeee

nnnneeeexxxxtttt----aaaaddddddddrrrreeeesssssssslllloooooooosssseeee11110000....222200000000....222255554444....3333

nnnneeeexxxxtttt----aaaaddddddddrrrreeeesssssssslllloooooooosssseeee11110000....222200000000....222255554444....5555

!!!!

london#sssshhhhoooowwwwmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggttttuuuunnnnnnnneeeellllttttuuuunnnnnnnneeeellll1111

Name: london_t1 (Tunnel1) Destination: 10.200.254.7

Status:


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


AutoRoute: disabled LockDown: disabled Loadshare: 0 bw-based

auto-bw: disabled




InLabel : -

OutLabel : Ethernet0/0/0, 35



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:


RSVP Resv Info:

Record Route: 10.200.210.1 10.200.212.1 10.200.213.1 10.200.215.1

8/10/2019 1974_chp8ONLba

21/30


Notice that the Shortest Unconstrained PathInfocannot 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.

10.200.202.2 10.200.202.1



Path Weight: UNKNOWN

Explicit Route: UNKNOWN

History:

Tunnel:



Current LSP:


Selection: reoptimization

Prior LSP:

ID: path option 10 [16]

Removal Trigger: label reservation removed

Example 8-11Verbatim Tunnel

!!!!





Example 8-10 Interarea Tunnel (Continued)

8/10/2019 1974_chp8ONLba

22/30

MPLS TE LSP AttributesMPLS TE LPS ATTRIBUTES

MPLS TE LSP Attributes

You can assign LSP attributes to a TE tunnel per path option. Therefore, depending on the pthat 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 tu

interface.


ttttuuuunnnnnnnneeeellllmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggppppaaaatttthhhh----ooooppppttttiiiioooonnnn1111eeeexxxxpppplllliiiicccciiiittttnnnnaaaammmmeeeeppppaaaarrrriiiissss----rrrroooommmmeeeevvvveeeerrrrbbbbaaaattttiiiimmmm

ttttuuuunnnnnnnneeeellllmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggffffaaaasssstttt----rrrreeeerrrroooouuuutttteeee



Status:


path option 1, type explicit (verbatim) paris-rome (Basis for Setup, path weight

Config Parameters:




auto-bw: disabled Active Path Option Parameters:


BandwidthOverride: disabled LockDown: disabled Verbatim: enabled

InLabel : -




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)



Path Weight: UNKNOWN

Explicit Route: UNKNOWN

Example 8-11 Verbatim Tunnel (Continued)

8/10/2019 1974_chp8ONLba

23/30


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.

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.

Example 8-12 LSP Attributes

!!!!iiiinnnntttteeeerrrrffffaaaacccceeeeTTTTuuuunnnnnnnneeeellll1111





ttttuuuunnnnnnnneeeellllmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggppppaaaatttthhhh----ooooppppttttiiiioooonnnn1111ddddyyyynnnnaaaammmmiiiiccccaaaattttttttrrrriiiibbbbuuuutttteeeessssaaaattttttttrrrriiiibbbbuuuutttteeeessss----1111

ttttuuuunnnnnnnneeeellllmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggppppaaaatttthhhh----ooooppppttttiiiioooonnnn2222eeeexxxxpppplllliiiicccciiiittttnnnnaaaammmmeeeeppppaaaarrrriiiissss----rrrroooommmmeeeeaaaattttttttrrrriiiibbbbuuuutttteeeessssaaaattttttttrrrriiiibbbbuuuutttteeeessss----2222

!!!!

mmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggllllssssppppaaaattttttttrrrriiiibbbbuuuutttteeeessssaaaattttttttrrrriiiibbbbuuuutttteeeessss----1111

aaaauuuuttttoooo----bbbbwwww

pppprrrrooootttteeeeccccttttiiiioooonnnnffffaaaasssstttt----rrrreeeerrrroooouuuutttteeee

lllloooocccckkkkddddoooowwwwnnnn!!!!

mmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggllllssssppppaaaattttttttrrrriiiibbbbuuuutttteeeessssaaaattttttttrrrriiiibbbbuuuutttteeeessss----2222

bbbbaaaannnnddddwwwwiiiiddddtttthhhh555500000000000000000000

rrrreeeeccccoooorrrrdddd----rrrroooouuuutttteeee

!!!!

paris(config)#mmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggllllssssppppaaaattttttttrrrriiiibbbbuuuutttteeeessssaaaattttttttrrrriiiibbbbuuuutttteeeessss----1111

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

8/10/2019 1974_chp8ONLba

24/30

Path Protection

It is, however, still faster than rerouting the primary TE LSP onto another path. That is becau

this involves resignaling the LSP, whereas with path protection, the backup TE LSP is alread

established at the time of the failure.

Each path option of a TE tunnel can be backed up by a protection LSP. The configuration neeis a path option with the protect keyword. Look at Figure 8-3 to see an example of path protect

Figure 8-3 Path Protection Example

The tunnel 1 has one primary and one backup LSP. Example 8-13 shows the tunnel configurafor Figure 8-3.

Example 8-13 Path Protection

!!!!






ttttuuuunnnnnnnneeeellllmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggppppaaaatttthhhh----ooooppppttttiiiioooonnnn11110000eeeexxxxpppplllliiiicccciiiittttnnnnaaaammmmeeeettttoooo----ssssyyyyddddnnnneeeeyyyy

ttttuuuunnnnnnnneeeellllmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggppppaaaatttthhhh----ooooppppttttiiiioooonnnnpppprrrrooootttteeeecccctttt11110000eeeexxxxpppplllliiiicccciiiittttnnnnaaaammmmeeeettttoooo----ssssyyyyddddnnnneeeeyyyy----bbbbaaaacccckkkkuuuupppp

!!!!

!!!!

iiiippppeeeexxxxpppplllliiiicccciiiitttt----ppppaaaatttthhhhnnnnaaaammmmeeeettttoooo----ssssyyyyddddnnnneeeeyyyyeeeennnnaaaabbbblllleeee

nnnneeeexxxxtttt----aaaaddddddddrrrreeeessssssss11110000....222200000000....222211111111....2222

next-address 10.200.215.2


!

ip explicit-path name to-sydney-backup enable

frankfurt

brussels berlin

POS 10/1

POS 10/3

10.200.212.2

10.200.211.2 10.200.215.2 10.200.202.2

Loopback 010.200.254.5/32

10.200.214.2

Loopback 0

10.200.254.6/32

rome sydney

TE Tunnel 1

Primary LSP

TE Tunnel 1

Backup LSP

conti

8/10/2019 1974_chp8ONLba

25/30





!



Status:


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, pathweight 3)

Config Parameters:




auto-bw: disabled




InLabel : -

OutLabel : Serial3/0, 32


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


RSVP Resv Info:

Record Route: NONE



Path Weight: 3 (TE)

Explicit Route: 10.200.212.2 10.200.214.2 10.200.202.2 10.200.254.7

brussels#sssshhhhoooowwwwmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggttttuuuunnnnnnnneeeellllssssttttuuuunnnnnnnneeeellll1111pppprrrrooootttteeeeccccttttiiiioooonnnn

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: 1 Common Link(s) , 1 Common Node(s)

Primary lsp path:10.200.211.2 10.200.215.2

Example 8-13 Path Protection (Continued)

8/10/2019 1974_chp8ONLba

26/30

Troubleshooting MPLS TE

Cisco IOS does not make sure that the primary TE LSP and backup TE LSP are diverse when u

dynamaic path options. Both LSPs might share many links or nodes, which defeats the purpos

path protection. Therefore, you must make sure that the paths of the primary TE LSP and bac

TE LSP are diverse, or as diverse as possible. You do this by configuring an explicit path opt

for both the primary TE LSP and the backup TE LSP. The command show mpls traffic-eng

tunnelstunnel-interface[brief] protectionshows the number of common links and nodes

between the primary and backup TE LSPs.


The most frequent problem with MPLS TE is a tunnel that is not set up. The tunnel interface d

not come up if the TE tunnel LSP is not set up. That is easy enough to notice. But why does

TE tunnel not come up? Much can already be seen by looking at the tunnel with the comman

show mpls traffic-eng tunnel tunnel tunnel-number. Other common troubleshooting techniq

involve looking at the TE database and enabling debug ip rsvp signalingand debug mpls tra

eng path spf.

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:



InLabel : -

OutLabel : Serial2/0, 32



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


Example 8-13 Path Protection (Continued)

8/10/2019 1974_chp8ONLba

27/30

8/10/2019 1974_chp8ONLba

28/30


The debugin Example 8-15 tells you that the reservable bandwidth on LSR brussels

(10.200.254.3) is too small.

After you correct that problem by specifying the correct bandwidth with the ip rsvp bandw

155000command 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-15 Troubleshooting MPLS TE Tunnel Path

paris#ddddeeeebbbbuuuuggggmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggppppaaaatttthhhhssssppppffff

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 10.200.254.5

*Apr 5 02:47:27.749: TE-PCALC_SPF: 10.200.254.2 aw 0 min_bw 18446744073709551615,

prev_node(NULL)

*Apr 5 02:47:27.749: TE-PCALC_SPF: 10.200.254.2

*Apr 5 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


prev_node(10.200.254.2)

*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: 10.200.254.3

*Apr 5 02:47:27.753: TE-PCALC_SPF: REJECT(bw available too small)


brussels(config-if)#brussels(config-if)#iiiinnnnttttppppoooossss11110000////1111

brussels(config-if)#iiiipppprrrrssssvvvvppppbbbbaaaannnnddddwwwwiiiiddddtttthhhh111155555555000000000000

paris#

*Apr 5 02:48:21.893: TE-PCALC_SPF: rrr_pcalc_node_exclude: excluding 10.200.254.5


prev_node(NULL)

*Apr 5 02:48:21.893: TE-PCALC_SPF: 10.200.254.2

*Apr 5 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


prev_node(10.200.254.2)*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: 10.200.254.3


prev_node(10.200.254.3)

8/10/2019 1974_chp8ONLba

29/30


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.


*Apr 5 02:48:21.893: node(64)=(aw=3, min_bw=155000, hops=2)

*Apr 5 02:48:21.893: TE-PCALC_SPF: 10.200.254.4

*Apr 5 02:48:21.893: TE-PCALC_SPF: REJ(no attribute flags) node 10.200.254.4, ip_address

10.200.214.1

*Apr 5 02:48:21.893: tunnel_affinity_bits 0x0,

*Apr 5 02:48:21.893: tunnel_affinity_mask 0xFFFF,

*Apr 5 02:48:21.893: link_attribute_flags 0xFFFF



paris(config-if)#ttttuuuunnnnnnnneeeellllmmmmppppllllssssttttrrrraaaaffffffffiiiicccc----eeeennnnggggaaaaffffffffiiiinnnniiiittttyyyy0000xxxx00000000000000000000000000000000mmmmaaaasssskkkk0000xxxx00000000000000000000000000000000



Status:


path option 10, type explicit not-router-berlin (Basis for Setup, path weight 4)

Config Parameters:

Bandwidth: 155000 kbps (Global) Priority: 7 7 Affinity: 0x0/0x0



auto-bw: disabled




InLabel : -




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

Example 8-16 Troubleshooting MPLS TE Tunnel Path (Continued)

8/10/2019 1974_chp8ONLba

30/30



RSVP Resv Info:

Record Route: NONE



Path Weight: 4 (TE)

Explicit Route: 10.200.210.2 10.200.212.2 10.200.214.2 10.200.254.6

Example 8-17 Troubleshooting MPLS TE Tunnel Path (Continued)

Documents

1974_chp8ONLba