[c-nsp] Rate limiting problem under 12.0(27) S1

[Rodney Dunn]

Ok...that's it.  I'll write a document for
CCO on this so I don't have to explain it
upteen million more times.  I'll post a link
when I can get time to do it and get it on CCO.

Rodney

On Thu, Oct 21, 2004 at 07:56:06PM -0400, Jon Allen Boone wrote:
> Rodney,
> 
>    Thanks!  Yes, it *is* the RSP-based WFQ problem.  Enabling VIP-based 
> WFQ has fixed it.
> 
> --jon
> 
> On Oct 21, 2004, at 17:44, Rodney Dunn wrote:
> 
> > You are not dCEF switching packets out this interface.
> >
> > uh oh..is this the RSP based WFQ problem yet again?
> >
> > Can you post:
> >
> > sh run int se 4/0/0/22:0
> > sh int se 4/0/0/22:0
> >
> > If the Queueing on the interface in the 'sh int' output
> > says "weighted-fair' vs. VIP-based WFQ then that's
> > your problem.
> >
> > Either do "fair-queue" to turn on distributed WFQ
> > or either do "no fair-queue" to do FIFO queueing on
> > the interface.  Then check 'sh int stat' and make
> > sure all the packets are being dCEF switchined out
> > the interface.
> >
> > Rodney
> >
> >
> > On Thu, Oct 21, 2004 at 02:18:38PM -0400, Jon Allen Boone wrote:
> >>
> >> On Oct 20, 2004, at 14:35, Rodney Dunn wrote:
> >>
> >>> Can you do:
> >>>
> >>> clear count
> >>>
> >>> wait 30 seconds:
> >>>
> >>> sh int Serial4/0/0/22:0 stat
> >>
> >> Serial4/0/0/22:0
> >>            Switching path    Pkts In   Chars In   Pkts Out  Chars Out
> >>                 Processor          6         96          6         96
> >>               Route cache          0          0       2527    3129504
> >>         Distributed cache       1123      70857          0          0
> >>                     Total       1129      70953       2533    3129600
> >>
> >>> wait 30 seconds:
> >>>
> >>> sh int Serial4/0/0/22:0 stat
> >>
> >> Serial4/0/0/22:0
> >>            Switching path    Pkts In   Chars In   Pkts Out  Chars Out
> >>                 Processor         12        192         12        192
> >>               Route cache          0          0       4585    5791945
> >>         Distributed cache       2337     185226          0          0
> >>                     Total       2349     185418       4597    5792137
> >>
> >>
> >>> I want to understand if you are dCEF switching
> >>> all the traffic going in/out this interface.
> >>>
> >>> Did you confirm on the downstream router it's indeed
> >>> not being rate limited?
> >>>
> >>
> >> downstream is a customer router - the snmp stats of the access router
> >> confirm that the rate-limiting doesn't work.  for testing purposes, I
> >> generated traffic using ping on a host, routing it through this
> >> interface to the customer.  Regardless of whether rate-limiting was
> >> applied or not, the load-average (both 30 sec and 5 min) and snmp
> >> indicate that rate-limiting isn't being done properly.
> >>
> >>> What we suggest is that if you are trying to do rate-limiting
> >>> on an interface you do it with MQC:
> >>
> >>    i'm going to give this a try
> >>
> >>>
> >>> policy-map test
> >>> class class-default
> >>>   police <blah>
> >>>
> >>> and then attach the service-policy in or out.
> >>>
> >>> Rodney
> >>>
> >>>
> >>> On Wed, Oct 20, 2004 at 02:21:09PM -0400, Jon Allen Boone wrote:
> >>>> Sorry, code version (in subject line) 12.0(27)S1.
> >>>>
> >>>> here's the relevant portion of an example config:
> >>>>
> >>>> interface Serial4/0/0/22:0
> >>>>   ip address XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX
> >>>>   no ip redirects
> >>>>   no ip directed-broadcast
> >>>>   no ip proxy-arp
> >>>>   rate-limit input 512000 64000 64000 conform-action transmit
> >>>> exceed-action drop
> >>>>   rate-limit output 512000 64000 64000 conform-action transmit
> >>>> exceed-action drop
> >>>>   encapsulation ppp
> >>>>   down-when-looped
> >>>> end
> >>>>
> >>>>
> >>>> Serial4/0/0/22:0
> >>>>    Input
> >>>>      matches: all traffic
> >>>>        params:  512000 bps, 64000 limit, 64000 extended limit
> >>>>        conformed 60339508 packets, 11592M bytes; action: transmit
> >>>>        exceeded 50024 packets, 63884982 bytes; action: drop
> >>>>        last packet: 32ms ago, current burst: 0 bytes
> >>>>        last cleared 5w1d ago, conformed 29716 bps, exceeded 163 bps
> >>>>    Output
> >>>>      matches: all traffic
> >>>>        params:  512000 bps, 64000 limit, 64000 extended limit
> >>>>        conformed 4697 packets, 5143576 bytes; action: transmit
> >>>>        exceeded 0 packets, 0 bytes; action: drop
> >>>>        last packet: 418016928ms ago, current burst: 0 bytes
> >>>>        last cleared 5w1d ago, conformed 13 bps, exceeded 0 bps
> >>>>
> >>>> SNMP traffic stats confirm that the rate limits aren't being
> >>>> honored...
> >>>>
> >>>> --jon
> >>>>
> >>>> On Oct 20, 2004, at 14:07, Rodney Dunn wrote:
> >>>>
> >>>>> Do you see the same problem if you use MQC with
> >>>>> a policer?
> >>>>>
> >>>>> That's the way we prefer it be done.
> >>>>>
> >>>>> btw, code version and interface configuration?
> >>>>>
> >>>>> Rodney
> >>>>>
> >>>>> On Wed, Oct 20, 2004 at 01:54:35PM -0400, Jon Allen Boone wrote:
> >>>>>> Folks,
> >>>>>>
> >>>>>>    I'm experiencing problems with CAR on a 7507+VIP2/50+PA-MC-T3.
> >>>>>> It
> >>>>>> appears that CAR is not properly rate-limiting traffic on either
> >>>>>> input
> >>>>>> or output.  Is this a known issue?  I'm having trouble getting Bug
> >>>>>> Tracker to return known bugs on this version of the IOS.
> >>>>>>
> >>>>>> --jon
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> 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/
> >>>>>
> >>>
> >