Introduction
Understanding “Input Discard” Interface Counter in Nexus 3000
Nexus 3000 - Product Overview
The Cisco Nexus 3000 Switch is a high-performance, high-density, ultra-low-latency Ethernet switch. This compact one-rack-unit (1RU) form factor 10 Gigabit Ethernet switch provides line-rate Layer 2 and Layer 3 switching. The switch runs the industry-leading Cisco NX-OS Software operating system, providing customers with comprehensive features and functionality that are widely deployed globally.
“Input Discard” Interface Counter in Nexus 3000
As in other Catalyst and Nexus products, Nexus 3000 also has “show interface ethernet x/y” command.
N3k-A# show interface eth1/1
Ethernet1/1 is up
Hardware: 10/100/1000 Ethernet, address: 547f.ee3f.9c68 (bia 547f.ee3f.9c68)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
Port mode is trunk
full-duplex, 1000 Mb/s
Beacon is turned off
Input flow-control is off, output flow-control is off
Switchport monitor is off
EtherType is 0x8100
Last link flapped 3d18h
Last clearing of "show interface" counters 3d18h
30 seconds input rate 2272 bits/sec, 284 bytes/sec, 3 packets/sec
30 seconds output rate 8304 bits/sec, 1038 bytes/sec, 13 packets/sec
Load-Interval #2: 5 minute (300 seconds)
input rate 2.15 Kbps, 3 pps; output rate 7.58 Kbps, 12 pps
RX
0 unicast packets 1344749 multicast packets 0 broadcast packets
1344749 input packets 98148908 bytes
0 jumbo packets 0 storm suppression packets
0 giants 0 input error 0 short frame 0 overrun 0 underrun
0 watchdog 0 if down drop 0 input with dribble 3 input discard(includes ACL drops)
0 Rx pause
TX
0 unicast packets 4772275 multicast packets 0 broadcast packets
4772275 output packets 342602114 bytes
0 jumbo packets
0 output errors 0 collision 0 deferred 0 late collision
0 lost carrier 0 no carrier 0 babble
0 Tx pause
1 interface resets
N3K-A#
In releases earlier to 5.0(3)U2(1), the “show interface ethernet x/y” report input discard counters just as “input discard” without “(includes ACL drops)”.
Bug CSCto53539
CSCto53539 - Interface discard counters increment even when packets are not forwarded
CSCto53539 has ONLY changed how the counter is reported in the “show interface eth x/y” results:
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCto53539
This bug is fixed in 5.0(3)U2(1) or later releases.
The redirection of certain protocol packets e.g. PIM/IGMP happens in N3K ASIC via an ACL entry. The packet is qualified using the ACL match actions ( e.g., IP protocol == PIM ) and one of the actions of this ACL would be to copy the packet to CPU. Since the protocol packets are typically required to be handled only by the CPU and are not expected to get forwarded, this ACL also had a DROP action. This way a copy of the packet would go to CPU and then the packet would get dropped in the hardware emulating the desired behavior.
However, drop action from an ACL on an incoming packet is counted as indiscards on the receive interface. Because of this all the legitimate CPU bound protocol packets that get redirected this way would contribute to the indiscards. Considering this an additional description was added in CLI to say "includes ACL drops" for such packets.
Getting further details on Input Discard counter
To get more granular details, it is recommended to use following command:
To get the statistics from Eth1/1:
N3k-A# show hardware internal interface indiscard-stats front-port 1
+---------------------+-------+----------------+---------------------+
| Counter Description | Count | Last Increment | Last Increment Time |
+---------------------+-------+----------------+---------------------+
IPv4 Discards 0 0
STP Discards 2 2 04-23-2012 17:47:04.558
Policy Discards 0 0
ACL Drops 0 0
Receive Drops 2 2 04-23-2012 17:47:04.558
Vlan Discards 0 0
+---------------------+-------+---------------+----------------------+
Please be aware of CSCtu29771, due to which the above command reports all counters as zero, even though the “show interface” reports non-zero input discards. This bug is fixed in 5.0(3)U3(1) or later releases.
Release note for CSCtu29771:
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtu29771
Details of the counters
IPv4 Discards
IPv4 Discards represent errors at IP layer e.g., IP checksum error
STP Discards
STP Discards are incremented when packets are received when interface is not in STP forwarding state
Policy Discards
Policy Discards are incremented when there are discards because of input policy on the interface e.g., storm control
ACL drops
ACL drops indicate that incoming packets match an ACL entry with a drop action.
This can increment under following conditions:
(1) When user configured ACL denies the traffic.
(2) When interface receives the link local multicast packets (EIGRP/PIM/BFD hello’s).
Reason being, internally the packet is getting copied to CPU, and dropped by the ACL Drop.
(3) "STP Discards" action is hit.
Through an enhancement (CSCtx63122), from 5.0(3)U3(1) onwards Nexus 3000 will NOT increase "ACL Drops" counter (and hence "input discard" under "show interface") due to control-plane packets like IGMP/PIM/BFD etc. except Precision Time Protocol (PTP) packets.
Receive Drops
This counter is a wrapper counter which represents a condition where no output port could be determined for this packet. From ASIC perspective, Receive Drop is almost a catch-all for all conditions. Some of the common conditions could be:
- - Vlan check failed
- - MTU check failed
- - "ACL Drops" action is hit
- - Traffic destined to a non-existing route
- - Traffic destined to an IP address for which ARP entry is incomplete
- - Multicast traffic getting dropped as the (S, G) has null OIF
It will be challenging to come up with a comprehensive list of all possible conditions. This counter is incremented if the forwarding result at the end of the ingress pipeline (in the forwarding decision making process) is zero, which means, no egress port identified.
Sample Scenario
Assume that there is a static mac-address entry for mac-address M2 in vlan V2 mapped to port P2.
If a frame with source mac-address M2 received in vlan V2 on P1. In this condition, source mac-address learning cannot happen for this frame and this frame will be dropped.
Vlan Discard
Vlan Discard indicates vlan-based discards e.g., vlan tagged packet ingressing on a port which is not member of the vlan.
Further Enhancement
Enhancement request CSCtx60271 has been filed modify the counters considered for "input discards" counters under "show interface".
With this fix, now the "input discards" counter does not include following counters:
- ACL (RACL/VACL/PACL) drops
- IGMP/BFD packets dropped by CoPP - while the packet rate is higher than 1000 packets/second
- DeJavu scenario - packets received and sent out on the same port or port-channel, with no modifications to the packet.
Release note for CSCtx60271:
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtx60271
N3k-A# show queuing interface eth 1/1
Ethernet1/1 queuing information:
TX Queuing
qos-group sched-type oper-bandwidth
0 WRR 100
RX Queuing
qos-group 0
HW MTU: 1500 (1500 configured)
drop-type: drop, xon: 0, xoff: 0
Statistics:
Ucast pkts sent over the port : 0
Ucast bytes sent over the port : 0
Mcast pkts sent over the port : 0
Mcast bytes sent over the port : 0
Ucast pkts dropped : 0
Ucast bytes dropped : 0
Mcast pkts dropped : 0
Mcast bytes dropped : 0
N3k-A#
Further Information on Nexus 3000
Nexus 3000 – Products Data Sheet
http://www.cisco.com/en/US/products/ps11541/products_data_sheets_list.html
Software Download page
http://www.cisco.com/cisco/software/navigator.html?mdfid=283734368&i=rm
Relevant Document
Nexus 3500 Series Switch Platform System Health Check Process
http://www.cisco.com/en/US/products/ps13383/products_tech_note09186a0080c1e9f2.shtml
For comments and feedback, please contact the author Yogesh Ramdoss at yramdoss@cisco.com
