15.4 Maintaining Network Documentation

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.4 Maintaining Network Documentation

Key Takeaways Explain This Topic AI

Operational documentation includes physical and logical diagrams, device inventory with firmware and subscriptions, VLAN and IP tables, port maps, configuration backups, a change log, and runbooks.

Documentation is updated as part of closing every change; an out-of-date diagram is worse than none because people trust it.

AOS-CX and Central help keep documentation accurate: show lldp neighbor-info verifies cabling, copy running-config <url> exports configurations, and Central keeps inventory, topology, and an audit trail.

As-built documentation records what was actually deployed, including deviations from the LLD and who approved them.

Credentials and shared secrets belong in an access-controlled password vault, never in diagrams, tickets, or plaintext configuration exports shared widely.

Last updated: October 2026

15.4 Maintaining Network Documentation

Quick Summary: Documentation is how a network stays understandable after the people who built it move on. HPE6-A85 lists maintain documentation as an Operate objective. In practice that means keeping a defined set of documents (diagrams, inventory, addressing, port maps, configurations, change log, and runbooks) accurate after every change, and using the network's own data (LLDP, Central inventory, configuration exports) to check them.

The Core Document Set

Document Contents Why it matters

Physical diagram Closets, racks, devices, and the cables between them, with port numbers Fast fault isolation and safe maintenance

Logical diagram VLANs, subnets, routing, VSX/VSF groupings, gateways, and tunnels Explains how traffic flows

Inventory Model, serial number, MAC address, location, firmware version, subscription, and support contract Upgrades, renewals, RMA, and audits

VLAN and IP tables VLAN IDs and names, subnets, gateways, DHCP scopes and helpers Prevents overlaps and supports new requests

Port maps Per-port device, VLAN mode, PoE priority, and access control Moves, adds, and changes
Configuration backups Current and historical configurations Recovery, comparison, and audits
Change log Date, change, reason, who, ticket, and result Answers "what changed?" during incidents

Runbooks / MOPs Step-by-step procedures for routine and emergency tasks Consistent operations by any team member

As-built What was actually deployed, including approved deviations The real starting point for operations
Contacts and escalation Vendors, support contract IDs, internal on-call Faster escalation
Keeping Documents Accurate
Use the network as the source of truth

Cabling and neighbors: show lldp neighbor-info on each switch confirms the physical diagram; differences mean either the diagram or the cabling is wrong.

Interface state: show interface brief and show vlan port <port> confirm port maps.

Inventory and firmware: show system , show version , and show images per switch; Central's device inventory for the whole estate.

Configuration: export configurations regularly, for example copy running-config sftp://backup@10.1.100.20/fl2-stack.cfg cli vrf mgmt , and keep them in version control so you can compare versions.

Use Central's records

Inventory and subscriptions for every managed device.

Topology views built from discovered neighbor data.

Audit trail , which records administrative actions and configuration pushes, including automatic rollbacks.

Reports for client, device, and usage history.

Make documentation part of change closure

A change is not closed until the documentation is updated. Add a "documentation updated" item to every MOP and change ticket, and record:

what was changed and where,
the before and after configuration (or checkpoint names),
verification results, and

who approved any deviation from the design.

As-Built Documentation

During implementation, reality often differs slightly from the LLD: a cable run turned out longer, so a different optic was used, or a closet had one free port fewer than expected. The as-built package records what was actually installed, with approved deviations, and replaces the LLD as the reference for operations.

Naming and Labeling Standards

Consistent names make documentation and CLI output readable:

Hostnames that encode site, building, floor, and role (for example HQ-B1-F2-ACC1 ).

Interface descriptions ( description ) that name the connected device, which also appear in many show commands.

LAG descriptions that name both ends.

Physical labels on both ends of every cable that match the port map.

Security of Documentation

Store passwords, RADIUS shared secrets, and SNMPv3 keys in an access-controlled password vault , not in diagrams or tickets.

Configuration exports can contain secrets; protect the backup repository with the same care as the devices.

Limit who can edit master documents, and keep version history.

Diagram Layers

One diagram that tries to show everything becomes unreadable. Most campus teams keep a small set of layered views:

Physical (Layer 1): devices, racks, and every cable with both port numbers. This is the view used during closet work and cabling repairs.

Layer 2: VLANs per trunk, VSF stacks, VSX pairs and their VSX-LAGs, and the spanning tree root. This explains which VLANs reach which closet.

Layer 3: subnets, gateways (including active-gateway virtual IPs), OSPF areas, VRFs, and the default route toward the WAN.

Wireless: AP placement on floor plans, SSIDs with their security, forwarding mode, and VLAN or gateway cluster, and the RF settings that were agreed (for example channel widths per band).

Management: the out-of-band network, the management VRF, Central connectivity, and where NTP, DNS, RADIUS, and syslog servers live.

Each view should show its date and the change that last updated it, so readers can judge how current it is.

Configuration Backup Practice

Schedule: export every device's configuration on a schedule and after every change. On AOS-CX, copy running-config <remote-url> {cli | json} vrf mgmt sends it to an SFTP or TFTP server; checkpoints ( show checkpoint ) provide on-box history.

Version control: store exports in a repository that keeps history, so you can compare any two versions and see who changed what.

Test restores: a backup that has never been restored is unproven. Practice restoring to a lab switch, for example with copy <remote-url> running-config or checkpoint rollback .

Central history: for Central-managed devices, the configuration audit and audit trail record pushes, mismatches, and automatic rollbacks, which complements device-level backups.

Worked Example: Closing a Change

A technician moved six printers from VLAN 10 to the new IOT VLAN 30 on floor 2. Before closing the ticket, the documentation updates are:

Port map: ports 1/1/31-1/1/36 now show VLAN 30 and MAC-Auth.

VLAN table: VLAN 30 lists floor 2 as a location.

Configuration backup: a new export of the floor 2 stack is stored, and the ticket references the checkpoint taken before the change.

Change log: date, ticket number, reason, implementer, and verification results (printers authenticated with the IOT role and reachable from the print server).

Diagrams: no physical change, so only the Layer 2 view's VLAN list for floor 2 is updated.

Common Exam Traps

Treating documentation as a one-time task. It must be updated after every change.

Trusting a diagram without verification. LLDP and Central data reveal undocumented changes.

Storing secrets in documents. Credentials belong in a vault.