15.3 Making Basic Ongoing Configuration Changes

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

1. Request and scope: what exactly must change, and why.
2. Impact check: which devices, users, and services are affected; does it need a maintenance window?
3. Protect: back up the configuration or create a checkpoint; use checkpoint auto for risky remote work.
4. Implement: apply the change in the correct place.
5. Verify: confirm the intended effect and check for side effects (Section 15.1 checks for the affected layer).
6. 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):

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.

1. 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.

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.

1. Services: a DHCP scope for 10.40.0.0/23 with gateway 10.40.0.1; OSPF advertises the new subnet (passive SVI).
2. Access control: a LAB_USER role that places users in VLAN 40, and the ClearPass policy that returns it.
3. 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.
4. 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

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.