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@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