North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: L2 Broadcast/multicast limits on ethernet ports

  • From: KASHIF SALAMM
  • Date: Mon Sep 20 15:42:02 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 <[email protected]> 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