[c-nsp] 3550 QoS not working as expected

[Tim Devries]

Yes, I did read that they are collected from the hardware counters,
therefore the counter discrepancy.  However in real time when I view the
traffic graph, it still show bandwidth spikes.  It more an issue of
semantics than anything else, because I really never gave much of a care
about the details of the QoS stats, just knowing some packets are classified
as dropped shows that the configuration should be working (at least to a
degree...).

The monitoring software grabs the interface counters through snmp.  I would
assume (perhaps erroneously?) that the 'real' time counters would still not
show traffic above 3Mb/s if QoS was actually working.

I'm fairly sure a new image will solve the problem.  I will try an aggregate
policy and apply it to my upstream link (so I can limit both ways -- i.e. it
may be possible the snmp oid's are reversed in software on what is input and
output?) to see if that makes any difference.

Thanks,

Tim

-----Original Message-----
From: Sam Stickland
To: Tim Devries
Cc: 'Nick Shah '; 'cisco-nsp at puck.nether.net '
Sent: 1/6/05 9:49 PM
Subject: RE: [c-nsp] 3550 QoS not working as expected



On Thu, 6 Jan 2005, Tim Devries wrote:

> When I do a
>
> Colo-3550#sh mls qos int fa0/1 stat
> FastEthernet0/1
> Ingress
>  dscp: incoming   no_change  classified policed    dropped (in pkts)
> Others: 38469779   38379716   90063      0          190138
> Egress
>  dscp: incoming   no_change  classified policed    dropped (in pkts)
> Others: 33285081      n/a       n/a      0          0
>
> Colo-3550#
>
> I see packets being dropped, but in my monitoring software I still see
it
> spiking up to 5-6Mb.

I believe the interface counters on the 3550 increment before the traffic
policing is applied - ie. they count prepoliced traffic.

It's something that makes checking whether configurations like this are
working an order of magnitude more difficult :/

S