[c-nsp] issues with 6500 platform

[Peter Rathlev]

On Tue, 2011-02-08 at 11:09 -0600, Jason Cardenas wrote:
> G3/12 is just another interface toward customers, not really involved
> in the "slowness". We have a fresh port for testing, no drops there.

Ok, so no real relation there. And you're not seeing any (serious)
output drops on the egress interface for the traffic in question, as
defined by "show ip cef exact-route <source-ip> <destination-ip>"?

> If we disable QoS all together, would it likely to kill the box even
> for a moment, like a second or two, or tree? We would certainly do
> this overnight with staff present on site, but I would really like to
> know into what we may be running here

The only serious thing I could imagine would be if you use CoPP, since
that depends on QoS being enabled globally. If you have a CoPP policy,
and it's actually needed, you might kill the box when disabling QoS.

Another thing would be priority-queueing, which would also no longer
work. So if you have jitter sensitive traffic it might be impacted
negatively.

> What interface QoS options could we try for our upstream interfaces &
> interfaces toward server farms that are running into this 'slowness'
> issue ?

If the slowness doesn't seem related to egress drops (cf. "show
queueing") I'm not sure that's the direction to look at. You might have
other reasons to adjust the wrr-queue interface configuration, but it
might also complicate the issue.

Pete Lumbis suggestion regarding captures might help narrow down the
problem. It could be simultaneous captures on the two end-points between
which you see the slowness. Wireshark could help pinpoint if the problem
is out-of-order packets. And it could qualify any drops, i.e. see if
they're bundled or spread out and so on.

-- 
Peter