ASR 9000 Line Card Installation: Verify and Troubleshoot

Installing a line card in a Cisco ASR 9000 router is usually straightforward, but when the Card Status LED does not go green, you need a systematic way to verify seating, power, and software loading before calling TAC. This guide explains the boot sequence of a line card, what each LED color means, and the IOS-XR commands used to configure and verify new interfaces — from show interface to show tech-support. It also covers the interface naming convention used across ASR 9000 platforms.

The reason a line card failure is worth engineering for is that the failure is almost always one of three things, and they are distinguishable within a few minutes if you know which order to check. Seating and power problems stop a card before it ever loads software. Software and FPD mismatches let it boot and then hold it in an inactive state. Configuration problems leave the card perfectly healthy but the ports administratively down. Each of those has a different set of commands, and mixing them up is what turns a ten-minute fix into an hour of guessing.

Background: Pre-Installation Checks

Before touching the chassis, confirm the physical preconditions. ASR 9000 line cards are hot-swappable, but hot-swap is not the same as risk-free — the slot must be supported by the chassis and the RSP software release, and the power budget must have headroom for the new card under peak load.

• Compatibility: verify the card part number is supported by the installed IOS XR release using the release notes or the show platform output before insertion.
• Power budget: check show environment all for available power and confirm the added draw fits, including redundancy requirements (N+N vs N+1).
• Cooling: confirm all fan trays are present and healthy; a card installed into a slot with a failed fan zone will over-temp and shut down, frequently appearing as a mysterious failed installation.
• Static protection: use an ESD wrist strap bonded to the chassis. This is not ceremony — an ESD event can damage a fabric interface without producing an immediate fault.
• Media readiness: know the optics you intend to use and confirm they are supported on this card type before insertion, so a successful install is not immediately followed by an unsupported-transceiver problem.

RP/0/RSP0/CPU0:router# show platform
RP/0/RSP0/CPU0:router# show install active summary
RP/0/RSP0/CPU0:router# show environment all

Line Card Initial Boot Process

During boot the line card powers on, executes initialization software, performs internal checks, and receives its IOS-XR software image from the RSP. Note that all new line cards are administratively down by default — port status LEDs stay off until you configure the interfaces and issue no shutdown.

The sequence in more detail: the card receives power, the on-card processor starts and runs its boot loader, POST tests run against memory, the fabric interface and the temperature sensors, the card requests and downloads its software image from the RSP over the backplane, and only then does it register with the RSP and appear in show platform as ready. A card that never appears in show platform never got that far — which means seating, power or an internal hardware fault, not a configuration problem. A card that appears but shows PROG_INIT or IOS XR RUN for an unusually long time is stuck in the image-download or registration stage, which points at software or the backplane data path.

RP/0/RSP0/CPU0:router# show platform
RP/0/RSP0/CPU0:router# show platform summary

The card state field is the single most informative value in the whole procedure. IOS XR RUN means the card is fully operational. PRESENT means the RSP sees a card in the slot but it is not running. FAILED, UNPOWERED and POWERED_ON each map to a different physical or power cause.

Reading Line Card and Port LEDs

Port Status LED: green = link up, blinking = line activity, red = enabled but link loss or SFP/XFP failure, off = administratively shut down. Card Status LED: green = booted and passing traffic, steady amber = boot in progress, blinking amber = software configuration error, red = hardware error, off = powered off.

Read them as a pair. A green port LED with an amber card LED is unusual and usually means the card is mid-boot while a previously configured interface is already forwarding on the fabric — wait for the card LED to go green before drawing conclusions. A red card LED is a hardware error and no amount of configuration will clear it; collect the diagnostic data first and plan a card replacement. Blinking amber on the card LED is the one state that is genuinely a software problem, and it usually corresponds to a failed image download or an FPD mismatch.

Troubleshooting the Installation

If the Card Status LED fails to go on: verify the card is fully seated (tighten captive screws, pivot ejector levers), check power cords and data cables, then try another slot to isolate a failed backplane port. If an error message appears on the console during initialization, look it up in the IOS-XR error message reference before proceeding.

Work in this order and do not skip a step, because each one eliminates a class of cause:

1. Seating. Ejector levers fully closed and captive screws tight. A card that looks inserted but is not fully home will show PRESENT and never progress.
2. Power. Use show environment all to confirm the slot has power allocated and that no power-supply failure is limiting the budget. Move the card to a different slot to distinguish a card fault from a backplane or power fault.
3. Software. Confirm the card type is supported on the running release with show install active summary and show platform. An unsupported card may be detected but never brought to IOS XR RUN.
4. FPD. Compare FPD versions on the new card against the existing cards and the RSP with admin show hw-module fpd location 0/1/CPU0. FPD upgrades reset the hardware, so schedule them.
5. Console errors. Capture the full console output during insertion — this is the only evidence that survives if the card never registers, and it is the first thing TAC will ask for.

RP/0/RSP0/CPU0:router# show logging
RP/0/RSP0/CPU0:router# show alarm brief system active
RP/0/RSP0/CPU0:router# show diag slot 0/1/CPU0
admin:RP/0/RSP0/CPU0:router# show hw-module fpd location 0/1/CPU0

Configuring and Verifying the Line Card Interfaces

