L2 Broadcast/multicast limits on ethernet ports

KASHIF SALAMM ksalam at rogers.com
Mon Sep 20 19:32:25 UTC 2004


Thanx Arien
 
Yes that's the command we will be doing.
 
The basic purpose is to stop the cpu's  to shoot up to 70 + % utilistaion and to crash/reboot as we experienced the same.
 
What numbers you are using for 10/100/1000 ports.
 
rgds.
 
KS
Arien Vijn <arien.vijn at ams-ix.net> wrote:

On Sep 20, 2004, at 6:25 PM, KASHIF SALAMM wrote:

> We are looking into deploying the L2 broadcast/multicast limits on the 
> ethernet ports of foundry switches.

Just to be sure, you mean that you want to add the following statements 
to your configuration?

broadcast limit x
multicast limit y

And there is also :

unknown-unicast limit x

> If anyone has case study or deployed it or any experience and don't 
> mind sharing , will be very appreciated.

We applied limits on BigIron JetCore hardware. We had IronCore silicon 
before and applied on that hardware also.

All limits work well. The switches start to drop the right types of 
frames as soon as the packet rates supersedes the respective limits.

But you need to be aware that these limits only apply to CPU forwarded 
frames. Hense it won't work as rate limiter on hardware (CAM) forwarded 
multicast frames. This also means that these features won't ease the 
CPUs of switches receiving fast amounts of broadcast/multicast frames. 
But it can be used to limit broadcast storms propagating through your 
L2-network.

Needless to say that, you must be careful if you use some kind of 
layer-2 redundancy protocol. As most if not all use multicast frames.

Hope this helps, Arien




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20040920/9028284e/attachment.html>


More information about the NANOG mailing list