HPE Aruba Switching Expert (Written, HPE7-A06) common mistakes
HPE Aruba Switching Expert (Written, HPE7-A06) · Understand the traps and how to avoid them.
Applying a dynamic LACP (LAG) configuration to a port and expecting it to pass traffic before the member ports are enabled and the aggregation is formed, then declaring the LAG broken when STP or forwarding state differs from a static trunk.
Candidates memorize that 'LACP is better than static trunks' but not the operational sequence: ports must be administratively enabled, LACP must negotiate the same key, and only then does the aggregator forward. Static trunks forward with fewer preconditions, so behavior diverges.
What to do instead
Trace the LACP state machine per member (collecting/distributing flags), confirm matching keys and modes on both ends, and verify the aggregator interface's STP/forwarding state rather than the physical member state.
Configuring an SVI or loopback for a routing protocol without confirming it is the intended source, then troubleshooting why adjacencies form on the wrong interface or why redistribution advertises unexpected networks.
Candidates focus on enabling the protocol globally and forget that source-interface selection and per-interface activation determine which adjacencies form and which networks are advertised.
What to do instead
Explicitly verify protocol activation per interface and the router-ID/source-interface, then check the resulting neighbor table and advertised routes before assuming a peering problem.
Assuming a MACsec or 802.1X-protected port behaves like an open port during testing, and skipping the client-supplied EAP method or supplicant config when a port stays unauthorized.
Candidates treat port security as a binary 'enabled/disabled' and overlook the authentication exchange, MKA session establishment for MACsec, and the required supplicant credentials.
What to do instead
Check the authenticator state machine (unauthorized/authenticating/authorized), confirm the EAP method and credentials match, and for MACsec verify the MKA session is up and the connectivity association key matches on both peers.
Building a role-based access policy and testing only with a client that matches the first rule, then being surprised when a different client falls to the default/captive role.
Role assignment is evaluated top-down and the default role catches unmatched clients; candidates test a single happy path and never verify rule ordering or the fallback.
What to do instead
Enumerate the client types that will hit the policy, test each to confirm the assigned role, and verify the default role and rule precedence explicitly rather than assuming the first match generalizes.
Treating a VLAN mismatch or native-VLAN inconsistency as a physical link failure and replacing cables or optics instead of checking tagging on both ends.
A link that is up/up with no traffic looks like a hardware problem; candidates skip the Layer 2 tag/native-VLAN check because the interface counters show the port is up.
What to do instead
Verify allowed VLAN lists, native VLAN, and tagging mode on both ends, and confirm the intended VLAN is actually carried across the trunk before escalating to hardware.
Diagnosing a PoE-powered device that will not boot by assuming the port is dead, without checking PoE class, power budget, and LLDP/negotiation.
Candidates conflate data connectivity with power delivery; a port can forward data while delivering insufficient or no power due to class, budget, or negotiation issues.
What to do instead
Check the port's PoE status, allocated class and wattage against the device requirement, and the switch's total power budget before replacing hardware.
Tuning QoS or storm-control without first establishing a baseline of the actual traffic profile, then attributing a performance change to the wrong cause.
Candidates jump to a configuration change to 'fix' performance and cannot distinguish the effect of the change from normal variation because no baseline existed.
What to do instead
Capture a baseline (throughput, latency, queue drops, broadcast rate) before and after each change, and change one variable at a time so the effect is attributable.
Assuming a link aggregation or uplink provides more throughput than it does, and blaming the switch when a single flow does not exceed one member's capacity.
Candidates treat a LAG as a single high-bandwidth pipe, but hashing places a single flow on one member, so per-flow throughput is bounded by one link.
What to do instead
Verify the hashing distribution across members and test with multiple flows; if per-flow throughput matters, address it at the flow/design level rather than expecting the LAG to aggregate a single flow.
Reading only the first error in a log or the first counter and stopping, rather than correlating interface counters, logs, and protocol state to find the root cause.
Candidates latch onto the most visible symptom and treat it as the cause; the actual root cause (e.g., a duplex mismatch causing CRC errors and STP churn) is upstream.
What to do instead
Correlate multiple sources: interface error counters (CRC, runts, giants), log timestamps, and protocol neighbor/STP state, and work backward from symptom to cause.
Designing or validating roaming without confirming the client's roaming behavior and the controller/cluster state, then attributing a roam failure to the AP.
Candidates focus on AP coverage and power but overlook client roaming decisions, controller clustering, and whether the client's security context follows it across the roam.
What to do instead
Verify controller/cluster membership and state, confirm the client's security and role context is preserved on the target AP, and test with the actual client type rather than assuming uniform roaming behavior.