Possible Loop Through IP Phone

[Craig Phillips]

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!)?

[InayathUlla Sharieff]

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

[Craig Phillips]

Hi Inayath,

Shouldn't the globally applied "spanning-tree portfast bpduguard default" make it so all the ports with portfast have bpduguard applied?

[paulstone80]

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

[Louis Poulin]

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

[Craig Phillips]

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.

[Louis Poulin]

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

[Craig Phillips]

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!

[haixiangwang]

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.