[c-nsp] MPLS TE auto-tunnel and ISIS metric

Peter Rathlev peter at rathlev.dk
Mon Oct 21 18:41:44 EDT 2013

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

Is the Sup2T maybe not suited for this kind of FRR? Or should I try
looking more into making it work better?


More information about the cisco-nsp mailing list