I have this situation:
PVST+_SWITCH ----- MST_REGION
MST consist of MST0(CST),MST1.MST2 with 20 swtiches
Problem started when I noticed flooding on switches in MST region. I also determined that the source of flooding is that every 35 seconds there are TCN in MST1. I was tracing source of TCN (via show spanning tree detail) and finaly found that source is PVST+_SWITCH ouside od MST region.
1) How switch outside MST region can influence TCN on MST1. Shouldn't MST interact with outside switches via MST0?
2) On PVST+ switch I cant find on either VLAN Topolgy change (there are 5 VLANs). Could it be some software bug on PVST+ switch that sends every 35 seconds TCN?
Also all ports on this switch has either portfast, or portfast trunk.
3) Since PVST+ runs 802.1d does it immeditly clear MAC-address table or it shortens age of mac entry by some factor?
thanks in advance,
1) You are right. However, when receiving a TCN from a particular vlan in PVST+, we can translate that to a topology change indication for the instance to which this vlan is mapped. That's an optimization. In fact, if this was a regular RSTP/STP bridge, we would indeed receive the TCN in instance 0 and we would have to propagate the indication to *every* instance in the MST region.
2) 35 seconds is the time during which the TC flag is asserted by the root bridge when a topology change notification (TCN) is received. So basically, it seems that you are continuously experiencing a topology change. You could trace the source of the TCN to outside of the region, couldn't you identify the port generating it eventually?
3) PVST+ reduces the aging time indeed. No immediate flush (that's RSTP/MST behavior).
1) Yes tt is regular RSTP/STP bridge (Catalyst 2960), but it seems I'm recieving TCN only in instance MST1. Sholud also this TCN be propagated in MST2 (no metter that problem is in VLAN which maps to MST1)?
2) Trace leads to PVST+_SWITCH, and I can't see any link flapping on that switch. Also all ports on that switch have portfastt configured
3) Do you maybe know how much PVST+ reduces aging time when TCN is experienced?
Just an question regarding this 35 seconds. It can be seen on root bridge in MST region that change occurs every 35 seconds, but the switch that sends this TCN is out of MST region(PVST+_SWITCH).
As I understood theory timer for topology change which is 35 seconds defines how long root bridge sends BPDU with TC bit set. Does it also define how frequenly PVST+ Switch can send TCN?
In theory is it possible to have more frequent MAC-table flushing doe to TCN than every 35 seconds?
Also since MST has different mechanism for TCN notofication comparing to PVST+ Is TCN flooded to all switches in MST region once it is injected by PVST+ or it have to reach root, and then root informs other bridges in MST region?
You don't restart a topology change while you're already in a topology change state. That's probably why you see this TCN every 35 seconds.
With STP, you don't flush mac addresses, you just age out faster (basically, only the flow that are not very active are impacted).
To be honest with you, I don't remember exactly the detail of the interaction between MST and PVST there. I guess that the TCN coming from the PVST side is simply tranlated into a TC in the MST region. There is no TCN frame in MST, and the root does not have to be notified. So basically, everything is done at the boundary STP/MST.
1) it is propagated to the instance to which the vlan is mapped. That's an optimization over propagating it everywhere.
2) Can't you see the origin of the TC on this switch (show span detail) ?
3) STP reduces the aging time to 15 seconds.
2) there is no TC on this switch so i suppose that it is some kind of software or hardware error.
And it is interesting that this switch has ROOT and ALT port toward MST region and TCN is sent only through ALT port.
I see on switch connected to root port that there is a lot of flapping. Although it is not as frequent as 35 seconds. Is it possible that one side can experience flapping and other don't.
I started debugging on PVST+_SWITCH and it shows every second:
STP: VLAN0001 sent Topology Change Notice on Gi0/2
But VLAN 1 is not used on any switch(PVST+ or MST). I know it is system VLAN and it can't be removed.
On root port (Gi0/1) there are ten other VLANs but only for VLAN 1 is sent TCN via Gi0/2. If there were root port flappings switch should send TCN for all VLANs isn't it (not just VLAN1)?
It seems it is still hardware or software error on PVST+_SWITCH.
That's an interesting find. Yes, in PVST+ the vlans are independent. The trick is that a TCN is a special STP message (again, it disappeared in RSTP and MST) that is sent on the root port and that should be acknowledged by the upstream designated bridge. So for example here, the PVST+ switch will keep sending a TCN to the MST switch until this latter acknowledges it (by setting the TCA bit in the BPDUs it sends). So here, the problem might be that the MST switch fails to send back this acknowledgment. Vlan 1 can be removed from the ports (not from the vlan database). However, when it's a matter of interacting between MST and PVST+, it's wise to keep it.
Can you check on the MST side what the switch is seeing in instance 0 (show span mst 0 detail), assuming that this TCN keeps being received.
Thanks and regards,
Actually I don't see the roles in there. I don't see a TCA received: it seems the flags field in the BPDU received on 0/2 is 00. It's been a while that I've not looked into the code and I don't understand why a BPDU that looks like an SSTP BPDU is then seen as an IEEE BPDUs on your debug. Anyway, just for the sake of the test, is it possible to disable g0/2 and see if the problem goes away? That would confirm we have to drill deeper in that direction.
problem dissaperas if Gi0/1 is in shutdown or Gi0/2. So it is enough to disable eather of the ports.
So TCN will be sent as long as ACK is not receiced from MST? But For every TCN sent there is one BPDU received from MST region (I supposed it has to be ack)
From what I see in the debug, this is not an ack. At that stage, it looks like you're hitting a software bug. I did not find a recent one, but my bug search skills are rusty;-) I would recommend you make sure you are running a recent version of the IOS and contact support if this does not help.