• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 80
  • Last Modified:

Interface statistic on Cisco switch

An interface on a Cisco switch show Total Output drops is 776, txload 4/255. What does it indicates ? Does it tell something wrong for the cable or the device connecting to the switch ? How to improve this situation ?


GigabitEthernet1/0/14 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet, address is 381c.xxxx.xxxx (bia 381c.xxxx.xxxx)
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 4/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/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:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 776
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 44000 bits/sec, 73 packets/sec
  5 minute output rate 1821000 bits/sec, 152 packets/sec
     3457773 packets input, 964760961 bytes, 0 no buffer
     Received 31107 broadcasts (19813 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 19814 multicast, 0 pause input
     0 input packets with dribble condition detected
     4206341 packets output, 4232934589 bytes, 0 underruns
     0 output errors, 0 collisions, 1 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
  • 3
  • 2
2 Solutions
Output drops means that there is/was congestion on interface and that line speed should be increased (currently 100 Mb- Full-duplex).

4/255 Tx is measure of how utilized is link that is sending traffic (4/255 = 1.5686275%).
5 minute output rate 1821000 bits/sec, 152 packets/sec
255/255 - would mean that output is completely utilized (saturated).

Other than increasing line speed, Weighted Random Early Detection (WRED/DWRED) can be configured to drop some amount TCP packets randomly before interface starts to be congested.
Configuring bigger buffer is not recommended when interfaces are saturated.
AXISHKAuthor Commented:
"Output drop" - is it the packet sending out from the interface to the device (Wifi AP in my case) ?

Will there be a possibility that there is something wrong on the device (ie Wifi AP) ?

For 1821000 bits/sec, is it equivalent to 1.8Gb/s which exceed the interface througout of 100Mb/s ?

atlas_shudderedSr. Network EngineerCommented:
Actually, with the number of total output packets ,4206341, the 750 drops is negligible. The drops could be from momentary over subscription. It  oils also be due to windowing and duplex mismatching on the interface. If it is congestion, you can increase bandwidth or implement congestion management or avoidance.

As I said above, the impact of the current error rate is negligible. If it were me, I would clear the counters, keep an eye on things for increases to above 5% and otherwise, leave it be till it gets to a level that performance is going to begin to be impacted.

Worried about phishing attacks?

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

"Output drop" - is it the packet sending out from the interface to the device (Wifi AP in my case) ?
Will there be a possibility that there is something wrong on the device (ie Wifi AP) ?
Not really. Most likely it was a burst of traffic (or few bursts) when interface was congested.

Generally 750 drops is negligible if compared to total output packets amount as atlas_shuddered wrote, but generally in most networks environments 0.1% loss can be tolerated (5% is way too much of traffic loss for any modern network (even 1% is too much)). Rate currently is less than 0.1%, if users are not complaining it can be tolerated. If it started to appear recently should be monitored. So, atlas_shuddered suggestion to reset interface counters and monitor what is going on is valid option.

Regarding 5 minute output rate 1821000 bits/sec, 152 packets/sec
Does not make much sense as it is written, either it is bug related to counter or Cisco's way to calculate 5 minute rate (not sure how it is calculated). Especially with 4/255 tx load (1.6%).
AXISHKAuthor Commented:
You're welcome.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now