On Fri, Mar 26, 2010 at 5:21 PM, Matthew Huff <mhuff@ox.com> wrote:
Bpduguard if running cisco. set all the switch ports to bpduguard or enable it globally
Bpduguarding a cool idea, and not a bad protective measure, if running that vendor's equipment, but it still allows a possibly large disruption for the (small) duration until the first BPDU is received and relies on reasonable operation from the thing creating a loop -- the guard is a no-op if whatever crosses jacks does not pass STP PDUs. Whether it is enough, depends on your threshold of pain for looping, packet loss, and the frequency of conference room physical configuration errors. 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. 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. 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. 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. 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). -- -J