Switches can have rate-limiters (aka storm-control measures) to control
broadcast, multicast and unknown-unicast. BPDU's are layer-2 multicast. Your
issues sounds like you're losing BPDUs.
Try "debug spanning-tree root" to see if it's causing root changes.
If you are running a lot of VLANs worth of BPDUs, you might be bumping into a
limit somewhere on your network or a peer's.
It's because of problems like this, that STP shouldn't cross
administrative-domains.
On 18 Dec 2014, at 4:09 pm, CiscoNSP List wrote:
>>
>> This seems like..."interesting" advice. At that point, you might as
>> well just turn spanning-tree off. This is somewhere around cutting off
>> your foot to stop your toe bleeding.
>>
>> That said: This seems like "design problem" not so much "gear
>> problem". Why are you running spanning tree with devices you don't
>> administratively control? And if you do control them, why the hell are
>> you seeing TCNs so often if your network is stable?
>
>
> We dont control the device this port is connected to, and when the port was
> configured, bpdufilter was not enabled(12months ago)TCN's have only
> recently been "arriving" on this port.
>
>
>>
>> -Blake
>>
>> On Wed, Dec 17, 2014 at 8:35 PM, CiscoNSP List
>> wrote:
>>> Another update on thisTAC are recommending that we enable bpdufilter on
>>> "all" ports, as any port that is root and receives a TCN will cause an
>>> "outage"we have bpdufilter enabled on customer facing ports(to other
>>> switches), but some of our legacy equipment/connections would be missing
>>> this command Im sureI find it incredibly difficult to believe that we
>>> have not been hit by this in the past, if this is "expected" behaviour on
>>> any switch.
>>>
>>> Would love to hear from any switching experts on TAC's recommendation, and
>>> have we just been "lucky" not to be impacted by this in the past?
>>>
>>>
>>> Cheers.
>>>
>>> From: cisconsp_l...@hotmail.com
>>> To: peteli...@templin.org; mrantoinemonn...@gmail.com; luky...@hotmail.com;
>>> cisco-nsp@puck.nether.net
>>> Subject: RE: [c-nsp] TCN's - Causing brief outages on ASR1K
>>> Date: Tue, 16 Dec 2014 10:51:07 +1100
>>>
>>>
>>>
>>>
>>> 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 ASRagain, 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: peteli...@templin.org
To: mrantoinemonn...@gmail.com; luky...@hotmail.com;
cisconsp_l...@hotmail.com; cisco-nsp@puck.nether.net
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 Trib
