MPLS TE Tunnels - How to prevent dynamic path re-route

[shukipeles]

Using Cisco 7613 as a PE we create a MPLS traffic-eng tunnel with one excplicit path-option with strict hops.

We do not configure any path-option with dynamic path calculation.

We expect that upon a link failure of one of the path links, the tunnel operational status will become "down".

What happens:

When the link failed, a new path is calculated by the CSPF, a new LSP is built according to the new path and the tunnel oper status is "up" again.

Why this happens and how to prevent the creation of the new dynamic path?

[Peter Paluch]

Hello Yehoshua,

To my best knowledge, the hops indicated in the ip explicit-path list are considered as loose source routing hops. OSPF is used to find shortest paths between these individual entries and then a TE LSP is built over the entire path you have specified. If the topology changes, OSPF recalculates the new paths connecting these explicit transit points, thereby possibly changing the route your TE LSP takes.

I haven't tested it myself but there are two keywords to the tunnel mpls traffic-eng path-option that can potentially be used to prevent this from happening. They are verbatim and lockdown. The first keyword should prevent the router from checking if the path is valid, the second should prevent the router from re-building the TE LSP once it has been set up. Would you mind trying them out?

Best regards,

Peter

[shukipeles]

Hello Peter

Thanks for your answer.

We have tried them (verbatim and/or lockdown) both.

It have not solved the problem

Best Regards

Yehoshua

[Nagendra Kumar Nainar]

Hi Yehoshua,

With just one path-option (which is explicit-path) and if it fails, TE tunnel should come down. Can you share your tunnel confg?.

Regards,

Nagendra

[Ashish Panda]

Are you requesting FRR at head end

can you share your tunnel headend configuration and IOS version

[shukipeles]

Hello Peter Nagendra and Ashish

Thank you all for your replies.

The tunnel is not requesting FRR.

We have found the reason for the re-route behavior as follows:

The ip explicit path that we have defined has only addresses of egress ports. To generate a real strict path we need to specify the address of ingress ports as well. Example: assume we have the following topology:

10.87.144.1<>ge1/1 (10.10.10.1)---------------------------------------------------------------------------(10.10.10.2)ge2/1<>10.87.144.2

10.87.144.1<>ge1/2 (11.11.11.1)---------------------------------------------------------------------------(11.11.11.2)ge2/2<>10.87.144.2

When we have created a tunnel from 10.87.144.1 to 10.87.144.2 with explicit path that includes only the address 10.10.10.1, the failure of link 10.10.10.1-10.10.10.2 cause the tunnel to re-route to link 11.11.11.1-11.11.11.2.

However, when the explicit path includes both addresses 10.10.10.1 and 10.10.10.2, no re-route occurs.

Best Regards

Yehoshua