[c-nsp] Input queue flushes and drops

Mon Mar 1 19:28:41 EST 2010

Guys,

I tried increasing the input queue (up to 2048) with no results, input
flushes keep going up. Users still experiencing really bad VoIP performance
in that WAN link...

Rodney, I didn't turn off SPD as I'm not sure if that is going to break
other stuff. This is a production head office main ISR router...
Any ideas?

Thanks again,
J

On Mon, Mar 1, 2010 at 9:13 AM, Javi <cangurobostero at gmail.com> wrote:

> Thanks guys.
>
> 12.4(13r)T, we have a policy-map with 4 classes:
>
> policy-map QOS-OUT
>   class DSCP-OUT-RT-VO
>    priority 1110 138750
>    police cir 1110000 bc 138750 be 138750
>      conform-action set-dscp-transmit ef
>      exceed-action set-dscp-transmit ef
>      violate-action set-dscp-transmit ef
>  class DSCP-OUT-D1-RT
>     bandwidth percent 7
>      random-detect dscp-based
>      random-detect dscp 34 25 75 20
>      random-detect dscp 36 12 24 20
>   service-policy QOS-OUT-D1-RT
>  class DSCP-OUT-D2-BA
>     bandwidth percent 55
>      random-detect dscp-based
>      random-detect dscp 18 61 122 20
>      random-detect dscp 20 34 68 20
>   service-policy QOS-OUT-D2-BA
>  class DSCP-OUT-D3-TO
>     bandwidth percent 21
>      random-detect dscp-based
>      random-detect dscp 10 48 96 20
>      random-detect dscp 12 31 62 20
>   service-policy QOS-OUT-D3-TO
>  class DSCP-OUT-RT-VI
>     bandwidth percent 6
>     queue-limit 30 packets
>     police 460000 57500 57500 conform-action set-dscp-transmit af43
> exceed-action set-dscp-transmit af21 violate-action set-dscp-transmit
> default
>
>
>
> And sh int stats:
>
>  GigabitEthernet0/1
>           Switching path    Pkts In        Chars In      Pkts Out   Chars
> Out
>            Processor        311249998 1622425452  311496548 1640497685
>            Route cache    910779860  166070169  883679645  1324432555
>            Total              1222029858 1788495621 1195176193 2964930240
>
>
>
> I'll increase the interface input queue and monitor for a few hours.
> Cheers,
>
> Javi
>
>
>
> On Sun, Feb 28, 2010 at 11:26 AM, Rodney Dunn <rodunn at cisco.com> wrote:
>
>>
>>
>> On 2/26/10 1:57 AM, Javi in AUS wrote:
>>
>>> Gents,
>>>
>>> We have a WAN facing Cisco 3845 which is showing the numbers below on
>>> it's
>>> Gi0/1 interface:
>>>
>>>  Input queue: 0/75/9/71805 (size/max/drops/flushes); Total output drops:
>>> 714432
>>>
>>>
>> Turn off SPD:
>>
>> config t
>> no spd enable
>> end
>>
>>
>>
>>
>>
>>> Of course, these counters are increasing and we have a bunch of users at
>>> the
>>> other side of the link complaining about poor VoIP performance (they hear
>>> us intermittently although we can hear them Ok).
>>> CEF is enabled globaly, input queue is set to default (75).
>>>
>>> GigabitEthernet0/1 is up, line protocol is up
>>>   Hardware is BCM1125 Internal MAC, address is 001b.d37d.f8a2 (bia
>>> 001b.d37d.f8a2)
>>>   Internet address is 10.83.2.17/30
>>>   MTU 1500 bytes, BW 20000 Kbit/sec, DLY 100 usec,
>>>      reliability 255/255, txload 11/255, rxload 10/255
>>>   Encapsulation ARPA, loopback not set
>>>   Keepalive set (10 sec)
>>>   Full-duplex, 100Mb/s, media type is RJ45
>>>   output flow-control is XON, input flow-control is XON
>>>   ARP type: ARPA, ARP Timeout 04:00:00
>>>   Last input 00:00:00, output 00:00:00, output hang never
>>>   Last clearing of "show interface" counters 3w3d
>>>   Input queue: 0/75/9/71805 (size/max/drops/flushes); Total output drops:
>>> 714432
>>>   Queueing strategy: Class-based queueing
>>>   Output queue: 0/1000/0 (size/max total/drops)
>>>   30 second input rate 848000 bits/sec, 634 packets/sec
>>>   30 second output rate 874000 bits/sec, 604 packets/sec
>>>      1146444284 packets input, 1913512714 bytes, 0 no buffer
>>>      Received 1785 broadcasts, 0 runts, 0 giants, 1 throttles
>>>      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
>>>      0 watchdog, 6993 multicast, 0 pause input
>>>      0 input packets with dribble condition detected
>>>      1121611018 packets output, 2544901813 bytes, 0 underruns
>>>      0 output errors, 0 collisions, 0 interface resets
>>>      0 unknown protocol drops
>>>      0 babbles, 0 late collision, 0 deferred
>>>      0 lost carrier, 0 no carrier, 0 pause output
>>>      0 output buffer failures, 0 output buffers swapped out
>>>
>>>
>>>
>> What is your policy doing on that interface for the output drops?
>>
>> sh policy-map interface gig 0/1
>>
>> What does 'sh int stat' show...the input queue is only for process
>> switched traffic so you need to figure that out?
>>
>> What code?...12.4(20)T and later you can do an EPC trace on the punt path
>> coming in the interface to see what traffic it is.
>>
>> Or try to catch the packets in 'sh buffers input-interface gig 0/1 packet'
>>
>>
>>
>>
>> Should we increase the input queue size to 150,200,250, etc ? Could these
>>> flushed/drops be the cause of the poor VoIP performance?
>>>
>>
>> Yeah..set it to the max of 4096.
>>
>> Rodney
>>
>>
>> Many thanks,
>>>
>>> P
>>> _______________________________________________
>>> 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/
>>>
>>
>