ExamFinch.com My Study

Study guide

15.3 Making Basic Ongoing Configuration Changes

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

15.3 Making Basic Ongoing Configuration Changes

Key Takeaways Explain This Topic AI

Routine changes (adding a VLAN, moving a port, adding an SSID, changing a role) follow a small change process: request, impact check, backup, implement, verify, and document.

AOS-CX checkpoints protect changes: up to 32 user checkpoints, system checkpoints (prefix CPC) created automatically after changes settle, checkpoint diff to compare, and checkpoint rollback to revert.

Running configuration changes take effect immediately on AOS-CX but must be saved with write memory (or copied to startup-config) to survive a reboot.

When a device is managed by Central, make changes in Central (group, template, or scope); local CLI edits can be overwritten or show up as configuration mismatches.

A new VLAN is an end-to-end change: VLAN on access, trunk allowed lists, SVI or active-gateway, DHCP helper and scope, snooping, and the matching role or SSID.

Last updated: October 2026

15.3 Making Basic Ongoing Configuration Changes

Quick Summary: After go-live, the network keeps changing: a new department needs a VLAN, a printer moves, an SSID is added, or a role must change. HPE6-A85 expects an associate to make these basic ongoing configuration changes safely: understand the impact, protect the change with a backup or checkpoint, apply it in the right place (CLI, VSX primary, or Central), verify it, save it, and document it.

A Lightweight Change Process

Request and scope: what exactly must change, and why.

Impact check: which devices, users, and services are affected; does it need a maintenance window?

Protect: back up the configuration or create a checkpoint; use checkpoint auto for risky remote work.

Implement: apply the change in the correct place.

Verify: confirm the intended effect and check for side effects (Section 15.1 checks for the affected layer).

Save and document: make the change persistent and update the documentation (Section 15.4).

Running Versus Startup Configuration

On AOS-CX, configuration commands change the running configuration immediately. To keep them after a reboot, save them: switch# write memory

( copy running-config startup-config does the same.) A change that works but was never saved disappears at the next reboot, which often happens months later during an unrelated upgrade.

AOS-CX Checkpoints

Checkpoints are snapshots of the configuration (AOS-CX 10.14 Fundamentals Guide):

  • Type How it is created Limit
  • User checkpoint copy running-config checkpoint <name> Up to 32

System checkpoint Automatically, about 300 seconds after configuration changes stop (named CPC plus a timestamp) Up to 32; the newest replaces the oldest

Auto checkpoint checkpoint auto <1-60 minutes> ; kept only if you enter checkpoint auto confirm in time Temporary until confirmed

  • Useful commands: switch# show checkpoint
  • switch# checkpoint diff before-vlan-40 running-config
  • switch# checkpoint rollback before-vlan-40

checkpoint rollback replaces the running configuration with the checkpoint, and everything configured after it is lost, so compare first with checkpoint diff .

  • Where to Make the Change
  • Central-managed devices

If a switch or AP is managed by Central, make the change in Central : the Classic Central group (UI group or template), or the appropriate new Central scope or profile. Local CLI changes on a Central-managed device can be overwritten at the next push or appear as a mismatch in the configuration audit. Classic Central's audit view also shows the Auto Commit state; after an automatic rollback, Auto Commit is turned off until you review the offending change (Section 11.1).

VSF stacks

A VSF stack has one configuration on the Conductor. Configure any member's ports from the Conductor using member/slot/port names such as 3/1/12 .

VSX pairs

Each VSX peer has its own configuration. Features configured with vsx-sync on the primary are copied to the secondary; anything not synchronized must be configured on both peers. Check show vsx config-consistency after changes that affect VSX-LAGs.

Worked Example: Adding VLAN 40 for a New Department

The LLD update says: VLAN 40, name LABS, subnet 10.40.0.0/23, gateway 10.40.0.1 on the core VSX pair, DHCP from 10.1.100.50, available on floor 2 desk ports through 802.1X role LAB_USER.

  • Access stack (floor 2): switch(config)# vlan 40
  • switch(config-vlan-40)# name LABS
  • switch(config-vlan-40)# dhcp-snooping
  • switch(config-vlan-40)# arp inspection
  • switch(config-vlan-40)# exit
  • switch(config)# interface lag 1
  • switch(config-lag-if)# vlan trunk allowed 40
  • switch(config-lag-if)# exit

On AOS-CX, vlan trunk allowed 40 adds VLAN 40 to the existing allowed list; check the result with show running-config interface lag 1 .

Core VSX pair (primary, with vsx-sync for VLANs, or on both peers): create VLAN 40, allow it on the downlink VSX-LAG, and create the SVI: core(config)# interface vlan 40

  • core(config-if-vlan)# ip address 10.40.0.2/23
  • core(config-if-vlan)# active-gateway ip mac 02:00:0a:28:00:01
  • core(config-if-vlan)# active-gateway ip 10.40.0.1
  • core(config-if-vlan)# ip helper-address 10.1.100.50

The secondary peer uses its own SVI address (for example 10.40.0.3/23) with the same active-gateway IP and MAC.

Services: a DHCP scope for 10.40.0.0/23 with gateway 10.40.0.1; OSPF advertises the new subnet (passive SVI).

Access control: a LAB_USER role that places users in VLAN 40, and the ClearPass policy that returns it.

Verify: show vlan 40 , show vlan port 1/1/52 , show active-gateway , a test client that authenticates, receives an address in 10.40.0.0/23, and reaches its applications.

Save and document: write memory on each switch (or confirm Central is in sync), then update the VLAN table, port map, and change log.

Common Change Types and Their Checks

Change Key steps Verify with

Move a desk port to another VLAN Change vlan access (or the role returned by ClearPass); confirm the VLAN exists on the switch show vlan port <port> ; client gets an address in the new subnet

Add a VLAN to a trunk vlan trunk allowed <id> on both ends show vlan port <port> on both ends

Remove a VLAN from a trunk no vlan trunk allowed <id> ; never remove the last VLAN by accident show running-config interface <port>

Change PoE priority power-over-ethernet priority <level> on the port show power-over-ethernet <port>

Add an SSID Create it in Central with security, forwarding mode, VLAN or gateway cluster, and role Test client connects, gets the right VLAN and role

Change a role's VLAN or policy Update the role locally or in ClearPass/Central; CoA can move active clients show port-access clients detail ; show radius dyn-authorization

AOS-CX trap: if you remove the last VLAN from a trunk's allowed list with no vlan trunk allowed , the interface stays in trunk mode and then carries all VLANs defined on the switch, including future ones (AOS-CX 10.14 CLI Guide). Replace the list deliberately rather than emptying it.

Common Exam Traps

Forgetting the trunks. A VLAN that exists on both ends but is missing from a trunk's allowed list does not pass traffic.

Changing only one VSX peer. Without vsx-sync, the secondary still has the old configuration.

Not saving. Running-configuration changes are lost at reboot until saved.

Local edits on Central-managed devices. They can be overwritten; make the change in Central.