Showing results for 
Search instead for 
Did you mean: 

Port inbound Discard High (Device Congestion)

yusuf habibi
Level 1
Level 1

Hi all,


What cause event on tools monitoring is "Port inbound Discard High (Device Congestion)" . everyday  events always appear on tools monitoring only for one Vlan.

I went looking for input errors on the port, but there are none, and the interface is running normal. So, what is a discard, and how do I troubleshoot it?



Regards, Habibi
5 Replies 5

Leo Laohoo
Hall of Fame
Hall of Fame
I went looking for input errors on the port, 

Post the output to the command "sh interface <Physical PORT>".

Hi leo,


thx for response,

already check for all physical interface and Vlan interface, zero input error count.


see the attachment, the event on monitoring tools





Regards, Habibi

Vikram Sisodia
Cisco Employee
Cisco Employee

I was looking up a similar case for ASR-9001 platform IOS XR code 4.3.2 and alerts looked like below:interface_alert.JPG


As I further checked on this the interface counters looked clean and there were no drops and signs of congestion/discards. All of the ingress and egress packets were forwarded in normal way and I could also see no dot1q frames were identified on  the interface that may have been dropped due to wrong VLAN encapsulations as per the counter explanations from below URL:

“InDiscards” are almost always caused by a port that is receiving tagged frames for a VLANID that that port is not a member of.


So as per the observations the reported alarm seems false and could not be related to counters on the interfaces:

The interface stats look clean and I do not see any discards for legitimate traffic:

Statistics for interface GigabitEthernet x/x/x/x (cached values):


    Input total bytes           = 33080084

    Input good bytes            = 33080084


    Input total packets         = 184799

    Input 802.1Q frames         = 0

    Input pause frames          = 0

    Input pkts 64 bytes         = 67504

    Input pkts 65-127 bytes     = 57148

    Input pkts 128-255 bytes    = 36526

    Input pkts 256-511 bytes    = 3825

    Input pkts 512-1023 bytes   = 16717

    Input pkts 1024-1518 bytes  = 3079

    Input pkts 1519-Max bytes   = 0


    Input good pkts             = 184799

    Input unicast pkts          = 98431

    Input multicast pkts        = 28492

    Input broadcast pkts        = 57876


    Input drop overrun          = 0

    Input drop abort            = 0

    Input drop invalid VLAN     = 0

    Input drop invalid DMAC     = 0

    Input drop invalid encap    = 0

    Input drop other            = 0


    Input error giant           = 0

    Input error runt            = 0

    Input error jabbers         = 0

    Input error fragments       = 0

    Input error CRC             = 0

    Input error collisions      = 0

    Input error symbol          = 0

    Input error other           = 0


    Input MIB giant             = 0

    Input MIB jabber            = 0

    Input MIB CRC               = 0



    Output total bytes          = 30648266

    Output good bytes           = 30648266


    Output total packets        = 96223

    Output 802.1Q frames        = 0

    Output pause frames         = 0

    Output pkts 64 bytes        = 593

    Output pkts 65-127 bytes    = 22117

    Output pkts 128-255 bytes   = 36792

    Output pkts 256-511 bytes   = 16198

    Output pkts 512-1023 bytes  = 17120

    Output pkts 1024-1518 bytes = 3403

    Output pkts 1519-Max bytes  = 0


    Output good pkts            = 96223

    Output unicast pkts         = 95850

    Output multicast pkts       = 373

    Output broadcast pkts       = 0


    Output drop underrun        = 0

    Output drop abort           = 0

    Output drop other           = 0


    Output error other          = 0


"Drops for unrecognized upper-level protocol" means that we've received
packets of a type that you haven't configured and therefore don't have a
handler for in the interface protocol handling chain.

That may be (and most likely is) expected and purely cosmetic.



- other side (switch) has CDP configured but you don't have CDP configured on this end
- someone on the Ethernet is sending IS-IS hellos but you don't have IS-IS configured on this end
- someone on the Ethernet is sending IPv6 neigbor discovery packets but you don't have IPv6 configured on this end

It may be worth checking:
- do these packets increment periodically (i.e. one packet every 30 sec or so)?
- are there any obvious features (CDP is a good candidate) that you haven't configured but the far-end (switch, or if it's a crosslink, then
the connected peer) has?


Otherwise capture & decode the packets, and perhaps reviewing the config will already give the answer in a couple of seconds.


If a 7600/ 6500 port is connected to the ASR9000 and input error increment due to 'unrecognized upper-level protocol', then to avoid various l2 packets reaching ASR9000, you can use:


switchport nonegotiate - disable Dynamic Trunk Protocol (DTP) on the port

no cdp enable - to disable running Cisco Discovery Protocol (CDP)

no vtp - to disable sending VLAN Trunking Protocol(VTP) frame

spanning-tree bpdfilter enable - To enable BPDU filtering on the interface

UDLD: If you are running CatOS try “set udld disable x/y” or “udld port disable” under the interface if you have IOS on the 6500.


LLDP: (new addition) switches by default have lldp enabled that could be, like CDP, be perceived as an unrecognized upper level protocol on the ASR9000.

Level 1
Level 1

I have this problem too, since i was upgrade my firmware ACI, the discards was appears, usually the disacrds could be hide with bcm-shell command, but after upgraded the firmware the bcm-shell command couldn't affected to hide the discards.

Is there any others solution for these issues?.



Many thanks,


Review Cisco Networking for a $25 gift card