Which Command Will Display the Current Contents of NVRAM: Complete Platform Guide

On Cisco IOS and IOS XE devices, the command that displays the current contents of non-volatile random-access memory (NVRAM) is show startup-config, which prints the saved startup configuration held in NVRAM. You can confirm the NVRAM filesystem itself with show filesystem, and on many platforms dir nvram: lists the files stored there. Other systems use different tools entirely: UEFI firmware uses varstore dumps, and embedded boards use nvram show or fw_printenv. The right command therefore depends on which NVRAM you mean, and the sections below separate these cases precisely.

What NVRAM actually is and why the command differs by platform

NVRAM is a small, battery-backed or flash-emulated memory region that survives power loss. On routers and switches it stores the startup configuration and a few environmental variables. On PCs it holds UEFI variables such as boot order and Secure Boot keys. On embedded Linux boards it stores bootloader environment variables. Because each platform exposes NVRAM through a different software layer, no single command works everywhere.

The Cisco case is the one most searches target. Cisco IOS keeps the running configuration in RAM and a saved copy in NVRAM. The show startup-config command reads that saved copy and prints it to the terminal. The word "current" matters: you see what is in NVRAM now, not what is active in RAM. If the two differ, the device will boot with the NVRAM version after a reload.

Plain language: NVRAM is the device's memory of how it should start, and the display command just reads that memory back to you.

Cisco IOS and IOS XE: the primary answer in detail

The canonical command is show startup-config. On IOS XE it also works, and show running-config displays RAM instead. To inspect the NVRAM filesystem itself, use show filesystem, which lists nvram: among the available filesystems and reports its size and free space. The dir nvram: command lists files in that filesystem on platforms that expose it.

A subtlety: on some switches the startup configuration is stored in flash rather than true NVRAM. The command still works because IOS abstracts the storage location. The counterintuitive detail is that show startup-config may show "Using 1234 out of 524288 bytes" even when the config looks complete, because NVRAM is tiny and the device compresses the saved config.

Typical NVRAM sizes on older Cisco platforms range from 32 KB to 512 KB. That is why large configurations, especially with many ACLs, can exceed NVRAM and fail to save, producing a "Configuration too big for NVRAM" error. Modern IOS XE platforms often use larger flash-backed storage and report sizes in megabytes.

Quantified context: sizes, persistence, and timing

NVRAM persistence depends on the backup mechanism. A classic battery-backed SRAM retains data for years if the battery holds, typically 3 to 10 years depending on chemistry and temperature. Flash-backed NVRAM retains data for decades without power but has limited write cycles, often 100,000 erase cycles per sector.

On Cisco devices, a save operation (copy running-config startup-config or write memory) completes in under a second for typical configs but can take several seconds on large configs. The startup-config is loaded during boot before the network interfaces come up, which is why a corrupt NVRAM config can strand a device.

UEFI variable stores on PCs are typically 64 KB to 128 KB per variable store, though some firmware reserves more. Embedded bootloader environments commonly occupy 32 KB to 256 KB of flash. These numbers explain a recurring failure: environments and configs outgrow their NVRAM region and writes silently fail or truncate.

Edge cases that change which command you use

The command differs sharply outside Cisco. On Linux with the nvram driver, nvram show prints bootloader variables, and fw_printenv does the same for U-Boot. On macOS, nvram -p prints the firmware variables. On Windows, UEFI variables are read through the firmware, not a simple shell command; tools like the UEFI shell's dmpstore or vendor utilities display them.

On Cisco devices, ROMmon mode is a separate edge case. When IOS will not boot, you inspect NVRAM indirectly with commands like confreg and set, and you may copy the config out with tftpdnld. The standard show startup-config is unavailable because IOS is not running. This is the professional caveat: the display command assumes a working OS, and recovery workflows need different tools.

Virtual and cloud platforms add another layer. Many virtual routers emulate NVRAM in a file, so the command works but the underlying "NVRAM" is just a disk file. Some cloud network appliances do not persist startup config across reboots unless explicitly saved, so show startup-config may show an empty or default config.

Comparison of NVRAM inspection methods

The table makes the core point: the keyword answer, show startup-config, is correct for the Cisco context that dominates searches, but each platform has its own inspector.

Misconceptions and red-flag warnings

A common misconception is that show running-config displays NVRAM. It does not; it reads RAM. Another is that saving is automatic. On Cisco IOS, changes live in RAM until you explicitly copy them to NVRAM, and a reload without saving discards them.

Red flag: show startup-config returns "startup-config is not present" because nothing was ever saved, so the device will boot to defaults or the setup dialog. Red flag: NVRAM write fails with a size error, meaning the config exceeds the region and will not persist. Red flag: NVRAM checksum errors at boot, often from a failing battery or interrupted write, which can force recovery mode. Red flag: UEFI variable store full errors, which can block firmware updates or boot entry changes. Red flag: A cloud or virtual appliance shows a startup config that does not match the running config, indicating save did not occur or storage is ephemeral.

Plain language: a mismatch between running and startup configuration is the single most reliable sign that your changes will not survive a reboot.

Practical actions and thresholds

To verify NVRAM contents and protect against loss, follow a fixed sequence. First, run show startup-config and capture the output. Second, compare it against show running-config to spot unsaved changes. Third, confirm NVRAM capacity with show filesystem. Fourth, if space is tight, prune stale entries before saving.

Concrete thresholds help. If NVRAM use exceeds about 80 percent of capacity, plan to reduce configuration size or migrate to a platform with flash-backed storage. If a battery-backed device is more than 5 years old, test persistence with a controlled reload during a maintenance window. If a save takes more than 10 seconds on a midrange device, investigate storage health.

For non-Cisco systems, document the exact command for each platform and test it during onboarding rather than during an outage. Store a copy of the startup configuration off-device, because NVRAM is small and failure-prone compared with disk storage.

Limitations and what the command cannot tell you

Displaying NVRAM contents does not verify integrity. The command prints what is stored, not whether it is valid; a corrupted config can print cleanly and still fail at boot. It also does not show the battery or flash health behind the storage, and it cannot recover a device that will not reach the operating system.

The deeper limitation is semantic: "NVRAM" means different hardware on different products, so any single-command answer is context-bound. The best practice is to identify the platform first, then use its inspector. For Cisco IOS and IOS XE, that inspector is show startup-config, backed by show filesystem for capacity checks.

This article is general educational information about device storage and command usage, not a configuration plan or a security recommendation for any specific system. Verify commands against your vendor's current documentation and test changes in a lab before applying them to production equipment.