MLNX-OS Configuration Management: Save, Load, Reset

Configuration file handling on NVIDIA MLNX-OS (the OS behind Mellanox switches) follows its own set of commands that trip up engineers coming from Cisco or Junos. This guide covers the essentials from the official MLNX-OS user manual: saving the running config, switching between configuration files, restoring factory defaults, and the special procedure for dual management module chassis — all with exact CLI syntax.

The mental model to hold onto is that MLNX-OS separates the running configuration from the saved configuration files, and lets several named files coexist in flash. Exactly one of them is marked active. Everything you type lands in the running configuration; nothing survives a reboot until you explicitly write it. Getting this model right explains almost every "my change disappeared" report.

Running, Saved and Active: Three Different Things

• Running configuration — what the switch is doing right now. Lives in memory. Modified by every configuration command you enter.
• Configuration files — named files in flash (for example initial or myconf). The factory-fresh switch comes with an initial file.
• Active file — the one configuration file the switch designates as the source for the next boot. Only one file can carry the (active) marker at a time.

If you save with a named file and do not make it active, you have created a draft; the running config is preserved on disk but the switch will still boot the old active file. That distinction is the source of the no-switch keyword explained below.

Saving the Configuration

Two equivalent commands exist depending on your CLI mode. In Config mode use configuration write; in Enable mode use write memory. Both save to the active configuration file:

switch (config) # configuration write

To save to a named file without making it active, append no-switch; omit it to save and activate the new file:

switch (config) # configuration write to myconf no-switch
switch (config) # configuration write to myconf
switch (config) # show configuration files
initial
myconf (active)

Read that output carefully: the second form changed which file the switch will use at the next boot. On a production switch, be deliberate about whether your intent is "take a copy" (no-switch) or "make this the standard config" (without it). Many engineers use no-switch for every save except the final one in a change window, which keeps the rollback target intact.

Loading a Configuration File

By default (or after a reset) the system loads the initial file. Switch to another saved file and make it active with:

switch > enable
switch # configure terminal
switch (config) # configuration switch-to myconfig

Because configuration switch-to applies a different configuration to the live switch, it will drop links, re-address interfaces and can move your management path. Run it from a console session where possible, and keep a second configuration file that represents the previous known-good state so the operation is reversible.

To pull a configuration file in from an external server — a restored backup, for example — use configuration fetch and then activate it:

switch (config) # configuration fetch scp://root@my-server/root/tmp/myconf
switch (config) # show configuration files
switch (config) # configuration switch-to myconf

Listing, Creating and Removing Configuration Files

The file lifecycle is deliberately simple, and the commands are worth having at your fingertips during a maintenance window:

switch (config) # show configuration files
switch (config) # configuration new my-new-file
switch (config) # configuration delete my-old-file
switch (config) # show configuration

configuration new creates a fresh file — seeded from the running configuration in most builds — that you can then edit conceptually through normal configuration commands and save into. show configuration displays the effective configuration rather than a stored file, which is the closest equivalent to a Cisco show running-config and the right way to answer "what is this switch actually doing".

Deleting a file is immediate and there is no recycle bin. Before removing anything, confirm with show configuration files which file carries the (active) marker, and confirm you have an off-box copy — the backup workflow is described in the MLNX-OS configuration backup guide.

Restoring Factory Defaults

If the configuration becomes corrupted, restore the factory default with reset factory keep-basic (the keep-basic variant preserves the basic network identity):

switch (config) # reset factory keep-basic

The command family has more than one flavour, and choosing the wrong one is how a remote engineer loses access to a switch:

• reset factory keep-basic — resets the configuration but keeps basic settings such as the management IP, so you stay reachable.
• reset factory — clears everything, including addressing. Expect to rebuild from the console wizard afterwards.
• reset factory keep-basic-backup — the variant used on systems where a backup of the basic settings should be retained; check the release notes for your MLNX-OS version before relying on it.

After a full reset the switch boots into an unconfigured state and normally presents the Configuration Wizard on the console — walk through it with the MLNX-OS first-time setup wizard guide and then reload the real configuration from backup.

