[c-nsp] 3550 QoS not working as expected

[Dmitry Valdov]

On Fri, 7 Jan 2005, McCallum, Robert wrote:

> Tim try this - it works for me.

Does it work for non-IP traffic? Can you please check this to be sure?

>
> 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:tdevries at northrock.bm]
>> Sent: 07 January 2005 02:28
>> To: Tim Devries
>> Cc: 'Nick Shah '; 'cisco-nsp at 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 '; '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
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco> -nsp
>> archive at
>> http://puck.nether.net/pipermail/cisco-nsp/
>>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

-- 
Dmitry Valdov                  mailto:dv at dv.ru
CCNP