I have a traffic-eng tunnel that isn't coming up. I have 4 traffic-eng tunnels, all pretty much the same (except path options and destination) and three are up:
*Tunnel1212 0 0 0 0 0 0 0 0 0
Tunnel1222 0 0 0 0 0 0 0 0 0
*Tunnel1232 0 0 0 0 0 0 0 0 0
*Tunnel1242 0 0 0 0 0 0 0 0 0
This tunnel will be used for MPLS FRR and should provide an alternate pre-signalled route between PTW-GW01 and PTW-AG02. The path should be PTW-GW01--PTW-GW02--PTW-AG02. Im not reserving any bandwidth so that isn't the issue here.
Tunnel1222 has the config:
ip unnumbered Loopback0
tunnel destination 22.214.171.124
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 1 explicit name AG02-BTEBB-over-GW02
I can force the tunnel to establish if I append the "verbose" keyword to the path option in the interface config (e.g. tunnel mpls traffic-eng path-option 1 explicit name AG02-BTEBB-over-GW02 verbose). This works as the router will attempt to build the interface without first checking the TE link database for a verified path. So the issue does not appear to be with the path itself, rather the presence of a verified path in the TE link database.
I'm happy to run debug commands, so long as I know what the impact will be (this is a live box and I must be aware of any potentially service-impacting debugging before issuing the relavent commands).
The box is a 7609 running IOS 12.2(33)SRD4
PTW-GW01#sh int Tunnel1222
Tunnel1222 is up, line protocol is down
Hardware is Tunnel
Interface is unnumbered. Using address of Loopback0 (126.96.36.199)
MTU 17888 bytes, BW 100 Kbit, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 188.8.131.52, destination 184.108.40.206
Tunnel protocol/transport Label Switching
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
It looks like 220.127.116.11 is IP reachable but that there is no valid path as far as MPLS TE is considered. This could be because some links in the path are not MPLS TE enabled. Please make sure that all the physical interfaces in the path are MPLS TE enabled ("mpls traffic-eng tunnels").
Harold Ritter Sr. Technical Leader CCIE 4168 (R&S, SP) email@example.com México móvil: +52 1 55 8312 4915 Cisco México Paseo de la Reforma 222 Piso 19 Cuauhtémoc, Juárez Ciudad de México, 06600 México
I've checked the interfaces and all are configured correctly with the mple traffic-eng tunnels command. The other tunnels that are up are using the same interconnect between GW01 and GW01.
Whats more, I also have MPLS tunnels from another device, CR01, which traverses GW02 and terminates on the same loopback on AG02 (18.104.22.168). If I check on GW02 I can also see the tunnel (using sh mpls traffic-eng tunnels role middle).
For some reason, and one that I cannot figure out, the GWs aren't seeing that loopback as a verified address within the TE link database. The verbatim keyword proves the link *will* work, so I now need to prove why this reachable IP, with other tunnels configured, will not work in this instance.
Any ideas how I see why the route isn't there? Is there a way to troubleshoot the TE link database?
I've looked at this previously and seen the same outputs, which is why I ran some of the debugging commands above to see why, when I have valid routes to the destination, they don't appear in the TE link database.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...