Cisco IOS-XR Input Drops: NP Counter Troubleshooting

2026年9月8日 LOG admin

Input drops on Cisco IOS XR platforms confuse many engineers who are used to classic IOS, because in XR there is no single input-queue definition that explains the counter. Instead, the input drop counter aggregates drops reported by different components, and the most common source on an ASR 9000 is the Network Processor (NP) on the ingress line card. This guide explains why IOS XR input drops behave differently, shows the show commands that pinpoint the cause, and walks through a structured packet-drop troubleshooting workflow.

Why IOS XR Input Drops Differ from Cisco IOS

In classic Cisco IOS, an input drop normally means the interface input queue filled up because too many packets were punted to the CPU. In IOS XR there is no such strict definition: each software or hardware component decides independently whether a drop increments the interface input drop counter. As a result, "input drops" on an XR router can be caused by unknown destination MACs, VLAN mismatches on subinterfaces, NP microcode drops, or even legitimate feature behavior such as dropping frames for features that are not configured.

The Ingress Path and Where Drops Are Counted

On an ASR 9000 a packet passes through several stages before it is forwarded, and each stage counts differently. Traffic arrives at the line card PHY, is framed and validated by the MAC layer, then handed to the Network Processor (NP), the forwarding engine on the line card. The NP performs the lookup, applies features, and decides the packet's fate: forward, replicate, or drop. Only a subset of those decisions increments the "input drops" counter that show interfaces prints. In broad terms the path is PHY, then MAC, then NP lookup and feature processing, and from there either the fabric towards an egress interface or the punt path towards the route processor. Drops can happen at any of those points, and each keeps its own statistics, which is exactly why an input drop on XR is a symptom rather than a diagnosis.

Knowing the stage matters because the counters are not interchangeable. A frame rejected by the MAC for a bad FCS never reaches the NP and appears as an input error, not an input drop. An L2 frame the NP cannot deliver, such as an unknown destination MAC or a dot1q tag with no matching subinterface, is counted as an input drop. A packet that the NP would happily forward but that is addressed to the router itself can be discarded by the punt policer and show up in control-plane statistics instead of on the interface. Chasing the wrong counter is how a troubleshooting session loses an hour.

Common Causes of Input Drops on ASR 9000

Unknown DMAC or dot1q VLAN: frames with a destination MAC that does not belong to the router, or with a VLAN that no subinterface matches. L2 flooding in the broadcast domain and Ethernet keepalives from legacy Cisco IOS routers are typical triggers.
NP microcode drops: the Network Processor drops packets for reasons such as IPv4 sanity/address checksum failures, martian source addresses, or MPLS leaf no-match conditions.
Misprogrammed CEF adjacency: a forwarding entry that does not point to a valid adjacency causes NP drops that surface as interface input drops.
Punt-path oversubscription: control-plane bound traffic exceeding the line card's punt rate.

Reading the Interface Counters Correctly

Before running a single NP command, confirm that the counter you are looking at means what you think it means.

Counter	What it means	Typical cause
Input errors	Frames damaged during reception, never delivered	FCS and CRC errors, bad cabling, duplex mismatch, faulty optics, dirty connector
Input drops	Frames received intact but not delivered	The subject of this article: unknown DMAC or VLAN, NP microcode reasons, punt limits, adjacency problems
Ignored	Received and discarded without processing	Frames the interface has no reason to look at, often broadcast storms or an unneeded protocol
Output drops	Egress queue full	Congestion on the outbound interface, not an ingress problem at all
CRC and frame errors	Physical-layer damage	Layer 1. These are not input drops, even when users report them that way

RP/0/RSP0/CPU0:router# show interfaces GigabitEthernet0/0/0/18 | include "input|output|drop|error"
RP/0/RSP0/CPU0:router# show interfaces GigabitEthernet0/0/0/18 | include "rate"
RP/0/RSP0/CPU0:router# show interfaces GigabitEthernet0/0/0/18 accounting
RP/0/RSP0/CPU0:router# show interface rates location 0/0/CPU0

Two more habits pay off. First, read the counter twice about a minute apart: a large static number is history, a number growing in step with the reported problem is your cause. Second, check whether the drops track a service or an interface. If only one subinterface under a physical port reports them, the fault is far more likely to be an encapsulation or feature mismatch than a hardware problem.

Key Show Commands for Input Drop Troubleshooting

Start at the interface level and then drill into the NP statistics. On an ASR 9000 running IOS XR, the useful commands are:

RP/0/RSP0/CPU0:router# show interfaces GigabitEthernet0/0/0/18
RP/0/RSP0/CPU0:router# show interfaces GigabitEthernet0/0/0/18.1
RP/0/RSP0/CPU0:router# show controllers np ports all location 0/0/CPU0
RP/0/RSP0/CPU0:router# show controllers np counters all location 0/0/CPU0
RP/0/RSP0/CPU0:router# show controllers np counters np0 location 0/0/CPU0

