Kevin,
Had you look into using Bandwidth-based suppression instead of Packet-based
suppression.
<excerpt>
Configuring Bandwidth-based Suppression
Bandwidth-based suppression is consider a hardware based suppression method.
The threshold is set as a percent of the bandwidth of the port. When the
multicast/broadcast traffic exceeds the threshold within a one second
period, the switch will stop forwarding multicast/broadcast traffic.
Unicast traffic will still be forwarded.
Cat5505> (enable) set port broadcast 2/12 75%
Port(s) 2/12 broadcast traffic limited to 75%
Configuring Packet-based Suppression
Packet-based suppression is consider a software based suppression method.
The threshold is set as the number of packet traveling through the port.
When the multicast/broadcast traffic exceeds the threshold within a one
second period, the switch will stop all incoming traffic for the remainder
of the period.
Cat5505> (enable) set port broadcast 2/12 500
Port(s) 2/12 broadcast traffic limited to 500 packets/second.
If you use Bandwidth-based suppression, your web traffic would still goes
through. Just set the threshold about 25%, that will leave you with 75% of
the port bandwidth for unicast traffic. There is only one small problem,
some of the catalyst only support packet-based suppression. Just do a set
port broadcast 2/12 ? to see if you input percentage.
Hopes this help.
Albert
-----Original Message-----
From: Kevin Welch [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 04, 2000 5:21 PM
To: Howard C. Berkowitz; [EMAIL PROTECTED]
Subject: RE: Port storm-control
I am actually trying to prevent problems from occuring... I had a situation
that was work related that has caused me to rethink the need to make sure
that broadcasts are kept in check. I had a localdirector connected to a
switch and I had two of the localdirector ports connected to the same vlan
due to a misread on the design. Now I had 4 localdirectors setup this way,
each generated approximately 40 MBits/sec of ARP requests. This actually
managed to take down the MSFC on the 6509 that was trunked to my 3548. It
was actually fairly interesting, and I have learned quite a bit as a result
of this, but I am actually trying to lab a similar setup and properly filter
broadcasts to keep this from happening again... I guess in effect I have
answered my own question... I need to determine the most appropriate number
of broadcasts based on my network.
Just a tip for those of you who get to play with localdirectors... I wouldnt
recommend hooking up two inside ports on the same vlan, unless you like arp
storms.
-- Kevin
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Howard C. Berkowitz
> Sent: Monday, September 04, 2000 4:08 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Port storm-control
>
>
> "Kevin Welch" <[EMAIL PROTECTED]> wrote
>
> A broadcast frame takes up the same bandwidth as any other frame of
> the same length. The urban legend that "broadcasts consume
> bandwidth" really refers to broadcast storms, so you are looking at
> the correct problem.
>
> A NetBEUI host that sends seven name resolution broadcasts when one
> would do is taking up the bandwidth that would be associated with
> seven more rational hosts.
>
> The more common effect of broadcasts is that they impact the CPU of
> all hosts that hear them. CID has some old figures showing the
> effect of 10 Mbps broadcasts on a Sparc 2 host.
>
> 100 per second 3% CPU
> 1000 per second 25% CPU
> 3800 per second Host OS crashed
>
> >I am playing around with a switch and looking at the storm-control
> >feature. I cannot seem to find any reference on what good values
> >are for thresholds to indicate a broadcast storm. I am currently
> >using 200 broadcasts per second and I think thats about right, but I
> >would like to know what the rest of you think.
> >
>
> The more hosts in a broadcast domain, the greater the effect of a
> broadcast storm can be. Remember that a storm on one host can
> trigger storms on others. Without a huge amount of science behind
> it, I use about 500 per second as a basic value, but 200 is certainly
> within reason.
>
> Setting it too low, if you have something like NetBEUI, can interfere
> with operations.
>
> ___________________________________
> UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
> FAQ, list archives, and subscription info: http://www.groupstudy.com
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
___________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
___________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