IOS-XR identifies interfaces as rack/slot/instance/port — for example, port 4 of a card in slot 1 is tengige 0/1/0/3:

RP/0/RSP0/CPU0:router# show interface
RP/0/RSP0/CPU0:router# configure terminal
RP/0/RSP0/CPU0:router(config)# interface tengige 0/1/0/3
RP/0/RSP0/CPU0:router(config-if)# ipv4 address 10.1.2.3 255.255.255.0
RP/0/RSP0/CPU0:router(config-if)# no shutdown

The four-part naming convention is worth internalising because it changes how you read every other command: rack is always 0 on the ASR 9000, slot identifies the physical card slot, instance distinguishes multiple NPU instances on high-density cards, and port is the physical port on that instance. A card with 36 ports across multiple instances does not have ports 0–35 on instance 0; confirm the mapping with the port-to-NPU output rather than assuming.

Verify transceivers with show inventory and show controllers to confirm SFP/QSFP types and serial numbers match expectations.

RP/0/RSP0/CPU0:router# show inventory
RP/0/RSP0/CPU0:router# show controllers tenGigE 0/1/0/3 phy
RP/0/RSP0/CPU0:router# show interfaces tenGigE 0/1/0/3
RP/0/RSP0/CPU0:router# show interfaces tenGigE 0/1/0/3 accounting
RP/0/RSP0/CPU0:router# show controllers np ports all

When a port is configured but stays down, check the state string rather than only the LED. administratively down means you have not issued no shutdown or the configuration was not committed. down, line protocol down means no signal — optics, fibre or the far end. up, line protocol down almost always means a framing or encapsulation mismatch, not a hardware fault.

Traffic Verification After Bring-Up

A line card is not verified until traffic has crossed it. Bring up the interface, confirm counters increment, and explicitly check for errors before handing the card into service — it is far easier to reject a marginal card during turn-up than to prove it faulty three weeks later.

RP/0/RSP0/CPU0:router# clear counters tenGigE 0/1/0/3
! generate or allow traffic, then:
RP/0/RSP0/CPU0:router# show interfaces tenGigE 0/1/0/3 accounting
RP/0/RSP0/CPU0:router# show controllers tenGigE 0/1/0/3 phy | include errors
RP/0/RSP0/CPU0:router# show interfaces tenGigE 0/1/0/3 | include drops|errors

Input errors with clean output errors point at the receive fibre or the far-end optic; bidirectional CRC errors usually mean a dirty or damaged connector or a marginal optic; drops without errors in a clean counters window point at a policy or queueing configuration rather than the card. A new card should produce an empty error delta over a soak period before you consider the installation complete.

Advanced Troubleshooting and TAC Data Collection

If a card fails, collect show logging, show diag slot, show context location slot, plus console and syslog output. show tech-support compiles many commands including show version, show running-config, show tech ethernet, show tech pfi and show stacks — always gather it before reloading or power-cycling, or the evidence is lost.

The distinction between show diag slot and show context location slot matters when a card is wedged: show diag reports what the RSP can see about the hardware, while show context reports the state of processes on the card itself. If the card's own processes cannot be queried, that inability is itself the finding — it tells TAC the card is not merely misconfigured but not executing.

RP/0/RSP0/CPU0:router# show logging
RP/0/RSP0/CPU0:router# show diag slot 0/1/CPU0
RP/0/RSP0/CPU0:router# show context location 0/1/CPU0
RP/0/RSP0/CPU0:router# show tech-support
RP/0/RSP0/CPU0:router# show tech-support fabric

Save the output off-box immediately. A reload or power-cycle wipes the in-memory evidence that makes a case solvable, and a card that has been power-cycled before the data was collected will usually just be replaced on suspicion rather than diagnosed — which is slower and more expensive than collecting the data first.

FAQ

Why are my new ports down after installation? Because ASR 9000 line cards bring ports up administratively down. Configure the interface and issue no shutdown.

The card shows PRESENT but never reaches IOS XR RUN — is it faulty? Not necessarily. Check seating and power first, then confirm the release supports the card, then check FPD. Only after those are eliminated is it a hardware suspect.

Can I install a line card while the router is running? Yes, the platform supports OIR, but confirm the slot and card are supported, confirm power and cooling headroom, and be aware that an FPD mismatch may require a reset of the card that was just inserted.

Do I need to reload the RSP to activate the new card? No. A correctly seated and supported card registers with the running RSP and appears in show platform without a reload.

What is the most common cause of a failed installation? In practice, incomplete seating followed by an FPD or release-support mismatch. Both are preventable with pre-checks, and neither requires TAC.

Related reading: troubleshooting input drops in IOS-XR and fresh-install an ASR 9001 via ROMmon. For the verification workflow after a card comes up, see Cisco ASR 9000 Line Card Bring-Up: Verify and Troubleshoot; for the diagnostic and OIR side, Cisco IOS-XR Line Card Diagnostics: show diag and Safe OIR; and when a green card is held inactive by cooling or fan faults, Cisco ASR 9000 Fan Module Failure: Troubleshooting Guide.

原文链接：https://www.cisco.com/c/en/us/td/docs/iosxr/asr9000/hardware-install/ethernet-line-card-installation-guide/b-asr9k-ethernt-line-card-install-guide/b-asr9k-ethernt-line-card-install-guide_chapter_010.html