Gert Doering wrote:
Hi,
On Thu, Jul 05, 2007 at 04:05:24PM +0100, Stephen Wilcox wrote:
your LAN would need to be very large or very unusual for you to see this as
a problem
One case where I've seen this cause more issues than just plain traffic
is with centralized syslog servers. If
Steve, Saku,
thanks for you continued interest in my problem :)
I thought we were talking of non-PFC platforms but I re-read and we
havent established what platform it is. In which case I would be wrong.
And yes you can block them (port block unicast) but I'm not sure if that
was what
On (2007-07-05 17:41 +0300), Tassos Chatzithomaoglou wrote:
1) you operate the L3 and L2
- match MAC and ARP timeout
Default arp is 4h, default mac is 5m.
Are there any recommended values?
We've decreased ARP timeout to 5min when we've absolutely
needed to sync them (good scenario is
On (2007-07-05 14:44 +0200), Vincent De Keyzer wrote:
The problem is: I am making the assumption that network performance on the
LAN could be sub-optimal due to frequent unicast floods (i.e. switches are
flooding all ports with unicast frames because it does not have the
destination MAC
Hi Vincent,
I'm saying it works just fine but the implementation is sucky. I use it
extensively but you just need to set your thresholds pretty high to make sure
they arent tripped. I also usually have it just filter rather than shut the
port that way it will auto-recover.
As to what 'pretty
On (2007-07-04 15:44 +0100), Stephen Wilcox wrote:
I take it you mean unicast frames with mac addresses that are currently
unknown to the switch on that port? In which case you cant limit it that
way.. but you have two options:
In risk of repeating myself, you can rate-limit them on PFC3C
On Wed, Jul 04, 2007 at 06:32:16PM +0300, Saku Ytti wrote:
On (2007-07-04 15:44 +0100), Stephen Wilcox wrote:
I take it you mean unicast frames with mac addresses that are currently
unknown to the switch on that port? In which case you cant limit it that
way.. but you have two options:
: lundi 2 juillet 2007 18:46
To: Vincent De Keyzer; Francois Ropert; cisco-nsp@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
Basically I have two answers now:
1. Eric points me to asymmetric traffic/routing and MAC/ARP timeouts
2. Stephen says unicast storm-control does not work properly by design (or
because of Microsoft, depending on which side you are on :)
Now, if anybody has successfully implemented unicast
-Original Message-
From: Vincent De Keyzer [mailto:[EMAIL PROTECTED]
Sent: martedì 3 luglio 2007 14.43
To: Brian Turnbow; cisco-nsp@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
Hi,
On Mon, Jul 02, 2007 at 01:25:17PM -0400, Pickett, McLean (OCTO) wrote:
The switch will only timeout the mac table entry if the host has failed to
generate a single valid frame over the timeout period. The switch will then
broadcast the first frame destined to the host and re-learn the
Hello,
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
On Mon, 2 Jul 2007 14:54:57 +0200
Vincent De Keyzer [EMAIL PROTECTED] wrote:
Hello,
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
On (2007-07-02 18:01 +0200), Vincent De Keyzer wrote:
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'm afraid your understanding is incorrect. Only platform where unknown
if the mac address in the router's
cache is no longer valid and does not exist on the network.
McLean
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric Spaeth
Sent: Monday, July 02, 2007 1:04 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Unicast storms
Hi Vincent,
I've seen this too, its very annoying.
The reason is it is sampling the rate over a 1 or 2 second interval as opposed
to the interface rate which by default is 5 minutes altho you can go to as low
as 30s (load-interval 30).
Cisco: it would be very nice if we could tune that
PROTECTED] On Behalf Of Eric Spaeth
Sent: Monday, July 02, 2007 1:04 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Unicast storms
If you have HSRP enabled on layer-3 switches, make sure that the
mac-address-table aging-time is set to 14400 seconds or better so that
it will not age out
17 matches
Mail list logo
