Can you please clarify my understanding of MPLS-TE path-options and how the head-end fails over to less-preferred paths when using inter-area tunnels? Assuming I have a working inter-area tunnel with multiple explicit paths defined:
The tunnel head-end will switch from path-option 1 to path-option 2 based on RSVP events only, eg. tunnel preemption or lack of bandwidth somewhere along path 1.
A node or link failure along path 1 will not trigger the switch to path-option 2 it will drop the tunnel instead.
Is this the expected behaviour? Is there another way to trigger the failover to the second path?
To clarify when you mention a node failure is the node in the same area as the headend or a remote area?
When you contrast preemption vs node fail you say switch paths vs drop paths. Can you explain exactly what you mean here?
It's logical that you would tear down a tunnel if a node failed and try to signal again. I think you are referring to when preemption occurs the tunnel has some time to signal the new path and switch. Ultimately if the new path is not found eventually the same outcome will be reached.
Actually preemption is tunable between hard and soft which are tear down and reoptimize respectively.
I've got this working now by changing my explicit-paths to use interface addresses instead of RID's and getting RSVP Hellos working properly. I'm testing in Dynamips and the RSVP Hellos weren't triggering the reroute until I raised the interval and misses threshold.
Introduction: The "external-out enable" command is available for
configuration under the "router ospf process" in case of the IOS-XR
operating system. This command basically enables advertisement of
intra-area routes on the device as external routes in th...
IntroductionIn this article we'll discuss how to troubleshoot packet
loss in the asr9000 and specifically understanding the NP drop counters,
what they mean and what you can do to mitigate them. This document will
be an ongoing effort to improve troublesh...