Dual Management Module Systems

On modular switches with two management modules, the reset procedure is sequential: connect via console, remove the slave module, run reset factory on the master, wait for reboot, log in as admin and run the Configuration Wizard, then insert the slave module, remove the master module so the slave takes over, repeat the reset on the new master, insert the other module, and finally power cycle. Getting this order wrong can leave you with a half-initialized chassis.

Three details make the difference between a clean reset and a support call. First, remove — do not just power off — the module, because the chassis must not see two management modules with conflicting configurations competing for mastership. Second, wait for the reboot to complete before inserting anything; a module inserted mid-boot can be detected as a new master and re-trigger the whole sequence. Third, record the chassis serial number and the module slot positions before you start, so that if the process stalls you can describe the state precisely. Keep a console session on the master throughout; a terminal server with logging is ideal, because you will want the boot log when it goes wrong.

Designing a Configuration File Strategy

Once you understand that several named files can coexist, the useful question becomes: what should they be? A workable convention for Mellanox switches:

• initial — leave it as the factory baseline. Never overwrite it; it is your last-resort known state.
• prod-<date> — the configuration actually running in production, saved and activated at each change window.
• pre-<change-id> — the state immediately before the current change, saved with no-switch so it can never become active by accident.
• lab-<feature> — experimental configurations, on non-production switches only.

With that scheme the rollback procedure is a single command — configuration switch-to pre-<change-id> — and the file list itself is the audit trail.

Configuration Files and Firmware Upgrades

Firmware work is where configuration files earn their keep. The safe sequence is to capture a text rendition of the current configuration, save and activate a dated file, record the running image version, and only then perform the upgrade. If the new image rejects a configuration line, an upgraded switch can boot with a partially applied configuration; the text rendition lets you diff what the switch intended against what it actually accepted.

Two habits reduce the risk further. First, upgrade one switch at a time on any path you care about — in a bonded or MLAG pair, never both ends of the same link in the same window. Second, keep the previous firmware image on the switch where the platform supports image slots, so a rollback does not depend on a file transfer over the very fabric that may be the problem.

Verifying and Auditing Configuration Changes

Two commands cover almost every audit question: show configuration tells you the effective configuration, and show configuration files tells you which stored file the switch considers active. Comparing the two shows exactly what changed but was never saved:

switch (config) # show configuration files
switch (config) # show configuration
switch (config) # configuration text generate active running save audit-check
switch (config) # configuration text file audit-check upload scp://root@server/tmp/audit-check

Generating the text rendition on demand and pulling it off-box gives you a versioned history of the switch's intent without running any automation agent on the switch itself. In a change-controlled environment that single pattern answers "what did this device look like at 03:00 last Tuesday" — a question that comes up far more often than anyone expects, and one that syslog does not answer well because syslog records commands, not resulting state.

What Actually Happens at Boot

Understanding the boot sequence removes the guesswork from recovery. The switch loads its firmware image, then reads the configuration file marked active and applies it. If the active file is missing or unreadable, the platform falls back to the factory baseline and presents the setup wizard on the console. That behaviour is predictable, which is good news: a switch that boots into the wizard is not broken, it simply could not find a usable configuration file — and your off-box backup is the fix.

Common Mistakes and How to Avoid Them

• "I saved and it still reverted." You used configuration write to name no-switch, which saved without activating. Check the (active) marker.
• "My change is in show configuration but not after reload." Nothing was written. Run configuration write or write memory.
• Reset removed the management IP. reset factory was used where keep-basic was intended.
• Two files look identical. One is a draft copied before the latest change window. Diff the text renditions rather than guessing.

Pair this with our MLNX-OS CLI modes and commands guide and switch port types configuration. New to the platform? Start with the MLNX-OS first-time setup wizard walkthrough. For file-level backups to a server, see backing up switch configuration to a server, and to keep an eye on configuration events after a change, see MLNX-OS filters, watch and log commands.

原文链接：https://networking-docs.nvidia.com/mlnxosum/3126200lts/configuration-management