Huawei

Huawei's VRP operating system (used across most Huawei switches and routers) has its own distinct command style - system-view instead of Cisco's configure terminal, and snmp-agent instead of snmp-server as the command prefix. If you're coming from Cisco or Arista, expect the concepts to be familiar but almost none of the actual keywords to match.

Entering configuration mode

<HUAWEI> system-view
[HUAWEI] snmp-agent

The bare snmp-agent command itself enables the SNMP agent - VRP doesn't turn SNMP on implicitly just because you've configured a community, unlike IOS.

SNMPv1/v2c (communities)

VRP requires you to explicitly declare which protocol versions are active before communities of that version will work:

[HUAWEI] snmp-agent sys-info version v2c
[HUAWEI] snmp-agent community read comaccess acl 2001
[HUAWEI] snmp-agent community write mgr acl 2001

Unlike Cisco's optional ACL restriction, an ACL argument is a standard, expected part of the Huawei community command - acl 2001 above ties the community to a numbered basic ACL defining which source addresses may use it:

[HUAWEI] acl 2001
[HUAWEI-acl-basic-2001] rule permit source 10.0.0.0 0.0.0.255
[HUAWEI-acl-basic-2001] quit

SNMPv3

[HUAWEI] snmp-agent sys-info version v3
[HUAWEI] snmp-agent group v3 MYGROUP privacy
[HUAWEI] snmp-agent usm-user v3 MYUSER MYGROUP
[HUAWEI] snmp-agent usm-user v3 MYUSER authentication-mode sha MYAUTHPASS
[HUAWEI] snmp-agent usm-user v3 MYUSER privacy-mode aes128 MYPRIVPASS

privacy on the group (matching Cisco's priv) requires both authentication and encryption; the user is created, associated with the group, and then has its authentication and privacy credentials set as separate follow-up commands rather than all in one line.

Sending traps

[HUAWEI] snmp-agent trap enable
[HUAWEI] snmp-agent target-host trap address udp-domain 192.168.1.100 params securityname comaccess v2c

snmp-agent trap enable must be run before any traps are sent at all, regardless of what's configured below it - a commonly missed step when traps don't seem to be arriving despite an apparently-correct target-host line.

Model/platform differences

This snmp-agent-based syntax is shared across VRP-based platforms - the Huawei enterprise switch and router lines (S-series, AR-series) and the CloudEngine data-center switch line both use it, though CloudEngine (VRP8-based) organizes some of the more advanced SNMPv3 target-host options slightly differently from the classic VRP5 command set used on older S-series hardware. For a specific platform and firmware version, checking that model's own command reference before assuming full parity is worth the extra step given how much the SNMP command set has grown across VRP releases.

Common OIDs and MIBs

Huawei's own MIBs live under enterprises.2011 (1.3.6.1.4.1.2011) - but as with several other vendors on this list, CPU and memory monitoring specifically has more than one generation of MIB behind it. See the gotcha below before picking one.

• CPU and memory (current, entity-indexed) - HUAWEI-ENTITY-EXTENT-MIB (1.3.6.1.4.1.2011.5.25.31). hwEntityCpuUsage and hwEntityMemUsage report utilization per physical component, indexed the same way as the standard ENTITY-MIB's entPhysicalIndex - meaning you generally walk ENTITY-MIB::entPhysicalTable first to identify which component is which (a specific board, a specific card), then use that same index into this MIB to get its CPU and memory figures.
• CPU (older, standalone) - HUAWEI-CPU-MIB (1.3.6.1.4.1.2011.6.3). hwCpuDevDuty reports CPU load as a simple 0-100 percentage in its own table, independent of the entity-indexing approach above. Still present and populated on many devices even where the newer entity-based MIB is also available.
• Fan status - hwFanStatusTable (part of HUAWEI-ENTITY-EXTENT-MIB, 1.3.6.1.4.1.2011.5.25.31.1.1.10). Reports per-fan status alongside the entity-indexed CPU/memory data in the same overall MIB.

Gotchas and platform-specific nuances

CPU and memory monitoring has two separate, independently-populated MIBs, and they aren't always in sync with each other. HUAWEI-CPU-MIB's hwCpuDevDuty is the older, simpler path - one flat table, no dependency on entity indexing. HUAWEI-ENTITY-EXTENT-MIB's hwEntityCpuUsage is the newer, more granular path, giving per-component figures on devices with multiple boards or slots, but it requires first resolving the correct entPhysicalIndex from the standard ENTITY-MIB to know which row actually corresponds to which physical component - there's no way to guess the right index without that lookup first. A monitoring integration built years ago against the older, simpler MIB may still work today, but won't give you the finer per-component breakdown the newer one supports - and a template built against the newer one won't work at all against a device or firmware version that only populates the older table. Checking which of the two a specific device actually populates - rather than assuming based on what worked on a different Huawei model - is worth doing before committing to one.

The ACL requirement on communities is mandatory, not optional - already covered above, but worth restating as a specific gotcha for anyone copying Cisco-style habits: a community configured without a valid, existing ACL reference will fail to apply, where the equivalent Cisco command would happily accept a community with no source restriction at all. The ACL itself has to exist as its own configuration object before the community command referencing it will succeed - configuring them in the wrong order is a common first-time mistake.