This action can be queuing, shaping, and policing. Hardware is Gigabit Ethernet, address is b4a4.e3ab.4181 (bia can determine what type of QoS action will be taken once the packet has been classified. I have also included a screenshot showing traffic graph. which in my opinion is not possible based on the traffic traversing the link. I replied but it seems like it disappeared? Here is the output you requested (as well as show int to illustrated 18 drops shortly after I cleared the counters.) Based on what I'm seeing, the packets are just dropping from the output queue but based on the numbers, the link is nowhere near saturated. Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec) RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec) OHQ: pkts in output hold queue OQD: pkts dropped from output queue IHQ: pkts in input hold queue IQD: pkts dropped from input queue Input queue: 0/75/0/0 (size/max/drops/flushes) Total output drops: 18ģ0 second input rate 26380000 bits/sec, 3564 packets/secģ0 second output rate 34062000 bits/sec, 5059 packets/secģ89531 packets input, 360361208 bytes, 0 no bufferĠ input errors, 0 CRC, 0 frame, 0 overrun, 0 ignoredĠ input packets with dribble condition detectedĥ35531 packets output, 442964566 bytes, 0 underrunsĠ output errors, 0 collisions, 0 interface resetsĠ lost carrier, 0 no carrier, 0 pause outputĠ output buffer failures, 0 output buffers swapped out Last clearing of 'show interface' counters 00:01:43 Last input never, output 00:00:01, output hang never Input flow-control is off, output flow-control is unsupported Hardware is Gigabit Ethernet, address is b4a4.e3ab.4181 (bia b4a4.e3ab.4181) GigabitEthernet1/0/1 is up, line protocol is up (connected) Interface GigabitEthernet1/0/1 queueing strategy: none so it would have to be a burst, since the link isn't generally saturated? And based on the output, it just looks like the link is saturated, being the drops are from the output queue. I just cleared the counters before running the commands to illustrate there were 18 drops already soon after I cleared them. I have included the show int output as well as the output you requested. People would be pulling files through these links, so a large amount of data can make sense, but why would TCP allow it if it was literally one connection (one client to one server?) Any insight is appreciated. I find the burst theory hard to believe because all of these servers would not be generating that much traffic at any given time. Can this be a hardware issue with the switch? There are no errors, nothing. It's also perplexing that the other interfaces show many drops as well. I would expect to see something somewhere explaining these drops. Are bursts really creating all of these drops? But it's nearly constant. I understand the polling interval may prevent me from seeing bursts, or maybe not.

I use PRTG to monitor traffic and that interface never shows more than around 150 Mbps. I never see anything in the output queue either. If I sit there and run show int every few seconds, the number essentially continually increments, but the input rate (set to 30 seconds, so I'm kind of just guessing) doesn't add up.

I have a switch that shows a lot of drops on just about all interfaces that have a device connected to them (VMhosts with lots of servers.) The main interface in question is an uplink to an ASA, essentially the gateway for those devices on the switch, which shows many many many more drops (which could be expected.) That interface, full duplex 1 Gbps.

Cisco interface queue fifo