https://network-switch.com/pages/about-us
Summary
To configure an H3C WA7320i reliably (and recover fast when mistakes happen):
- Secure access first (SSH + properly configured VTY/user roles).
- Save correctly using save safely and set main + backup next-startup configs.
- Verify before/after changes with display startup, display saved-configuration, and display diff.
- Always have a rollback path (configuration replace file / remote rollback server).
- Back up/restore startup config to a TFTP server and/or archive configs to a remote server.
This guide focuses on configuration correctness and recovery-the stuff that saves you during on-site cutovers and late-night incidents: safe saving, startup file redundancy, config diff, rollback, remote rollback, and backup/restore.
Understand the 3 configuration "states"
Running vs Startup vs Next-startup
- Running configuration lives in memory and is cleared at reboot/power-off unless you save it.
- A .cfg file is human-readable text; the system may also create a paired .mdb binary file for faster loading.
- At startup, the device tries main next-startup, then backup next-startup, otherwise falls back to factory defaults.
Engineer takeaway: Most "my config disappeared after reboot" incidents are simply "running config wasn't saved to next-startup."
The "Right Way" baseline workflow
Step 1) Make management access resilient (so you don't lock yourself out)
A safe pattern is:
- Create/verify a privileged local user and roles.
- Enable SSH and set VTY lines to use scheme authentication.
- Restrict inbound protocols (ideally SSH only).
The config guide's example shows local-user, role attributes, and enabling remote access (SSH/Telnet) as part of a complete access setup. The VTY/user-line section also explicitly includes a protocol inbound { all | ssh | telnet } control.
Wrong vs Right
| Goal | Wrong (common) | Right (recommended pattern) |
| Remote access | Enable remote access but forget VTY scheme / inbound restriction → lockout risk | Configure SSH + VTY scheme authentication and explicitly set inbound protocol. |
| Privilege | Users exist but missing roles/services | Ensure user roles and service types are present (example includes service-type ssh telnet terminal + role attributes). |
Step 2) Save safely (and set startup redundancy)
The guide warns not to reboot/power-cycle while saving and recommends using the safely keyword. It also highlights the save syntax that can write to main or backup next-startup configuration files.
Right approach
- Save running config with safely (reliability best practice).
- Use main + backup next-startup files for redundancy (best practice).
You can specify next-startup files using:
- startup saved-configuration cfgfile [ backup | main ]
or save-and-set in one step: - save [ safely ] [ backup | main ] [ force ]
Verify immediately
- display startup (current + next startup filenames)
- display saved-configuration (next startup contents)
Step 3) Compare configs before you change (diff is your "preflight check")
The guide provides multiple display diff methods (file vs file, startup vs running, etc.).
Right approach
- Before big changes: capture a known-good file and run display diff against current/running/startup.
Step 4) Build a rollback path before you touch production
Local rollback (fastest when you have the file on device)
Rollback using:
- configuration replace file filename
Important caution: Settings not in the replacement file may be lost, causing service interruption.
Remote rollback (your "break glass" plan)
You can roll back using a file stored on FTP/TFTP and even schedule it.
You configure server parameters with configuration replace server { ftp | tftp } ... file filename.
Scheduling pitfall: If you schedule a rollback and then move the system clock backward, the schedule can be canceled automatically.
Avoid "rollback takes forever"
If the replacement file is huge, rollback can take a long time; the guide suggests extracting only required settings into a smaller file and using:
- configuration execute file filename (deploy without reboot; skips conflicting/failed lines)
Step 5) Back up and archive (so recovery is a procedure, not a guess)
Backup/restore main next-startup config (TFTP)
You can back up the main next-startup configuration file to a TFTP server and restore it back.
Commands:
- Backup: backup startup-configuration to { ipv4-server | ipv6 ipv6-server } [ dest-filename ]
- Restore: restore startup-configuration from { ipv4-server | ipv6 ipv6-server } src-filename
Prereqs include server reachability, TFTP service enabled, and permissions; also verify main next-startup is specified or backup fails.
Remote configuration archiving (FTP/TFTP/SCP/SFTP)
Archiving supports remote servers and can be interval-based; archives follow a filename format like prefix_YYYYMMDD_HHMMSS.cfg.
Remote archiving command pattern:
- archive configuration server { ftp | tftp | scp | sftp } ... filename-prefix ... [ interval interval ]
Do not enable both local and remote archiving at the same time-they are mutually exclusive.
Step 6) Configuration files: don't "fix" them on your laptop
The guide is explicit:
- Use a config file created on the device to ensure successful startup load.
- If you must edit, edit on the device-do not download locally for editing.
It also lists strict file format requirements:
- Sections separated by #
- Starts with #
- Ends with return
Step 7) Encrypting configuration (useful, but know the tradeoffs)
If you enable configuration encryption, encrypted startup configs can only be decrypted by devices with the same master key-and you cannot view encrypted file contents with more, or compare encrypted config files for differences.
Enable with:
- configuration encrypt
Engineer takeaway: If your workflow relies on diff/inspection, plan encryption carefully (or keep a controlled plaintext workflow for troubleshooting).
Common Configuration Mistakes (and How to Avoid Them)
1) "It worked... until reboot" (forgot to save correctly)
Symptom: After reboot, WA7320i comes up missing your changes.
Cause: Running configuration wasn't saved to next-startup. Running config is cleared on reboot/power-off.
Right fix: Use save [safely] [main|backup] and verify with display startup.
2) "Saving caused service impact / I overwrote the wrong file"
Cause: save overwrites the target configuration file; the guide explicitly warns to read system messages carefully and understand impact.
Right fix: Use save safely and standardize filenames + main/backup strategy.
3) "Startup config won't load" (edited off-box / wrong file format)
Cause: Config file not compliant, or edited locally. The guide says don't download locally for editing and lists strict formatting rules (starts with #, ends with return, section separators).
Right fix: Generate files on device (archive/save), edit on device, keep format compliant.
4) "I can't diff my config anymore"
Cause: You enabled encryption; encrypted configs can't be viewed with more or compared for differences.
Right fix: Decide whether you need diff/inspection in your operational workflow before enabling configuration encrypt.
5) "Rollback nuked settings and caused interruption"
Cause: configuration replace removes settings not present in replacement file; the guide warns this can cause service interruption.
Right fix: Always display diff first and ensure the replacement file contains everything required for the intended state.
6) "Rollback is taking too long"
Cause: Replacement file is huge; guide notes rollback can take a long time in that case.
Right fix: Put only needed settings into a smaller file and use configuration execute file for targeted deployment.
7) "Remote rollback didn't execute"
Cause: Scheduling is sensitive to system time; changing clock backward can cancel the schedule.
Right fix: Treat system time as change-controlled during rollback windows; validate display configuration replace server output before relying on schedules.
8) "Backup to TFTP fails"
Cause: Main next-startup file not specified or doesn't exist; guide says backup fails in that case and recommends display startup validation.
Right fix: Set main startup config, verify, then run backup/restore commands.
9) "I can't delete the startup config file"
Cause: The file may be set as both main and backup; you must reset both attributes to actually delete.
Right fix: Follow the guide's reset logic (reset both main + backup if needed).
10) "Archiving doesn't behave as expected"
Cause: Local and remote archiving are mutually exclusive; enabling both breaks expectations.
Right fix: Choose one archiving method (local or remote) and standardize intervals and naming.
"I configured it wrong-what do I do?"
1. If you still have CLI access
- Check what will boot nextdisplay startup
- Inspect what's saved for next bootdisplay saved-configuration
- Diff saved vs runningUse one of the display diff methods (startup vs current, etc.).
- Restore a known-good baselineLocal: configuration replace file filename Remote: configure configuration replace server ... and run/schedule rollback.
- Lock in the fixsave safely and verify startup files.
2. If you lost network access (but have the device reachable)
- Use remote rollback from FTP/TFTP (download → temp file → replace running → delete temp file).
- If you scheduled it, don't adjust system time backward during the window.
3. If the device can't start correctly
The upgrade chapter notes the BootWare menu method is used when the device cannot start up correctly and should be a last resort.
Subtle but real advantage: where a good distributor helps engineers
When you're deploying Wi-Fi 7 at scale, the hard part isn't "a single command"-it's repeatable change control: safe saves, validated startup redundancy, rollback rehearsals, and restoring service quickly.
That's also where a distributor with certified engineers can help: validating the plan, reviewing diffs, and ensuring you have a tested rollback path before you cut over.
(If you need help aligning WA7320i config practices to your site design-office, campus, construction projects-this is exactly the kind of workflow our CCIE/HCIE/H3CIE-level team supports end-to-end.)
Engineer-executable checklist
- Confirm main + backup next-startup configs are different files (redundancy).
- After changes, run save safely (avoid power cycle during save).
- Verify with display startup and display saved-configuration.
- Before big changes, run a display diff preflight.
- Maintain a rollback file and know the warning: replace can drop missing settings.
- If rollback files are huge, prefer configuration execute file for targeted deployment.
- Configure remote rollback server parameters (FTP/TFTP) before maintenance windows.
- Keep system time stable when using scheduled rollback (don't move backward).
- Back up main startup config to TFTP; verify prerequisites and main startup presence.
- Don't edit config files locally; obey format rules
Frequently asked questions (FAQs)
Q1: Why do my WA7320i settings disappear after reboot?
A: Because many changes only exist in the running configuration (memory). On reboot/power-off, running configuration is cleared unless saved to a startup/next-startup file. The guide explicitly states running config is cleared at reboot and must be saved to use it after power cycling.
Q2: What's the safest way to save configuration on H3C?
A: Use "save safely" when saving, because the guide recommends the safely keyword for reliable saving and warns not to reboot/power-cycle while saving to avoid losing next-startup configuration.
Q3: Should I keep both a main and a backup next-startup configuration file?
A: Should I keep both a main and a backup next-startup configuration file?
Q4: How can I verify what the device will load on the next reboot?
A: Use "display startup" to show the current startup and next startup filenames, and "display saved-configuration" to display the next startup configuration contents.
Q5: I want to roll back config without rebooting-what should I use?
A: Use "configuration replace file filename". The guide describes configuration rollback as replacing running configuration with a replacement file without rebooting, but also warns settings not in the replacement file can be lost and service interruption can occur.
Q6: Why did my scheduled remote rollback not run?
A: One common reason is system time changes. The guide warns that if you schedule a rollback and the system clock is changed backward, the rollback schedule can be canceled automatically if it "expires" due to the time change.
Q7: How do I back up and restore the startup configuration to a server?
A: For the main next-startup configuration file, the guide provides:
Backup to TFTP: "backup startup-configuration to ..."
Restore from TFTP: "restore startup-configuration from ..."
It also notes you must have the main next-startup configuration specified, or backup fails.
Q8: Can I edit an H3C configuration file on my laptop and upload it back?
A: The guide says don't. For successful startup load, use a configuration file created on the device; if you edit it, edit it on the device, and do not download locally for editing. It also lists strict formatting rules like starting with # and ending with "return".
Q9: Why doesn't "display diff" work after I enabled config encryption?
A: Because encrypted configuration files cannot be compared for differences, and you can't view them with more either. The guide explicitly lists these restrictions after encryption.
Q10: My rollback file is huge and the device takes too long-how can I speed this up?
A: The guide notes rollback can take a long time if the replacement configuration contains many settings. If only specific settings are needed, put them into another file and use "configuration execute file" to deploy only those settings, reducing rollback time.
Did this article help you or not? Tell us on Facebook and LinkedIn . We’d love to hear from you!
