The 'input errors' counter is simply the sum of the various errors that can be seen with inbound traffic (CRC, frame, overrun, and ignored). For that reason, you will generally find that the input errors is identical to another counter or matches up with the sum of the 4 categories mentioned. This is expected behavior. Ignored errors themselves are generally the result of bursty traffic that is hitting this interface inbound. Within each interface, we have a set limit of buffers to accommodate inbound packets called an Rx ring. If we experience a microburst of traffic on the interface at a rate faster than the interface can keep up with or clean out, we will increment the ignored or overrun counter depending on where the packet is within the input cycle. This indicates that this packet was dropped. The general solution is to look at the other side of the link and make sure flow-control is enabled and that it is able to accept pause frames if applicable. The interface should send these out if supported to tell the other side to slow down. Outside of that, you could look at implementing QoS on the opposite end of the link to limit bursts but the side-effect of this could be a bottleneck. The general recommendation is to identify the source of the bursts through a packet sniffer and determine a) is this legitimate traffic and if not, eliminate it and b) if the traffic is legitimate and is continuing to cause problems, offload it to another device more capable of handling higher traffic rates.
Given that the total number of input errors is a very small percentage of your total packets input, though, I don't suspect that these are incrementing very often. There are also some hardware counters, depending on the driver, that may provide further confirmation of the inbound hardware limitation being reached that can be checked in 'show controllers'. Hope this helps.
GoalDocumentationDefineAdd Device to Smart AccountSync Smart Account via vManage1.1 VNF package for vBranchDesignDeployOperate
To successfully provision a ENCS device in remote site with internet connection.
Minimum software relea...
はじめに確認方法Version による Application name の変更について備考参考情報 はじめに本ドキュメントでは Cisco SD-WAN における Policy 上で設定可能な Application を確認する方法について記載しています。 確認方法サポートされている Application name についてはご使用されている vManage へ API を呼び出して確認することが可能です。https://<IP or FQDN>/...
DMVPN (Dynamic Multipoint VPN) Introduced by Cisco in late 2000 is a routing technology you can use to build a VPN network with multiple sites (spokes) without having to statically configure all devices. It’s a “hub and spoke” network, where the spok...
On 24th August 2021, Cisco announced the latest IOS XE release - Cisco IOS XE Bengaluru 17.6.1a
IOS XE 17.6.1a unlocks various routing features and enhancements comprehensively covering different technology segments such as voice, security,...
DMVPN (Dynamic Multipoint VPN) Introduced by Cisco in late 2000 is a routing technology you can use to build a VPN network with multiple sites (spokes) without having to statically configure all devices. It’s a “hub and spoke” network, where th...