[c-nsp] 3550 QoS not working as expected

[McCallum, Robert]

yep this is what the match ALLMac does

Robert McCallum 
CCIE #8757 R&S
01415663448
07818002241 

> -----Original Message-----
> From: Dmitry Valdov [mailto:dv at dv.ru] 
> Sent: 07 January 2005 09:04
> To: McCallum, Robert
> Cc: 'cisco-nsp at puck.nether.net '
> Subject: RE: [c-nsp] 3550 QoS not working as expected
> 
> 
> 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
>