[c-nsp] Brief CPU spikes on 6500 Sup 720
Aaron Riemer
ariemer at amnet.net.au
Thu Jul 15 09:55:56 EDT 2010
Good point mate. Will check it out.
-----Original Message-----
From: Matlock, Kenneth L [mailto:MatlockK at exempla.org]
Sent: Thursday, 15 July 2010 9:51 PM
To: Aaron Riemer; Phil Mayers
Cc: cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Brief CPU spikes on 6500 Sup 720
I know it's a longshot, but have you looked at the default gateway on
the server?
In a pervious job the admin had set the broadcast address (.255) as the
gateway, meaning ALL traffic out was getting broadcast. Under normal
operation that wasn't a problem, but during backups the flood would
occur.
Ken Matlock
Network Analyst
Exempla Healthcare
(303) 467-4671
matlockk at exempla.org
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Riemer
Sent: Thursday, July 15, 2010 7:45 AM
To: 'Phil Mayers'
Cc: cisco-nsp at 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:
1) asymmetric routing cannot be the problem for the L2 switched
traffic
2) No TCN's are occurring within the VLAN STP (PVST).
3) Packet captures confirmed that all ports on VLAN1 on one core were
receiving the unicast traffic destined for a host on this vlan.
4) From the packet captures we were able to deduce source / dest MAC
addresses confirming that the destination MAC was in fact not aging out
and
could be seen clear as day in the MAC table.
Had TAC on the line troubleshooting it for a couple of hours tonight and
still no closer to solving the problem. Mac-age time out is set to the
same
as the arp timeout (4 hours)
I don't believe the issue is linked to the CPU spikes but rather the
output
drops that we are seeing oversubscribing our 6548 line cards.
Anyone have any further ideas?
Thanks,
Aaron.
-----Original Message-----
From: Phil Mayers [mailto:p.mayers at imperial.ac.uk]
Sent: Wednesday, 14 July 2010 11:14 PM
To: Aaron Riemer
Cc: 'Matthew Huff'; 'JC Cockburn'; cisco-nsp at 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) 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, the standby node has a route for the subnet as
well as the active e.g. traffic might flow out through the active, and
back through the standby as follows:
host
|
active-standby
| |
(cloud) ^
| |
router --/
|
target
from host->active->router-target
return target->router->standby->host
...if "standby" has an ARP entry (default 4 hours) but not MAC table
entry (default 5 minutes) it will unknown-unicast-flood the return
traffic. If it's a lot of traffic, that will burn a lot of bandwidth...
Whether this will happen will depend on your routing topology.
>
> I am just trying to work out why the hell this has only just started
> occurring!
Well, without knowing the source of the traffic it's impossible to tell.
_______________________________________________
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/
More information about the cisco-nsp
mailing list