[c-nsp] Unicast storms

[Brian Turnbow]

It will vary a bit between switches 
But here is how it is described by cisco.

Storm control (or traffic suppression) monitors packets passing from an interface to the switching bus and determines if the packet is unicast, multicast, or broadcast. The switch counts the number of packets of a specified type received within the 1-second time interval and compares the measurement with a predefined suppression-level threshold. 

Storm control uses one of these methods to measure traffic activity: 

*Bandwidth as a percentage of the total available bandwidth of the port that can be used by the broadcast, multicast, or unicast traffic 

*Traffic rate in packets per second at which broadcast, multicast, or unicast packets are received (Cisco IOS Release 12.1(22)EA1 or later) 

With either method, the port blocks traffic when the rising threshold is reached. The port remains blocked until the traffic rate drops below the falling threshold (if one is specified) and then resumes normal forwarding. If the falling suppression level is not specified, the switch blocks all traffic until the traffic rate drops below the rising suppression level. In general, the higher the level, the less effective the protection against broadcast storms. 

Unicast flooding does not worry about known or unknown macs, just the amount of traffic.

There is  Unknown Unicast Flood Blocking or UUFB available on some platforms to block the flooding of unknown unicast traffic.

Regards
Brian


-----Original Message-----
From: Vincent De Keyzer [mailto:vincent at autempspourmoi.be] 
Sent: martedì 3 luglio 2007 14.43
To: Brian Turnbow; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Unicast storms

Brian,

I don't think this is the way "unicast storm-control" is supposed to work.

Of course the traffic on the LAN is bursty, but that's just fine; what I
think Cisco tried to address with this feature is the unicast flood due to
unknown destination MAC address.

Foundry has similar (equivalent?) features, and they are less ambiguously
named: "broadcast limit", "multicast limit" and "unknown-unicast limit".

Now this is all only guesswork, since I have never seen this feature clearly
explained on CCO...

Vincent

> -----Original Message-----
> From: Brian Turnbow [mailto:b.turnbow at twt.it]
> Sent: lundi 2 juillet 2007 18:46
> To: Vincent De Keyzer; Francois Ropert; cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] Unicast storms
> 
> It would be all unicast traffic measured in 1 second intervals , not just
> unknown destinations, so you might want to try setting up a rate limit
> with permit actions to see if you are having bursts of traffic.
> 
> Brian
> 
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Vincent De Keyzer
> Sent: lunedì 2 luglio 2007 18.01
> To: 'Francois Ropert'; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Unicast storms
> 
> > > I have configured _unicast_ storm-control on our LAN recently, and it
> > > keeps kicking in all of the time (something like 50 times per hour).
> > >
> > > The configured treshhold is quite high (10% - that's 100 Mbps on GigE
> > > ports!...).
> > >
> > > I believe there is something wrong - where do I start troubleshooting
> > > this?
> > >
> > Read the rxload% and input in show interface command to see if are you
> > really under the 10% assuming you haven't snmp nor netflow.
> 
> Well,
> 
> I have snmp, but this is not my understanding of unicast storm: as far as
> I
> understand, unicast storm is defined as traffic with an unknown
> destination
> MAC address.
> 
> I don't think you can see this with 'sh int' or SNMP, can you?
> 
> Vincent
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/