ExamFinch.com My Study

Study guide

14.4 Preparing for Implementation

Practice this exam

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

14.4 Preparing for Implementation

Key Takeaways Explain This Topic AI

Implementation readiness covers the platform (GreenLake inventory, Central assignment, subscriptions, groups or scopes), services (DHCP, DNS, NTP, RADIUS, firewall), physical readiness, and configuration artifacts.

A method of procedure (MOP) lists ordered steps, pre-checks, success criteria, and a rollback plan for each change window.

On AOS-CX, copy running-config <url> cli vrf mgmt backs up the current configuration and checkpoint auto <minutes> provides an automatic rollback if the change is not confirmed.

The target firmware should be chosen from the release notes and staged ahead of time, including the upgrade method for VSF stacks and VSX pairs.

Pre-deployment checks confirm that devices can reach Activate and Central over outbound HTTPS with correct time, and that RADIUS servers already list the new devices as clients.

Last updated: October 2026

14.4 Preparing for Implementation

Quick Summary: The last Plan objective is to prepare for implementation . The goal is simple: when the change window opens, nothing should be missing. Devices are already in the cloud inventory with subscriptions, DHCP and NTP are ready, ClearPass knows the new switches, cables are tested and labeled, configurations and firmware are staged, and a method of procedure (MOP) spells out every step, every check, and how to back out.

  • Readiness Checklist
  • 1. Cloud Platform (Central-managed deployments)

HPE GreenLake workspace: devices added by serial number and MAC address (or through the order), assigned to the Central service, and given a subscription (manually or by auto-subscribe).

Central structure: devices pre-assigned to the correct Classic Central group and site, or to the correct new Central site and device group, so they receive the right configuration on first contact (Sections 7.1 and 11.1).

Firmware compliance: the target firmware set for the group, so devices upgrade during onboarding instead of later.

Templates and variables: template groups loaded with variable files from the LLD.

2. Network Services

DHCP: scopes for every new VLAN, helper addresses on the gateways, and, if AOS-CX ZTP without the cloud is used, the right option 43 sub-options or options 66/67 (Section 11.2).

DNS: resolution for Activate and Central names from the management network.

NTP: reachable time sources; TLS certificate checks fail with a wrong clock.

Firewall: outbound HTTPS (TCP 443) from management networks; any rules between user, IoT, and server networks that the design requires.

AAA: the new switches and gateways added as RADIUS clients in ClearPass with matching shared secrets, the roles that ClearPass will return already defined, and dynamic authorization (CoA) allowed.

3. Physical Readiness

Racks, power circuits, UPS capacity, and cooling verified against the new load (including PoE).

Horizontal cabling and fiber tested and labeled to match the port map.

Optics, DACs, power supplies, and mounting kits on site, with spares.

Console access and an out-of-band management connection available for every stack.

4. Configuration Artifacts

Configurations or templates peer-reviewed against the LLD.

A plan for the native VLAN, trunk allowed lists, and uplink LAG membership confirmed on both ends.

For brownfield sites, the current configuration backed up before any change.

5. Firmware

Target AOS-CX and AOS 10 versions chosen from the release notes, which list supported upgrade paths, known issues, and feature changes.

Images downloaded and checked, or firmware compliance set in Central.

The upgrade method chosen for each platform: standard reboot, VSF ISSU on CX 6300 stacks for minor-release upgrades, VSX sequential upgrades ( vsx update-software ), or Central Live Upgrade for AOS 10 APs and gateway clusters (Section 15.2).

Writing the Method of Procedure (MOP)

A MOP is the script for the change window. A useful MOP has:

  • MOP part Content
  • Scope and impact Devices affected, expected user impact, and the maintenance window
  • Roles Who executes, who verifies, who approves rollback, and who to call

Pre-checks Current state captured: show interface brief , show lldp neighbor-info , show vsf or show vsx status , show ip route , client counts in Central

  • Steps Numbered, one action per step, with the exact commands or Central actions
  • Verification Expected results after each major step (link up, LAG formed, OSPF Full, clients connected)
  • Success criteria What must be true to close the change
  • Rollback Trigger conditions, exact rollback steps, and how long rollback takes
  • AOS-CX Tools That Protect a Change

Back up the configuration switch# copy running-config sftp://netops@10.1.100.20/fl2-stack-before.cfg cli vrf mgmt

The configuration can be copied to SFTP or TFTP in CLI or JSON format (AOS-CX 10.14 Fundamentals Guide).

  • Create a named checkpoint switch# copy running-config checkpoint before-change-1042
  • switch# show checkpoint

AOS-CX stores up to 32 user checkpoints, and it also creates system checkpoints automatically (prefix CPC ) after configuration changes settle for 300 seconds by default.

  • Use an automatic rollback timer for risky remote changes switch# checkpoint auto 15
  • switch# configure

...make the change...

switch# checkpoint auto confirm

If you do not confirm within the interval (1 to 60 minutes), the switch restores the configuration it had when auto mode started. This protects you when a change cuts off your own remote access.

Know how to roll back switch# checkpoint rollback before-change-1042

checkpoint diff before-change-1042 running-config shows exactly what changed.

Staging Versus Zero-Touch

Zero-touch provisioning (ZTP): devices ship directly to site; correct cloud inventory, subscriptions, group or site assignment, and network services make them configure themselves. Ideal for many identical sites.

Staging: devices are configured or upgraded in a lab first. Useful when the site cannot provide internet access during installation or when complex changes need testing.

Pre-Implementation Tests

Several assumptions can be tested before the window opens:

Cloud reachability: from a device or test host on the management network, confirm DNS resolution of the cloud names, outbound HTTPS, and NTP synchronization. On an existing AOS-CX switch, ping and traceroute with vrf mgmt test the management path.

RADIUS: authenticate a test device against ClearPass from a lab switch that uses the production server group and shared secret; confirm the expected role is returned.

DHCP: confirm that each new scope is active and that the relay addresses in the LLD match the server.

Configuration syntax: load templates on a lab switch of the same model and firmware to catch typing and syntax errors early.

Go / No-Go Criteria

Agree in advance on what must be true to start the change (for example: all hardware on site, cloud and RADIUS tests passed, backups taken, approvers available) and what will trigger a rollback during the window (for example: uplinks not restored within 20 minutes, or authentication failing for test clients). Writing these down prevents pressure-driven decisions in the middle of the night.

Communication

Tell affected users when the window is, what they may notice, and whom to contact. Afterwards, report the outcome, including anything that still needs attention.

Common Exam Traps

Forgetting subscriptions. A device in the GreenLake inventory without a subscription is not ready for Central management.

No rollback plan. Every MOP needs one; AOS-CX checkpoints make it concrete.

Choosing firmware without the release notes. The supported upgrade path and the VSF or VSX upgrade method come from the release notes.