Huawei HCIA-Datacom common mistakes
Huawei HCIA-Datacom · Understand the traps and how to avoid them.
When asked which route ends up in the routing table, they assume the static route always wins over the OSPF route, and they describe a floating static route (higher preference) as the one that will be preferred.
Static routes feel 'manually configured, therefore trusted', so real-world intuition is applied instead of Huawei's numeric preference table, which candidates rarely memorise as numbers.
What to do instead
Memorise the preference table and apply 'smaller wins': Direct 0, OSPF 10, IS-IS 15, Static 60, RIP 100, OSPF external 150, BGP 255. A floating static is just a static route whose preference is raised above the IGP (e.g. 80) so it sits in the table but is not selected while the IGP route exists.
They assume any untagged frame arriving on a trunk port is dropped, cannot say what the PVID does to a frame, and claim a hybrid port can be a member of only one VLAN.
Access/trunk/hybrid are learned as slogans ('trunk carries many VLANs') without the actual per-frame tagging rule, so questions about native VLAN and PVID break the model.
What to do instead
Write out the ingress/egress flow for each port type: untagged ingress frame is tagged with the port PVID and forwarded only if that VLAN is allowed; tagged ingress frame is dropped unless its VLAN is in the allowed list; default PVID is VLAN 1. Hybrid ports may carry multiple VLANs, some tagged and some untagged.
They answer RSTP questions with 802.1D facts: five port states, Listening and Learning states, 30-second convergence, and no mention of alternate or backup port roles.
STP is studied first and the classic timer list gets memorised as 'the STP answer', then RSTP is skimmed as a faster version of the same thing.
What to do instead
Keep the contrast explicit: RSTP has three states (Discarding, Learning, Forwarding), four roles (Root, Designated, Alternate, Backup), no Listening state, and uses the Proposal/Agreement mechanism plus edge ports for fast convergence; edge ports should be paired with BPDU protection.
They write a wildcard mask by copying the subnet mask (e.g. 192.168.1.0 255.255.255.0 to match a /24) and apply a numbered basic ACL in the 3000 range expecting it to match destination TCP ports.
Huawei wildcard masks look like subnet masks, and the ACL number ranges (2000/3000/4000) are memorised as a list rather than attached to a matching capability.
What to do instead
Wildcard bit 0 means 'must match', 1 means 'don't care', so a /24 range is 0.0.0.255. Basic ACL 2000-2999 matches source only; advanced ACL 3000-3999 matches source/destination/protocol/port; L2 ACL 4000-4999 matches MAC fields. Remember rules are matched top-down, first match wins, so order changes the result and a trailing explicit rule may be needed.
When the requirement is 'let Internet users reach an internal web server', they configure Easy IP, and they never designate the interfaces as nat inside / nat outside.
All NAT variants are reduced to one idea ('translate private to public'), so source translation and destination translation are not separated, and the inside/outside designation is treated as cosmetic.
What to do instead
Map requirement to mechanism: many-to-one using the interface address = Easy IP; many-to-many from a range = NAT address pool with PAT; inbound access to an internal server = NAT Server (static public IP:port to private IP:port). Always add nat inside on the private side, nat outside on the public side, and confirm a return route exists.
They state that HDLC is the default encapsulation on Huawei serial interfaces, and they describe CHAP as a two-message exchange that sends the password across the link in clear text.
Cross-vendor habit (IOS defaults to HDLC, VRP defaults to PPP) plus PAP and CHAP being blurred together because both use a username/password pair.
What to do instead
Huawei serial interfaces default to PPP; HDLC must be set explicitly and is vendor-specific. PPP order is LCP, then PAP/CHAP authentication, then NCP (IPCP) for the network layer. PAP is two messages in plaintext; CHAP is a three-way challenge/response using an MD5 hash so the password never crosses the link.
They rank syslog severity 7 as the most severe, treat SNMP trap and inform as the same message type, and mix up which UDP ports carry requests versus notifications.
Severity names are memorised in text order rather than with their numbers, and trap versus inform differs only by acknowledgement, a detail that is easy to skip during revision.
What to do instead
Syslog: 0 emergency is the most severe and 7 debugging the least. SNMP agent listens on UDP 161, notifications are sent to UDP 162; a trap is unacknowledged while an inform must be acknowledged and is retransmitted. SNMPv2c is still community-based; SNMPv3 adds authentication and encryption.
They describe IPv6 as still using broadcast and ARP, label fe80:: as a globally routable prefix, and treat an address as usable immediately after configuration.
The IPv4 mental model is carried over, and the many IPv6 prefixes and ND message types look alike on paper.
What to do instead
IPv6 has no broadcast, and ARP is replaced by ND (NS/NA/RS/RA). fe80::/10 is link-local (auto-generated, one per interface, never routed); 2000::/3 is global unicast; ff00::/8 is multicast; FC00::/7 is unique local; ::/128 is unspecified and ::1 is loopback. Duplicate Address Detection must complete before an address becomes preferred, and one interface normally holds several IPv6 addresses.
They say the VXLAN VNI is 12 bits like a VLAN ID, and they treat the VTEP as the IP address of the virtual machine, so they cannot describe how an encapsulated frame is delivered.
VXLAN is learned as 'VLAN but bigger', and neither the 24-bit VNI nor the NVE/VTEP abstraction maps to any IPv4 concept already known.
What to do instead
The VNI is 24 bits (about 16 million segments) in the VXLAN header; the original Layer 2 frame is encapsulated in UDP with destination port 4789 between VTEPs, which are identified by the NVE interface address (typically a loopback). The underlay must route between VTEPs, and the control plane can be flood-and-learn or BGP EVPN.
They mix up the automation stack, saying NETCONF runs over SNMP, that RESTful APIs are stateful sessions, or that YANG is itself a protocol.
The acronyms arrive together as a list, and each is memorised as a name without being tied to its transport, data model or operation set.
What to do instead
Attach each name to its transport and role: NETCONF is XML-encoded RPC over SSH (port 830) using YANG data models with datastore operations such as get-config and edit-config; RESTful interfaces are stateless HTTP with verbs GET/PUT/POST/DELETE returning JSON or XML with HTTP status codes; Python is the scripting layer (e.g. requests, netmiko) that drives either of them.