nanog mailing list archives

Re: L2 Broadcast/multicast limits on ethernet ports


From: KASHIF SALAMM <ksalam () rogers com>
Date: Mon, 20 Sep 2004 15:32:25 -0400 (EDT)

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





Current thread: