06-05-2013 11:35 AM - edited 03-07-2019 01:44 PM
Hey guys,
I'm having an issue that partially brought down our network. Just wondering if someone could help me out. I've gone through previous posts regarding looping through IP phones but none really came to a definate conclusion.
So a user plugged both the PC and SW ports on the phone into the same switch.
The network partially went down. I was still able to access the switch she plugged into and was able to shut down these ports and the network was restored.
Both ports have the following config (removed QoS settings):
switchport access vlan 10
switchport mode access
switchport voice vlan 20
spanning-tree portfast
Globally we have
spanning-tree portfast default
spanning-tree portfast bpduguard default
It is my understanding that the portfast ports will still send BPDU's. So the switch will send the BPDU to the phone, which is then in turn sent back to the other switch port causing a loop. Since they are portfast the BPDU will be received causing a loop. Should this not be corrected after a couple seconds though as they receive each others BPDU's?
I also do not see either of the port go into errdisable mode on the switch.
Could someone please explain why the loop wasn't prevented or how we could solve this problem (it has occured twice in the past month!)?
06-05-2013 05:32 PM
HI Craig,
Yes indeed the port which is configured as port-fast will send BPDUS but it should not recieve any.
Anyhow not to get into much on this, can you try enabling the bpduguard on the interface?
config t
int X
spanning-tree bpduguard enable
then
show int X
show int status
sh errdisable recovery
HTH
Regards
Inayath
06-06-2013 09:35 AM
Hi Inayath,
Shouldn't the globally applied "spanning-tree portfast bpduguard default" make it so all the ports with portfast have bpduguard applied?
06-06-2013 10:20 AM
Hi Craig,
Bridging loops can still occur on an interface where PortFast is enabled which is why it shouldn't be used on interfaces that connect to hubs/switches.
I may be wrong, but it sounds like the PC or phone are acting as a bridge and forwarding broadcast frames they receive to through to the other device, which in turn forwards them back to the switch, creating a loop.
I'm not sure if BPDUs carry vlan information, but it could be that they're sent out one switch interface on one vlan, and received on the other interface on the other vlan, so the switch doesn't recognise the BPDU as being looped.
Hopefully someone can clarify this or correct me, but that is how I understand the issue to of occurred.
HTH
Paul
Sent from Cisco Technical Support Android App
06-11-2013 10:32 AM
Hello,
Just wondering if you found an answer because I'm having the same concern.
Furthermore, I'm unable to reproduce the behavior in a little lab environnement: the ports get shutdown with err-disabled status as expected.
Thank you,
Louis
06-12-2013 09:35 AM
Hey Louis,
No resolution found of yet. It looks as though the best bet is to configure port-security for maximum number of MAC addresses. I was going to make a mini lab environment today as well to see if it had anything to do with the 2 VLAN's going back to the phone. (Ex. BPDU's not being sent for the Voice Vlan).
I'll let you know what I find. There are some useful comments on this page:
http://blog.ioshints.info/2012/01/prevent-bridging-loops-without-bpdus.html
If you hear/learn anything please let me know as well!
Thanks.
06-14-2013 08:35 AM
Hello Craig,
I found something regarding the issue I encountered. I was able to recreate the problem in a lab environment!
The switch that caused the problem is using IOS 12.2(35)SE. When using IOS 12.2(53)SE for example, I'm unable to recreate the problem. So I suspect something with this particular version (12.2(35SE)). Another good reason to upgrade to a more recent IOS!
Furthermore, spanning-tree portfast bpdufilter default is present in the global configuration... that doesn't help. When removing this command from the global config, I'm unable to reproduce the problem since BPDU packets continously flow from portfast ports: the loop is then detected by bpduguard and the port is shutdown (err-disabled).
The problem I encountered was with two Cisco switches. One 3560 switch with PoE, portfast configured directly on the port, bpduguard and bpdufilter configured globally along with rapid-pvst. The second switch, a 2960, was issued a "write erase" and was without PoE. Movers saw two cables sitting at four desks and an IP Phone at each desk. One cable was connected to the first switch and the other cable to the second switch. People needed two cables because they had two computers planned to be installed. As you can imagine, trying to help, the movers plugged the PoE cables in the Switch port of the phones and the non PoE cables in the PC port of the phones. That created two loops and merged two vlans. You can imagine the storm on the network.
So my problem is bit more complex than plugging two cables from the same switch on the back of an IP Phone. It's also pretty uncommon.
I hope you can figure out what happened on your side. Let us know when you'll do!
Louis
06-17-2013 04:01 PM
Thanks for the reply Louis,
Unfortunately it looks like everything that was causing you issues don't exist in our environment. Switches that were plugged into are running 12.2(55)SE3 with "Portfast BPDU Filter Default is disabled" I still havent had a chance to lab this up here but hopefully I can get to the bottom of it!
08-01-2014 08:43 AM
Why don't you just use errordisable to disable the port and you can set it to recover after 1 mins and it will just give them chance to call you instead of storm.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide