cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
35763
Views
22
Helpful
4
Comments
Yogesh Ramdoss
Cisco Employee
Cisco Employee

 

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

Comments

 There are some "input discard" by "show interface ethernet1/x" command,and "input discard" counter is basically equal to unicast packets,there is no "Ucast pkts dropped " by "show que interface".

What's reason about this symptom? Is it that the unicast packets arriving at the incoming interface can not find the outgoing interface?

Yogesh Ramdoss
Cisco Employee
Cisco Employee

@Rps-Cheers 

 

You are right.

 

When one sees "input discards" under "show interface ..." it is reported from the counters at MAC level (Please be aware, there are some counters in this command that are also obtained from software level). Input discards indicate that the switch is not able to find valid egress interface for the packets received and dropping them as expected. E.g., on a L2 trunk port receiving a packet with .1Q tag of 50, while vlan 50 is not in the VLAN database of the switch.

 

"show queueing ..." statistics come after MAC/PHY level check. The drop counters in this command indicate valid packets in the buffer and getting dropped for various reasons. E.g., over-subscription.

 

Hope this helps. Thanks for choosing Cisco Systems!

@Yogesh Ramdoss Can you give some suggestions, and then do this to solve this problem?

Yogesh Ramdoss
Cisco Employee
Cisco Employee

@Rps-Cheers 

 

First of all, I don't it is a problem at all, unless someone reports packet loss and this switch/port identified as the cause. The indiscards may be reported for packets that should be dropped.

 

I am not aware of any method to find details of the packets that are getting discarded, directly from the switch. You can do RX SPAN on that port and review the packets to see if there is any packet unexpectedly received on that port.

 

To address this type of challenge, next-gen platforms start to support SPAN-on-Drop feature. This feature helps to capture the packets that switch looked up for forwarding decision and decided to drop.

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: