Introduction
This document describes the implications of using the reload ascii command.
NX-OS Configuration Files
During bootup, NXOS can load the configuration in one of two different ways:
- Binary boot: the default boot mechanism. Precompiled configuration in binary format is applied to every NXOS process. The plain text startup-config file is not used, and is only available for reference. In general, this file is expected to accurately reflect the configuration applied on bootup, given it is a mirror of the running-config, which is what the binary configuration is based on. This binary configuration is called Persistent Storage Service (PSS).
- ASCII boot: only used in exceptional situations. Configuration in plain text format is read from the startup-config file. It then gets applied during switch boot exactly as it would have beenif entered via NX-OS CLI, line by line. Conceptually similar to running write erase and reload commands, followed by copying a backup of the configuration to running-config.
Potential Problems with ASCII Boot
It is generally not recommended to execute this command unless Cisco TAC proposed it.
The exact behavior can differ between different switch models and software versions. In general, newer Nexus 9000 series switches show far fewer issues related to ASCII boot, as there have been workarounds applied internally to minimize impact. Older switches such as Nexus 7000 can encounter more problems.
- Time to boot. The switch can take significantly longer to boot, especially if it is a modular switch with a large amount of VDCs. In some cases, the boot can take 1 hour or even longer. This in itself can cause problems.
- Configuration inconsistency while booting up. Since the configuration is applied line by line at a relatively slow pace, the parts of the configuration that are earlier in the startup-config file can take effect much sooner than the ones closer to the end. For example, it could happen that VPC domain and peer-link configuration gets applied much sooner than the peer-keepalive interface configuration. The VPC auto-recovery timer could expire before peer-keepalive is configured, VPC never has a chance to find out that there is a peer with "primary" role already, and VPC can come up as primary on the local switch as well, leading to a split brain situation.
- Configuration missing after bootup. Since the commands are being applied line by line, it could happen that the entity being configured is not ready yet, so its configuration cannot be applied. This is avoided in most cases on newer Nexus 9000 series switches, but is relevant to older ones like Nexus 7000. Example: FEX port configuration, ports such as Ethernet101/1/1 can still be missing in the system by the time their commands need to be applied. After running the reload ascii command, a full diff check of the running config is necessary.
- Configuration not taking effect until subsequent reload. Nexus 9000 series switches generally have ways to avoid this, but on Nexus 7000 switches in particular, configuration that requires a reload to take effect, such as limit-resource u4route-mem minimum X maximum Y, does not take effect until a subsequent normal reload, exactly as if it has been configured manually via CLI on a freshly out-of-the-box switch.
Recommended Approach to Minimize Downtime
If dealing with a redundant production network where impact due to reloading the switch needs to be avoided, given the previously mentioned potential caveats, on Nexus 7000 switches, and, to a lesser extent, on Nexus 9000 switches, it is recommended to perform the ASCII reload as described.
- Isolate the switch from the network to ensure that any inconsistent states while in the process of applying configuration do not affect the live network.
- Plan for the reload process to take a long time, especially on modular switches with many linecards and VDCs.
- Back up the configurations of all VDCs.
- Perform the reload ascii command. While the switch itself can become accessible relatively soon, the bootup is only completed once the "%ASCII-CFG-2-CONF_CONTROL: System ready" message appears in syslog. This can take significantly longer. Examples of messages to look for:
switch# show logging log | in ASCII
2025 Aug 20 09:32:07 switch %DAEMON-2-SYSTEM_MSG: <<%ASCII-CFG-2-CONF_CONTROL>> Ascii replay - ascii_cfg_server[14359]
2025 Aug 20 09:32:44 switch %ASCII-CFG-2-CONFIG_REPLAY_STATUS: Bootstrap Replay Started.
2025 Aug 20 09:32:49 switch %ASCII-CFG-2-CONFIG_REPLAY_STATUS: Bootstrap Replay Done.
2025 Aug 20 09:33:50 switch %ASCII-CFG-2-CONFIG_REPLAY_STATUS: Ascii Replay Started.
2025 Aug 20 09:33:56 switch %ASCII-CFG-2-CONFIG_REPLAY_STATUS: Ascii Replay Done.
2025 Aug 20 09:33:56 switch %ASCII-CFG-2-CONF_CONTROL: System ready
- Run a diff check to compare all running-configurations to the backups taken prior to reloading. If any parts of the configuration are missing, add them manually.
- To ensure that all of the commands requiring a reload take effect, run the copy running-config startup-config and reload commands in order to perform a normal binary reload.
Feedback