[c-nsp] TCN's - Causing brief outages on ASR1K

Antoine Monnier mrantoinemonnier at gmail.com
Mon Dec 15 04:18:04 EST 2014

A TCN will cause all the learned MAC addresses to be flushed by the
switiches, but it will not "block" traffic. So the TCN on its own should
not be the cause of OSPF and LDP flaps.

Is your switch running out of space for all the learned MAC addresses?

 I dont see how enabling "portfast trunk" would help in that scenario (it
should only change the behavior if an interface flaps).
Has the source of TCN being identified? Configuring ports as "portfast"
will lower the probability of generating TCN, that may be why they advised
you to do this. However applying to a port that is stable (no interface
flap) is not really going to help for this specific problem.

On Mon, Dec 15, 2014 at 9:06 AM, Lukas Tribus <luky-37 at hotmail.com> wrote:
> > Is it expected behaviour for a TCN to cause a flap on an ASR...We have
> many other POP's with switches
> > 4948's/4500's etc(trunk)->ASR+7200's and do not have spanning-tree
> portfast trunk enabled, and
> > they do not experience any flaps?
> This has nothing todo with the ASR1k at all. Its expected behavior that
> STP on the switch will block traffic
> when there's a reconvergence, especially when malconfigured (like not
> using portfast on
> router or host connected links).
> Why this doesn't happen on your 7k2 we can't tell, there are a lot of
> moving parts that only you know
> (for example whether you are using pvst, rapid-pvst or mst and where
> exactly the root of those particular
> vlans is).
> Regards,
> Lukas
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

More information about the cisco-nsp mailing list