Spanning Tree Loop through IP Phone

[jliow]

Recently an end-user just wrecked havoc on the network, pluging in a lan cable that on the IP phone that is suppose to be for the PC back into a nearby empty wall jack.

While we enabled the spanning tree portfast for all the edge switches port, thinking its suppose to stop this kind of connection, however it didn't happen.

When we call up TAC, I was told thats because the PC port on the IP Phone doesn't send BPDU packets, that was why spanning tree didn't do any port blocking.

Question 1: I though the PC and network port on the IP phones are kinda like a mini switch, somehow I realise now that its not....that true?

Question 2: Most importantly how do I prevent this in future? Will Port-security mac address count contrl be useful?

[Amit Singh]

Hello,

Question1: Yes, IP phones donot send BPDU's.You can enable BPDU guard and it does not shut the port down when an IP Phone is connected.

Question:I think it will be worth giving it a shot, I havenot tried it practically but should work.

Try out in a LAB and let us know your findings.

-amit singh

[Jozef Janitor]

Answer to Q2: I don't think that port-security will handle this problem. But maybe the storm-control feature will limit the broadcast storm to a normal limit.

[vijayasankar]

Hi,

As pointed out by Amit, the IP phones doesn't act like a switch.

When you enable portfast on a port, the switch wil not send out a BPDU on the port. But when it receives a BPDU via that port, it can shut the down port when BPDU guard is enabled.

In your scenario, the link connected to the port fast enabled port is connected back to the switch.

As the switch never sends out a BPDU on port fast enabled, there is no way the switch can detect this loop. I assume that the wall-jack that was shorted also led to a port fast enabled port.

The only was to prevent this scenario is to disable port fast on the port connected to the ip phones.

As stated by the other netpro's port-security is not going to help in this scenario.

-VJ

[jliow]

thank you VJ and all other netpros who have contributed.

Would storm control be a good practice to mitigate this kind of sceanario?

[vijayasankar]

Hi,

I haven't tried that option and hence not sure whether it would help.

However the storm control works by limiting the traffic level on the port, till the storm reduces.

In this scenario, until the loop is identified and corrected, the issue is going to be persistent.

Also Using storm control may leave this scenario unnoticed.

-VJ

[jechoi]

Hi VJ,

Got any solution to this?

This can be cisco's vulnerability issue. We are encountering the same problem.

Thanks,

Jeff

[vijayasankar]

Hi Jeff,

As far as i know, no solution exists for this race around condition.

If two "port fast" enabled ports are looped, it will create a mess in the network.

Because the switch will never send a BPDU via a port fast enabled port. Hence there is no way the switch can detected that both the ports are looped.

It is better to disable the port fast in this scenario.

If you encounter any solution, kindly keep us all posted.

Regards

VJ

[jechoi]

Thanks for the info. I'll have a conference call tomorrow with our local cisco systems and see if they have a solution. I'll keep you posted.

[Francois Tallet]

You are probably talking about the global portfast bpdufilter command, because BPDUs do get sent on portfast enabled ports.

I don't know much about the IP phone, but even if it is not running STP, it could still relay the BPDUs and then the switch behind the phone could detect a loop.

I would not be surprised if the problem was rather related to configuring bpdufilter on the ports (which indeed prevents BPDU transmit and receive). Else, if indeed the IP phone is filtering BPDUs, there is nothing STP can do here.

Port security allows you to shut down a port after a certain number of mac addresses have been learnt on it. When you have a bridging loop, flooded traffic coming from the backbone will go through your access ports, and you are very likely to learn lots of mac addresses and discover the problem. I think the feature might help here.

Regards,

Francois

[jechoi]

One thing i hate about this problem is that we are using CE500. Unfortunately, not much to be configured.

This is easily reproduced. Plug both ports of the ip phone to both ports of the switch with portfast enabled.

[jliow]

Yea Agree, after initial use of CE500 found its many limitations, despite of its lower cost, looking at the features and functions, I do not think its worth the take. thats why during my second phase of project implementation, I totally rule CE500 out of the picture.

I've tried implementing port-security controls limiting mac address, enable BPDU-guard and broadcast storm, worked for me so far.

[jliow]

To add on, this is a prevalent problem of Cisco, Cisco should address this issue not for end users like us to figure out work arounds if their product is so vulnerable.

[Francois Tallet]

I'm frustrated because I don't have the equipment to test this myself, but I'm really surprised. Do you think this is specific to the CE500? I'm trying to figure out if the problem is with the CE500 not sending BPDUs on portfast enabled ports (which is wrong, a portfast enable port *does* run STP), or the IP phone filtering BPDUs (which would not be very clever either btw).

In that setup, I can perfectly see a temporary bridging loop, but it should end as soon as the switch ports hear of each other.

Thanks and regards,

Francois

[jechoi]

I do not think that the problem is specific to CE500 only. Haven't tested it though. The one who openned this topic may not be using CE500.

Any ip phone would also do. Just borrow any phone you see. :-)

Our customer encountered it using 7912 ip phone. While lacking that particular ip phone on the lab, we used 7940 that is available.

Not really sure what the architechure of the ip phone is but it should have some mechanism to tell the switch to block one port.

Anyway, our local cisco will be the one opening the case to TAC in order to solve this problem since it is concerning their product. I hope we get an answer soon. Our client is very concern about security issues.