* Switch 111 & Switch 444 are running either STP or RSTP.
* A broadcast is going on
* SW 111 is the root bridge
* All ports have the same port priority
* Port ID = Port number (port number is labelled in the figure)
What happens when we connect the two hubs together?
I think before establishing such a connection, all ports are in forwarding state. After establishing the connection, port 1 of SW 444 becomes root port and port 2 of SW 444 should go to discarding/blocking state.
But at the time of connection establishment between the hubs, a loop is created. It is resolved immediately once BPDUs are sent/received. Since a broadcast is going on, it creates a broadcast storm at the time of connection establishment due to the temporary loop. BPDUs may suffer collisions and they may be lost which in turn delays the network convergence. If the storm is too heavy it may take several minutes for the network to converge.
I am not sure whether my observation is right or not. Please comment on this.
If my observation is right, how can we prevent such a scenario?
That's why STP tries to avoid loop at any cost, even the slightest temporary one. Of course, BPDUs are supposed to be treated with the highest priority, so even on congested segments, they should evenutally go through and block the port (a single BPDU received will fix the problem). But there are other issues associated with bridging loop. For instance, many bridges are able to bridge in hardware while running STP (the control protocol) in software. If a bridging loop is occurring, traffic will be forwarded wire rate around this loop. If there is any kind of traffic that is listened to by the bridge, it could just kill its CPU. In that case, STP would not run any more while the traffic happily loops around for ever. Just think of a bridge that has an ip management interface. If an ARP packet is looping, it will hit the CPU big time...
I have an additional remark to make though. The scenario you describe is explicitly forbidden in the spec. I mean that it is a known case and STP is expected to fail (at least temporarily) in these conditions. There are other similar assumptions made by STP. For instance if you lose three BPDUs, the link is considered as down (and it'd rather be down for user traffic too;-)).
There is no real work around to this situation. If your bridges are powerfull enough to sustain the hit of a temporary bridging loop, the network should stabilize as soon as a BPDU is received. There is the port security feature (that restrict the number of mac addresses that can be learnt on a port) that can be configured on access ports and sometimes help in order to discover bridging loops... else, I can't think of anything efficient except avoiding doing this.
In my case, switching is done in hardware (switching chip) and STP is running in software (in Management CPU running uClinux). If the switch receives a broadcast packet, it's forwarded to management CPU also(to an integrated MAC in the CPU). During a broadcast storm, STP does get control, but the CPU buffer overflows and BPDUs are lost.
* The CPU MAC device driver treats BPDUs just like other frames, so what do you think of a device driver modification? Does it work?
There is an option in the switching chip to configure the egress rate of CPU port (switch port connected to the integrated MAC). If the data rate exceeds the configured value, only high priority frames (eg. BPDUs) are allowed to egress the CPU port.
* Is it a good work around? If yes, how can I find the egress rate upper limit? (Both CPU port & integrated MAC are capable of transferring data @ 100Mbps)
* I had gone through the IEEE spec and couldn't find the portion which specifies that the scenario under consideration is forbidden. If possible please specify the section number.
Hey, I'm working for Cisco, I should not help improving your implementation;-)
Yes, this buffer overflow is the kind of problem I was referring to when I was mentioning that the control plane could die as a result of a temporary bridging loop while the traffic is still forwarded (maintaining the problem in the network).
Indeed, you should treat the BPDUs as special on your ingress ports. Cisco has a special "BPDU class" for that type of packets. And indeed, you should also make sure that you have one way or another to prioritize the BPDU transmission on your overloaded ports.
The problem you are experienced is quoted several time in the spec. Quickly searching inside 802.1D-2004 using the keyword "hub" and "repeater" I found annex K.1 and a note in 17.3 "RSTP overview". Note that this problem is not specific to RSTP or MST. It is a basic assumption in STP since day one and should be more or less explicitly in every spec.
Hi everyone, I would like to thank you in advance for any help you can provide a newcomer like myself!
Im studying the 100-105 book by Odom and am currently on the topic of Port security. I purchased a used 2960 and I'm trying to follow a...
While deploying a number of 18xx/2802/3802 model access points (APs), which run AP-COS as their operating platform. It can be observed on some occasions that while many of their access points were able to join the fabric WLC withou...
I am going to design and build an LAN network under a tunnel underground with long distance between the switches.
I will have 2 Catalyst switches and 8 Industrial IE3000, and they will be connected with fiber.
For now I am planning on use Layer-2 s...