[c-nsp] Ang: ME3600X Output Drops

[Pshem Kowalczyk]

Hi All,

I think we have finally got rid of the drops on ME3600X by using the
following config on each EVC:

policy-map PM-CUST-DEFAULT-20M-OUT
 description limiting to 20 Mbps
 class CM-DUMMY
 class class-default
  shape average 20000000
  queue-limit percent 100

The key for us was 'queue-limit percent 100'. With statically defined
queue depth, even with 2MB of buffer per EVC we were getting drops on
4Mb/s flows. I was told that with this sets the buffers to dynamically
allocated as needed.
This is using 15.3(2)S.

kind regards
Pshem

On 21 August 2012 21:32,  <Gustav.Ulander at steria.se> wrote:
> We have the same problem on our 3600X devices.
> Look at bugg CSCua16046
> We belive that is the bug that we are encountering. Havent updated software
> on the device yet though.
>
>
> -----cisco-nsp-bounces at puck.nether.net skrev: -----
> Till: cisco-nsp at puck.nether.net
> Från: "Ivan"
> Sänt av: cisco-nsp-bounces at puck.nether.net
> Datum: 2012-08-21 01:49
> Ärende: [c-nsp] ME3600X Output Drops
>
>
> Hi,
>
> I am seeing output drops on a ME3600X interface as shown below
>
> GigabitEthernet0/2 is up, line protocol is up (connected)
>   MTU 9216 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
>      reliability 255/255, txload 29/255, rxload 2/255
>   Encapsulation ARPA, loopback not set
>   Keepalive set (10 sec)
>   Full-duplex, 1000Mb/s, media type is RJ45
>   input flow-control is off, output flow-control is unsupported
>   ARP type: ARPA, ARP Timeout 04:00:00
>   Last input 6w1d, output never, output hang never
>   Last clearing of "show interface" counters 00:12:56
>   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 231
>   Queueing strategy: fifo
>   Output queue: 0/40 (size/max)
>   30 second input rate 10299000 bits/sec, 5463 packets/sec
>   30 second output rate 114235000 bits/sec, 12461 packets/sec
>      3812300 packets input, 705758638 bytes, 0 no buffer
>      Received 776 broadcasts (776 multicasts)
>      0 runts, 0 giants, 0 throttles
>      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
>      0 watchdog, 776 multicast, 0 pause input
>      0 input packets with dribble condition detected
>      9103882 packets output, 10291542297 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
>
> I have read about similar issues on the list:
> http://www.gossamer-threads.com/lists/cisco/nsp/157217
> https://puck.nether.net/pipermail/cisco-nsp/2012-July/085889.html
>
> 1. I have no QoS policies applied to the physical interface or EVCs.
> Would increasing the hold queue help?  Is there a recommended value - the
> maximum configurable is 240000.  What is the impact on the 44MB of packet
> buffer.
>
> 2. If the hold queue isn't an option is configuring QoS required to
> increase the queue-limit from the default 100us.  Again are there any
> recommended values and what impact is there on the available 44MB of
> packet buffer.
>
> 3. I have found that when applying policies to the EVCs the "show policy
> map" output does not have information for the queue-limit as I have seen
> when applying polices to the physical interface.  Does this mean that EVCs
> will still suffer from output drops?
>
> Thanks
>
> Ivan
>
> _______________________________________________
> 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/