Replying to my own message.... * Adjusting the hold queue didn't help.
* Applying QOS and per referenced email stopped the drops immediately - I used something like the below: policy-map leaf class class-default queue-limit 491520 bytes policy-map logical class class-default service-policy leaf policy-map root class class-default service-policy logical * I would be interested to hear if others have ended up applying a similar policy to all interfaces. Any gotchas? I expect any 10Gbps interfaces would be okay without the QoS - haven't seen any issue on these myself. *Apart from this list I have found very little information around this whole issue. Any pointers to other documentation would be appreciated. Thanks Ivan Ivan > 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 [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
