I think we have a problem with our switch network. Every node on the network is receiving more then one stp message in a two second period. I have tried setup a switch to be the root for all vlans, and then set the hello time to 10 sec. Then we will still see two messages coming in every 10 sec. Is this a problem? If so, what is the most likely the problem?
The network has all type of switches from 4006's to 3750's.
Thanks for your time and help,
Yes. I have wireshark on three different PC's, in the same vlan on different switches. All three systems see two different sets of messages. Because when I set the root's hello time to 10 sec, I will see two different message come in every 10 sec.
This is happening on 3 different vlans.
If you have captured the BPDUs in the same vlans, then we should be able to quickly see what kind of problem this is.
- are they both "IEEE" BPDUs. I'm just think of a corner case with Cisco PVST. Vlan 1 BPDUs are sent twice, to two different mac address. That's unlikely to be your case if you are not trunking to your pc...
- who are the bridges sending the BPDUs -> you should see this in the BPDU itself, as they include the sender bridge ID. If they are coming from two different bridges, it's likely that one of those bridges is not receiving the BPDUs from the other (will need further investigation). If both BPDUs are coming from the same bridge (and then likely to be identical), then it's probably a bug.
Both message are the same. The Bridge ID is the same in both messages. The BPDU payload is exactly the same for both messages.
161 44.065997 Cisco_4d:e7:7f Spanning-tree-(for-bridges)_00 STP Conf. Root = 4257/00:1c:f9:f3:0e:00 Cost = 4 Port = 0x8070
164 44.751895 Cisco_4d:e7:7f Spanning-tree-(for-bridges)_00 STP Conf. Root = 4257/00:1c:f9:f3:0e:00 Cost = 4 Port = 0x8070
Looks like a bug to me (to be identified).
- wast of cpu utilization
- probably stricter rate limiting of the information can send out (STP can only send a certain amount of BPDUs per seconds, if it's wasting half of its quota to send duplicate information, it could potentially delay the propagation of useful information -> less likely to be an issue with STP than RSTP).
No my statement was not about RSTP being more buggy than STP;-)
I just meant that the impact of this issue will most likely be negligible with STP because of its convergence time. RSTP is more likely to use its "quota" of BPDU transmission than STP. Even with RSTP, you would need to have a network with lots of redundant links so that this issue has an impact on convergence time.
Similarly, you would need to have a network with lots of vlan-ports in order for this issue to have an impact on the CPU of your devices.
So basically, you don't have to worry about this problem but it would be nice if it was fixed (at least for the principle).
It's just a matter of how many additional BPDUs will be generated as a result of this.
If all your bridges were showing this behavior for all the vlans, you would basically double the STP load. It might not be an issue at all. If you have 200 vlans on 1000 ports and each of them is sending double amount of BPDUs, it's definitely a problem.
BTW, now, in order to track down a little bit more the problem, are you running RSTP/MST or STP?
With STP, BPDUs are originated from the root bridge and then relayed down the tree. So the duplication is very likely to be cause by the root bridge.
With RSTP/MST, BPDUs are sent periodically on all designated ports. Then, the problem would likely be on the bridge that sent the BPDU (identified by the sender bridge ID in the BPDU).
If you can identify this bridge, it will be easier to find a corresponding bug ID based on its model and the release it's running.
have you configured any form of SPAN to the port where the PCs with the sniffer stay ?
because with some SPAN setups you get every packet twice on the protocol analyzer.
If so your problem wouldn't be a real issue but an effect of the monitor session setup.
If instead you have just connected the PC to an access port in vlan x the problem is real.
Hope to help