The show controllers np ports command maps each front-panel interface to its NP and port number, so you know which NP statistics belong to the interface that reports drops. show controllers np counters then exposes the detailed NP drop counters; not every counter in this output indicates a problem, because many counters also track normal traffic.

Decoding the NP Counter Output

show controllers np counters prints hundreds of lines, one per counter, per NP. Read it with filters rather than by scrolling:

RP/0/RSP0/CPU0:router# show controllers np counters all location 0/0/CPU0 | include DROP
RP/0/RSP0/CPU0:router# show controllers np counters all location 0/0/CPU0 | include RSV
RP/0/RSP0/CPU0:router# show controllers np counters np0 location 0/0/CPU0 | exclude " 0$"

Excluding the lines that end in zero is the fastest way to see only the counters that are actually moving. The families below are the ones that most often line up with a rising interface input drop counter.

Counter family	What it means	Usually caused by
Unknown DMAC or unknown VLAN	The frame's destination MAC or dot1q tag matches nothing the line card knows	L2 flooding across a shared segment, keepalives from a device whose MAC has not been learned, a subinterface that does not match the tag
IPv4 address sanity or checksum failure	The header does not pass the hardware validity check	Malformed traffic, a host with broken offload, a middlebox rewriting headers
Martian source	The source address cannot be valid on this link	Spoofed traffic, a routing loop, or reverse-path forwarding rejecting the source
MPLS leaf no-match	A labelled packet arrived with no matching label entry	An LSP that is not signalled end to end, or an inconsistent label stack between domains
Punt or control-plane limit	Traffic destined for the route processor exceeded the policer	Routing churn, a broadcast storm reaching the CPU, a missing or too loose CoPP policy
Adjacency or no-route	A forwarding entry exists but points nowhere usable	An incomplete CEF adjacency or a misprogrammed next hop after a topology change

Counter names change between platforms and microcode releases, so do not build a runbook around one literal string. Match the family, unknown DMAC, sanity failure, martian, label no-match, punt limit, adjacency, and then find what your release calls it. show controllers np ports all location is what tells you which NP and port number correspond to the front-panel interface you are chasing; without it you may spend the whole session staring at the counters of the wrong NP.

Using the NP Microcode Capture

When a specific NP counter is incrementing, capture the actual dropped packets to confirm the root cause. The microcode capture feature shows a snapshot of the packets that hit a given NP drop reason:

RP/0/RSP0/CPU0:router# show controllers np capture np1 location 0/0/CPU0

The output includes the drop reason (for example RSV_DROP_MPLS_LEAF_NO_MATCH or an IPv4 checksum failure) and a hex dump of the packet, which tells you the source interface and the exact header that triggered the drop.

Three Cases That Explain Most Input Drops

1. Layer 2 noise the router was never meant to see

The most common trigger is not a fault in the router at all. A broadcast domain extended to the router carries flooding traffic, and any frame whose destination MAC is not one the router owns, or whose VLAN tag matches nothing configured, is dropped by the NP and counted on the interface. The classic example is a legacy Cisco IOS router sending Ethernet keepalives into the shared segment: the frames are perfectly valid, they are simply not for this device. Confirm it by checking whether the counter grows in step with L2 flood or broadcast traffic, then fix the topology rather than the router, by moving the offending device off the segment or filtering those frames at the access edge.

2. A subinterface that does not match the tag

When a subinterface encapsulation does not match the tags arriving on the wire, the frames fall through to no interface and are dropped. This is easy to introduce and easy to miss, because the physical port looks healthy and the parent interface reports no errors.

RP/0/RSP0/CPU0:router# show running-config interface GigabitEthernet0/0/0/18.1
RP/0/RSP0/CPU0:router# show interfaces GigabitEthernet0/0/0/18.1
RP/0/RSP0/CPU0:router# show controllers np ports all location 0/0/CPU0

Compare the configured encapsulation against the tags the upstream switch is actually sending, and check for a missing untagged subinterface where the peer expects one to exist.

3. The control plane as the bottleneck

If the drops correlate with protocol churn rather than with user traffic, the packets are probably being punted to the route processor and discarded when they exceed the punt rate. The evidence is in control-plane statistics rather than on the interface.

RP/0/RSP0/CPU0:router# show policy-map control-plane input
RP/0/RSP0/CPU0:router# show controllers np counters all location 0/0/CPU0 | include PUNT
RP/0/RSP0/CPU0:router# show processes cpu location 0/0/CPU0 | exclude " 0%"

A missing or too-permissive CoPP policy, a routing loop reaching the CPU, or a broadcast storm are the usual causes. Protect the control plane rather than removing the limit: the policer is the only thing standing between a chattering neighbour and a reloaded router. More on that side of the problem in Cisco switch high CPU troubleshooting and IOS XR QoS with class-map and policy-map.

Recommended Troubleshooting Workflow

Clear the counters so you start from a clean slate:

