Last night i had a bad day. STP loop occur in one of core switch.
connection is like that
core switch -> HUB -> hub
between this hub to hub two cables are connected. which cause loop. I just wondering why this port didn't go to block state. though i have enabled portfast disable on the port.
Hi,When you have two connections between the hubs, whatever traffic sent by the core switch will again seen by the core switch.
1) MAC address table on core switch will be corrupted.traffic gets multiplied
2) traffic will be blackholed due to incorrect mac learning.i think that is what would have happened.
kindly clarify on few things:-
--> Is portfast enabled on the switch interface connected to HUB ?
--> How many ports of switch are connected to same HUB ?
Well think about it for a second.
The Core Switch will run an STP Instance... (possibly more than one if using PVST.
The Core will see any traffic it has sent over the link.. (Not good)
Hubs DO NOT run STP. Infact Hubs don't RUN anything, they are repeaters.
So what you have is the Core sending frames to a Node on the last hub.
The data leaves the Core accross one Ethernet link. The First Hub repeats the data out of BOTH ports connected to the second hub.
The Node, receives it's data, but the hubs are repeaters, and so repete the signal back out of the 2 ports connected to the 1st hub. The 1st hub, repeats the signal back to the core.
This is probably whats happening. You'll want to replace those hubs with Switches my freind in order to run R/STP
That is what I was trying to clarify if Hub is connected multiple switch ports with portfast enable then we can talk about STP loop.
otherwise what you are saying the jist of the problem.
Yes, from the original post it's not made clear...
It seems a little bit of an odd design too.
Why not just plug the hubs into the core??
We'll have to await clarification I think.
PS. It didn't drop into blocking state, as there was no switching loop on the Core. It would be the the job of the switch, connected to the core (in your topology, hub 1, where it a switch), that blocks 1 port to the 2nd Hub. The Core, as far as it's concerned has nothing to block.. :)
portfast disabled on the port
coreswitch is the root of STP instance.
user connected formed his own connecting extending hub to hub. by mistake he connected two cable between hub to hub.
i discovered frequently flapped port and i disabled it but i want to how to over come this failure. this could happen future.
how to avoid
"how to avoid"?
Well your using hubs, so there is not really a great deal you can do.
Short of swapping the hubs to switches your kinda at a loss really. You could lock down the Core switch port to only the MAC Addresses of the PC's connected... (a Long and labourious task).
Even that would not stop people doing this exact same thing, it would just switch the port to errdisable when a MAC Address NOT on the list plugs in.
At least with switches you could disable the unused switch ports, AND run R/STP... that would solve your problem for good.
At least then when a user does this, the layer 2 switch handles STP, and the core remain unaffected. (Apart from the TCN etc, and resulting BPDU.s)
To overcome this failure you have to manually remove the loop between hubs and problem created by loop between hubs is already described by Matt.
All you can do is the play around "errdisable detect" command set to automatically disable the port in case of link-flap or loopback error.
How to avoid,
1) please enable portfast since there are are no other swicthes connected to the hub.
Enable BPDU filter/guard also.
2)If you expect this kind of manual errors in future, consider using port security with the set of mac addresses of the pcs connected to the hub.when there is a violation you can put the port down.
I agree with the above solution with a slight exception: it's just bpduguard that you want to configure on this port, not bpdufilter.
The switch should be able to block its port because it will receive back its own BPDU, looped by the hubs. The loop will still carry on between the hubs, but it will be isolated from the rest of the network by the switch.
The problem is that the CPU of the switch can bit hit badly if its own BPDUs are sent back to it at a very high rate (those BPDUs are looping "wire rate" on the hub). In that case, data traffic will be blocked, but the control traffic hitting the CPU could kill the switch-> in this situation, bpduguard should save the day as it should err-disable the port (you can have the port recover automatically after a while).
Port security is a nice option, but it will only help if the loop is going around two switched ports, generating a lot of mac move. In this particular case, the number of mac addresses seen by the switch is constant.
Portfast+BPDUgaurd(minus BPDU filter) will work.
As its a case of physical loop so I would suggest not to set any option of auto recover from errdisable state.
As manual intervention is required to remove the loop between hubs so better to keep the switch port disabled until unless somebody does shut- no shut.
There is no loop in the topology, as far as that switch is concerned.
The loop is further "downstream".
It's not like the Switch see's it's own BPDU comming in on another port, so it can't move the port to blocking state.
Instead it is recieving them on the same port it sent them on....
As far as the STP Process is concerned all is well.
What is STP to do.....??
That Port is NOT part of a switching loop as far as it's concerned, yet it see's it own BDPUs come back???? Is it to move that Port to blocking state? OR as it's NOT actually a part of the loop, to leave it in forwarding mode???
The correct Operation of STP States that the port should remain forwarding frames, so that is the action it takes.
Like we have been saying you need switches for STP to start moving ports to blocking state further "downstream".
There has been some hesitation in the IEEE spec as to what the switch should do in that case. However, in the recent standards, and in all Cisco implementations, receiving your own BPDU triggers a move to the discarding state. The problem with hubs is that is it possible that the BPDUs get dropped or corrupted (if the loop is consuming too much bandwidth, the switch might not be able to transmit a BPDU, and hubs don't prioritize control traffic. Also, there might be permanent collisions on the medium, preventing any transmission.). Other cause would be the configuration of BPDU filter, that would prevent STP from receiving its own BPDUs. Check the spanning tree counters on the interface and see if it is receiving anything.
thanks for your suggestion. last night i did testing after enabling the bpduguard and root guard feature. it works for hub to hub connection.
but when i did the testing with basic dlink switch it doesn't work. core switch didn't detected bpdu guard.
core switch -> dlink switch -> self looped
Two potential reasons I can think of:
-1- the dlink is not running STP but is dropping BPDUs. That would be a very bad idea but I've seen this behavior on some switches.
-2- the dlink is running STP, and is not sending any bpdu back to the core switch. This is possible as the core switch generally has a higher priority and is thus designated. The dlink have just a root port on the core switch and is just silent (and, as a consequence invisible to the core switch). Note that there is a short race condition at link up: if the dlink sends its BPDU before the core switch, the core switch will be able to detect it and shut the port down. So the burden of preventing the loop is moved down to the dlink switch in that case.
Unfortunately, I don't have a solution for either case... The core switch cannot do anything if it does not receive its BPDU back:-( Eventually, there is a limit to what you can do to prevent user configuration error. When you think of it, even without a loop, a user can still introduce line rate traffic in your network from a single port...
There is a third possibility: that he has bdpu-filter ebanbled. That would stop the switch transmitting BPDUs out the port. If he has bpdu-filter on either of the ports facing the hub, then that would explain why he gets a loop when the two hubs get connected together. IMHO, bpdu-filter should not be enabled except in some very specific exceptional circumstances. Please confirm there are no bpdu-filters.
Please also do a show spanning-tree on each switch and post the result.
This isn't strictly an STP loop but a packet loop.
How to avoid? BPDU guard would put the port into err-disable (shut it down) if it saw a BPDU. Do not use guard and filter together - filter works first so you don't get the effect of guard. In this case they may not have had much effect.
What is really needed is a policy, and use the technology to back that up.
The policy states no unauthorised hubs or switches.
Use BPDU Guard on all "edge" ports, so that is a user connects a switch the port is effectively closed and they have to come begging if they want it reopened.
Use port security with a max address set to one for a user port or three for a port with an IP phone. That way if a user plugs in a single hub there is no benefit to them as it won't allow more than one user device.
This is then a technical enforcement of the stated policy, but you need to have something in place for how to deal with people that break the policy - loss of bonus? dismissal? black mark and you set their port to 10M Half duplex along with marking all their traffic as first to be discarded in QoS?