Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

MPLS traffic-eng tunnel down

Hi all,

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:

interface Tunnel1222

description GW01-GW02-AG02-link2

ip unnumbered Loopback0

tunnel destination 1.1.1.1

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng path-option 1 explicit name AG02-BTEBB-over-GW02

tunnel mpls traffic-eng record-route

end

When I check the down tunnels:

Name: GW01-GW02-AG02-link2          (Tunnel1222) Destination: 1.1.1.1

  Status:

    Admin: up         Oper: down   Path: not valid   Signalling: Down

    path option 1, type explicit AG02-BTEBB-over-GW02

  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

  History:

    Tunnel:

      Time since created: 3 days, 23 hours, 56 minutes

      Time since path change: 3 days, 18 hours, 39 minutes

      Number of LSP IDs (Tun_Instances) used: 1889

    Prior LSP:

      ID: path option 1 [616]

      Removal Trigger: configuration changed

      Last Error: PCALC:: Destination IP address, 1.1.1.1, not found

But if I check the MPLS forwarding table on GW01 and GW02:

PTW-GW01#sh mpls forwarding-table 1.1.1.1 255.255.255.255

Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop

Label  Label or VC   or Tunnel Id      Switched      interface

492    Pop Label     1.1.1.1/32 16971520      Te8/7.312  2.2.2.2

PTW-GW02#sh mpls forwarding-table 1.1.1.1 255.255.255.255

Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop

Label  Label or VC   or Tunnel Id      Switched      interface

615    Pop Label     1.1.1.1/32 0             Te8/7.312  4.4.4.4

Additionally:

PTW-GW01#sh ip explicit-paths name AG02-BTEBB-over-GW02

PATH AG02-BTEBB-over-GW02 (strict source route, path complete, generation 199)

    1: next-address 3.3.3.3

    2: next-address 4.4.4.4

PTW-GW01:

router ospf 6871

  mpls ldp sync

  mpls traffic-eng router-id Loopback0

  mpls traffic-eng area 0

PTW-AG02#sh conf virt btebb | b router ospf

router ospf 6871

router-id 1.1.1.1

maximum-paths 2  

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

  Description: GW01-GW02-AG02-link2

  Interface is unnumbered. Using address of Loopback0 (5.5.5.5)

  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 5.5.5.5, destination 1.1.1.1

  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

  Queueing strategy: fifo

  Output queue: 0/0 (size/max)

  5 minute input rate 0 bits/sec, 0 packets/sec

  5 minute output rate 0 bits/sec, 0 packets/sec

  L2 Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes

  L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast

  L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes

     0 packets input, 0 bytes, 0 no buffer

     Received 0 broadcasts (0 IP multicasts)

     0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

     0 packets output, 0 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

     0 output buffer failures, 0 output buffers swapped out

There is no additional information contained within the logs, other than the admin status of the interface (here I have issued the shut/no shut commands):

Sep 24 09:59:11: %PARSER-5-CFGLOG_LOGGEDCMD: User:playton  logged command:interface Tunnel1222

Sep 24 09:59:15: %LINK-5-CHANGED: Interface Tunnel1222, changed state to administratively down

Sep 24 09:59:17: %LINK-3-UPDOWN: Interface Tunnel1222, changed state to up

Everyone's tags (3)
5 REPLIES
New Member

MPLS traffic-eng tunnel down

I've done some more troubleshooting this morning, and the output from the debugging shows the error:

Sep 25 09:45:03: TE-PCALC_PATH: get_path:Dst ip addr 1.1.1.1 (ospf 6871  area 0) not found

However, there is a route:

O        1.1.1.1/32

           [110/101] via 2.2.2.2, 00:47:33, TenGigabitEthernet8/7.312

And if I check the LDP neighbor and the mpls forwarding-table:

PTW-GW01#sh mpls ldp neighbor 1.1.1.1 det

    Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 5.5.5.5:0

TCP connection: 1.1.1.1.1203 - 5.5.5.5.646; MD5 on

Password: not required, neighbor, in use

State: Oper; Msgs sent/rcvd: 8510/20901; Downstream; Last TIB rev sent 6055

Up time: 4d19h; UID: 83; Peer Id 9;

LDP discovery sources:

  TenGigabitEthernet8/7.312; Src IP addr: 2.2.2.2

    holdtime: 15000 ms, hello interval: 5000 ms

        Addresses bound to peer LDP Ident:

          2.2.2.2     1.1.1.1  4.4.4.4

Peer holdtime: 180000 ms; KA interval: 60000 ms; Peer state: estab

PTW-GW01#sh mpls forwarding-table 1.1.1.1 255.255.255.255

Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop

Label  Label or VC   or Tunnel Id      Switched      interface

492    Pop Label     1.1.1.1/32 20480537      Te8/7.312  2.2.2.2

All devices are using their Lo0 as the router-id for mpls under the ASN. And are using area 0:

PTW-GW01#

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

PTW-GW02#

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

PTE-AG02#

mpls traffic-eng router-id loopback0

mpls traffic-eng area 0.0.0.0

And Lo0 is the destination for the tunnels, and the address that the debug is saying is not found.

Cisco Employee

Re: MPLS traffic-eng tunnel down

Hi Phillip,

It looks like 1.1.1.1 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").

Regards

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.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
New Member

MPLS traffic-eng tunnel down

Thanks Harold,

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 (1.1.1.1). 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?

Cisco Employee

MPLS traffic-eng tunnel down

Hi Phillip,

Can you post the output for the following commands:

sh mpls traffic-eng topology path destination 1.1.1.1

sh mpls traffic-eng topology 1.1.1.1

If you change the explicit path to a dynamic, does the tunnel come up?

Regards

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.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
New Member

MPLS traffic-eng tunnel down

HI Harold,

Sorry for the delayed response, I had the cheek to take a couple of days leave!

When I look at the topology I see the following:

PTW-GW01#sh mpls traffic-eng topology path destination 1.1.1.1

Query Parameters:

  Destination: 1.1.1.1

    Bandwidth: 0

   Priorities: 0 (setup), 0 (hold)

     Affinity: 0x0 (value), 0xFFFFFFFF (mask)

Query Results:

% No matching path to destination, 1.1.1.1

PTW-GW01#

PTW-GW01#sh mpls traffic-eng topology 1.1.1.1

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.

1166
Views
0
Helpful
5
Replies
CreatePlease login to create content