Auto MDI/MDI-X + conference rooms + bored == loop
James Hess
mysidia at gmail.com
Sat Mar 27 01:29:52 UTC 2010
On Fri, Mar 26, 2010 at 5:21 PM, Matthew Huff <mhuff at 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
More information about the NANOG
mailing list