MLNX-OS Configuration Management: Save, Load, Rollback

Every MLNX-OS outage caused by a configuration change has the same root cause: the change was applied to the running configuration, not tested, and then saved. Understanding the difference between the running and startup configurations, where the files live, and how to load a known-good file without console access turns configuration management from a risk into a routine. This article covers the model, the file operations, and a recovery workflow for when a switch is unreachable.

Running versus startup configuration

The workflow that prevents most incidents is a two-step discipline: make the change, verify it, then save. Resist the habit of saving first "just in case" — that converts an experimental change into the boot configuration.

Everyday operations

switch (config) # show running-config
switch (config) # show running-config | include ethernet

switch (config) # write memory

switch (config) # show configuration files
switch (config) # show configuration files initial-config

write memory copies the running configuration into the startup configuration, overwriting the previous startup file. Before running it on a fabric, capture the current startup file as a dated backup — the save is not reversible on the device itself.

Backing up to a remote host

switch (config) # configuration upload backup-20260921 scp://user@10.10.10.5/configs/switch-a.cfg
switch (config) # show configuration files

Storing backups on the switch's own filesystem gives you a false sense of safety: the most common failure modes are a full flash, a replaced chassis, or a switch that will not boot. Copy every accepted change off the device. Automating this on a schedule is the single highest-value operational habit for an MLNX-OS fleet, and the same playbook pattern used for IOS devices works here (facts collection plus a configuration fetch task).

Loading a configuration file

switch (config) # configuration fetch scp://user@10.10.10.5/configs/switch-a.cfg
switch (config) # configuration switch-to /tmp/switch-a.cfg
switch (config) # reload

Fetch, switch-to, reload: the three steps that restore a known-good state. Two cautions. First, some versions require the file to be validated before switching; run the configuration verify form if available on your release. Second, a load replaces the whole configuration — anything configured after the backup was taken (a new VLAN, a new user account) will be gone.

Recovering an unreachable switch

1. Connect to the console or the management interface and get a login prompt.
2. Check which configuration is active: show configuration files.
3. If the startup file is the broken one, revert to the previous file rather than trying to repair it live.
4. If the network configuration is what broke reachability, fix it in the running configuration first and verify the management path before saving.
5. Only save once you have confirmed reachability from an external host.

On modular systems with dual management modules, the documentation calls out the sequence explicitly: the configuration file must be loaded on the correct management module, and a power cycle may be needed to force the load. If you are running a dual-supervisor chassis, verify which module holds the active configuration before assuming a file is missing.

Configuration hygiene for a fleet

• Hostname-first templates — in a fleet, a saved configuration whose hostname is wrong is worse than no backup; automated loads propagate the mistake.
• Version the files — name backups with the switch name and date, and store them in the same repository as the templates.
• Diff before load — a quick textual diff between the current running configuration and the file you are about to load catches unintended removals.
• Log configuration events — send syslog to a central collector so configuration changes and login events are correlatable after an incident.
• Test the restore path — an untested backup is a hope, not a plan. Restore onto a lab switch at least once per quarter.

Verification after any restore

switch # show version
switch # show running-config
switch # show interfaces ethernet status
switch # show vlan
switch # show logging

Confirm interfaces are up with the expected speeds, VLANs exist, and the log does not show configuration application errors. Only then consider the change window closed.

Verifying configuration accuracy after a restore

A restore that completes without errors is not a verified restore. These four checks catch the failure modes that appear days later:

1. Identity check — hostname, management address and default gateway match the device you intended to configure.
2. L2/L3 state — expected VLANs exist and interfaces carry the intended addresses (show interfaces ethernet status, show vlan, show ip route).
3. Services — SNMP, syslog, NTP and authentication settings are present; a silent NTP failure makes every later log timestamp useless.
4. Reachability from outside — ping and SSH from a different subnet, which tests routing and ACLs rather than local configuration.

switch # show version
switch # show interfaces ethernet status
switch # show vlan
switch # show ip route
switch # show logging | tail 50
switch # show configuration files

For fabrics, verify one representative device per role rather than spot-checking randomly: spine, leaf and management switch each exercise different parts of the configuration.

Scheduling automated backups

Manual backups are taken on the days nobody has time to take them. A workable schedule for a small fleet:

Automating the fetch is straightforward with an Ansible task or a shell loop over the inventory using SCP; the important part is not the tool but the retention policy and the periodic restore test. Store backups outside the switch's own filesystem and outside the same failure domain as the switch itself — a backup on the device it protects is not a backup.

Configuration hygiene checklist

• Every configuration file carries the device hostname in its filename.
• Descriptions on interfaces reference the change ticket or the connected device.
• Unused interfaces are documented rather than left ambiguous.
• Passwords and SNMP communities are stored in a secret manager, not in the configuration repository.
• Obsolete backups are pruned on a schedule, so restoring by filename does not accidentally use a two-year-old file.
• A single named owner is responsible for the configuration repository.

Related articles

For the full interface and routing configuration workflow see Mellanox MLNX-OS VLAN and IP routing configuration; automated configuration collection is covered in Ansible network facts and config backup examples, and central logging is explained in Cisco IOS logging levels, buffer and trap configuration (the concepts map directly to MLNX-OS syslog settings).

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