On Mar 26, 2010, at 7:29 PM, Chuck Anderson wrote:
On Fri, Mar 26, 2010 at 08:29:52PM -0500, James Hess wrote:
Most all switch manufacturers provide some type of port security feature that allows an end-user connection port to automatically be disabled and require admin intervention to re-activate, if the number of MAC addresses exceed a configurable number, e.g. allow 5 MAC addresses, which are remembered as that port's list of "secured" MAC addresses with an aging time of 5 minutes.
In fact, the last time this happened, I implemented exactly what you describe, mac-security with a limit of 5 MACs. The security kicked in and shutdown the port, but not before the core shutdown the edge switch's uplinks (see below).
Use that function, and use the functions of a switch that provide storm control for client ports. With a reasonable aging duration for expiring secured MAC addresses.
Have that.
If a client port emits packets with more than the expected number of MAC address sources within a short time, then that should be an early warning that traffic has taken an improper path.
Have that.
Keeping in mind a loop doesn't necessarily create an instant issue, until there is other broadcast traffic on the network, that crosses the loop, and starts messing up the CAM table on the upstream device, as well as possibly generating duplicate traffic.
Which pretty much means within milliseconds on my network.
Sounds like you forgot to configure the "Root is that-way ->" sanity check on your switches. Make sure that Root bridge can't be determined to be in a direction other than "upstream" will help a lot with this.
But with port security, the number of devices that lose packets due to the loop should be limited (the smaller you set the limit without impacting legitimate use of the port, the better).
So basically, the problem is the core switches implement a proprietary loop-prevention protocol that sends "beacon" frames out every 500ms, and if a certain number of these special frames come back (exceeds threshold) it shuts down the port. Even with a 10:1 ratio of
That's Icky... Can you replace that with traditional spanning tree? It's just too sensitive for a deployment of any real size.
threshold settings on the two redundant links to the edge switch, it still trips both thresholds fast enough that both redundant links get shutdown in the short time before the edge switch's protection mechanism (mac-security, STP, bpduprotect, whatever) kicks in. I've now set the ratio to 100:1 (500:5 in actual packet counts) and the transmit interval to 1000ms in the hopes that at least one core link will survive long enough for the edge port to shutdown and break the loop first, but I'm beginning to think that this protocol is crap and I should just disable it and let the core ride out the loop in the hopes that it survives without taking down the entire core before the edge switch shutdown happens.
Yes, I think that would be much better. (Of course, another alternative would be traditional spanning tree, or, some variant of STP with faster timers).
The good news is that this core is being replaced soon, hopefully with gear that will be able to implement a service-provider-like design with per-port VLAN separation as was suggested in this thread. But it surprises me that low-end switch vendors (like NetGear) still put out crap that doesn't do STP, especially when the switch does Auto MDI/MDI-X, which is just asking for trouble.
Usually people don't use Netgear cheap switches in environments with more than a desktop worth of topology.
Anyone know if Auto MDI/MDI-X is inherent or required in 1000Base-T? It would be nice if I could shut it off.
Yes, it is. (This is actually a good thing in everyone else's environment). Owen