H3C vs Huawei CLI: Command Comparison for Network Engineers

H3C and Huawei switches share a common ancestor, so their command-line interfaces look almost identical - but the subtle differences trip up engineers who manage both fleets. This article lines up the two CLIs side by side: system view navigation, VLAN creation, port security, MAC address lookups and verification commands, with Cisco and Ruijie included as reference points for cross-platform fluency.

The reason the two CLIs are so close is historical. Both descend from the same engineering lineage — H3C was originally a joint venture and the Comware operating system and Huawei's VRP grew from a shared base of design decisions. The result is a pair of interfaces where ninety percent of what you type is character-for-character identical, and the remaining ten percent is exactly the kind of detail that causes an outage. An engineer who knows one platform cold will be productive on the other within an hour, then spend the next month discovering the edge cases. This article collects those edge cases in one place, with the exact prompt strings and keywords that differ.

Who This Comparison Is For

If you manage a mixed estate — a campus running H3C in the access layer and Huawei in the distribution, or a service provider with legacy Comware gear alongside newer VRP kit — the operational risk is not ignorance of either platform. It is confidence. You type a command from muscle memory, it is accepted by the parser, and it does something subtly different from what you intended. Standardising the two CLIs side by side in a runbook, the way this article does, is the cheapest way to remove that risk. The Cisco and Ruijie columns are included because most teams have at least one of those in the mix, and because seeing three prompts together makes the shared grammar obvious.

The View Hierarchy Model

Both H3C and Huawei use a two-level view model that differs from Cisco's three-state model. In Cisco IOS you move from user exec (>) to privileged exec (#) to global configuration ((config)#), and one of the classic mistakes is forgetting that show commands behave differently in the first two states. In Comware and VRP there is no separate privileged-exec state: you are either in user view (angle brackets) or in system view and its sub-views (square brackets). Read-only commands work from user view; anything that changes configuration requires system view.

Recognising which view you are in is as simple as looking at the prompt character: <Huawei> is user view, [Huawei] is system view, and [Huawei-GigabitEthernet0/0/1] is an interface sub-view nested inside it. The nesting is real: to reach an interface you enter system view first, then the interface, and quit unwinds one level at a time. This is why the prompt visibly grows as you descend.

System View Navigation

Both platforms use the user view / system view model, unlike Cisco's enable / configure terminal:

<Huawei> system-view
[Huawei] quit

<H3C> system-view
[H3C] quit

A subtlety worth remembering: quit steps back one level, while return jumps all the way back to user view from any depth. Engineers coming from Cisco expect exit and end; on Comware and VRP the equivalent pair is quit and return. Typing exit still works on both platforms as an alias for quit, which is helpful but also dangerous, because it does not guarantee you have left the hierarchy — it only takes you up one rung.

VLAN Configuration Side by Side

! Huawei VRP
<Huawei> system-view
[Huawei] vlan 10
[Huawei-vlan10] description Marketing
[Huawei-vlan10] quit

! H3C Comware
<H3C> system-view
[H3C] vlan 10
[H3C-vlan10] description Marketing
[H3C-vlan10] quit

! Cisco IOS (reference)
Router> enable
Router# configure terminal
Router(config)# vlan 10
Router(config-vlan)# name Marketing

Key insight: H3C's CLI mirrors Huawei's almost one-to-one for VLAN, interface and display commands - the prompts differ only in the bracket content.

The one difference that matters in this block is description versus name. Huawei and H3C both call the VLAN label a description; Cisco calls it a name. Teams that keep runbooks for both platforms frequently mix them up, and the failure mode is quiet — on a Cisco device description Marketing inside a VLAN context is not a VLAN label at all. The other difference is that in VRP and Comware the sub-view for a VLAN is named after the VLAN ID ([Huawei-vlan10]), so the prompt itself tells you which VLAN you are configuring, whereas Cisco's (config-vlan)# does not.

Bulk creation is another place the two diverge from Cisco. Both Huawei and H3C accept a range in one command:

[Huawei] vlan batch 10 20 30
[H3C] vlan 10 to 20

Huawei's vlan batch takes a space-separated list or a range, and H3C's vlan 10 to 20 creates a contiguous block. Both are faster than the Cisco habit of one vlan command per ID, and both are idempotent — re-running them does nothing to VLANs that already exist.

Interface and Trunk Configuration

The port-mode vocabulary is shared almost perfectly between the two vendors and is different from Cisco's in naming rather than in concept. An access port is an access port everywhere; a trunk is a trunk, but the way you permit VLANs differs.

! Huawei
[Huawei] interface GigabitEthernet0/0/24
[Huawei-GigabitEthernet0/0/24] port link-type trunk
[Huawei-GigabitEthernet0/0/24] port trunk allow-pass vlan 10 20

! H3C
[H3C] interface GigabitEthernet1/0/24
[H3C-GigabitEthernet1/0/24] port link-type trunk
[H3C-GigabitEthernet1/0/24] port trunk permit vlan 10 20

Read those two blocks carefully: Huawei says allow-pass, H3C says permit. That single word is the most common typo when an engineer moves between the platforms, and both parsers will reject the wrong keyword outright, so at least the failure is loud. Note also the interface naming convention: Huawei uses GigabitEthernet0/0/1 (stack/slot/port) while H3C commonly uses GigabitEthernet1/0/1 because H3C counts the chassis as slot 1 in some families. Always confirm the interface name with display interface brief before typing a configuration line by hand.

Port Security Commands

