Huawei HCIE-Datacom common mistakes
Huawei HCIE-Datacom · Understand the traps and how to avoid them.
In the lab exam, configuring BGP peerings and route reflectors before verifying underlay IGP reachability and loopback-to-loopback connectivity, then debugging adjacency flaps for an hour with no adjacency ever forming.
Candidates memorize BGP configuration syntax from written prep and jump straight to overlay protocols, forgetting that BGP sessions depend on IGP reachability to the update-source addresses; the failure looks like a BGP problem but is an underlay problem.
What to do instead
Before any BGP/MPLS configuration, run a checklist: all loopbacks pingable end-to-end, IGP adjacencies full, and update-source interfaces reachable. Build a habit of verifying each layer (physical, link, IGP, then BGP) before moving up, and re-verify the layer below whenever a new adjacency fails.
On OSPF multi-area questions, answering based on default behavior without checking whether the area is stub, totally stubby, NSSA, or totally NSSA, and mispredicting which LSAs appear in which area.
Candidates learn LSA types in isolation but do not internalize the LSA filtering matrix per area type; exam scenarios deliberately put a Type 7 or Type 5 LSA question in an NSSA context to test exactly this.
What to do instead
Build a one-page matrix of area types versus allowed LSAs (1,2,3,4,5,7) and which router originates each, then practice reading a topology and predicting the LSDB of each area before configuring. Verify with display ospf lsdb per area.
Treating MPLS L3VPN as a single configuration task: setting up VPN instances and MP-BGP without confirming LDP label distribution and the end-to-end label stack (inner VPN label plus outer transport label) on the data path.
Candidates can configure a VPN instance and see routes in the VRF table, so they assume the VPN works; they miss that a broken LDP session or PHP behavior means packets are dropped in the core even though control-plane routes look correct.
What to do instead
After configuring L3VPN, trace the label stack explicitly: check display mpls ldp lsp, display mpls lsp, and verify the inbound/outbound labels at each hop for the VPN prefix. Practice reading a label stack and mapping each label to its owner (VPN label from PE, transport label from LDP).
Configuring VXLAN/EVPN with the wrong VNI-to-bridge-domain mapping or forgetting to bind the NVE interface to the correct source address, then assuming the fabric is broken when only some VLANs fail to stretch.
Candidates conflate VNI, VLAN, and bridge domain as one concept and copy configuration without tracking which VNI maps to which BD and which VAP is bound to which VNI; a single mismatched VNI breaks one segment while others work, confusing diagnosis.
What to do instead
Maintain an explicit mapping table (VLAN to BD to VNI to VAP) while configuring, and verify each layer separately: display bridge-domain, display vxlan vni, and display evpn routing-table. Test per-VLAN connectivity rather than assuming fabric-wide success.
On QoS questions, quoting a queuing or scheduling mechanism without identifying the actual congestion point and direction (ingress versus egress, WAN versus LAN) where the policy must be applied.
Candidates memorize PHB names and queue types but skip the step of locating where congestion occurs; QoS applied on the wrong interface or direction has no effect, and exam scenarios are built around this directional reasoning.
What to do instead
For every QoS scenario, first draw the traffic path and mark the congestion point and direction, then choose the mechanism (classification, marking, queuing, shaping, policing) for that point. Practice mapping DiffServ markings to per-hop behavior at each hop before writing configuration.
Answering network automation questions with Python or Ansible code that would run but does not match the platform's actual data model, YANG path, or NETCONF/RESTCONF operation semantics.
Candidates with scripting experience assume generic API patterns apply, but Huawei automation questions test specific YANG models, NETCONF edit-config operations (merge, replace, delete), and RESTCONF HTTP method semantics that differ from intuition.
What to do instead
Study the specific YANG modules and operation semantics used in the exam, and practice reading a YANG tree to derive the correct XML/JSON payload by hand. Verify each edit-config operation type against its actual effect before assuming merge behavior.
On IPv6 migration questions, configuring dual stack or transition mechanisms without verifying that the routing protocol actually carries IPv6 (for example, assuming OSPFv2 carries IPv6 or forgetting to enable the address family).
Candidates carry IPv4 assumptions into IPv6 scenarios; OSPFv2 does not route IPv6, IS-IS needs the IPv6 topology enabled, and BGP needs the IPv6 address family activated, so the control plane silently does not advertise IPv6 prefixes.
What to do instead
For every IPv6 scenario, explicitly confirm which protocol instance and address family carries the prefixes, then verify with display ipv6 routing-table and the protocol-specific IPv6 neighbor table. Practice the OSPFv3 versus OSPFv2 distinction and IS-IS multi-topology configuration until automatic.
In the lab exam, spending the full time on one complex task (for example, a full MPLS VPN or EVPN fabric) and leaving several simpler, higher-value tasks unconfigured and unverified.
Candidates fixate on the hardest task to prove competence and lose track of time; the lab scoring rewards broad correctness, so an unfinished hard task plus several untouched easy tasks scores worse than completing everything at a basic level.
What to do instead
Before starting, scan all tasks and triage by points-per-minute; do quick, verifiable tasks first, then return to hard ones with remaining time. Reserve the final 20 to 30 minutes for end-to-end verification and saving configuration, not new configuration.
Diagnosing a routing problem by reading only the routing table, without checking the FIB, ARP/neighbor entries, and interface counters to find where the actual forwarding path breaks.
Candidates treat the routing table as ground truth, but a prefix can be present in the RIB while the FIB lacks it (for example, due to recursion failure or next-hop unreachable), or the next-hop MAC may be unresolvable; the routing table looks correct while packets drop.
What to do instead
Adopt a layered troubleshooting order: interface state and counters, ARP/ND, FIB, then RIB, then control-plane adjacencies. Practice using display fib, display arp, and interface statistics together to localize a break before changing configuration.
Answering security and traffic-policy questions by listing ACL or policy-based routing configuration without checking rule order, implicit deny, and whether the traffic matches the intended direction.
Candidates focus on writing rules rather than on evaluation order and direction; an earlier broad permit or a default deny silently overrides the intended rule, and traffic-policy applied inbound versus outbound changes which packets are matched.
What to do instead
Before writing rules, state the intended match order and direction explicitly, then verify with counters (display acl, display traffic-policy statistics) that the intended rule is being hit. Practice predicting which rule matches a given packet by walking the list top-down.