Ever since I passed "Implementing Cisco MPLS" (642-611) exam, I've been aching to try my hands at MPLS TE. So, here is the task:
Click on image to see bigger version.
Since R2-R4 link is T3, OSPF will pick R2-R3-R5 path from R1 to either R6 or R7 leaving R2-R4-R5 link underutilized. At the same time I know that traffic from R1 to 10.0.0.0/24 is going to low enough to fit comfortably into T3 link. I wanted to create explicit path tunnel R1-R2-R4-R5-R7 with backup dynamic tunnel. I am going to skip configuration part - there are more then enough examples on the 'Net.
Let's see if tunnel is up
R1#sho mpls traffic-eng tunnels
Name: 6503sw2_t0 (Tunnel0) Destination: 192.168.1.4
Status:
Admin: up Oper: down Path: not valid Signalling: Down path option 1, type explicit mypath
Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled
History:
Tunnel:
Time since created: 20 hours, 1 minutes
Time since path change: 3 minutes, 24 seconds
Number of LSP IDs (Tun_Instances) used: 334
Prior LSP:
ID: path option 1 [309]
Removal Trigger: path option removed
Last Error: PCALC:: No addresses to connect 172.16.0.14 to 172.16.0.10
Not good.
Searching for this type of error message gives one sage advise:
For cases involving an explicit path option, you can try to narrow down the problem by first checking every hop in the explicit hop list. You can also try to back down the tunnel: Move the tail one hop back each time to see if the tunnel comes up. If the tunnel comes up when you move the tail to a previous hop, you can conclude that there is a problem between that hop and the next hop, and you can start scrutinizing that hop carefully.
And so I did. Let's see how R2 and R5 see R4:
R2# show ip rsvp neighbor
Neighbor Encapsulation Time since msg rcvd/sent
172.16.0.18 Raw IP 00:02:12 00:02:10
172.16.0.21 Raw IP 00:02:10 00:02:23
R5#show ip rsvp neighbor
Neighbor Encapsulation Time since msg rcvd/sent
172.16.0.1 Raw IP 00:03:59 00:04:18
172.16.0.6 Raw IP 00:04:16 00:03:59
Hmm, they do not see R4 as RSVP neighbor at all. What's going on on R4?
R4# sho ip rsvp interface detail gi 0/0
Gi0/0:
Interface State: Up
Bandwidth:
Curr allocated: 0 bits/sec
Max. allowed (total): 30M bits/sec
Max. allowed (per flow): 30M bits/sec
Max. allowed for LSP tunnels using sub-pools: 0 bits/sec
Set aside by policy (total): 0 bits/sec
Admission Control:
Header Compression methods supported:
rtp (36 bytes-saved), udp (20 bytes-saved)
Traffic Control:
RSVP Data Packet Classification is ON
Signalling:
DSCP value used in RSVP msgs: 0x3F
Number of refresh intervals to enforce blockade state: 4
Number of missed refresh messages: 4
Refresh interval: 30
Authentication: disabled
How does it compare with R4-facing interface on R5?
R5#sho ip rsvp interface detail gi 0/2
Gi0/2:
RSVP: Enabled
Interface State: Up
Bandwidth:
Curr allocated: 0 bits/sec
Max. allowed (total): 40M bits/sec
Max. allowed (per flow): 40M bits/sec
Max. allowed for LSP tunnels using sub-pools: 0 bits/sec
Set aside by policy (total): 0 bits/sec
Admission Control:
Header Compression methods supported:
rtp (36 bytes-saved), udp (20 bytes-saved)
Traffic Control:
RSVP Data Packet Classification is ON via CEF callbacks
Signalling:
DSCP value used in RSVP msgs: 0x3F
Number of refresh intervals to enforce blockade state: 4
Authentication: disabled
Key chain:
Type: md5
Window size: 1
Challenge: disabled
Hello Extension:
State: Disabled
"RSVP: Enabled" string is missing in R4 command output. After some research I found that I need "T" type IOS to run RSVP-TE on R4 which is Cisco 3825.
Let's see what we have after the upgrade:
R4#sho ip rsvp interface detail gi 0/0
Gi0/0:
RSVP: Enabled
Interface State: Up
Bandwidth:
Curr allocated: 5M bits/sec
Max. allowed (total): 30M bits/sec
Max. allowed (per flow): 30M bits/sec
Max. allowed for LSP tunnels using sub-pools: 0 bits/sec
Set aside by policy (total): 0 bits/sec
Admission Control:
Header Compression methods supported:
rtp (36 bytes-saved), udp (20 bytes-saved)
Traffic Control:
RSVP Data Packet Classification is ON
Signalling:
DSCP value used in RSVP msgs: 0x3F
Number of refresh intervals to enforce blockade state: 4
Authentication: disabled
Key chain:
Type: md5
Window size: 1
Challenge: disabled
Hello Extension:
State: Disabled
and tunnel:
R1#sho mpls traffic-eng tunnels bri
Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 3042 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 42 seconds
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
6503sw2_t0 192.168.1.4 - Gi2/1 up/up
Much better. Confirm routing
R1#sho ip route 10.0.0.0 255.255.255.0
Routing entry for 10.0.0.0/24
Known via "ospf 100", distance 110, metric 14, type intra area
Last update from 192.168.1.4 on Tunnel0, 19:41:13 ago
Routing Descriptor Blocks:
* 192.168.1.4, from 192.168.1.4, 19:41:13 ago, via Tunnel0
Route metric is 14, traffic share count is 1
Now, since MPLS TE tunnel is unidirectional, I need to create R7-R5-R4-R2-R1 tunnel as well.
When entering configuration mode, this new option allows you to request confirmation (a confirmation time limit must be supplied) of the configuration changes.
