15.1 Validating the Solution
Key Takeaways
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, andshow 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-centraland the device's status in Central confirm cloud management, andcheckpoint diffor Central's configuration audit confirms the intended configuration is the running one.
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 vsfandshow vsf topology: all members present, Ring topology where designed, status "No Split", and the split-detection method you configured.show vsx statusandshow vsx brief: ISL up and in sync, keepalive established, correct primary and secondary roles.show active-gatewayon both VSX peers: the same virtual IP and virtual MAC for each SVI.
3. Layer 2
show vlanandshow 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 interfacesandshow lag <id>: every planned member is bundled and forwarding on both ends.show spanning-treeandshow 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 interfaceandshow 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).pingandtraceroutewithsourceandvrfoptions to test return paths, for exampleping 10.1.100.50 source vlan10.
5. Network Services
- DHCP relay:
show ip helper-addresslists the helpers per SVI, andshow dhcp-relayshows valid requests and responses increasing. - DHCP snooping:
show dhcp-snooping bindingshows bindings for connected clients; uplinks are trusted. - DNS:
show ip dnslists the configured servers; name resolution works from the switch. - Time:
show ntp statusshows the switch synchronized, which matters for logs, certificates, and cloud management.
6. Access Control
show radius-server: servers configured and reachable.show port-access clientsandshow 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 diffor 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.
After an implementation, an engineer wants to confirm that each planned OSPF adjacency on a CX 8360 core switch is fully established. Which command provides this?
show lldp neighbor-info
show vsx status
show ip ospf neighbors
show ip route summary
During validation of a new VSF stack, which result confirms the stack is formed as designed with resilient cabling and split detection?
show vsf reports Topology: Chain, Status: No Split, and Split Detection Method: None
show vsf reports Topology: Ring, Status: No Split, and Split Detection Method: mgmt
show lacp interfaces shows every VSF member port in the Detached state
show spanning-tree shows the VSF links as Alternate ports on every member
Which test best validates that a new voice SSID meets the user requirement, beyond device-level checks?
Confirming the voice VLAN exists on the core switch and on the AP uplink trunk
Making a call on a handset while walking between APs to confirm it survives
Confirming the AP's uplink port is up at 2.5 Gbps with PoE class 4 power
Confirming that the gateway cluster appears as connected in Central
Sections you finish are checked off in the contents.