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