15 messages in net.nether.puck.cisco-nsp[c-nsp] 3550 QoS not working as expected
FromSent OnAttachments
Tim DevriesJan 6, 2005 12:14 pm 
Nick ShahJan 6, 2005 5:39 pm 
Tim DevriesJan 6, 2005 6:21 pm 
Nick ShahJan 6, 2005 6:58 pm 
Tim DevriesJan 6, 2005 7:27 pm 
Nick ShahJan 6, 2005 7:51 pm 
Tim DevriesJan 6, 2005 8:24 pm 
Sam SticklandJan 6, 2005 8:49 pm 
Tim DevriesJan 6, 2005 9:28 pm 
McCallum, RobertJan 7, 2005 3:49 am 
Dmitry ValdovJan 7, 2005 4:03 am 
McCallum, RobertJan 7, 2005 4:05 am 
WILDE, DavidJan 7, 2005 4:25 am 
Nick ShahJan 9, 2005 4:10 am 
Tim DevriesJan 10, 2005 11:02 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:[c-nsp] 3550 QoS not working as expectedActions...
From:McCallum, Robert (robe@thus.net)
Date:Jan 7, 2005 3:49:36 am
List:net.nether.puck.cisco-nsp

Tim try this - it works for me.

class-map match-any matchall match access-group name AllIpPackets match access-group name AllMac

policy-map ratelimit8meg class matchall police 8000000 8000 exceed-action drop ! mac access-list extended AllMac permit any any ! ip access-list extended AllIpPackets permit ip any any

Remember (Im sure you have) to enable mls qos globally for this to work.

Robert McCallum CCIE #8757 R&S 01415663448 07818002241

-----Original Message----- From: Tim Devries [mailto:tdev@northrock.bm] Sent: 07 January 2005 02:28 To: Tim Devries Cc: 'Nick Shah '; 'cisc@puck.nether.net ' Subject: RE: [c-nsp] 3550 QoS not working as expected

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

_______________________________________________ cisco-nsp mailing list cisc@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco> -nsp archive at http://puck.nether.net/pipermail/cisco-nsp/