Study guide
15.1 Validating the Solution
HPE Aruba Networking Certified Associate - Campus Access HPE6-A85
Track your progress as you read
Finished sections get a check mark.
1 Introduction: HPE6-A85 Exam Overview
HPE6-A85 Exam Facts and Current Blueprint
2 Chapter 1: Network Stack Fundamentals
1.1 OSI Reference Model and Encapsulation 1.2 TCP/IP Protocol Suite and IP Headers 1.3 Layer 2 Operation, ARP, and 802.1Q Tagging
3 Chapter 2: Physical Connectivity and Host Addressing
2.1 Ethernet Media and Transceiver Standards 2.2 Power over Ethernet (PoE, PoE+, PoE++) Standards and Budgeting 2.3 LLDP, LLDP-MED, and Voice VLAN Configuration 2.4 Host IP Addressing and DHCP Relay Operations
4 Chapter 3: Network Resiliency and Virtualization
3.1 Virtual Switching Framework (VSF) Architecture and Topologies 3.2 VSF Split Detection, Failover, and Auto-Stacking 3.3 Virtual Switching Extension (VSX) Architecture and Operations 3.4 High-Availability Gateways: VRRP and VSX Active-Gateway
5 Chapter 4: AOS-CX Architecture and Switch Operation
4.1 AOS-CX Hardware Portfolio and State Database Architecture 4.2 Network Analytics Engine (NAE) and Automated Telemetry 4.3 AOS-CX Interface Configuration and Port Control 4.4 Link Aggregation (LAG) and LACP Configuration
6 Chapter 5: Layer 2 Protocols and Spanning Tree
5.1 AOS-CX VLAN Configuration and Native VLAN Handling 5.2 Spanning Tree Protocols: STP, RSTP, and MSTP 5.3 Spanning Tree Protections and Loop Prevention 5.4 MAC Address Table Learning, Aging, and Forwarding
7 Chapter 6: Wireless Fundamentals, Standards, and RF
6.1 IEEE 802.11 Standards and Wi-Fi Generations 6.2 RF Fundamentals, Signal Propagation, and Channel Design 6.3 Aruba Access Point Hardware Portfolio and Suffix Conventions 6.4 WLAN Topologies, BSSID/ESSID, and Roaming Standards
8 Chapter 7: Aruba Wireless Architecture and Management
7.1 AOS 10 Architecture and Aruba Central Integration 7.2 Wireless Forwarding Modes: Bridge vs Tunnel Mode 7.3 Automated RF and Client Optimization: AirMatch and ClientMatch 7.4 Secure Wireless Access: WPA3, SAE, and MPSK Implementation
9 Chapter 8: IP Routing Fundamentals and OSPF
8.1 IP Routing Principles and Packet Forwarding 8.2 OSPFv2 Protocol Mechanics and Adjacency Formation 8.3 OSPF Designated Routers and Multi-Area Deployments 8.4 ECMP, Static Routing, and VRF Isolation
10 Chapter 9: Campus Network Security and Segmentation
9.1 DHCP Snooping and Dynamic ARP Inspection 9.2 Port Security and MAC Address Limiting 9.3 ClearPass Policy Management and RADIUS Change of Authorization 9.4 Dynamic Segmentation, User-Based Tunneling, and Policy Enforcement
11 Chapter 10: Authentication, Authorization, and Accounting
10.1 The AAA Framework and Architecture 10.2 802.1X Authentication and EAP Methods 10.3 MAC Authentication and Captive Portal Onboarding 10.4 Administrative Access Control: RADIUS vs TACACS+
12 Chapter 11: Network Management and Telemetry
11.1 Aruba Central Cloud Architecture and Group Configuration 11.2 Zero-Touch Provisioning (ZTP) and Aruba Activate 11.3 AI Insights and Aruba User Experience Insight (UXI) 11.4 Network Telemetry, Streaming APIs, and SNMP/Syslog
13 Chapter 12: Troubleshooting the Solution
12.1 Structured Troubleshooting Methodologies and Scope Isolation 12.2 AOS-CX Layer 2 and Interface Diagnostic Commands 12.3 Layer 3, IP Services, and End-to-End Diagnostics 12.4 Physical-Layer Troubleshooting 12.5 Troubleshooting Wireless Clients and Network Access
14 Chapter 13: Optimizing Performance: QoS, Baselines, and Comparisons
13.1 Quality of Service (QoS) Classification and Marking 13.2 Queuing Algorithms and Congestion Management 13.3 Traffic Policing, Shaping, and Broadcast Rate Limiting 13.4 Establishing a Performance Baseline 13.5 Comparing Results to the Baseline
15 Chapter 14: Plan the Solution
14.1 Analyzing the Current Environment 14.2 Interpreting an Architect's High-Level Design 14.3 Creating a Low-Level Design 14.4 Preparing for Implementation
16 Chapter 15: Validate and Operate the Solution
15.1 Validating the Solution 15.2 Performing Firmware Updates 15.3 Making Basic Ongoing Configuration Changes 15.4 Maintaining Network Documentation
15.1 Validating the Solution
Key Takeaways Explain This Topic AI
Validation proves that the deployed network matches the low-level design and works for users; it is checked layer by layer, not assumed because commands were accepted.
Core AOS-CX validation commands include show interface brief , show lldp neighbor-info , show vsf , show vsx status , show lacp interfaces , show spanning-tree , show ip ospf neighbors , and show active-gateway .
Service checks confirm DHCP relay ( show ip helper-address , show dhcp-relay ), snooping bindings, DNS, NTP ( show ntp status ), and RADIUS reachability ( show radius-server ).
Wireless validation tests the real client journey: association, authentication, IP address, DNS, applications, and roaming, ideally with planned failover tests in the change window.
show aruba-central and the device's status in Central confirm cloud management, and checkpoint diff or Central's configuration audit confirms the intended configuration is the running one.
Last updated: October 2026
15.1 Validating the Solution
Quick Summary: A switch accepting a command does not mean the network works. Validation compares the deployed network against the low-level design and against what users need, layer by layer: physical links and power, stacking and redundancy, Layer 2, Layer 3, network services, access control, wireless, and management. The results become the acceptance record and the first baseline for operations.
Validation Principles
Validate against the LLD. Every port map entry, VLAN, LAG, and protocol setting in the LLD should be checked.
Work bottom-up. A Layer 3 test that fails because a cable is in the wrong port wastes time; confirm the physical layer first.
Test the user experience, not just the devices. A green device dashboard does not prove that a phone can register or a laptop can roam.
Record evidence. Save command output and test results with timestamps; they become the acceptance record and the starting baseline.
- Layer-by-Layer Checklist
- 1. Physical Layer and Power
Check AOS-CX command Expected result
Ports up at the planned speed show interface brief Uplinks and AP ports up at the planned speed (for example 2.5G for multi-gigabit APs)
Right neighbor on each port show lldp neighbor-info Neighbors match the port map
Optical health show interface dom or show interface <port> transceiver detail Receive power inside the thresholds
- PoE delivery show power-over-ethernet Expected devices powered; budget headroom remains
- Hardware health show environment Fans, power supplies, and temperature normal
- 2. Stacking and Redundancy
show vsf and show vsf topology : all members present, Ring topology where designed, status "No Split", and the split-detection method you configured.
show vsx status and show vsx brief : ISL up and in sync, keepalive established, correct primary and secondary roles.
show active-gateway on both VSX peers: the same virtual IP and virtual MAC for each SVI.
3. Layer 2
show vlan and show vlan port <port> : VLANs exist and ports carry the right tagged and untagged VLANs. Remember that on AOS-CX the native VLAN must also be in the allowed list.
show lacp interfaces and show lag <id> : every planned member is bundled and forwarding on both ends.
show spanning-tree and show spanning-tree mst-config : the intended root bridge, consistent region settings, and no unexpected blocked ports; edge ports set as admin-edge.
show mac-address-table : clients learned on the expected ports and VLANs.
4. Layer 3
show ip interface and show ip route : interfaces up with the correct addresses and the expected routes present, including the default route.
show ip ospf neighbors : every planned adjacency in Full state (or 2-Way between DROthers on broadcast segments).
ping and traceroute with source and vrf options to test return paths, for example ping 10.1.100.50 source vlan10 .
5. Network Services
DHCP relay: show ip helper-address lists the helpers per SVI, and show dhcp-relay shows valid requests and responses increasing.
DHCP snooping: show dhcp-snooping binding shows bindings for connected clients; uplinks are trusted.
DNS: show ip dns lists the configured servers; name resolution works from the switch.
Time: show ntp status shows the switch synchronized, which matters for logs, certificates, and cloud management.
6. Access Control
show radius-server : servers configured and reachable.
show port-access clients and show port-access clients detail : test devices authenticated with the expected method (802.1X or MAC-Auth) and role.
show radius dyn-authorization : CoA counters increase when ClearPass changes a role, proving dynamic authorization works.
7. Wireless
Test with real clients of each important type:
The SSID is visible in the intended bands.
The client associates and authenticates (WPA3-Enterprise, MPSK, or captive portal, as designed).
The client receives an address from the intended VLAN or gateway cluster.
DNS and key applications work, including a voice call if voice is in scope.
The client roams between APs without dropping a call (fast roaming with 802.11r where configured).
Central shows the client with the expected role, VLAN, and band; UXI sensors, if deployed, pass their tests.
8. Management
show aruba-central : the switch is connected to Central.
Central shows the device online, in the right group or scope, compliant with the target firmware, and with its configuration in sync.
checkpoint diff or Central's configuration audit confirms that the running configuration is the intended one.
Failover Tests
Redundancy that has never been tested is a hope, not a design. In an approved window, test the events the design is supposed to survive:
- Test Expected result
- Unplug one member link of an uplink LAG Traffic continues on the remaining member; LAG stays up
- Reboot the VSF Standby member Conductor keeps running; the Standby rejoins
- Fail one VSX peer or its uplinks VSX-LAG traffic shifts to the surviving peer; active-gateway keeps answering
Make a RADIUS server unreachable in a lab or test port New clients receive the critical role if one is designed
Power-cycle an AP Clients roam to neighbors; the AP returns with the same configuration
Record how long each recovery took; these numbers are useful later when someone asks whether a failure "should have" caused an outage.
Acceptance Record
Close the implementation with:
- the completed checklist with pass or fail for each item,
- command output and screenshots as evidence,
- any deviations from the LLD and who approved them, and
open issues with owners.
The same measurements become the first baseline for operations and optimization (Section 13.4).
Common Exam Traps
Validating only the device you changed. A trunk change must be checked on both ends, and a VLAN change must be checked all the way to its gateway.
Ignoring the native VLAN rule. A native VLAN missing from the allowed list passes no untagged traffic on AOS-CX.
Skipping user tests. "OSPF is Full" does not prove that DHCP works for a new VLAN.