Prevent bridging loops without BPDUs?
Anton sent me an interesting question:
Most IP phones have a network facing port and a port for user to connect the PC. Today a user plugged in both of these ports into the switch. It looks like phone filters out BPDUs, so the switch did not catch this loop. Do you know of a feature or design that would be able to catch/prevent this type of event?
My answer would be “no, there’s nothing you can do if you have a broken device that acts like a STP-less switch” but you know I’m not a switching or IP telephony guru. Any ideas?
Switchports are configured with a voice vlan, Portfast is enabled with BPDU guard.
It seems the phone bridges the data and the voice vlan.
The switches so far were not able to catch it.
Brings down pretty much everything including the distribution layer switches, pretty nasty.
switchport port-security
switchport port-security maximum 4
switchport port-security aging time 10
switchport port-security violation <protect> (depending on your situation) </protect>
If you have MAC-based authentication enabled, then a loop causes MAC addresses to appear, and be authenticated, on different ports. Since this process is usually mediated by a radius server, you can do two things - rate-limit it, and watch for well-known MACs like your routers, HSRP/VRRP vMACs and so forth, and "detect" the loop - then deny all authentication (and thus, learning) of new MACs on that switch/port combo for a period of time.
If you have 802.1x it works even better; the phone supplicant only runs on the "network" facing port. The PC-facing port doesn't have an 802.1x supplicant, so the upstream switch port never goes to "forwarding".
Both have other benefits (RADIUS-based vlan assignment, proper logging of who is where, accounting, etc.)
We have observed that loops are much less harmful to the upstream network when being "gated" by mac/802.1x auth. You get local weirdness, but it's rare for it to take the network out, and you can find the location of the weirdness from the radius logs, and fix the problem.
A "BPDU-filtering, STP-less" switch is a catastrophe.
Rich Seifert addressed this problem in "The All New Switch Book"
I don't have the citation handy, but it boils down to this: A device that filters BPDUs, and doesn't proactively prevent loops is spectacularly broken. Send them back to the manufacturer.
-----------------
Bridges usually fall into one of two categories: Those that support 802.1D, and those that don’t.
Those that support 802.1D do all of the right things STP-wise, so no problem.
Those that don't support 802.1D don't generate or understand BPDUs, but they also don't know about the 802.1D requirement to filter frames in the range 01:80:C2:00:00:00-01:80:C2:00:00:0F. This means that they'll pass BPDUs generated by the rest of the network. The SOHO box won't prevent loops on its own, but the rest of the network should detect and correct the problem*
In 'The All-New Switch Book', Rich Seifert said: "if you're going to violate 802.1D, you have to violate it *all*the*way*"
I think it is more a policy issue than a feature issue. Why would you let your user connect network devices to the switch directly? Shouldn't the switch be secure somewhere?
I was the person who originally asked the question(thanks for posting Ivan).
Some background, this happened during an office move, when movers showed initiative and plugged in everything that fits into the jack. Explaining that movers brought down corp network leaves you feeling pretty stupid.
Thank you all for your suggestions, I think limiting the number of MACs per port and 802.1x look promising. Though 802.1x on IP phones is a pain in the butt.
However, it's important not to use port security auto recovery on it, otherwise the loop will break and restart a while later.
Restrict will be more permissive, but may make the issue harder to pinpoint/detect. I'd use shutdown, as it will surely make something break.
Storm control is a must.
* storm control set to the lowest bandwidth needed to get the job done.
* explicit maximum allowed number of source MACs that can be learned over the port (port security feature). This limits looping packets to the configured maximum of source macs. Set it to the lowest number needed to get the job done.
* unused ports should always be disabled and also have the above two settings "just in case".
Ideally the IEEE would have standardized a UNI to exchange source MACs a long time ago so such bandaids wouldn't be necessary and so many unnecessary outages avoided.
You can try to do this in order to help to mitigate the issue.
On interface configuration mode:
storm-control broadcast level 25.00 (this is the percentage of bandwidth that will be the threshold of broadcast, if th limit is exceeded, the action is defined as follows)
storm-control action shutdown
switchport port-security maximum 5
switchport port-security
switchport port-security aging time 1 (will flush the MAC addresses each minute, it can be adjusted at your convenience)
switchport port-security aging type inactivity
In global configuration mode
errdisable recovery cause psecure-violation
errdisable recovery interval 300
Sorry for my english and hope this help.