ASR9000 Fabric Troubleshooting: Essential Show Commands

On an ASR 9000 running IOS XR, line cards forward traffic in hardware and the fabric is the switch between them. When traffic drops between two cards that are both perfectly healthy on the interface side, the fault is almost always in the fabric plane, the fabric-facing path of the network processor, or the control-plane connection that reports fabric state. This article collects the show commands and the isolation logic that Cisco's own service-provider knowledge base recommends, without the trial-and-error.

How the ASR 9000 fabric is laid out

An ASR 9000 chassis contains multiple fabric cards (or fabric ASICs on the line cards, depending on the platform generation), each carrying several planes. Every line card connects to every plane, and traffic is spread across the planes that are up. A single failed plane does not take the chassis down — it reduces fabric bandwidth and, in a badly designed topology, creates uneven load across slots. A failed plane plus an already-degraded card is what produces the classic "traffic drops but no interface counters move" symptom.

Step 1: is the fabric healthy at the chassis level?

RP/0/RSP0/CPU0:router# show controllers fabric plane all detail
RP/0/RSP0/CPU0:router# show controllers fabric health
RP/0/RSP0/CPU0:router# show controllers fabric stats all
RP/0/RSP0/CPU0:router# show platform

show platform reports each node's HW state, SW state and Config State — the fastest way to see whether a line card or RP is stuck in a non-OK state. Follow it with the fabric controllers if the platform looks clean but traffic does not flow.

Step 2: per-slot and per-plane counters

RP/0/RSP0/CPU0:router# show controllers fabric link port all
RP/0/RSP0/CPU0:router# show controllers fabric stats plane 0 location 0/1/CPU0
RP/0/RSP0/CPU0:router# show controllers np structs all location 0/1/CPU0

Counters to watch are the per-plane cell drops and CRC-type errors. A plane showing drops only on one slot points at that slot's fabric interface (a bad fabric cable between card and fabric card on modular systems, or a marginal ASIC); a plane showing drops across all slots points at the plane itself.

Step 3: separate NP drops from fabric drops

The distinction matters because the remediation is different. Fabric drops mean cells were lost crossing the switch fabric. Network processor drops mean the packet was discarded at ingress or egress before or after the fabric — a policer, an ACL, a queue overflow, or an LPTS control-plane punting issue. Cisco's companion note on troubleshooting packet drops and understanding NP drop counters is the correct next read once you have established the fabric is clean:

RP/0/RSP0/CPU0:router# show controllers np counters np0 location 0/1/CPU0
RP/0/RSP0/CPU0:router# clear controllers np counters location 0/1/CPU0

Clear, wait for a representative sample period, then re-read. Comparing two snapshots 60 seconds apart is far more informative than an absolute counter value that has been accumulating since the last card reload.

Step 4: control-plane and system-database health

IOS XR's distributed architecture means fabric state is reported through the system database, and a wedged client connection can make a healthy plane look broken:

RP/0/RSP0/CPU0:router# show imds interface brief
RP/0/RSP0/CPU0:router# show sysdb connections detail location 0/1/CPU0
RP/0/RSP0/CPU0:router# show sysdb trace verification location 0/1/CPU0
RP/0/RSP0/CPU0:router# show im database

show imds interface brief gives handle, state, MTU and encapsulation for every interface the interface manager knows about — a mismatch between what the interface is configured as and what IMDS reports is a strong signal. show sysdb trace verification confirms that configuration changes were verified and accepted on that node.

Step 5: memory and watchdog evidence

RP/0/RSP0/CPU0:router# show packet-memory
RP/0/RSP0/CPU0:router# show watchdog threshold memory
RP/0/RSP0/CPU0:router# show uidb data

Many Cisco-support-class commands in the troubleshooting module — show tbm hardware, show uidb index, show uidb trace — require the cisco-support task ID and are intended for use with TAC. Knowing they exist and what each covers shortens a TAC case considerably: show tbm hardware covers tree-bitmap hardware state, show uidb covers the underlying information database that IMDS builds on.

Practical isolation order

1. show platform — any node not OK stops the investigation there.
2. show controllers fabric plane all detail and show controllers fabric health — plane-level verdict.
3. Fabric counters per plane per location — is the fault plane-wide or slot-specific?
4. NP counters — fabric clean but drops present means the problem is local to a card.
5. show imds interface brief / show sysdb connections — only if counters and platform disagree.

Pair the fabric view here with the interface-level counters in ASR 9000 IOS XR show commands for troubleshooting and the hardware side in ASR 9000 environment, power and temperature checks.

原文链接：https://community.cisco.com/t5/service-providers-knowledge-base/asr9000-xr-understanding-the-fabric-and-troubleshooting-commands/ta-p/3147083