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

Jon Allen Boone ipmonger at delamancha.org
Thu Oct 21 19:56:06 EDT 2004


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/
>>>>>
>>>
>



More information about the cisco-nsp mailing list