Cisco Nexus ICMP Unreachable: Why the Command Does Not Appear in Running-Config

During a Nexus security-hardening review, an ICMP unreachable-related change left no expected line in show running-config. I reviewed command syntax, defaults display, and IP interface checks to determine what that observation could establish.

Cisco Nexus ICMP unreachable configuration and operational behavior

1. The original observation

The review covered Ethernet and VLAN interfaces. After attempting the change, I could not see the expected running-configuration line. I considered both an existing default and an unexpected interface context. The configuration display alone did not resolve which explanation applied. The verification workflow below is documentation-based; it does not establish results from an unrecorded device test.

2. Environment and evidence limits

Item	Scope
Hardware	Cisco Nexus 9500 Series
Software	NX-OS 7.0(3)I7(7)
Interfaces reviewed	Ethernet and VLAN interfaces
Original observation	Expected command line absent from the displayed running configuration
Documentation validation	Cisco Nexus 9000 NX-OS 7.0(3)I7(x) command references and Cisco security guidance
Lab validation	Not performed for this publication

Interface names are illustrative. Production addresses, topology, credentials, logs, and customer details are omitted.

3. Verify the command and scope

The Cisco Nexus 9000 NX-OS 7.0(3)I7(x) Command Reference uses the plural form:

ip unreachables
no ip unreachables

This control excludes port-unreachable messages. Check that behavior separately rather than treating all ICMP Destination Unreachable codes as one setting.

The Cisco Nexus OS Software Security Primer uses singular no ip unreachable. Check the target reference and on-device help before using examples from another document or OS. Acceptance of shortened or singular input in the original session was not established.

Accepted ip unreachables and no ip unreachables commands change interface configuration and may affect error reporting and diagnostics. The show commands below inspect state.

4. Compare configuration and state

Running configuration and operational IP interface state are separate checks

Default values may not appear as explicit commands

Use show running-config all to compare configuration with defaults included. This can reveal a display difference, but still does not independently establish live ICMP behavior.

The default can depend on hardware, NX-OS release, and interface mode

The Security Primer warns that defaults vary with hardware, NX-OS release, and Layer 2 or Layer 3 operation. Verify the target instead of borrowing Nexus 7000, 3000, or another 9000 release's default.

Operational IP interface state is a separate source of evidence

The NX-OS 7.0(3)I7(x) show-command reference documents show ip interface fields for unreachable and port-unreachable behavior. Inspect that state alongside configuration.

5. Read-only verification

The following commands inspect configuration and state without changing forwarding:

Nexus ICMP verification workflow from NX-OS release to packet testing

Step 1: Confirm platform and interface role

show version
show interface brief
show interface switchport

Record the build and whether the Ethernet target is an L2 switchport or L3 interface. Ethernet and VLAN interfaces may expose different IP contexts.

Step 2: Compare configuration and defaults

show running-config interface ethernet 1/1
show running-config interface vlan 100
show running-config all

Ethernet1/1 and Vlan100 are examples. Confirm the release-specific interface all syntax before automation; an unchanged display does not prove a successful change.

Step 3: Check IP interface state

show ip interface ethernet 1/1
show ip interface vlan 100

Use the commands where the interface has an IP context. Check unreachable and port-unreachable separately. Fields vary by release, and no captured CLI output is claimed here.

Step 4: Validate packets if required

If acceptance depends on packets, use a representative isolated lab. Capture ICMP type/code under controlled conditions and record ACLs, routing, control-plane behavior, and rate limits before attributing absent messages to this setting. These are documented investigation steps. They do not establish that I collected this output or performed a capture during the original review.

6. Security and diagnostic tradeoffs

RFC 792 defines IPv4 ICMP Destination Unreachable messages. Cisco notes that generating ICMP errors in response to filtered traffic can consume CPU resources. Reducing some messages can be relevant to a hardening policy, but ICMP errors also assist troubleshooting.

For example, RFC 1191 defines IPv4 Path MTU Discovery using fragmentation-needed feedback. The effect of a particular NX-OS setting on individual ICMP error codes and traffic paths needs release-specific verification before applying a blanket disablement policy.

Before an operational change, record the requirement and target interface, assess application and diagnostic effects, and prepare rollback and verification.

7. Interpreting the missing line

My initial default-value explanation needed more evidence. Verify spelling, interface mode, default-inclusive output, and operational state before drawing a conclusion from a missing line.

For a separate account-review case, see Cisco Nexus SNMPv3 User Appears as a CLI Account: Before You Delete It. It examines NX-OS user behavior before account removal.

8. Operational checklist

Confirm hardware, software release, and supported CLI syntax.
Check whether the interface is operating at Layer 2 or Layer 3.
Distinguish normal running-config from default-inclusive output.
Use show ip interface for a more direct IP state check.
Account separately for ICMP unreachable and port-unreachable behavior.
Review performance, diagnostics, and Path MTU Discovery considerations.
Where required, test packet-level results in a representative lab.
Document findings and uncertainties rather than treating an absent line as proof.

Search This Blog

NetOps Field