Huawei S5720-LI: How to generate a compliance / drift report
By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30
| Vendor | Huawei |
|---|---|
| Operating system | VRP (Versatile Routing Platform) |
| Category | Deployment Automation |
| Skill level | Intermediate to advanced |
| DIY-able? | Yes with CLI access; some scenarios need Huawei TAC + RMA. |
Automation pipelines targeting Huawei share a common shape: render desired config, validate against VRP (Versatile Routing Platform) syntax, stage, push, verify, persist. The S5720-LI platform follows that shape too, it is the credential and authorization story that varies.
Persisting changes via save is the step engineers forget when they are used to vendors that auto-commit. On VRP (Versatile Routing Platform) you get one chance per reload to make changes survive; miss it and your pipeline silently produces ephemeral state.
The walkthrough below is exactly what I run against customer fleets. minus the credential bits, which belong in your secret manager.
What this guide covers
How to generate a compliance / drift report for Huawei S5720-LI (VRP (Versatile Routing Platform)).
Step-by-step
- Choose the automation surface: vendor controller, API, or CLI scripting.
- Verify reachability + credentials from your automation host.
- Test the change on a single device + maintenance window.
- Roll out in waves of 10-20 devices to limit blast radius.
- Pre-collect baseline, push the change, post-collect; diff.
- Roll back any device whose post-check fails.
Sample CLI invocation
# Manual baseline
display version
display device
display interface brief
# Push change (via vendor CLI)
system-view
interface GigabitEthernet0/0/1
ip address 10.0.0.1 255.255.255.0
undo shutdown
save
# Verify
display interface brief
Best practices
- Always test on a single device or sandbox before fleet rollout.
- Keep configurations in version control (Git).
- Use AAA + RBAC for the automation account; never embed credentials in code.
- Build pre/post-change validation into your pipeline.
Frequently asked questions
Will this work on my specific VRP (Versatile Routing Platform) version?
The procedure reflects current VRP (Versatile Routing Platform) behaviour. Older releases may need minor syntax adjustments, use the CLI help (? or tab-completion) to verify.
Should I open a Huawei TAC case immediately?
Open one if you suspect hardware failure or the symptom persists after a maintenance-window reload. Make sure your support entitlement is active first.
Where can I find the Huawei official documentation?
https://support.huawei.com/enterprise/en/knowledge-base.html: search the product family + feature name.
Is this procedure safe in production?
Test in a lab or maintenance window first. Capture pre-change state so you can roll back.
Related guides
Related fixes
Related guides worth a look while you sort this one out:
- Huawei S5731: How to generate a compliance / drift report
- Huawei S5732: How to generate a compliance / drift report
- Huawei S5720-LI all ports dead: Diagnose & Fix
- Huawei S5720-LI: How to back up configs nightly to a Git repo
- Huawei S5720-LI: How to deploy with a Python script (paramiko / netmiko / native API)
- Huawei S5720-LI: How to deploy with Ansible
References
- Huawei support portal: https://support.huawei.com/enterprise/en/index.html
- Huawei knowledge base: https://support.huawei.com/enterprise/en/knowledge-base.html
- Huawei security advisories: https://www.huawei.com/en/psirt/security-advisories
- Open a case: https://support.huawei.com/enterprise/en/case-management.html
Reference material, not professional advice. Validate against your specific VRP (Versatile Routing Platform) version and test in a non-production environment before applying.
What changed recently?
Fault diagnosis on a Huawei device goes faster when you map the symptom to a recent change:
- Did firmware update in the last 7 days?
- Did the network (router, ISP, VPN) change?
- Was the device moved physically?
- Did paired devices (phone, hub, app) update?
- Were any accessories swapped in or out?
The answer narrows the root cause to a manageable subset.
Safety + preconditions
Before any work on a Huawei device:
- Unplug from mains for any internal-access procedure.
- Discharge stored energy (capacitors in PSUs, residual battery charge) per manufacturer guidance.
- Use ESD-safe handling for boards and modules, no carpet, no wool sleeves.
- Avoid moisture; never apply liquids near vents or connectors.
- If you smell smoke, see scorch marks, or feel uneven heat, stop and escalate.
How to confirm it's actually fixed
On a Huawei device, the test is rarely "reboot and see". Use this list:
- Active reproduction: trigger the original failure path on purpose.
- Indirect reproduction: do an activity that would expose the same subsystem.
- Status indicator review: every LED / display / app status should be green.
- 24-hour soak: leave the device under normal load overnight; check the next morning.
- Telemetry check: review the device or app's diagnostic log for new error entries.
When to call Huawei support instead
Escalate if:
- The same symptom returns within 24 hours of a clean fix.
- You see physical damage (burn marks, swollen battery, cracked PCB).
- The device is in warranty and a hardware replacement is the cheaper outcome.
- Repair requires specialised tools you don't own (alignment jigs, calibration software).
- Following the official path keeps the warranty intact, which matters more than the time spent.
More frequently asked questions
Will this void my warranty?
Applying official firmware updates and following the user manual will not affect warranty. Opening sealed components, jumping safety circuits, or using third-party parts can void warranty in most jurisdictions.
What if my model isn't exactly the same revision?
Cross-check the model code on the rating plate against the manufacturer support page. Major firmware generations sometimes shift the menu path; the option is usually under a similarly-named section.
What if the fix returns after a reboot?
Persistent fault returns mean either: a hardware fault (escalate), a configuration that's being overwritten by a sync source (check cloud profiles), or a regression in a recent firmware update (rollback).
Can I roll this back if something breaks?
Yes for software-level changes (firmware rollback, config rollback). Hardware changes are usually one-way. Always back up settings before starting.
Are there safer alternatives for non-technical users?
Yes. the manufacturer's self-service troubleshooter (HP Smart, LG ThinQ, Samsung Members, similar) usually walks through the same steps in a guided UI. Use that first if you're not comfortable with menu paths.
Topology deep dive: where the S5720-LI sits in the network
My typical Huawei S5720-LI series access switch deployment in the BSNL state-data-centre floor runs forty-eight 1GE access ports per switch, stacked five high using iStack on 10G SFP+ uplinks. The stack faces a pair of S12700E core chassis upstream via 2x10G LACP, and downstream the access ports trunk voice (Airtel SIP), data (Reliance Jio backhaul), and PoE+ for surveillance. iStack master is locked to the bottom unit because the top of the rack moves more often during cabling churn, and you do not want a master re-election every time someone reseats an SFP+.
The Layer 2 / lite-L3 access switch (24 or 48 GE + 4 SFP+) role matters because the failure-impact blast radius scales with it. A floor-closet outage on a S5720-LI is annoying. A core-aggregation outage on the same S5720-LI family takes down a BFSI trading desk for the minutes it takes to RMA. I price the spare accordingly: cold spare for access, hot spare on a maintenance contract for core.
Cabling note that bites people: VRP labels physical ports as 10GE1/0/1 on a fixed switch and 10GE2/0/0/1 on a chassis (slot/sub-slot/card/port). When you copy a config between platforms, the interface namespace breaks silently. I keep a `sed` script in my git repo that translates between the two forms for exactly this reason.
Configuration walkthrough on VRP
For a fleet of S5720-LI units across three sites, I drive config from a Git repo with a CI runner that uses Netmiko's huawei_vrp driver. The key configuration choices on the device are:
system-view
stelnet server enable
ssh user automation authentication-type password
ssh user automation service-type stelnet
ssh user automation assign vrf management
aaa
local-user automation password irreversible-cipher [hash]
local-user automation privilege level 15
local-user automation service-type ssh
#
snmp-agent sys-info version v3
snmp-agent group v3 ro-secure privacy
snmp-agent usm-user v3 nmsro group ro-secure authentication-mode sha [hash] privacy-mode aes128 [hash]
quit
On the runner side, every push is a three-step pipeline: render with Jinja2, dry-run with display this, then commit with save. I never push directly to the running config; the diff goes through a `git diff --stat` review first. For the BFSI fleet, the runner refuses to touch a device if the last config-commit hash on the switch does not match the Git HEAD, which catches out-of-band changes some weekend admin made through the console.
Troubleshooting commands by platform layer
The shortest path from symptom to root cause on a S5720-LI is to start at the highest layer that still reports clean and walk down. I keep this command bundle in a saved tmux paste-buffer:
display version
display device
display device pic-status
display environment
display fan
display power
display memory-usage
display cpu-usage
display logbuffer | include WARN|ERR|FAULT
display alarm active
display diagnostic-information
The Huawei error format I look for is %%01IFNET/4/IF_STATE, %%01DEVM/2/BOARD_REMOVE, or the dreaded %%01SYSTEM/1/HARDWAREFAULT. Those numeric prefixes are stable across VRP V200 releases; my Splunk parser keys off them.
For port-layer faults specifically, the trio that almost always tells the story is:
display interface brief
display interface 10GE1/0/24
display transceiver interface 10GE1/0/24 verbose
display port vlan
display elabel slot 1
The display elabel output gives you the line card's BOM number, serial, and Huawei-side manufacture date. That is the field the TAC engineer always asks for on a hardware case, so capture it before you have to call.
For chassis or stack issues, layer in display stack, display stack peers, display mad detail, and display switching-frame-utilization. The MAD (Multi-Active Detection) output tells you whether a stack split has happened or is at risk.
India compliance and deployment notes
If your Huawei S5720-LI series access switch sits in an Indian regulated environment, three rule-sets apply regardless of vendor:
- MeitY procurement guidance: Huawei kit is permitted for non-strategic enterprise use but excluded from some Trusted Telecom Portal categories. Check whether your circuit is classified under the trusted-source list before procurement, especially for BSNL/MTNL backbone roles.
- DPDP Act 2026 alignment: Logs from S5720-LI units carrying user-attributable IPs (PoE phones, BYOD laptops) count as personal data under the DPDP definition. Push to a central SIEM that has data-localisation guarantees; do not stream telemetry to a Huawei eSight tenant hosted outside India unless the data-residency clause is in the BoQ.
- TEC certification: The SKUs commonly bid on GeM carry TEC GR numbers (TEC/GR/IT/SWP-016/06 for L2/L3 switches). Match the GR number against the device's elabel when you receive shipment; mismatched grey-market units have shown up in tier-2 city tenders.
Pricing reality from my last three procurements: list price on the Huawei Enterprise India catalogue ran 35-45 percent higher than the closing tender price; expect tender discounting around INR 78,000-1.45 lakh per unit on GeM tender (24-port vs 48-port, PoE+ vs non-PoE). CarePack AMC: budget INR 9,500 / year for 8x5xNBD; INR 17,200 / year for 24x7x4-hour. Spares retention rule of thumb for BFSI: one cold MPU per ten chassis, one hot fan tray per rack.
For STQC labs, RBI-regulated banks, and SEBI-supervised stock exchanges (NSE colo at BKC, BSE colo at PJ Towers), the deployment must also satisfy the cyber-resilience framework: change-control logged in an immutable store, vulnerability bulletins tracked against the Huawei PSIRT feed, and quarterly recovery drills documented. The S5720-LI integrates with Huawei iMaster NCE for those, but most BFSI teams I work with run Solarwinds or a home-grown Ansible-driven setup because procurement of iMaster carries its own approval cycle.
A real-world deployment I ran
At a BSNL state-data-centre user floor in Pune and a Reliance Jio NOC stack in Navi Mumbai, I wired up the Ansible run against thirty-eight S5720-LI switches in three days. The Python venv ran ansible-core 2.16 with the `community.network` collection. Inventory came from a Bengaluru-hosted NetBox behind Cloudflare, and the runner sat in the same colo so SSH RTT stayed under 6ms. First production change rolled a small VLAN-name standardisation across the fleet, 38 commits in 4 minutes 12 seconds, zero failures. The only gotcha: Huawei's VTY has a habit of dropping idle sessions before the connection-cleanup runs, and Ansible's default keepalive is too lazy. Setting connection_options.ssh_keepalive=30 in the host_vars file fixed it.
Two patterns I extracted from that incident and now bake into every S5720-LI runbook: (1) every reload, controlled or panic, gets a logbuffer dump pushed to FTP before the reload runs, because the post-reload buffer rolls fast; (2) every TAC case opens with the elabel, the version, the patch list, and the last 200 lines of logbuffer attached, because the TAC engineer's first three questions are always the same. Saving them up front cuts the case time roughly in half.
Extended FAQs from real S5720-LI cases
Does VRP V200R023 break compatibility with V200R021 configurations?
No, the config grammar is forward-compatible within the V200 family. The migration scripts in Huawei's release notes call out a handful of deprecated knobs (legacy STP timers, old IS-IS authentication modes); review those before the cutover but a clean V200R021 config will parse on V200R023 without rewriting.
How long does the S5720-LI hold logs in the buffer before they roll?
Default logbuffer size is 1024 entries on the S5720-LI, which in a noisy access-layer environment can roll in under an hour. Bump it: info-center logbuffer size 4096. Always feed an external rsyslog regardless of buffer size; the buffer is a peek-window, not a system of record.
Can I run the S5720-LI without a Huawei CarePack contract?
Yes, but you lose access to firmware downloads, PSIRT advisory notifications, and TAC. For lab and non-revenue gear that is fine. For BFSI or telco production, the cost of CarePack is negligible against a single SLA breach.
What is the right SNMP / Telemetry mix for S5720-LI in 2026?
SNMPv3 for slow-changing inventory (boards present, serials, uptime). gRPC dial-out telemetry for fast counters (interface stats every 10 seconds, CPU and memory every 30). Run both; the SNMP feed is the inventory truth, the telemetry feed is the operational truth.
Will Huawei eSight or iMaster NCE work in an air-gapped Indian government network?
Yes. both ship as on-prem installable products. Procurement requires a separate license and the install footprint is non-trivial (multi-VM, separate Oracle or MySQL). For most enterprise users, a leaner stack of Grafana + InfluxDB + a Telegraf instance speaking gNMI to the S5720-LI solves the same monitoring requirement at a fraction of the licence cost.