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 '; 'cisc...@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
15 messages in net.nether.puck.cisco-nsp[c-nsp] 3550 QoS not working as expected
