<DIV>Thanx Arien</DIV>
<DIV> </DIV>
<DIV>Yes that's the command we will be doing.</DIV>
<DIV> </DIV>
<DIV>The basic purpose is to stop the cpu's  to shoot up to 70 + % utilistaion and to crash/reboot as we experienced the same.</DIV>
<DIV> </DIV>
<DIV>What numbers you are using for 10/100/1000 ports.</DIV>
<DIV> </DIV>
<DIV>rgds.</DIV>
<DIV> </DIV>
<DIV>KS<BR><B><I>Arien Vijn <arien.vijn@ams-ix.net></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"><BR>On Sep 20, 2004, at 6:25 PM, KASHIF SALAMM wrote:<BR><BR>> We are looking into deploying the L2 broadcast/multicast limits on the <BR>> ethernet ports of foundry switches.<BR><BR>Just to be sure, you mean that you want to add the following statements <BR>to your configuration?<BR><BR>broadcast limit x<BR>multicast limit y<BR><BR>And there is also :<BR><BR>unknown-unicast limit x<BR><BR>> If anyone has case study or deployed it or any experience and don't <BR>> mind sharing , will be very appreciated.<BR><BR>We applied limits on BigIron JetCore hardware. We had IronCore silicon <BR>before and applied on that hardware also.<BR><BR>All limits work well. The switches start to drop the right types of <BR>frames as soon as the packet rates supersedes the respective limits.<BR><BR>But you need to be aware that these limits only apply to CPU forwarded <BR>frames. Hense it
 won't work as rate limiter on hardware (CAM) forwarded <BR>multicast frames. This also means that these features won't ease the <BR>CPUs of switches receiving fast amounts of broadcast/multicast frames. <BR>But it can be used to limit broadcast storms propagating through your <BR>L2-network.<BR><BR>Needless to say that, you must be careful if you use some kind of <BR>layer-2 redundancy protocol. As most if not all use multicast frames.<BR><BR>Hope this helps, Arien<BR><BR><BR><BR><BR></BLOCKQUOTE>