H3C Comware vs Huawei VRP Command Mapping Table

H3C Comware and Huawei VRP share an ancestry, so their CLIs look nearly identical - which is exactly why moving between them is dangerous. The command skeletons match while the verbs and keywords diverge, and the mistakes are the kind that change a production trunk: port default vlan versus port access vlan, save force versus save, and link aggregation built with completely different object names. This article is a mapping table for the daily tasks, plus the traps that are not obvious from the command reference.

Views and Navigation

The first three columns are identical, which is precisely how the false confidence starts. Both platforms share the view hierarchy (user view → system view → interface/protocol view), both use undo to negate a command, and both accept abbreviated commands and ? completion. Assume nothing beyond that.

Interface Naming: The Trap That Breaks Every Script

Interface names look interchangeable and are not. The same physical port on the front panel can be GigabitEthernet0/0/1 on one platform and GigabitEthernet1/0/1 on the other, and in a stack the first number changes meaning entirely.

Consequence for automation: a template using GigabitEthernet0/0/{port} renders valid-looking config on both platforms, applies on one, and errors on the other. Enumerate interfaces first (display interface brief on both) and generate the numbering from the device rather than from an assumption.

VLANs and Ports

! Huawei VRP
[HUAWEI] vlan batch 10 20
[HUAWEI] interface GigabitEthernet0/0/1
[HUAWEI-GigabitEthernet0/0/1] port link-type access
[HUAWEI-GigabitEthernet0/0/1] port default vlan 10
[HUAWEI-GigabitEthernet0/0/1] port link-type trunk
[HUAWEI-GigabitEthernet0/0/1] port trunk allow-pass vlan 10 20

! H3C Comware
[H3C] vlan batch 10 20
[H3C] interface GigabitEthernet1/0/1
[H3C-GigabitEthernet1/0/1] port link-type access
[H3C-GigabitEthernet1/0/1] port access vlan 10
[H3C-GigabitEthernet1/0/1] port link-type trunk
[H3C-GigabitEthernet1/0/1] port trunk permit vlan 10 20

Three traps hide in those six lines: the access VLAN verb (default vs access), the trunk verb (allow-pass vs permit), and interface numbering conventions that depend on the chassis and slot layout. A script that copies trunks between platforms will produce syntax that is accepted on one and not the other - always validate in a lab or with a dry run before a bulk change.

Hybrid Ports: VRP and Comware Agree

The hybrid port type is where the two platforms converge almost exactly, which makes it the safest way to move tagged/untagged logic between them:

Note the word order: VRP puts the tag state before vlan, Comware puts it after. Both are valid on their own platform and rejected by the other, and because the keywords are the same set, a copy-paste error here produces a port that silently loses a VLAN rather than an outright syntax error. The PVID command is the exception - it is identical on both, which is one of the few places you can copy blindly.

VLAN Interfaces and Layer 3

Comware accepts the prefix-length form (/24) far more consistently than VRP, but both accept dotted decimal, so write templates with the dotted mask if you want one string to work everywhere. The logical interface type name is the other gotcha: Vlanif and Vlan-interface are not interchangeable, and neither is case-insensitive on all releases.

Link Aggregation

This is the single largest source of confusion in mixed-brand networks: "Eth-Trunk" and "Bridge-Aggregation" are the same idea, but the member-add syntax lives in different places (inside the physical interface on both - the trick is that on Huawei the logical interface exists first). Note also that the member-add command runs on the physical port on both platforms while the mode command (lacp-static vs dynamic) runs on the logical interface - mixing those two up is the classic reason a newly built LAG comes up in "unselected" state. If you are coming from a Huawei background, our detailed 华为交换机 Eth-Trunk 链路聚合配置 covers the static and LACP modes in depth.

Static Routing and Route Tables

The masking syntax is the practical difference: Comware's "0" shorthand for 0.0.0.0 does not exist in VRP, and a template that emits 0 0 will fail on Huawei. Also verify the metric/preference keyword defaults - both platforms use preference (administrative distance) rather than metric for static route preference, but the default values differ between product families even within the same vendor.

Spanning Tree: Same Words, Different Defaults

MSTP is the area where the two platforms are closest - the region commands are word-for-word the same, which is a rare luxury. The differences are in the small print: the global enable command exists only on Comware (stp global enable), and edge port uses enable on VRP and a bare keyword on Comware. Because region configuration must match exactly across every device in the region (name, revision level, and VLAN-to-instance mapping), a single mismatched word places a switch in its own region and it will happily keep forwarding without participating in the intended topology.

Port Security and DHCP Snooping

Two vocabulary splits to memorise: max-mac-num versus max-mac-count, and protect-action versus intrusion-mode. The violation semantics also differ - VRP's protect-action values (protect, restrict, shutdown) do not map one-to-one onto Comware's intrusion-mode values (blockmac, disableport, disableport-temporarily), so a hardening template ported between platforms can silently downgrade from "disable the port" to "drop the offending MAC". Confirm the behaviour you actually get, not the behaviour the keyword suggests.

