On Ethernet and Switchport interfaces, the "Discard" stat can be incremented for many different reasons; some indicating healthy network operation and others indicating a network issue. Understanding the discard stat is important to evaluating your network health in correlation with them. This document explains the discard stat thoroughly as well as offering reasons for why a discard is incremented and what action you should take, if any, when you see this.
Sections Included in this Document
Hardware and Software Requirements
Explanation of the Discard Stat
Situations Where a Discard is Incremented
Further Trouleshooting and Information
Hardware and Software Requirements
The discard stat appears on every Ethernet, Switchport, and VLAN interface in an AOS unit. For information on whether or not your unit has these interfaces, please see the AOS Feature Matrix - Product Feature Matrix.
Explanation of the Discard Stat
One of the biggest misconceptions concerning the discard statistic is that a discard is an error. In fact, examining the other Ethernet based stats (includes Switchports and VLANs) you will see there is a general set of errors called "input errors" and "output errors". Whenever one of the other statistics like "CRC errors" or "overruns" increments, so does one of these general error counters. When a discard increments, the input and output errors stay the same. What does this mean? That the discard stat is its own unique counter and should not be treated as an error.
In any healthy network, traffic needs to be discarded at certain points. Consider configuring a switchport to trunk mode. For security reasons, the administrator only allows VLANs 1 and 2 on the link with the switchport trunk allowed vlan 1,2 command. If a packet is received with a VLAN tag of 3, it will be dropped. In this case, a discard will be incremented indicating the interface is working as configured.
Additional reasons that a unit can increment a discard legitimately will be explained further in this document. Before continuing in this document, it is very important to remember that a healthy network will absolutely have discards and the presence of them does not necessarily indicate a network problem. The cause of discards should be investigated and troubleshot if they are incrementing at a high rate that can not be explained, or when they can be correlated to a specific network problem.
Situations Where a Discard is Incremented
When a packet/frame is received on an interface and when it is put in a queue to exit an interface, there are several checks that are run to make sure it is something that should be transmitted. The following sections discuss when a discard may be incremented on the different types of interfaces for one of these reasons. Note that this list only includes the most common reasons that a packet may be discarded - it does include every unique situation where it may occur. However, discards for other than the following reasons should be very rare, and in this case would not warrant the reason to troubleshoot discards anyway.
Layer 2 interfaces are considered to be switchport interfaces (all types), interfaces that function as switchports but have the Ethernet moniker (on the NetVanta 6355, 1224, and 7100), and Ethernet Subinterfaces (802.1q mode). A discard can be incremented for any of the following reasons:
For VLAN interfaces only
On Ethernet Ports only
VLANs and Ethernet Interfaces
#show process cpu
System load: 1sec:5.59% 1min:7.03% 5min:5.96% Min: 0.00% Max: 100.00%
Context switch load: 0.14%
Invoked Exec Time Runtime Load %%
Task Id Task Name PRI STA (count) (usec) (usec) (1sec)
1 Idle 0 W 608845940 233 942640 94.26
3 PC Config 7 S 499071177 968 13040 1.30
4 PacketRouting 38 W 766295348 49 17963 1.80
5 Timer 39 W 472845169 13 5659 0.57
6 Thread Pool 4 W 12026 120 0 0.00
7 Timer-00 10 W 488120549 2 1132 0.11
8 Nm01 5 W 0 1966 0 0.00
9 Clock 9 W 14334724 12 30 0.00
10 FrontPanel 37 W 97105578 64 1301 0.13
11 con0 39 W 83786 6 0 0.00
12 CF Manager 9 W 95424567 2 57 0.01
13 ICP Session 8 W 10810188 909 988 0.10
14 RouteTableTick 6 W 8061684 48 190 0.02
15 RouteTableTick 6 W 8104871 66 190 0.02
16 OSPF 6 W 13095560 264 365 0.04
17 IGMPTick 6 W 4850112 110 113 0.01
18 IGMP-Receiver 6 W 97162 31 0 0.00
19 IP Events 24 W 4965396 24 23 0.00
20 tcptimer 22 W 2717686 10 92 0.01
21 tcpinp 22 W 421589 156 502 0.05
22 tcpout 22 W 1341238 67 478 0.05
23 Port Manager 9 W 96136488 36 755 0.08
24 eth01 39 W 317655915 6 1319 0.13
25 eth02 39 W 1 2 0 0.00
26 SnmpThread 6 W 239578062 27 1173 0.12
27 WWW 19 W 1139607 38 0 0.00
28 DnsClient 16 W 2410161 25 0 0.00
29 DnsProxy 16 W 3563737 63 0 0.00
30 DnsTable 16 W 955533 8 0 0.00
31 sec 39 W 199770358 20 785 0.08
32 IKE 6 W 864911 61 0 0.00
33 IPSecKeyGen 4 W 0 463723 0 0.00
34 SCEP 6 W 0 461818 0 0.00
35 MediaConnectio~ 34 W 5229625 556 551 0.06
36 FTPServer List~ 5 W 0 460915 0 0.00
37 SMTP Client 16 W 1339 69 0 0.00
38 SNTP Client 19 W 57 21 0 0.00
39 Switch Managem~ 37 W 0 76 0 0.00
40 Switch Mainten~ 4 W 23873756 989 3938 0.39
41 Stacking 9 W 4778371 27 30 0.00
42 UCC3 39 W 64805586 3 642 0.06
43 RSTP 37 W 0 130 0 0.00
44 RSTP 37 W 1209743598 15 1859 0.19
45 CLIInjectQ 6 W 0 59603 0 0.00
48 RipOut 6 W 7822251 17 2024 0.20
49 RipIn 6 W 0 37080 0 0.00
50 UDP Relay 19 W 1 67 0 0.00
51 PacketCapture 4 W 9702057 39 78 0.01
52 PING Client 16 W 1736792 47 0 0.00
53 DHCP Server 29 W 13013 42 0 0.00
54 UDP In 36 W 3222258 109 0 0.00
55 Flow Meter Log~ 17 W 11133629 108 155 0.02
56 CFM Maint 38 W 4805227 26 26 0.00
57 OSPFv3 6 W 10364499 6 26 0.00
58 DHCP Client 19 W 733295 47 0 0.00
59 BGP Thread 6 W 10251697 5 130 0.01
60 TWAMP-Control 6 W 1018526 171 0 0.00
61 TWAMP-Test 16 W 1 11 0 0.00
62 TFTP 5 W 986871 28 0 0.00
63 AUTOLINKQ 4 W 0 173963 0 0.00
64 HttpClientQ 6 W 0 119685 0 0.00
65 ntpd 19 W 7264032 83 282 0.03
66 TFTPThreadPool 4 W 0 48761 0 0.00
67 TFTPThreadPool 4 W 0 48689 0 0.00
68 TFTPThreadPool 4 W 0 48568 0 0.00
69 TFTPThreadPool 4 W 0 48501 0 0.00
70 TFTPThreadPool 4 W 0 48433 0 0.00
72 DHCPv6 Server 29 W 1 199 0 0.00
146 MRouteTick 6 W 0 522 0 0.00
#show process queue
Queue Max Depth (%)
------------------------------ -------------
PC Config 7
PacketRouting 39
FrontPanel 0
ICP Session 1
RouteTableTick 2
RouteTableTick 2
OSPF 3
IP Events 3
IKE 1
IPSecKeyGen 0
MediaConnectionQueue 0
Switch Management 0
Switch Maintenance 7
Stacking 0
RSTP 0
RSTP 5
CLIInjectQ 0
PacketCapture 0
UDP In 76
Flow Meter Logging 2
CFM Maint 0
OSPFv3 4
BGP Thread 0
AUTOLINKQ 0
HttpClientQ 0
MRouteTick 0
#show int eth 0/1
...lines ommitted...
Interface Shaper: 50000/312500/312500 (rate/budget/max budget)
6250 bytes added to budget every 1 ms
packet stats: 197758/0/0/0 (packets sent/waiting/dropped/delayed)
It is important to note a couple of things before continuing with this section. First, as stated earlier in this document: discards are a normal byproduct of network operation. You should only be troubleshooting discards on your units if you notice an actual network problem that could correlate with them, or you notice them increment at an increased rate from the normal for that interface. Secondly, you should go through the above sections explaining the types of discards as well. Not only are the troubleshooting steps below based on these examples, but there are many implied troubleshooting steps you can take by going through the above sections. Not all of these will be covered below. For example, reading above you know that when the source and destination MAC address in a frame are equal, the frame is dropped. So this implies that if you see these types of frames in your network through some type of packet analyzer that would explain at least some of the discards. This is not directly discussed below because it was fully covered in the description section.
#show interface sw 0/1
swx 0/1 is UP, line protocol is UP
Description: AP
Hardware address is 00:A0:C8:00:E1:7A
BW is 10000 Kbit
100000b/s, negotiated full duplex, configured full-duplex
input flow control is disabled, 0 pause frames received
ARP type: ARPA; ARP timeout is 20 minutes
Last clearing of "show interface" counters: never
30 second input rate 1253742 bits/sec, 156 packets/sec
30 second output rate 976856 bits/sec, 123 packets/sec
Queueing method: fifo
Output queue: 0/256/0 (size/max total/drops)
Interface Shaper: NOT ENABLED
13423523 packets input, 12312412412 bytes
12536452 unicasts, 1232432 broadcasts, 243524 multicasts input
0 symbol errors, 122 discards
0 input errors, 0 runts, 0 giants
0 alignment errors, 0 crc errors
13422343 packets output, 13253434232 bytes
11242342 unicasts, 23424342 broadcasts, 123124 multicasts output
0 output errors, 0 deferred, 123 discards
0 single, 0 multiple, 0 late collisions
0 excessive collisions
show qos map int eth 0/1
eth 0/1
qos-policy out: Voip
map entry 10
match dscp 46
priority bandwidth: unlimited
note: since unlimited, other qos bandwidths cannot be assured
packets matched: 1232435, bytes matched: 1232453645
map entry default
packets matched: 624, bytes matched: 477490
packets dropped: 0, bytes dropped: 0
30 second offered rate 224040 bits/sec, drop rate 0 bits/sec
Input QoS Map not assigned for this interface
#show process queue
Queue Max Depth (%)
------------------------------ -------------
PC Config 7
PacketRouting 39
FrontPanel 0
ICP Session 1
RouteTableTick 2
RouteTableTick 2
OSPF 3
IP Events 3
IKE 1
IPSecKeyGen 0
MediaConnectionQueue 0
Switch Management 0
Switch Maintenance 7
Stacking 0
RSTP 0
RSTP 5
CLIInjectQ 0
PacketCapture 0
UDP In 76
Flow Meter Logging 2
CFM Maint 0
OSPFv3 4
BGP Thread 0
AUTOLINKQ 0
HttpClientQ 0
MRouteTick 0
Further Troubleshooting and Information
The best way to know what could be causing the discards in a network is to know your network. If you aren't aware of the protocols in your network, how they function, which types of hosts are connected to each interface, and so on, you wont be able to fully understand the root cause of discards. You should make sure you are familiar with the below:
In the end, the best way to troubleshoot discards is to take a packet capture on the interface or interfaces seeing the excess stat. This will tell you what is going on because you can see actual packets and match it with all the potential causes described above.
Several important notes to remember:
For more information on configuring Class of Service, please see Configuring Ethernet Switch QoS and CoS in AOS
For more information on network security, please see Security Best Practices for AOS Products
For more information about properly provision switches and network design recommendations, please see Switch Provisioning Best Practices
For more information on properly configuring VLANs, please see Configuring InterVLAN Routing in AOS - Quick Configuration Guide
.