14.4 Preparing for Implementation
Key Takeaways
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 mgmtbacks up the current configuration andcheckpoint 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.
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,
pingandtraceroutewithvrf mgmttest 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.
An engineer will change uplink VLANs on a remote AOS-CX switch over SSH and is worried about cutting off access. Which feature restores the previous configuration automatically if the engineer cannot confirm the change?
loop-protect re-enable-timer on the uplink ports
checkpoint auto with checkpoint auto confirm
spanning-tree bpdu-guard timeout on the uplinks
vsf split-detect mgmt on the management port
New AOS 10 APs are ready for zero-touch onboarding. Which item must be completed in HPE GreenLake before they can be managed by Central?
Assign the devices to the Central service and apply subscriptions
Create a VRF named mgmt on each AP so it can reach the cloud
Install a TACACS+ server in GreenLake for AP administrator logins
Configure DHCP option 82 on the access switches for each AP port
Which element is essential in a method of procedure (MOP) for a campus change window?
Rollback triggers and step-by-step rollback instructions
A list of every VLAN in the organization's other campuses
A copy of the network's original hardware purchase order
The vendor's marketing data sheet for each new device
Sections you finish are checked off in the contents.