Since this seems to be getting more and more complicated, I'd like to ask whether there's an option to migrate to a code that would support IP-FRR instead of TE-FRR please?
Just shooting in the dark is the fast-reroute enabled on the primary tunnels? (via auto-tunnel template) Or do you otherwise see that the primary tunnels are protected please? adam -----Original Message----- From: cisco-nsp [mailto:[email protected]] On Behalf Of Peter Rathlev Sent: Tuesday, October 22, 2013 12:42 AM To: dip Cc: cisco-nsp Subject: Re: [c-nsp] MPLS TE auto-tunnel and ISIS metric On Thu, 2013-10-17 at 22:03 -0600, dip wrote: > i agree in this case probably better option would be to use auto > tunnel mesh which should satisfy what you are looking for . Thank you Dip and Adam. Just the information I needed to make something work. :-) I have to define a tunnel destination ACL that only covers the immediate neighbors to get NHOP protection and nothing else, but that's okay with me. Traffic towards destinations that cross an LSR without mesh configuration is discarded with a "no label" reason, but that's probable by design. I'm a little puzzled now though. Failover times with FRR are not exactly better than with, au contraire. All the show commands look fine with both "primary:" and "repair:" paths in CEF and correct MPLS TE output but we're seeing around 1-2 seconds recovery time for a software forced crash on an intermediary device. The mesh tunnels are defined so that the path that breaks with the crash is protected. This is at best the same as the around 1 second we see with not FRR and the more tests we do (thank $deity the Sup2T reloads quickly!) the more it looks like this FRR configuration makes things worse instead of better. Is the Sup2T maybe not suited for this kind of FRR? Or should I try looking more into making it work better? -- Peter _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
