Cisco IOS XR show tech-support: Collect & Analyze

2026年9月19日 LOG admin

On a distributed IOS XR platform every show command you type is answered by a specific CPU: the route processor, a line card, or the fabric. That is exactly why show tech-support exists, and also why a badly collected bundle wastes a TAC case. This guide covers what IOS XR collects, how to target a single line card instead of the whole chassis, how to build a custom profile for recurring incidents, and how to skim the output before you upload 100 MB of logs.

What tech-support collection actually does

The show tech-support commands run a curated list of show commands across the relevant nodes and assemble the output into a file that can be shipped off-box. IOS XR is intentionally comprehensive about this: information has to be pulled from all line card CPUs in the system, and sometimes from hardware registers directly, because the control-plane picture on the RP alone is incomplete.

RP/0/RSP0/CPU0:router# show tech-support ?
  <cr>
  A  Filename to save the output
  ...

Scoping the collection

The full chassis collection is the last resort, not the first step. Start narrow — usually one line card or one protocol — and expand only if the narrow bundle does not explain the fault.

# Whole chassis (large, slow, use sparingly)
RP/0/RSP0/CPU0:router# show tech-support

# Save directly to a file on harddisk: or to a remote TFTP/FTP server
RP/0/RSP0/CPU0:router# show tech-support harddisk:/tech_20260919.txt
RP/0/RSP0/CPU0:router# show tech-support ftp://user:pass@10.0.0.10/tech.txt

# Line-card scoped collection (much faster)
RP/0/RSP0/CPU0:router# show tech-support lc 0/1/CPU0

Collection is CPU-intensive on the node that runs it. On a busy line card in the forwarding path, run it during a maintenance window or after you have diverted the traffic, and never in the middle of a failover.

Custom profiles: collecting the same thing twice

Newer releases let you group commands into a named profile so a recurring incident collects a consistent, reproducible data set:

RP/0/RSP0/CPU0:router(config)# tech-support profile BGP_ISSUE
RP/0/RSP0/CPU0:router(config-tech-prof)# show bgp summary
RP/0/RSP0/CPU0:router(config-tech-prof)# show bgp neighbors
RP/0/RSP0/CPU0:router(config-tech-prof)# show route bgp
RP/0/RSP0/CPU0:router(config-tech-prof)# commit

RP/0/RSP0/CPU0:router# show tech-support custom BGP_ISSUE

The value is operational: the second engineer to look at the problem gets the same data as the first, and reproducibility stops the "run this one extra command" loop that slows down escalations.

What to check before you open a case

Version and uptime — show version, show redundancy. A reload five minutes before the fault changes the entire diagnosis.
Node state — show platform and show redundancy tell you which line cards or RPs are up, or in a reset loop.
Logs with timestamps — show logging | include <pattern>, and remember the RP logs do not contain line card crashes unless the card reported them.
Counters that move — compare two samples a few minutes apart instead of trusting a single snapshot.
Time synchronisation — if NTP is not synced, correlating events across nodes becomes guesswork. show ntp status first.

Reading a bundle efficiently

A whole-chassis bundle is thousands of lines per node. Navigate it instead of reading it line by line:

# On-box filtering while collecting
RP/0/RSP0/CPU0:router# show tech-support | include "ERROR|Warning|Down|reset"

# Typical structure of the output
# 1. System information (version, uptime, chassis)
# 2. Platform / inventory
# 3. Interface and controller counters
# 4. Protocol state (BGP/OSPF/IS-IS/MPLS)
# 5. Routing table summary
# 6. Logs and core dumps

Most tickets resolve inside sections 3 and 6. Interface counters with a rising error column plus a matching syslog window is a Layer 1 story; a protocol section showing an adjacency bouncing in step with a control-plane counter is a CPU path story.

Housekeeping

Tech-support files are large and they accumulate. Assign them a lifecycle: write to harddisk:/tech/, copy off-box, and delete on the device at the end of the ticket. On platforms where harddisk: is small, filling it up during a collection turns a degraded device into an outage.

Collected deliberately — scoped, timed to the incident, and filtered — tech-support data is the difference between a TAC case that gets fixed in a day and one that drags for a week.