mpls traffic-eng reoptimization.
-
Guest
Re:mpls traffic-eng reoptimization.
Well yes and no. Because like I said in my previous post, you can load-share across the 2 tunnels so this way you don't have any wasted bandwidth. This is done with my configuration having "autoroute announce" in both tunnels.
-
Guest
Re:mpls traffic-eng reoptimization.
Has your question been answer sufficiently? If so, can you please vote and advise Author's question has been answered?Thanks.Joe.
-
Guest
Re:mpls traffic-eng reoptimization.
Okay so you asked two questions:#1. If you have 2nd path option configured and if there is a failure on 1st path option, you would like the 1st path option to remain in place (using FRR) and 2nd path option should not kick in? is that a correct understanding of your question?If yes, then I'd have to ask you a question in return - why then you have a second path option configured if you want the TE tunnel to continue using FRR path option ?What normally happens is that when the PLR detects the failure, it also sends an RSVP message to the head-end of the tunnel informing it about the failure in the path. This is why you normally would see that when FRR is in place for the 1st path option, you see tunnel stating "Change in resources detected: reroute pending" if you do a "show mpls traffic-eng tunnel" on the head-end.Now if the head-end has a 2nd path-option configured, it would switch to the 2nd path-option (as it is supposed to do) in a make-before-break fashion. If you dont want it, then remove the 2nd path-option
#2: Reoptimization timers - i dont think reoptimization timers will help you in achieving what i mentioned in part #1 because reoptimization is a scheduled event that has little to do with FRR and subsequent second path option kicking in.It would help you more when your failed 1st path recovers and traffic needs to be switched back to 1st path option.regardsUsman