Yes our setup is cat6k HSRP therefore they will need to change the load balance
method until we move them to nexus VPC (a current project).
Aaron.
Sent from my iPhone
On 17/07/2010, at 4:06 PM, Lincoln Dale wrote:
>
> On 17/07/2010, at 4:55 PM, Aaron Riemer wrote:
>
>> Thanks Lincoln.
>>
>
On 17/07/2010, at 4:55 PM, Aaron Riemer wrote:
> Thanks Lincoln.
>
> The server team must be using the "Route based on IP hash" method then.
>
> "All adapters in the NIC team must be attached to the same physical switch
> or an appropriate set of stacked physical switches."
also ensure you pay
ailto:l...@cisco.com]
Sent: Saturday, 17 July 2010 2:46 PM
To: Aaron Riemer
Cc: 'Lee'; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Brief CPU spikes on 6500 Sup 720
On 17/07/2010, at 9:58 AM, Aaron Riemer wrote:
> Enabled SNMP traps and MAC-notifications and this brought another is
On 17/07/2010, at 9:58 AM, Aaron Riemer wrote:
> Enabled SNMP traps and MAC-notifications and this brought another issue to
> my attention. There is a huge amount of mac-flapping going on (not for this
> host) but our ESX hosts that have vmnics trunking to both our cores.
>
> The VM guys are sendi
is
kind of behaviour.
Has anyone else experienced this?
Cheers,
Aaron.
-Original Message-
From: Lee [mailto:ler...@gmail.com]
Sent: Friday, 16 July 2010 8:09 AM
To: Aaron Riemer
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Brief CPU spikes on 6500 Sup 720
> 3) Packet captures co
Anyone have any further ideas?
>
> Thanks,
>
> Aaron.
>
> -Original Message-
> From: Phil Mayers [mailto:p.may...@imperial.ac.uk]
> Sent: Wednesday, 14 July 2010 11:14 PM
> To: Aaron Riemer
> Cc: 'Matthew Huff'; 'JC Cockburn'; cisco-nsp@puck
iemer'; Matlock, Kenneth L; 'Phil Mayers'
Cc: cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] Brief CPU spikes on 6500 Sup 720
One thing to point out is the packet captures did not indicate
destination
adress of the subnet broadcast address however.
-Original Message-
To: 'Matlock, Kenneth L'; 'Phil Mayers'
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Brief CPU spikes on 6500 Sup 720
Good point mate. Will check it out.
-Original Message-
From: Matlock, Kenneth L [mailto:matlo...@exempla.org]
Sent: Thursday, 15 July 2010 9:51
Good point mate. Will check it out.
-Original Message-
From: Matlock, Kenneth L [mailto:matlo...@exempla.org]
Sent: Thursday, 15 July 2010 9:51 PM
To: Aaron Riemer; Phil Mayers
Cc: cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] Brief CPU spikes on 6500 Sup 720
I know it's a lon
'
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Brief CPU spikes on 6500 Sup 720
Guys,
We are still seeing these floods. They occur when our backups run and it
doesn't matter if the traffic is routed into the vlan or switched within
the
same vlan as the same problem occurs.
Therefore:
7;Matthew Huff'; 'JC Cockburn'; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Brief CPU spikes on 6500 Sup 720
On 14/07/10 15:51, Aaron Riemer wrote:
> Yes i have read all about unicast flooding:
>
> Can occur by:
>
> 1) Asymmetric routing
> 2) Spanning Tree TCN
> 3
Guys,
Can ASIC oversubscription cause the switch to unicast out all ports for that
ASIC?
I am still seeing some unicast traffic hitting ports where it shouldn't be.
Cheers,
Aaron.
On Thu 15/07/10 12:27 AM , Benjamin Lovell wrote:
> Depending on the number of connected IP addresses this can
On 7/14/10 10:06 AM, Matthias Müller wrote:
> Hi,
>
> On Wed, 14 Jul 2010 11:16:45 -0400 (EDT)
>> The vlan in question had an arp timeout of 60s and had a couple of KVM
>> servers with 100 or so virtual machines. Especially when a large number
>> of VMs started up, we'd see periods of packet lo
Hi,
On Wed, 14 Jul 2010 11:16:45 -0400 (EDT)
> The vlan in question had an arp timeout of 60s and had a couple of KVM
> servers with 100 or so virtual machines. Especially when a large number
> of VMs started up, we'd see periods of packet loss. My assumption is that
> the sup720-3bxl can onl
Depending on the number of connected IP addresses this can be an issue. This is
why in most cases it will be better to bring up the MAC table timers as opposed
to bring down the ARP timers.
-Ben
On Jul 14, 2010, at 11:16 AM, Jon Lewis wrote:
> On Wed, 14 Jul 2010, Phil Mayers wrote:
>
>>> mac
hewbhuff | Fax: 914-460-4139
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Aaron
> Riemer
> Sent: Wednesday, July 14, 2010 10:59 AM
> To: 'Benjamin Lovell'
> Cc: cisco-nsp@puck.neth
: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Benjamin Lovell
> Sent: Wednesday, July 14, 2010 10:38 AM
> To: Aaron Riemer
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Brief CPU spikes on 6500 Sup 720
>
> Most of the
On Wed, 14 Jul 2010, Phil Mayers wrote:
mac-address-table aging-time 14400
http://www.ciscopress.com/articles/article.asp?p=336872
Or of course drop the ARP timeout:
int VlanX
arp timeout 290
I haven't tracked down the exact issue, but we've seen issues when using
too short an arp timeou
On 14/07/10 15:51, Aaron Riemer wrote:
Yes i have read all about unicast flooding:
Can occur by:
1) Asymmetric routing
2) Spanning Tree TCN
3) MAC aging out
I cannot see any TCN's or Asymmetric routing so i think we may have to
adjust the mac aging as you suggested.
If you're running HSRP, t
On 14/07/10 15:59, Aaron Riemer wrote:
Forgive my ignorance. What is ECPM??
ECMP = Equal-cost multipath
Shouldn't all routed traffic be handled by the active HSRP node?
Outbound yes. Inbound no; both HSRP active & standby have "connected"
routes for the subnet.
__
---
> From: Benjamin Lovell [mailto:belov...@cisco.com]
> Sent: Wednesday, 14 July 2010 10:38 PM
> To: Aaron Riemer
> Cc: 'JC Cockburn'; 'Phil Mayers'; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Brief CPU spikes on 6500 Sup 720
>
> Most of the time we see
cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Brief CPU spikes on 6500 Sup 720
Most of the time we see problems like this it is caused by asymmetric
routing. The ECPM return path leads to the standby switch which does not
know the DMAC as all traffic was processed by the active switch. This is
us
just started
occurring!
Cheers,
Aaron.
-Original Message-
From: Matthew Huff [mailto:mh...@ox.com]
Sent: Wednesday, 14 July 2010 10:41 PM
To: 'Aaron Riemer'; 'JC Cockburn'; 'Phil Mayers'
Cc: 'cisco-nsp@puck.nether.net'
Subject: RE: [c-nsp] Brief CPU
On 14/07/10 15:40, Matthew Huff wrote:
Since you are running HSRP,I'm willing to bet it's a asymmetrical routing with
aging timeout causing a unicast flooding.
This is a very good bet.
If you make the arging timeout>= to the arp timeout it might fix your problem:
mac-address-table aging-ti
.nether.net] On Behalf Of Aaron
> Riemer
> Sent: Wednesday, July 14, 2010 9:46 AM
> To: 'JC Cockburn'; 'Phil Mayers'
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Brief CPU spikes on 6500 Sup 720
>
> Hi Phil,
>
> Answers below:
>
> 1)
all suspect ports?
>
>
> Thanks,
>
> Aaron.
>
>
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of JC Cockburn
> Sent: Wednesday, 14 July 2010 8:03 PM
> To: 'Phil Mayers'
> Cc: cisco-
l suspect ports?
Thanks,
Aaron.
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of JC Cockburn
Sent: Wednesday, 14 July 2010 8:03 PM
To: 'Phil Mayers'
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Brief C
On 14/07/10 13:03, JC Cockburn wrote:
Hi Phil,
I had a problem like this last year on 6500's.
It was related to bug: CSCsk23521
Basically a server in our datacenter used multicast addresses in the range
allocated for BPDU's, and this just killed the SP (100% CPU...).
Ugh. Nasty bug!
If you d
on the 6500 you can see if
the SP CPU is under fire...
Cheers
JC
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers
Sent: Wednesday, July 14, 2010 1:41 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Brie
On 14/07/10 11:30, Aaron Riemer wrote:
Hi Group,
We are having trouble with unicast flooding on a particular VLAN and
associated ports and as a result brief spikes in CPU usage on one of our
6509 core switches.
ARP and MAC timeouts are set to default and we haven't had problems with
this in
Hi Group,
We are having trouble with unicast flooding on a particular VLAN and
associated ports and as a result brief spikes in CPU usage on one of our
6509 core switches.
ARP and MAC timeouts are set to default and we haven't had problems with
this in the past. The problem is I believe thi
31 matches
Mail list logo
