<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
<br>
What is the natural of your traffic then ? Do you allow broadcast,
unknown unicast to be flooded by the edge-switches ? <br>
Applying L2 ACL at the edge switches might be you answer, if you
only allow traffics sourcing from one MAC addresses.<br>
IMHO, allow the broadcast packets hitting your CPU is bad, just
drop broadcast traffic from unknown source L2 ACL.<br>
<br>
On 4/5/11 6:47 PM, Mark Johnson wrote:<br>
<blockquote
cite="mid:BANLkTikiEvNAn8wRAgVDsEkYp52+NYxFBw@mail.gmail.com"
type="cite">
<pre wrap="">Anyone out there know of a good way to protect against customer broadcast
storms? We use a few MLX switches with customer ports on them. Occasionally,
a customer will create a loop in their equipment which causes a storm all
the way back to our MLXs. The line cards are pretty good at handling (CPU
goes to 30-40%) but would like to know of a good way to protect our MLX.
Also, any have best security practices they apply on customer ports to help
keep the core switching stable?
</pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
foundry-nsp mailing list
<a class="moz-txt-link-abbreviated" href="mailto:foundry-nsp@puck.nether.net">foundry-nsp@puck.nether.net</a>
<a class="moz-txt-link-freetext" href="http://puck.nether.net/mailman/listinfo/foundry-nsp">http://puck.nether.net/mailman/listinfo/foundry-nsp</a></pre>
</blockquote>
<br>
</body>
</html>