! Huawei: limit MACs and block on violation
[Huawei] interface GigabitEthernet0/0/1
[Huawei-GigabitEthernet0/0/1] port-security enable
[Huawei-GigabitEthernet0/0/1] port-security max-mac-num 2
[Huawei-GigabitEthernet0/0/1] port-security protect-action shutdown

! H3C: same goal, different keywords
[H3C] interface GigabitEthernet1/0/1
[H3C-GigabitEthernet1/0/1] port-security max-mac-count 2
[H3C-GigabitEthernet1/0/1] port-security intrusion-mode blockmac

Note the vocabulary differences: max-mac-num vs max-mac-count, protect-action vs intrusion-mode.

There is a deeper difference hidden in that pair of snippets. On Huawei, port security is a feature you explicitly enable with port-security enable; on H3C the same family of commands is available without that explicit enable step in many Comware releases, so the presence or absence of the enable line is a real behavioural difference, not just a cosmetic one. The violation actions also differ in vocabulary and in set: Huawei offers protect, restrict and shutdown actions via protect-action, while H3C exposes a richer intrusion-mode with values such as blockmac, shutdown and disableport. Pick the action deliberately — a mismatched violation policy is invisible until the first rogue device appears on the port.

Link Aggregation and Spanning Tree

Link aggregation follows the same pattern of near-identical grammar with a renamed keyword. On both platforms the construct is an Eth-Trunk / Bridge-Aggregation, and the two operating modes are static and LACP:

! Huawei Eth-Trunk with LACP
[Huawei] interface Eth-Trunk 1
[Huawei-Eth-Trunk1] mode lacp-static
[Huawei-Eth-Trunk1] quit
[Huawei] interface GigabitEthernet0/0/1
[Huawei-GigabitEthernet0/0/1] eth-trunk 1

! H3C Bridge-Aggregation
[H3C] interface Bridge-Aggregation 1
[H3C-Bridge-Aggregation1] link-aggregation mode dynamic
[H3C-Bridge-Aggregation1] quit
[H3C] interface GigabitEthernet1/0/1
[H3C-GigabitEthernet1/0/1] port link-aggregation group 1

Huawei names the aggregate interface Eth-Trunk and adds members with eth-trunk; H3C names it Bridge-Aggregation and adds members with port link-aggregation group. The static-versus-dynamic mode flag is mode lacp-static on Huawei and link-aggregation mode dynamic on H3C — the words "static" and "dynamic" describe the same LACP behaviour from two different angles, which is a genuinely confusing bit of naming to keep straight. For spanning tree, both use MSTP by default and expose it through stp commands, but verify the region configuration on each platform before assuming a mixed-vendor topology will converge as designed.

MAC Address Lookup

<Huawei> display mac-address
<H3C> display mac-address
Router# show mac-address-table

This is the happiest case in the whole comparison: the command is identical on both platforms and returns the same three-column table of MAC, VLAN and port. The practical habit is to filter by VLAN when hunting a single host, since a busy access switch can hold tens of thousands of entries:

<Huawei> display mac-address vlan 10
<H3C> display mac-address vlan 10

Cisco users should note that the IOS command is show mac address-table on modern platforms — the hyphens in mac-address-table are an older Catalyst convention that some releases no longer accept. That small detail catches out engineers who learned on 3750s and now work on newer gear.

Saving the Configuration

Neither vendor writes running configuration to startup automatically, which is the single most expensive shared habit to forget. A change that is not saved disappears on the next reload.

<Huawei> save
<H3C> save force

On Huawei, save prompts for a confirmation and, on some releases, a filename. On H3C, save force skips the interactive confirmation, which makes it the correct choice for scripts and automation. A safe pattern for engineers working interactively is to save after verifying the change is correct, not before — saving a broken configuration is worse than losing an unsaved one, because now the broken state survives a reload.

Common Verification Commands

! interface status
display interface brief          (Huawei / H3C)
show ip interface brief          (Cisco)

! configuration
display current-configuration    (Huawei / H3C)
show running-config              (Cisco)

! ping (all platforms)
ping <IP>

The display versus show prefix is the one convention that is consistent within each vendor and reliable across the entire command set: H3C and Huawei use display, Cisco and most other vendors use show. Once you internalise that single rule, the rest of the verification vocabulary transfers without much friction.

<Huawei> display current-configuration interface GigabitEthernet0/0/1
<H3C> display current-configuration interface GigabitEthernet1/0/1

Both also support display this from inside a sub-view to print only the configuration under the current context, which is far faster than dumping the entire running configuration and scrolling. This is the closest analogue to Cisco's show running-config interface ... and it is a habit worth adopting on both platforms.

Key Differences and Migration Tips

• Huawei uses VRP, H3C uses Comware - both derived from the same heritage, so syntax migration is mostly renaming.
• Watch command-name drift: port-security max-mac-num vs max-mac-count; display vs show prefixes are consistent within each vendor.
• For teams that manage both, standardize on one naming convention in documentation and runbooks to avoid cross-vendor mistakes.
• Remember the save step on both: Huawei save, H3C save force, and never assume a reboot will preserve an unsaved change.
• Interface names differ by chassis numbering and, on H3C, sometimes by slot counting — always confirm with display interface brief before hand-editing.

For a broader command-mapping reference, see the H3C Comware vs Huawei VRP command mapping table and the Huawei, H3C and Cisco command equivalents guide. Related articles: H3C vs Huawei switches: Comware vs VRP, 华为静态路由配置详解, and Port mirroring on Cisco, Huawei and Arista.

原文链接：https://telecomate.com/cross-platform-network-mastery-unifying-switch-configurations-for-huawei-h3c-ruijie-and-cisco