We have configured the Tunnel-TE with explicit path options 1 & 2. When we generate a failure scenario in primary path, the traffic switches over to secondary immediately but on the failure restoration, the primary tunnel does not preempt. On further investigation, we found that default reoptimization time for TE Tunnel is 60 mins which is vey high for us.
The tunnel configuration is as below.
ipv4 unnumbered Loopback10
path-option 1 explicit name PATH_Pri
path-option 2 explicit name PATH_Sec
explicit-path name PATH_Pri
index 10 next-address strict ipv4 unicast 10.220.37.82
explicit-path name PATH_Sec
index 10 next-address strict ipv4 unicast 10.220.37.6
index 20 next-address strict ipv4 unicast 10.220.37.86
index 30 next-address strict ipv4 unicast 10.220.37.9
While exploring through internet, I came across a forum which mentions 3 options for reoptimization but it is for IOS. The wording goes like...
I would like to know that
1. Is there any specific requirement behind keeping the default (periodic) reoptimization timer to 60 mins?
2. I could not find the options for configuring 'Event Driven reoptimization' in IOS XR. How to get it?
3. What are best practice reoptimization timer to be used in the network?
P.S: We are running IOS-XR 4.3.2 on ASR 9000.
The same commands are similar for IOS-XR. Here is the command references:
after-frr delay: 0
cleanup delay: 20
installation delay: 20
RP/0/RSP0/CPU0:ASR9001(config)#mpls traffic-eng reoptimize events ?
link-up Trigger reoptimization on topology link-up events
I hope this will be useful
gfichera You are the man. Your reply works man. The only set back is that re-optimization is triggered by the RSVP (in your IGP) at the headend. Of which, this can take some time(seconds) depending on fast your IGP convergence to inform the headend that,"Oh man, that primary LSP that was down is now up, lets re-optimize and use it."