Use this switching operations review checklist to distinguish what you can explain, what evidence you can interpret and what decision follows from it. For each item, describe the expected behavior before consulting notes, identify a relevant observation and state what that observation cannot prove. If any part is missing, revisit the matching lesson and obtain fresh evidence before marking the item complete. A familiar command or a successful ping alone is insufficient.

Complete the learning and bounded exercises organized by HPE6-A86: Building a Skills-Based Switching Learning Roadmap first. This is a recall and evidence check, not a new configuration tutorial or a scored readiness test. Operational references use AOS-CX 10.13 on CX 6300; that teaching baseline is not an identified exam release. Use authorized isolated labs and retain recovery access for any repeated change.

Use Three Checks for Each Item

Apply three verbs: explain the relationship, show appropriate evidence, and decide the next safe action. Record the topology, platform/release, source, destination and relevant context beside the evidence. Label predicted results and untested skills honestly. These checks support technical review; completing them does not predict an exam result or establish coverage of every public objective.

Trace Forwarding and Addressing

  •  Explain the roles of physical media, Ethernet forwarding and transport. Show a packet-path sketch that separates Media Access Control (MAC) addresses from Internet Protocol version 4 (IPv4) addresses. Decide which layer's evidence is relevant to the symptom.
  • Calculate a host's subnet and decide whether its destination is local or remote. Identify the gateway and Address Resolution Protocol (ARP) target for the next hop; do not substitute a remote server's MAC address for the local gateway mapping.
  • Identify the virtual local area network (VLAN), access/native/allowed membership and learned forwarding path at each attachment. Explain why a VLAN boundary is neither an IP subnet definition nor a complete security policy.
  • Use Link Layer Discovery Protocol (LLDP) neighbor evidence to identify a peer and port, then check forwarding separately. Neighbor discovery does not prove that the intended VLAN reaches the far endpoint.

Distinguish Resilience Mechanisms

  •  Explain how Spanning Tree Protocol (STP) prevents Layer 2 loops. Distinguish Rapid Spanning Tree Protocol (RSTP) from Multiple Spanning Tree Protocol (MSTP), including region agreement and VLAN-to-instance mapping. Identify an expected alternate path before treating a blocked port as a fault.
  • For Link Aggregation Control Protocol (LACP), identify the logical link aggregation group (LAG), intended partner and eligible forwarding members. Distinguish active/passive negotiation from passive/passive and from static aggregation. Explain why one flow does not establish summed member bandwidth.
  • For Virtual Switching Framework (VSF), identify the logical switch, conductor, standby and stack paths. Explain ring versus chain failure boundaries and split detection. Keep Virtual Switching Extension (VSX) distinct, and check exact model, link and image constraints before proposing changes.
  • Interpret a controlled failure record: healthy state, one failed component, surviving path, interruption and restored redundancy. Decide whether both service and resilience returned; a link light alone cannot close recovery.

Separate Routing Stages

  •  Distinguish a connected subnet, a local interface address, an explicit static route and a default route. Show the selected destination route and reachable next hop in the intended virtual routing and forwarding (VRF) context, then check the return decision.
  • Explain why host gateways and active switched virtual interfaces (SVIs) matter for inter-VLAN traffic. Compare host-originated acceptance with a switch-originated probe whose source may have different return-route requirements.
  • For Open Shortest Path First (OSPF), separate neighbor state, link-state database, protocol routes, main-table selection and host service. Identify which stage lacks evidence rather than equating a Full neighbor with working end-to-end traffic.

Separate Security and Congestion Decisions

  •  Distinguish administrator authentication, authorization and accounting (AAA) from endpoint admission using 802.1X or MAC authentication. Show which identity and authority each controls; preserve an independent administrative recovery path.
  • Identify the scope and direction of an access control list (ACL), ordered access control entries (ACEs) and implicit denial. Explain why a control-plane restriction and a transit filter affect different exchanges. Include permitted and denied test expectations where applicable.
  • Trace quality of service (QoS) from classification and marking through trust, local priority, queue mapping and scheduling. Explain why trusting an endpoint's marking needs justification and why queue priority creates no extra link capacity.
  • Distinguish weighted scheduling from strict priority and its starvation risk. Check platform-specific queue behavior before interpreting a counter or proposing a policy; do not assume universal queue counts.

Review Management and Operational Evidence

  •  Justify the management tool by task, authority, scale and reachability. Distinguish local access from Aruba Central's documented management model, and verify exact software compatibility before relying on a tool combination.
  • Compare Trivial File Transfer Protocol (TFTP), File Transfer Protocol (FTP), Secure Shell (SSH) File Transfer Protocol (SFTP) and Telnet by purpose and protection. Recognizing a legacy method does not justify using it for secrets; prefer supported secure transfers and SSH administration.
  • Distinguish common community-based Simple Network Management Protocol version 2c (SNMPv2c) from authenticated/encrypted monitoring options. Verify the supported listener context and collector receipt rather than assuming a universal default or treating every SNMP variant as equally protected.
  • Compare timestamped counter changes, events, polling and bounded active tests. Explain what each establishes. Preserve evidence before clearing state; a timeout does not identify the failed device or exclude a return-path problem.
  • Separate running configuration, startup configuration, checkpoints, off-device backups and software images. Show a change record with compatibility, acceptance, deadline and recovery criteria. A configuration checkpoint is not a software rollback guarantee.

Turn an Incomplete Check into a Specific Repair

Return to the lesson matching the missing relationship. Use HPE6-A86: IPv4 Subnetting, ARP and the Next-Hop Decision for next-hop reasoning; HPE6-A86: Troubleshooting Switched and Routed Connectivity for evidence interpretation; or HPE6-A86: Maintaining Configurations and Planning Software Changes for recovery distinctions. Select other component lessons through the prerequisite roadmap when needed.

Repeat a small changed example, retain its actual evidence and explain the observation's limit. Then revisit the failed checklist item. Keep unresolved equipment or support questions open rather than inventing results. The useful outcome is a clear account of what you can explain and demonstrate, with a specific next action for each remaining gap.

Authoritative Sources