[c-nsp] Unusual Problem with Catalyst 6500 and Sup702-3b

[Nick Hilliard]

On 17/10/2010 23:11, Stephan M. Mackenzie wrote:
> I spot checked a few ports

why not check them all?  Electrons are cheap.

% perl -e 'for($i=1;$i<=2;$i++){for($j=1; $j<=48;$j++){print"show counters
interface gigabitEthernet $i/$j | i qos3Outlost\n"}}'

Cut-n-paste the output of this into your switch.[1]

Also, have you checked all of the interfaces for port drops?

# show int  | i drops

If you see a port with lots of drops, check to make sure that the port
drops aren't increasing.

> the one that had a few was my main link to
> Provider...
> 
> edge01.stl#show counters interface gigabitEthernet 6/2 | i qos3Outlost
> 53.                        qos3Outlost = 87

that's pretty insignificant.

> if I run MTR or extended pings to the slower hosts, I dont see any
> measureable packet loss

Probably not, no.  mtr doesn't fill a switch port up with traffic.  Nor
does ping, unless you're running a flood ping.

> is there any way to debug a network request

What is a "network request"? And how does it relate to individual packets?
 This is a switch router.  It doesn't care about layer 4 through layer 9.

If you want to snoop on traffic, check out span / rspan / erspan.  Beware
that on a loaded 6148 blade, this can cause havoc with dropped packets.

If both your backplane drops and your port queue drops are insignificant,
then check for duplex mismatches (as other people have suggested), framing
errors and that sort of thing.  e.g.

# show int  | i error

Under normal circumstances, you should see 0 errors, low and non-increasing
drops and 0 backplane drops.

Nick

[1] we're all lazy.  here's the output: http://pastebin.com/PqAEZgNN