Cisco ASR 9000 IOS XR Troubleshooting Show Commands

IOS XR spreads state across a distributed architecture - RPs, line cards, the fabric and per-NPU forwarding - so 'show and hope' fails on an ASR 9000. The commands below are grouped in the order an experienced engineer actually uses them: prove the control plane, then the forwarding hardware, then the interface registration, and only then look at protocols. Everything here is safe on a production box.

Layer 0 - Is the Box Healthy and Where Is the Fault Located?

show version
show platform
show redundancy
show controller fabric plane all
show controllers fabric plane all statistics
show led

show platform is the fastest way to see whether a card is in IOS XR RUN, failed or administratively down, and whether the RP pair is in an SSO or redundant state. On an ASR 9000, a single failed fabric plane degrades capacity without breaking anything visibly, so show controller fabric plane all is worth running before you assume a card fault.

Layer 1 - Interfaces and Their Registration in the System

show interfaces brief
show interfaces <interface>
show interfaces <interface> accounting
show imds interface brief
show controllers <interface> stats
show interfaces <interface> rates

Two of these deserve explanation. show imds interface brief lists every interface the Interface Manager Distribution Server knows, with its state, encapsulation, MTU and handle. If an interface is physically up but missing or wrong here, you have an infrastructure problem rather than a physical one - it is the single best 'is the line card actually participating?' check. show interfaces accounting shows per-protocol in/out counters including drops, which separates 'traffic never arrived' from 'traffic arrived and was discarded'.

Layer 2 - Forwarding Plane Counters and the Fabric

show controllers npu
show controllers npu stats traffic all
show controllers npu stats drop all
show controllers fabric <location> statistics
show controller fabric link port
show packet-memory

On the ASR 9000, the NP counters are where you win or lose a performance case: np_stats counts describe what the network processor saw and did, and the drop counters frequently name the exact reason (parity, ucode, policer, tail drop, MTU). Compare counters on the ingress card against the egress card for the same flow - a gap between them is a fabric or backplane problem.

Layer 3 - What the Protocols and the System Database Think

show route <prefix>
show bgp ipv4 unicast <prefix>
show bgp ipv4 unicast summary
show rpl route-policy <name> detail
show sysdb connections
show sysdb trace verification location 0/0/CPU0
show im database

show rpl route-policy <name> detail is underused and saves hours: policy bugs are a common cause of 'the route exists but is not advertised', because the route appears in the RIB, is blocked at the policy and never reaches the neighbour.

Layer 4 - Capture Before You Escalate

show logging
show logging last 200
clear counters <interface>
show tech-support <module>

Use scoped show tech-support variants rather than the full bundle on a busy router. And note which commands are Cisco-support-only: the commands documented in the Advanced System Command Reference under the cisco-support task ID (for example show uidb data, show sysdb trace verification, show tbm hardware) are diagnostic tools intended for TAC engagement, not general operational checks.

A Worked Order That Finds Most Faults

1. show platform and show redundancy - any failed card or RP instability changes everything downstream.
2. show interfaces brief plus show imds interface brief - physical state versus registration.
3. Clear counters, reproduce, then read show interfaces <int> accounting and the NP drop counters.
4. show route for the affected prefix, then the RPL policy detail if it is not advertised.
5. Only then look at protocol timers, next-hop reachability and the IGP.

Related reading on this site: MPLS L3VPN VRF and route targets for the service-layer checks, and IP SLA and floating static route failover when the 'problem' turns out to be a design that only fails over on a timer.

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