C3560 output drop without mls qos enabled

[oldcreek12]

Hi, We are seeing output drops on a C3560 switchport, this port does not have QoS enabled -- application does not need special qos treatment, as long as packets are not droppd, so I suppose all traffic will share the same queue? then how should I read the output of "show platform port-asic stats drop" which indicates that it is queue 3 weight 2 drop? I am wondering what is the best way to fix this? enable mls QoS and increase queue 3 bandwidth share on this interface or just increase the output queue depth?

switch#sh mls qos interface gi0/1

GigabitEthernet0/1

QoS is disabled. When QoS is enabled, following settings will be applied

trust state: not trusted

trust mode: not trusted

trust enabled flag: ena

COS override: dis

default COS: 0

DSCP Mutation Map: Default DSCP Mutation Map

Trust device: none

qos mode: port-based

switch#sh int gi0/1

GigabitEthernet0/1 is up, line protocol is up (connected)

  Hardware is Gigabit Ethernet, address is 001e.bde3.c1a1 (bia 001e.bde3.c1a1)

  Description: logmaster2 eth1

  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

     reliability 255/255, txload 117/255, rxload 2/255

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX

  input flow-control is off, output flow-control is unsupported

  ARP type: ARPA, ARP Timeout 04:00:00

  Last input never, output 00:00:01, output hang never

  Last clearing of "show interface" counters 3d22h

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 24199725 <==

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  5 minute input rate 7862000 bits/sec, 14850 packets/sec

  5 minute output rate 460070000 bits/sec, 38574 packets/sec

     3565966292 packets input, 239033290582 bytes, 0 no buffer

     Received 98 broadcasts (0 multicasts)

     0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

     0 watchdog, 0 multicast, 0 pause input

     0 input packets with dribble condition detected

     9204042236 packets output, 13623898947333 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

     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

switch#sh int gi0/1 counters errors

Port        Align-Err     FCS-Err    Xmit-Err     Rcv-Err  UnderSize  OutDiscards

Gi0/1             0           0           0           0          0     24232544 <==============

Port      Single-Col  Multi-Col   Late-Col  Excess-Col  Carri-Sen      Runts     Giants

Gi0/1            0          0          0           0          0          0          0

switch#show platform port-asic stats drop gig 0/1

  Interface Gi0/1 TxQueue Drop Statistics

    Queue 0

      Weight 0 Frames 0

      Weight 1 Frames 0

      Weight 2 Frames 0

    Queue 1

      Weight 0 Frames 0

      Weight 1Frames 0

      Weight 2 Frames 0

    Queue 2

      Weight 0 Frames 0

      Weight 1 Frames 0

      Weight 2 Frames 0

    Queue 3

      Weight 0 Frames 0

      Weight 1 Frames 0

      Weight 2 Frames 1041431734 <==

[oldcreek12]

Looks like many people had similar problem with C3560 output drop when qos is disabled, yet I did not see a definitive answer for it, according to this url (very useful)

https://supportforums.cisco.com/docs/DOC-8093

enabling mls qos might help, but this is not an option for us because I fear that enabling qos will cause other ports to drop packets if queue/threshhold settings are not fine tuned. How do I increase output buffer on 3560?

[siddiqirf]

can you not enable mpls qos under a specific interface only instead of doing it globally on the device?

[oldcreek12]

Not really.

[Joseph W. Doherty]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

Most have the opposite issue, i.e. they enable QoS and see drops which they didn't have previously (due to resource sharing across the activated queues).

Unsure you can do any resource tuning without enabling QoS.  But if that's true, you might obtain fewer drops with active QoS custom tuned.  (NB: I agree with Jiangu, the document he references is very good.)

Only other easy (?) alternative might be to increase bandwidth for this port, e.g. Etherchannel or 10g.

[benjammin]

You can adjust the tx-ring-limit without enabling QoS globally. Also the command sh controllers might be useful

[oldcreek12]

hmm, are you sure? correct me if I am wrong, but we are talking about ASIC hardware queues here, not IOS software queue.

[benjammin]

The default queueing is first in first out i.e.'Queueing strategy: fifo'

If you're putting too much into the queue that it's causing drops, increasing the tx ring would allow you to put more in. I'm not suggesting it will solve the issue completely, but may mitigate it.

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

Logically this is a good suggestion.  I've often manipulated tx-ring-limit on ISRs, but didn't think of it for a Catalyst switch.  I was just on a 3750, and the command appears as an interface command.  Looking at the various Ethernet controllers stats, though, didn't see a tx-ring-limit size, so the command might be a no-op.  However, could be worth trying.