Straight from chapter 4 of Huawei's Sx3-series switch maintenance manual — the five-step routine inspection: environment, basic information, running status, ports and services. What to look at in each step, what counts as a pass, the recommended cycle, and the exact display commands used to check it.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Huawei's own Sx3-series maintenance manual splits routine maintenance into five sections, each with its own recommended cycle — that structure is the actual point.
Chapter 4 of Huawei's Sx3-series switch maintenance manual, “Routine Maintenance,” organizes everything into five sections: device environment check, device basic information check, device running check, port content check, and service check. Each section carries its own suggested cycle — daily, weekly, monthly, quarterly, half-yearly or yearly — and its own pass/fail standard for every item.
What follows is that five-step routine, in order — what to check, the display command that checks it, the standard that counts as a pass, and the recommended cycle — plus the gotchas that turn a check that looks routine into one that gets misread.
Same order the source manual uses — environment first, service checks last.
Diagram labels are kept in English for engineering clarity.
A stable running environment is the precondition for the device running normally at all — this step has no CLI commands, only physical checks.
| Recommended Cycle | Check Item | Check Method | Pass Standard |
|---|---|---|---|
| Day | Air conditioning / room temperature | — | The air conditioning runs continuously and stably, keeping the equipment room temperature within the range the device can tolerate. |
| Power connection | — | Power cables are correctly connected to the device's designated position and firmly seated; the device's power indicator stays solid green. | |
| Week | Room temperature and humidity | — | Operating temperature 0°C to 45°C; long-term relative humidity 5%RH–85%RH and short-term 0%RH–95%RH, without condensation. If the room can't consistently meet this, service the air-conditioning system or add humidity control. |
| Cooling / airflow | — | Fans must keep running normally during operation (except while being cleaned) — shutting them off deliberately raises device temperature and can damage boards. The area around the device must be free of clutter. | |
| Quarter | Cable routing | — | Power cables are routed separately from business cables; both power and business cabling are neat and orderly. |
| Cable labeling | — | Cable labels are clear, accurate and follow the standard. | |
| Half-year | Dust-screen cleanliness | — | The dust screen is clean and free of visible dust buildup — clean or replace it promptly to avoid affecting cabinet-door and fan-frame ventilation. |
| Year | Fan-frame cleanliness | — | Clean the fan frame promptly so accumulated dust doesn't threaten the fan frame's stable operation. |
Checks whether basic information like software version, patch information and system time is correct — recommended monthly.
| Check Item | Check Method | Pass Standard |
|---|---|---|
| Software version running | display version | The board's PCB version number and software version number match what is required. |
| Software package in use | display startup | The file names of the product software and configuration file currently in use, and to be loaded at next startup, are correct. |
| License information | display license | The license file is activated, and its “Expired date” is either “PERMANENT” or still within the valid run period. |
| Patch information | display patch-information | The patch file must match actual requirements — Huawei recommends loading the latest patch for the running product version — and the patch must be in effect, meaning the total patch count matches the running patch count. |
| System time | display clock | Time should match local actual time (difference no greater than 5 minutes) for precise fault localization. If it doesn't, run clock datetime or configure NTP to synchronize network time. |
| CF-card / Flash space | dir cfcard: / dir flash: | Every file on the CF card (chassis switches) or Flash (box switches) must be useful — otherwise delete it with the delete /unreserved command. |
| Configuration correctness | display current-configuration | Verify the currently effective configuration parameters are correct by reviewing the running configuration. |
| Debug switches | display debugging | All debug switches should be turned off while the device is running normally. |
| Configuration saved | compare configuration | After business configuration is confirmed correct, it must be saved — the running configuration must match the saved configuration. |
<HUAWEI> display version
<HUAWEI> display startup
<HUAWEI> display license
<HUAWEI> display patch-information
<HUAWEI> display clock
<HUAWEI> dir flash:
<HUAWEI> display current-configuration
<HUAWEI> display debugging
<HUAWEI> compare configurationChecks running conditions — board status, fan and power status, alarms, CPU and memory, logs, temperature — mostly daily, two items monthly.
| Recommended Cycle | Check Item | Check Method | Pass Standard |
|---|---|---|---|
| Day | Board running status | display device | Focus on board presence and status information: normal means board “Online” = “Present”, “Power” = “PowerOn”, “Register” = “Registered”, “Status” = “Normal”. |
| Day | Fan status | display fan | “Register” = “Registered” indicates normal. |
| Day | Power status | display power | “state” = “supply” indicates normal. |
| Day | Alarm information | display alarm all | No alarm information present. If there is an alarm, record it — any alarm of severity level “critical” or above needs immediate analysis and handling. |
| Day | CPU status | display cpu-usage | CPU usage of each module is normal. If CPU usage exceeds 80%, it warrants close attention. |
| Day | Memory usage | display memory-usage | Memory usage is normal — if “Memory Using Percentage” exceeds 60%, it needs attention. |
| Day | Log information | display logbuffer / display trapbuffer | No abnormal information present. |
| Day | Temperature check | display temperature all | Each board's temperature is at least 5°C below the threshold, with status “Normal”. |
| Month | FTP service port | display ftp-server | Any FTP network service port not in use should be closed. |
| Month | Active/standby board backup status | display switchover state | When both active and standby boards are present, both must show status information; after a switchover completes and the device resumes normal operation, the active board should show “realtime or routine backup” to be considered normal. |
<HUAWEI> display device
<HUAWEI> display fan
<HUAWEI> display power
<HUAWEI> display alarm all
<HUAWEI> display cpu-usage
<HUAWEI> display memory-usage
<HUAWEI> display temperature allChecks port negotiation mode, configuration and status — recommended weekly.
| Check Item | Check Method | Pass Standard |
|---|---|---|
| Port error packets | display interface | While business is running, check for port errors including CRC errors. |
| Port negotiation mode | display interface | Port negotiation mode is correct and consistent on both ends — half-duplex mode is not acceptable. |
| Port configuration | display current-configuration interface | Interface configuration items — negotiation mode, rate, isolation, rate limiting — are reasonable. |
| Port status | display interface brief | Port Up/Down status meets the planned requirement. |
| Port traffic statistics | display ip interface | Collect data twice, 5 minutes apart, then compare. Normally the second collection shows growth, with the base count no greater than 500. |
<HUAWEI> display interface brief
<HUAWEI> display interface GigabitEthernet0/0/1
<HUAWEI> display current-configuration interface GigabitEthernet0/0/1
<HUAWEI> display ip interface GigabitEthernet0/0/1
... wait 5 minutes ...
<HUAWEI> display ip interface GigabitEthernet0/0/1Checks whether the services actually running on the device are healthy — recommended weekly. The source manual covers many protocol-specific items; the representative ones below apply to almost any enterprise switch.
| Check Item | Check Method | Pass Standard |
|---|---|---|
| VLAN information | display vlan | Review the basic information of every VLAN on the device. |
| MAC address table | display mac-address | MAC address table information is correct. |
| Routing table | display ip routing-table | A default route or another precise route exists, to allow remote fault localization; devices at the same layer of the network that run a routing protocol should have consistent route counts. |
| DHCP Snooping binding table | display dhcp snooping user-bind all | Static entries and dynamic entries are both correct. |
| CPCAR traffic (anti-attack) | reset cpu-defend statistics all / display cpu-defend statistics all | CPCAR statistics show no packet-drop count — reset the counters, then check them again to confirm. |
| If configured — VRRP / MSTP / OSPF status | display vrrp / display stp / display ospf peer | The source manual also lists protocol-specific checks where these are running: VRRP state, MSTP root and designated ports, and OSPF neighbor state, among others — each with its own display command and pass standard. |
<HUAWEI> display vlan
<HUAWEI> display mac-address
<HUAWEI> display ip routing-table
<HUAWEI> display dhcp snooping user-bind all
<HUAWEI> reset cpu-defend statistics all
<HUAWEI> display cpu-defend statistics allEvery command in the five steps above is read-only — display or dir — but reading the result correctly is where things go wrong.
RISKThe port traffic-statistics check specifically calls for collecting data twice, 5 minutes apart, then comparing. A single display ip interface snapshot has no baseline to compare against, so “the counter looks high” or “looks low” is not actually a pass/fail judgment.
SAFER PRACTICEAlways run the command twice, exactly 5 minutes apart, and compare the delta against the base-count threshold of 500 the source manual specifies — not the raw number from a single check.
RISKThe source standard says CPU usage above 80% or “Memory Using Percentage” above 60% “needs attention” or “warrants close attention” — it does not say the check fails outright at those numbers. Treating them as a hard pass/fail line either causes false alarms on a switch that's simply busy, or gives false comfort at 79% on a device trending upward fast.
SAFER PRACTICETrack the trend across checks, not just the single reading — a CPU that's climbed from 40% to 75% over three weekly checks deserves more attention than a steady 78% that's been flat for months.
RISKThe basic-info check's debug-switch item exists precisely because debug output is easy to turn on during a troubleshooting session and easy to forget to turn off — and a forgotten debug switch keeps consuming CPU cycles indefinitely, showing up later as an unexplained CPU-usage climb in the running check.
SAFER PRACTICEMake display debugging part of the monthly basic-info check a habit, not an afterthought — and turn off anything left on from a previous diagnostic session immediately, whether or not it's your own.
RISKThe basic-info check's “configuration saved” item compares the running configuration against the saved configuration — a mismatch is easy to miss because the device behaves correctly right up until the next reboot, restart or switchover silently reverts it to whatever was last saved.
SAFER PRACTICERun compare configuration as a routine step right after any change, not just during the monthly check, and save immediately once the change is confirmed correct.
Every command in this five-step routine is read-only — it observes, it doesn't change anything.
display, dir and compare configuration don't touch the device's configuration or interrupt a single packet. Remediation is a different matter — a failed check might point you toward a command that does carry real risk, like a reboot to reload a corrupted board, or a delete to clear a full storage device. Before running any of those, it's worth checking our dangerous commands checklist — the same source documentation's list of which router and switch operations can interrupt business or destroy data, and the safer way to reach the same result.
Pulled straight from the field — the ones worth having an answer ready for.
The structure and standards here are taken specifically from chapter 4 of the Sx3-series switch maintenance manual. Other Huawei switch series and other vendors follow broadly similar five-category logic — environment, basic info, running status, ports, services — but the exact thresholds (like the 80% CPU and 60% memory figures) and command syntax should be checked against the manual for your specific model.
The source manual doesn't quote a total duration — it quotes a cycle per section instead (daily, weekly, monthly, and so on), because not every step runs every time. A daily pass covers only the daily items in steps 1 and 3 and takes a few minutes; the full five-step pass including the port traffic-statistics 5-minute wait is closer to 20–30 minutes on a typical enterprise switch.
Step 3, the running check — it's where board status, alarms, CPU, memory and temperature live, and it's the step most likely to reveal something already going wrong right now, rather than something that's merely out of policy.
Every command in this routine is a standard display, dir or compare configuration command — all of them work fine over Telnet or SSH, the same as Console. The only physical, on-site items are in step 1, the environment check (air conditioning, cabling, dust screens), which genuinely need a person in the equipment room.
That's a normal, valid outcome — the source manual's checklist format includes a “not applicable” option specifically for items that don't apply to a given device or deployment, such as the CF-card check on a box switch with no CF card slot. It's not a failure and doesn't need remediation, just a note explaining why.
This routine is built from chapter 4 of Huawei's Sx3-series switch maintenance manual. It covers the general environment, basic-info, running-status and port checks that apply to nearly any enterprise switch, plus a representative subset of the service check — the source manual's service-check section also includes protocol-specific items (OSPF, VRRP, MSTP, BGP, ISIS, multicast) that only apply if you're running that protocol, and those aren't reproduced item-by-item here. This is a health check, not a fault-diagnosis procedure — for that, see our fault information collection checklist once it's published.
Tell us your switch models and how many devices are in scope — we'll help you turn this into a recurring checklist with the right cycle for each step.