Check ASR line cards and local IPv4 exposure together

Bottom line: Match the actual router and line-card inventory before interpreting the traffic boundary. Keep exposure assessment, recovery from an incident and installation of fixed software as separate decisions.

Source fact: documented behavior

The Cisco IOS XR Software for ASR 9000 Series Routers IPv4 Unicast Packets Denial of Service Vulnerability applies to listed ASR hardware running vulnerable 64-bit IOS XR software with IPv4 enabled on an installed line-card interface.

Its hardware scope includes ASR 9000 and 9900 systems with Lightspeed or Lightspeed-Plus line cards, plus ASR 9902 and 9903 routers.

Cisco distinguishes affected router-destined IPv4 processing from transit IPv4 and IPv6 traffic, which it says do not trigger this issue; the advisory provides updates and no workarounds.

What the source does not establish

This article preserves the advisory’s applicability and traffic scope. It does not classify arbitrary packet captures, identify the cause of an unexplained reset or certify another platform as supported. Do not generate a flood or crafted traffic to test exposure; use inventory and current vendor guidance for the assessment.

Applicability questions

• What exact chassis and installed line-card identifiers are present?
• Which 64-bit IOS XR release is actually running?
• Where is IPv4 configured in the affected hardware scope?
• What incident evidence or vendor assistance is needed before attributing a reset?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends matching hardware, release and IPv4 configuration before drawing a conclusion about this ASR advisory.

1. Collect the actual chassis and line-card inventory through approved read-only administration. Match each identifier with the current advisory list rather than relying on an abbreviated ASR family label. Retain unresolved product identifiers for vendor clarification. Give a fixed-function router and a modular chassis their own evidence references instead of forcing both into an assumed slot layout.
2. Record the installed IOS XR release and the relevant IPv4 interface configuration. Keep the source’s for-us processing boundary visible in the assessment notes. Ask the network owner to distinguish a router-addressed service path from a transit path using existing authorized design and monitoring evidence. Do not convert that distinction into a new firewall workaround that the advisory does not supply.
3. Compare the confirmed product and release with the applicable fixed-software guidance and schedule the reviewed upgrade. If an incident is already being investigated, preserve existing alarms and diagnostic observations before a recovery action where practical. Keep the incident’s suspected cause provisional until evidence and appropriate vendor analysis support attribution.

Verification and evidence

Proposed verification: use a desk inventory containing one listed hardware configuration and one unresolved card identifier. Require the reviewer to identify the missing evidence before assigning a disposition. Add a transit-only observation and ask why it does not by itself demonstrate the router-destined condition described by the source.

After an authorized update, retrieve the actual software identity and confirm the intended network services through ordinary approved checks. Preserve any continuing line-card errors as a separate investigation. No router inventory, packet processing, reset or upgrade was tested for this article, and ordinary service recovery is not presented as proof that a vulnerable release was fixed.

Official references

• Cisco IOS XR Software for ASR 9000 Series Routers IPv4 Unicast Packets Denial of Service Vulnerability — Cisco; official security advisory.

Source review completed October 30, 2026. Recheck the official source and deployment-specific applicability before changing production settings.