Cisco IOS XR TAC Command List: Collect Before the Case

Nothing slows down a Cisco TAC case more than a back-and-forth asking for missing command output. The official IOS XR quick-reference command list tells you exactly what to collect before you open the ticket — platform state, install history, configuration commits, routing and forwarding counters. This article explains the list, groups the commands by what they diagnose, and shows why each block matters for ASR 9000, NCS and Cisco 8000 platforms.

Why Collect IOS XR Diagnostic Output Up Front

IOS XR is a distributed, commit-based operating system: configuration errors, FPD issues and NP drops each hide in different subsystems. The TAC list is designed so one paste session captures every subsystem snapshot, letting engineers triage without repeated calls. Enable logging on your SSH/telnet client and paste the blocks exactly as shown.

Core System State Commands

term length 0
show platform
show install active summary
show version
show hw-module fpd
show diag
show logging
show install log
show running
show configuration failed
show configuration commit changes all
show configuration history

These answer the three questions that start every case: what hardware is present, what software is running (including committed installs and FPD versions), and whether any configuration commit has failed.

Redundancy and Hardware Health

show redundancy
show redundancy summary
show environment
admin show environment
show led
show context location all
show processes cpu
show processes blocked location all
show watchdog memory-state

RP failover state, environment thresholds and blocked processes catch the classic "router reloads itself" causes before they become outages.

Routing, Forwarding and MPLS Plane Commands

show ospf neighbor
show bgp sessions
show bgp summary
show rib update-groups
show tcp brief
show l2vpn xconnect
show mpls traffic-eng tunnels
show bfd session
show drops
show controllers np counters all

These expose control-plane adjacency health (OSPF/BGP), label-switched path state (L2VPN xconnect, TE tunnels, BFD) and data-plane drops — the first place packet loss shows up on ASR 9000 and NCS platforms. For NCS family, add show asic-errors all detail location 0/RP0/CPU0 and show alarms brief system active.

Prepare the Session Before You Paste Anything

The TAC list assumes a terminal that will not paginate or truncate. Ten minutes of preparation saves a day of round trips:

• Set the terminal to no pagination: term length 0 (and term width 512 if long lines wrap).
• Turn on session logging in your SSH client (PuTTY, SecureCRT, iTerm, Windows Terminal all support it) and save the transcript to a file with the case number in the name.
• Add timestamps to your own notes: run show clock first and record it in the case, so the engineer can correlate syslog entries with the transcript.
• Never collect the output in a maintenance window that differs from the failure window unless nothing else is available — counters reset and logs roll.
• Do not edit the transcript. Redacting a serial number or delete the line is fine; re-typing "cleaned up" output destroys its evidentiary value.

The same discipline applies to the router side: enable a large log buffer before you start, and confirm it with the logging commands further down, because the cause of many IOS XR faults is an event that happened days before anyone noticed.

Interface, Link and Bundle Blocks

Physical and link-layer state is asked for in almost every IOS XR case, because an interface that is up with CRC errors, or a bundle member that keeps flapping, explains a surprising number of "the router dropped traffic" reports.

show interfaces brief
show interfaces
show interfaces counters errors
show interfaces <interface>
show controllers <interface> phy
show imds interface brief
show bundle <bundle-interface>
show lacp counters
show ethernet oam statistics <interface>

Two details matter when you paste these. First, paste the full show interfaces output only when the interface count is small; on a 100-port chassis, collect show interfaces brief plus the specific interfaces under suspicion, otherwise the transcript becomes unreadable. Second, always include the show controllers ... phy output for the suspect port — that is where the optical transmit/receive levels live, and a marginal receive level shows up there long before it shows up in the packet counters.

Platform, NPU and ASIC-Level Counters

On ASR 9000, NCS and Cisco 8000 platforms the forwarding engine is where the truth lives. These commands are also the ones most often missing from a case:

show drops
show controllers np counters all location 0/1/CPU0
show controllers np counters all
show asic-errors all detail location 0/RP0/CPU0
show controllers fabric plane all detail
show controllers fabric link health

show drops summarises per-node drop reasons. The NP counter output is per-line-card, so collect it for the card in the path (location 0/1/CPU0) and for the ingress card where the traffic enters. The ASIC error and fabric commands are what distinguish a software bug from a degrading fabric link; when TAC asks for "asic errors and fabric health", these are the blocks they mean.

Command availability is release and platform dependent — the NP counter command exists in slightly different forms on NCS 5500 and Cisco 8000. Use the help key to confirm before you paste, and note the exact syntax you used in the case along with the show version output, so the engineer knows which platform reference to apply.

Control Plane, Memory and Process Health

Control-plane faults show up as protocols that flap for no obvious reason, or as a router that stops responding to SSH while still forwarding traffic. The process blocks catch both:

