Pct Discards Out is calculated as follows: decode((NH_MATH.SUBTRACT((ifInUcastPkts + ifOutUcastPkts + ifInNUcastPkts + ifOutNUcastPkts + ifInErrors + ifInDiscards + ifInUnknownProtos),(ifInUcastPkts + ifInNUcastPkts + ifInErrors + ifInDiscards + ifInUnknownProtos))),0.00,0.00,(((100.0)*(NH_MATH.SUBTRACT((ifInDiscards + ifOutDiscards),ifInDiscards)))/NULLIF((NH_MATH.SUBTRACT((ifInUcastPkts + ifOutUcastPkts + ifInNUcastPkts + ifOutNUcastPkts + ifInErrors + ifInDiscards + ifInUnknownProtos),(ifInUcastPkts + ifInNUcastPkts + ifInErrors + ifInDiscards + ifInUnknownProtos))),0)))
Using example data values for a 5 minute sample where Discards Out % was above 100%, the following variables of note recorded the following values:
outputQueueDrops = 9035
discardsOut = 9035
framesOut = 1421
UnicastOut = 1421
In effect, the calculation being performed to arrive at the Discards Out % value is:
(100 * 9035) / 1421 = 635.81984517945109078114004222379
Basically, Discards Out are multiplied by 100 to get the percentage, and divided by the number of Frames (packets) Out.
There was an anomaly at this example poll where Discards Out increased considerably, apparently due to Output Queue Drops.
Output drops are caused by a congested interface. For example, the traffic rate on the outgoing interface cannot accept all packets that should be sent out. The ultimate solution to resolve the problem is to increase the line speed. However, there are ways to prevent, decrease, or control output drops when you do not want to increase the line speed. You can prevent output drops only if output drops are a consequence of short bursts of data. If output drops are caused by a constant high-rate flow, you cannot prevent the drops. However, you can control them.
When packets are processed, they are sent to the output queue of the outgoing interface. Issue the show interfaces exec command to view the size of the queue, the current number of packets in the queue, and the number of drops. Based on the type of interface and the type of queueing configured, the number of output queue drops is not explicitly shown, because the output drops counter summarizes the output drops separately at the processing level and at the interrupt level.
However, it takes longer to process a packet than to sent the packet from the output queue to the wire. Therefore, it is highly unlikely that output queue drops (drops at processing level) can occur without drops at interrupt level. Output queue drops occur only if the interface is already congested at interrupt level, so that packets cannot be pulled out of the output queue before the queue becomes full. Therefore, output drops at processing level (output queue drops) and output drops at interrupt level always occur together, and there is practically no need to distinguish between these two counters.
However, there is one exception. If the output queue is constantly full and if no packets are sent out of the interface at all, you must check for a hardware failure on the interface.
This type of issue with router interfaces is due to the performance and/or configuration of the router. In cases like this, the router admin needs to review the device and take the appropriate corrective measures.