cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1325
Views
14
Helpful
11
Replies

Automesh Tunnel would not UP

networknoobs
Level 1
Level 1

Hi, since I'm exploring the possibilities of setting up an automesh tunnels, I re-use one of the scenario I found in CCIE SP practise lab and enable automesh configuration.

Sad to say that the tunnel was created between 2 PE routers but it was not up, initially i found out RSVP and LSP tunnel was not enabled, then I proceed to enable it but still the tunnel would not UP.

Any idea, I attach both PE configuration here, thanks

11 Replies 11

Harold Ritter
Cisco Employee
Cisco Employee

Creed,

Try configuring "mpls traffic-eng tunnels" on the interface on which you want the tunnel to be signaled and "mpls traffic-eng area 0" under the router ospf process. This should fix the issue.

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

Hi, I've configured "mpls traffic-eng area 0" under both PE router (R3 and R4), and all the interfaces in these two routers that connected to the P routers also configured with "mpls traffic-eng tunnels".

But the tunnels just would not up. Any ideas?

R3#show mpls traffic-eng tunnels destination 150.1.4.4

Name: R3_t1000 (Tunnel1000) Destination: 150.1.4.4

Status:

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

path option 1, type dynamic

Config Parameters:

Bandwidth: 0 kbps (Global) Priority: 1 1 Affinity: 0x0/0xFFFF

Metric Type: TE (default)

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

auto-bw: (86400/86143) 0 Bandwidth Requested: 0

Samples Missed 0: Samples Collected 0

History:

Tunnel:

Time since created: 48 minutes, 42 seconds

Number of LSP IDs (Tun_Instances) used: 104

Path Option 1:

Last Error: PCALC:: No path to destination, 150.1.4.4

R3#

I've seen some error of "No path to destination, 150.1.4.4". But a ping to 150.1.4.4 is alive.

Any ideas?

Hello Creed,

Last Error: PCALC:: No path to destination, 150.1.4.4

it means there are not enough resources to setup it

try to specify bandwidth in the rsvp command on the physical interfaces

see

auto-bw: (86400/86143)

And also you need to check your IOS release and platform to see if the feature is supported.

Edit:

are you using 64kbps serial interfaces in the lab setup ?

use

ip rsvp bandwidth 64000 64000

Hope to help

Giuseppe

Creed,

I still do not see the command "mpls traffic-eng area 0" under the router ospf process in the attached files ans "mpls traffic-eng tunnel" under the different interfaces. You also need to make sure that the router(s) in between R3 and R4 are configured appropriately.

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

Creed,

To make sure whether the issue is due to misconfiguration or lack of resource, just use the following command:

show mpls traffic-eng topology path dest 150.1.4.4 on R3 and the other way around on R4 to see if the CSPF can find a path without any restriction between the two PEs.

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

Hi hritter,

Guess it driving me nuts, I performed the commands as you requested and it stated "No matching path to destination".

R4#sh mpls traffic-eng topology path dest 150.1.3.3

Query Parameters:

Destination: 150.1.3.3

Bandwidth: 0

Priorities: 0 (setup), 0 (hold)

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

Query Results:

% No matching path to destination, 150.1.3.3

R4#

What I did was, all interface (PE-P, P-P, P-PE) enable with tag-switching and mpls traffic-eng tunnels, OSPF processes configured with TE supported, then create Auto-Template on both PE and hoping it'll works...ping to both IP was alive but when perform the show mpls topology path it returned with "No matching path to dest".

So I guess that wouldn't be the RSVP then, any ideas? Meanwhile I'll try some other steps see whether it helps. Thanks

Silly me, I forgot to enable OSPF for TE support on the P routers, now the tunnels is up, the first tunnel is 1000, and when I performed "sh run int tunnel 1000" and there's no configuration, so I assume it use the default configured in the Auto-Template.

Now tunnels are up, so 1 question, the auto-mesh tunnels are where all my traffics would be routed into, if I create some additional Tunnels with explicit-path among few PE, can I selectively route traffic into the additional tunnels, while the remaining traffics get routed into the auto-mesh tunnels?

!

interface Auto-Template1

ip unnumbered Loopback0

no ip directed-broadcast

tunnel destination mesh-group 10

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 1 1

tunnel mpls traffic-eng path-option 1 dynamic

tunnel mpls traffic-eng fast-reroute

tunnel mpls traffic-eng auto-bw

tunnel mpls traffic-eng exp default

end

R3#sh run int tunnel100

Building configuration...

Current configuration : 332 bytes

!

interface Tunnel100

ip unnumbered Loopback0

no ip directed-broadcast

tunnel destination 150.1.4.4

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 1 1

tunnel mpls traffic-eng path-option 1 dynamic

tunnel mpls traffic-eng auto-bw

tunnel mpls traffic-eng exp 5

end

With the above configuration, would it works? It means traffic matches EXP5 would get routed into the "Tunnel 100" which is manually created, then the rest of the traffics would go into "Auto-Template" which means the auto-mesh tunnels.

Since the automesh tunnels configuration is referring to the one we configured in auto-template, is it possible that I assign an explicit path to one of the automatically created tunnel? what if the tunnel goes down and back up again, would the explicit configuration in the automesh tunnel still valid?

Lots of questions in my mind, does automesh tunnel are with Fast-reroute and with path-protection? If the automesh tunnel went down, the time for the fail-over would it be fast like the manually created tunnel?

Thanks

Creed,

Here are a few answers:

1. Although I have never tried it myself, Class Based Tunnel Selection (CBTS) should work in this context.

2.You won't be able to use an explicit path on the template as this template is used for all dynamically created tunnels.

3. You can use auto-mesh in conjunction with FRR.

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

Hi, guess so, I've tried some ping traffic in Dynamips and saw the manual tunnels have packets output rapidly.

I was thinking even with auto-mesh in conjunction with FRR, but the document stated automesh won't works in device that runs SSO and NSF, so I guess I'll have to put a stop @ it since all my devices came with redundant route-processors.

What's the additional advantage the automesh brings compare to the normal LSP? It still dynamically created and does not allow explicit path to be configured, I'm scratching my head now though.

Nevertheless you've been really great help to point out the mistake of my configuration, really appreciate that.

Right now off my mind I think that the advantage of the automesh tunnel would be the one-hop seen by the traceroute if i disable the "mpls ttl thingy".

And how to configure FRR and path protection for the Automesh, this is just out of curiosity though, as the automesh document I downloaded from Cisco does not really stated that.

Thanks man

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: