Thanks for all the replies. Just an update to this - No issues for 4 days (with spanning-tree portfast trunk enabled on trunk port from 4948 -> ASR), then this morning, another TCN was received on an AGG port(On the 4948) to a carrier (The TCN's (Since we are now looking for them)) seem to only arrive on 2 ports...both being carrier AGG ports, with multiple vlans, and to the same carrier.....we do not have any visibility into the carriers network
This TCN did also cause OSPF+LDP flaps on the ASR....again, only for a ~5seconds It's "RRR"(So highest priority) with TAC, but we are still in the same place we were over a week ago.....as you can imagine, customers are not impressed! > Date: Mon, 15 Dec 2014 09:04:43 -0800 > From: [email protected] > To: [email protected]; [email protected]; > [email protected]; [email protected] > Subject: Re: [c-nsp] TCN's - Causing brief outages on ASR1K > > You can run RSTP or MST all day long on a switch to get rapid STP > convergence, but you'll only gain the rapidness of RSTP/MST on ports > where they neighbor is actually participating in the correct STP > variant. Routers don't participate in STP, so the 4948 has to treat > those ports as legacy STP. Whenever there's a root placement event, the > 4948 has to block the port until the STP process/timers can confirm that > there's no superior root bridge hiding inside or behind the router. > > Now, if there's a small enough event going on that SHOULDN'T be causing > a root placement event but IS, that could be a bug in the 4948 code. > > However, I'd say very strongly that you SHOULD have portfast [trunk] > towards any devices that aren't participating in the STP process, unless > those devices are capable of creating an L2 loop. > > On 12/15/2014 1:18 AM, Antoine Monnier wrote: > > 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 <[email protected]> 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 [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/ > > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