ACLs: traffic-filter vs packet-filter

The rule syntax inside the ACL is almost identical, but the ACL creation and the interface application differ on both ends: num/name versus basic/advanced, and traffic-filter versus packet-filter. The application keyword is the one that hurts in production: pasting a Huawei filter onto an H3C port is rejected outright, but pasting an H3C filter direction in the wrong order on a Comware port can silently override an existing filter, because Comware allows one filter rule per direction per port.

Management Access, SSH and Local Users

# Huawei VRP
[HUAWEI] aaa
[HUAWEI-aaa] local-user netops password irreversible-cipher <secret>
[HUAWEI-aaa] local-user netops privilege level 15
[HUAWEI-aaa] local-user netops service-type ssh terminal
[HUAWEI] stelnet server enable
[HUAWEI] user-interface vty 0 4
[HUAWEI-ui-vty0-4] authentication-mode aaa
[HUAWEI-ui-vty0-4] protocol inbound ssh

# H3C Comware 7
[H3C] local-user netops class manage
[H3C-luser-manage-netops] password simple <secret>
[H3C-luser-manage-netops] authorization-attribute user-role network-admin
[H3C-luser-manage-netops] service-type ssh terminal
[H3C] ssh server enable
[H3C] line vty 0 63
[H3C-line-vty0-63] authentication-mode scheme
[H3C-line-vty0-63] protocol inbound ssh

Four separate differences in one task: the AAA container (VRP nests users under aaa, Comware defines them directly in system view with a class), the role model (privilege level versus authorization-attribute user-role), the line naming (user-interface vty 0 4 versus line vty 0 63), and the authentication mode keyword (aaa versus scheme). Getting the role wrong on Comware is the difference between a usable account and one that logs in to a permission-denied prompt, and the failure gives you no hint about which keyword was missing.

Stacking: iStack vs IRF

These are genuinely different object models, not synonyms: Huawei binds physical ports into a logical stack-port, H3C binds them into an IRF port and then requires the irf-port-configuration active step before the change takes effect. On H3C you must shut the physical ports before adding them to an IRF port, and the activation command is what triggers the merge - skip it and the member reboots into a standalone device with a config it cannot use.

Verification Command Pairs

display interface brief                 ! both
display vlan                           ! both
display mac-address                    ! both
display ip routing-table               ! both
display current-configuration | include vlan   ! both support pipe filtering

The display verb and the pipe filter (| include, | exclude, | begin, | no-more) exist on both platforms with the same semantics, so verification scripts are the part of your toolkit that ports most cleanly. The extended filter keywords are where they part company - type <display-command> | ? on the live device to see exactly which filters that release accepts rather than assuming the other vendor's list.

Saving, Rebooting and Startup Files

The save behaviour is the classic cross-platform mistake. On VRP, save prompts for confirmation and then for a filename - engineers who habitually type save force get an error and often conclude the save failed when nothing was attempted. On Comware, save alone prompts interactively and save force skips the prompts; in a scripted session, the interactive form will hang waiting for input. If you are scripting either platform, H3C Comware 命令行基础:视图、undo 与保存 walks through the view model and the save semantics in detail.

Migration Tips

1. Save before you experiment: Huawei prompts for confirmation on save, H3C users usually type save force to skip the filename prompt - knowing the difference avoids "I saved and nothing happened".
2. Do not assume reset behaviour: both support reset saved-configuration, but the reboot confirmation prompts and what survives differ by release.
3. Port-security vocabulary differs too (max-mac-num vs max-mac-count, protect-action vs intrusion-mode) - check the platform's own command reference before pasting a hardening template.
4. Keep a per-brand template repository instead of one "universal" config, and test template changes against both versions in the lab.

Migration Checklist: Porting a Config Between Platforms

1. Enumerate interfaces on the target with display interface brief and rewrite every interface name from that output. Never trust the numbering in the source config.
2. Translate verbs, not sentences. Work through a fixed list - access VLAN, trunk permit, hybrid tag state, aggregate member add, ACL application - because those are the keywords that differ while everything around them looks the same.
3. Check the defaults you did not write. STP mode, MST region revision, port-security violation action and static-route preference all have platform defaults that may differ from the config you are migrating from.
4. Save and reboot deliberately. Use the form of save that matches the platform and confirm with display startup that the running config is the startup config before you walk away.
5. Diff, then verify in the operational plane. A byte-identical config is not the goal - run display vlan, display mac-address and a ping matrix after cutover to confirm the data plane agrees with the control plane.

Related reading: H3C vs Huawei CLI command comparison, Huawei CE switch display troubleshooting and Huawei, H3C and Cisco command equivalents.

原文链接：Telecomate: unifying switch configurations for Huawei, H3C, Ruijie and Cisco