RP/0/RSP0/CPU0:router# clear counters all
RP/0/RSP0/CPU0:router# clear controller np counters all

Reproduce the traffic pattern that caused the drop and re-check show interfaces to confirm the input drop counter is still increasing.
Run show controllers np counters all location on the affected line card and identify which counter moves at the same rate as the interface input drop counter.
If the cause is not obvious, use the NP capture to inspect a dropped packet, then fix the root cause (filter the offending MAC/VLAN, correct the feature configuration, or escalate a suspected hardware/software bug with the captured evidence).

Clearing Counters Without Misleading Yourself

Counters are cumulative since the last clear, and a router that has been up for a year carries a year of history. Clear deliberately, and only on the interface or NP you are investigating, because a global clear on a busy router wipes evidence you may need later in the case.

RP/0/RSP0/CPU0:router# clear counters GigabitEthernet0/0/0/18
RP/0/RSP0/CPU0:router# clear controller np counters np0 location 0/0/CPU0

Note the time, reproduce the condition, then take a second reading. A drop rate only means something next to a traffic rate: one drop per second on a 10 Gbps uplink is a curiosity, one drop per second on an idle management port is a configuration error.

When to Escalate to Cisco TAC

Most input drops end as a configuration fix, but some need a case. Escalate when the counter belongs to a hardware or microcode family rather than a protocol family, when a sanity or parity failure appears, when there is no configuration that explains the drop, or when a counter clears itself and returns. Bring three things: the output of show controllers np counters all location taken before and after a clear, the NP microcode capture of the offending packet, and the exact software version. With those in hand the case starts at the right level instead of at "please collect logs". Related reading: IOS XR line card diagnostics with show diag and safe OIR, Cisco IOS logging and syslog levels, mtr for diagnosing packet loss and latency and IOS XR CLI modes and show commands.

A One-Page Checklist

Confirm the counter type: input drops, not input errors and not output drops.
Read it twice, 60 seconds apart, to establish a rate rather than a total.
Map the interface to its NP and port with show controllers np ports all location.
Filter the NP counters for the moving counter and identify its family.
Capture one dropped packet with the NP microcode capture to confirm the header.
Fix the cause: filter the traffic, correct the encapsulation, repair the adjacency, or protect the control plane.
Clear, wait, and confirm the counter stays flat.

Putting the drop rate next to the traffic rate

A drop counter on its own says nothing about severity, and the fix differs depending on whether the traffic is a trickle or a flood. Always take the interface rate in the same moment as the counter, and look at the packet size distribution: a counter that moves with tiny frames is a different problem from one that moves with full-size packets.

RP/0/RSP0/CPU0:router# show interfaces GigabitEthernet0/0/0/18 | include "rate|load"
RP/0/RSP0/CPU0:router# show interfaces GigabitEthernet0/0/0/18 accounting
RP/0/RSP0/CPU0:router# show interfaces GigabitEthernet0/0/0/18 statistics
RP/0/RSP0/CPU0:router# show interface rates location 0/0/CPU0

A few drops per second on a saturated 100G link is normal policing; the same rate on an idle management port is a configuration error. On bundled links, compare the members: if one member reports the drops while the others are quiet, hashing is unbalanced and that member is carrying more than its share, which is a hashing or a member-capacity problem rather than a forwarding bug. And because drops often arrive in micro-bursts, a one-second sampling interval can miss them entirely - if the counter grows but the average rate looks calm, treat the number as evidence of burstiness rather than of a steady load.

Collecting evidence so the case does not stall

Whether the outcome is a configuration change, a bug report or a TAC case, the same three artefacts decide how fast it moves: timestamped counter output taken before and after a clear, one captured dropped packet, and the exact software version.

RP/0/RSP0/CPU0:router# show controllers np counters all location 0/0/CPU0 file harddisk:/np-before.txt
RP/0/RSP0/CPU0:router# show interfaces GigabitEthernet0/0/0/18 file harddisk:/intf-before.txt
! reproduce, then capture again with the same commands into *-after.txt
RP/0/RSP0/CPU0:router# show controllers np capture np1 location 0/0/CPU0
RP/0/RSP0/CPU0:router# show version | include "XR|Version"
RP/0/RSP0/CPU0:router# show install active summary

Writing the output to a file at capture time saves you from a truncated terminal and gives the reviewer a before/after pair they can diff. Note the wall-clock time next to each file, because "the counter was rising" is only meaningful against the moment you cleared it. Related reading: Cisco ASR9000 troubleshooting show commands and IOS XR line card diagnostics.

Original article: https://community.cisco.com/t5/service-providers-knowledge-base/asr9000-xr-troubleshooting-packet-drops-and-understanding-np/tac-p/3126735 | Cisco: Troubleshoot Input Drops in IOS XR

作者：admin

链接：https://gitgit.ee/cisco-ios-xr-input-drops-np-counters-troubleshooting.html

文章版权归作者所有，未经允许请勿转载。