show processes cpu location all
show processes memory location all
show processes blocked location all
show memory summary location all
show watchdog memory-state location all
show context location all
show context summary location all

show processes blocked is the single most valuable command in this group: if a process is blocked, whatever it is waiting on is usually the root cause, and the wait reason frequently names the resource. show context output gives per-process context information including recent CPU consumption, which is how you find a process that has been quietly spinning for weeks.

For routing protocol specific state, add the protocol families you run — a session that flaps is far easier to diagnose with the peer-level view than with the summary:

show ospf neighbor detail
show bgp sessions
show bgp summary
show bgp vrf all summary
show isis adjacency detail
show route summary
show rib update-groups
show bfd session detail
show mpls ldp neighbor brief

Logging, Alarms and Timing

Logs and alarms are the narrative of the failure; timing is the correlation key. Collect them together:

show logging
show logging last 500
show alarms brief system active
show alarms brief system history
show clock
show ntp status
show ntp associations
show environment all
show environment temperature

Two practical notes. If your case involves a crash or a reload, the entire show logging buffer is relevant, not the last twenty lines — say so in the case so nobody assumes it was trimmed deliberately. If NTP is not synchronised, timestamps in the log cannot be matched to upstream devices, and the first corrective action should be fixing time synchronisation before collecting anything else.

Filesystem, Cores and Install Artifacts

Install and filesystem blocks answer "what software is actually running, and did anything fail while it got there":

show version
show install active summary
show install committed summary
show install log
show install inactive
show filesystem
dir harddisk:
show configuration failed
show configuration history
show configuration commit changes all

show install log records the outcome of every install operation including failures that never reached the console. show configuration failed is essential when a commit has been rejected — the output names the exact line that would not parse. If a core dump or traceback file exists on the disk, dir harddisk: will show it and TAC will want it uploaded rather than pasted. Do not delete files from harddisk: to free space on a router that is under a support case before asking whether they are needed.

Symptom-to-Command Map

When the fault is specific, TAC still wants the full list — but these are the blocks that usually decide the case:

• Traffic loss on one path: interface counters and errors, show drops, NP counters for the ingress and egress card, show controllers <intf> phy.
• Protocol flapping: protocol neighbour detail, show processes blocked, show logging, show watchdog memory-state.
• Card not running: show platform, show hw-module fpd, show diag <location>, install blocks.
• Router reloaded unexpectedly: show logging (full), show context location all, watchdog output, environment output, show install log.
• Configuration will not commit: show configuration failed, show configuration history, show install active summary.

Packaging the Output for the Case

Paste into a text file, not into the case form directly, then:

1. Run each block exactly as listed, in the same order as the reference list.
2. Save the transcript as a single plain-text file named with the SR number and a timestamp.
3. Compress it (tar.gz or plain .zip) — transcripts are trivially compressible and often attach faster than the portal's inline paste.
4. Attach it to the case and state in the description which blocks are missing and why, instead of silently omitting them.
5. Screenshots of scrollback are not accepted as a substitute — they cannot be searched or grepped.

Also state up front: platform model, IOS XR release, whether the fault is intermittent or constant, the exact local time of an observed event, and anything changed in the last 24 hours. TAC engineers can work without those facts, but only by asking you for them one at a time.

Automating the Collection

Once the list is written down, it stops being a manual chore. The same blocks can be wrapped in a script, an Ansible task, or a NAPALM/pyATS job so that the output is captured the moment a symptom appears, rather than hours later when the counters have already been reset by a clear or a reload. Two rules for automation:

• Collect first, analyse second — a collector that tries to interpret output tends to drop the lines that mattered.
• Keep the command list in one file, versioned, so that adding a new platform command is a change you can review rather than something buried in a playbook.

Five Mistakes That Waste a TAC Cycle

1. Pasting show tech-support instead of the requested blocks: it is enormous, it takes minutes on a busy router, and it is often truncated in transit.
2. Collecting after a clear counters, a reload, or a log-buffer roll, which erases the evidence TAC needed.
3. Trimming output to "the interesting part" and removing the header lines that show the node, the location and the software version.
4. Sending screenshots or a chat transcript rather than a text attachment.
5. Not stating the time of the fault, so the log correlation has to be guessed.

Combine this collection routine with our multi-vendor CLI cheat sheet and OSPF neighbor troubleshooting guide for day-to-day triage. Automation-minded teams can wrap these commands in Ansible playbooks to collect them fleet-wide, or use pyATS and Genie to parse the same output into structured state for before/after comparison. For the drop counters specifically, see our IOS XR input drops and NP counter guide.

原文链接：https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xr-software/215365-quick-reference-guide-to-collect-tac-req.pdf