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?
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.
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.
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.
thank you VJ and all other netpros who have contributed.
Would storm control be a good practice to mitigate this kind of sceanario?
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.
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.
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.
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.
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.
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.
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.
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,
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.
This problem is not limited to a certain phone or switch. It happens in all scenarios.
The only thing that helps a little is storm control. At least you will be able to access the switch and found the problem.
I have port-security, bpdu guard and other features enabled on all switches but when users are doing this by mistake storm control is the only feature that help us.
I think Cisco should fix this as the problem is the way that phones are passig traffic from one interface to the other one.
Bdw, what other switch platform encountered this problem? We tested using 3650 and no problem with it so we assume that the problem is only CE500. BPDUguard works fine on 3650.
I've not checked manually all the platforms (I only tried a 3750) but it seems that the documentation does not show bpdufilter anywhere for the ip phone smartport.
In any case, the smartport are just macro. Except on the CE500 switches, you can do a show run and check that bpdufilter is not enable on the interface to make sure there is no problem.
Bpduguard (which will definitely be enabled by the smarport config) is ok.
It's probably good to involve the tac here. I understand there is a problem, but I don't have enough information to determine exactly what is the source of the problem. What I'm sure of is that it's not because portfast ports are not sending BPDUs, and I'm very skeptical about IP phones filtering out BPDUs (that would be a very dumb thing to do, but I can never tell;-). A switch with two ports does not really need to run STP so long it is forwarding transparently BPDUs as well as traffic. Now, I guess the IP phone can be seen in certain respect as a switch with 3 ports, and I'm sure there are ways of making nasty combinations with it!
I got confirmation internally that the CE500 enables bpdufilter as part of the smartport phone configuration. This is wrong and I'll have a bug open for this. This bpdufilter configuration is specific to the CE500 so other switches should not be affected this way.
Bdw, simulated this problem with 3650 switch. BPDU is indeed relayed. So problem is more on CE500.
We opened a TAC case with regards to this. You may want to inform the TAC engineer about the newly opened DDTS to avoid duplicate. SR 606386351
We resolved this issue by ensuring that BPDUGUARD was enabled on all PortFast ports. This basically says that if it detects a BPDU coming in, shut the port down. The port will indicate "err-disable". So while the phone itself doesn't generate BPDUs, it will pass the BPDUs from it's upstream switch. BPDUGUARD will see the incoming BPDUs on a port as an error condition and shut the port down.