cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1554
Views
15
Helpful
19
Replies

STP loop

kamalnathsingh
Level 1
Level 1

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.

Loop

regards,

Kamalnath

19 Replies 19

nambi_gct
Level 1
Level 1

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.

Hi,

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 ?

rgds

matthewt1501
Level 1
Level 1

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

Cheers.

Matt

Hi Matt

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.

rgds

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.

Cheers.

Matt.

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

kamalnath

"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)

Cheers

Matt

Hi

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.

HTH

rgds

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.

Regards,

Francois

Hi Franco,

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.

rgds

Why STP not able block this port. Though STP instance are running.

this may be due to root switch..

Currently.

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".

Cheers.

Matt

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.

Regards,

Francois

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco