ExamFinch.com My Study

Study guide

13.4 Establishing a Performance Baseline

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

13.4 Establishing a Performance Baseline

Key Takeaways Explain This Topic AI

A baseline is a documented record of normal performance, measured over a representative period with defined metrics, before optimization changes are made.

Useful wired baseline metrics include interface utilization, errors and queue drops, CPU and memory ( show system resource-utilization ), PoE usage, spanning tree topology changes, and routing neighbor stability.

Useful wireless baseline metrics include clients per radio, band distribution, channel utilization, noise, retries, signal and SNR distribution, roaming results, and authentication and DHCP success rates.

Central monitoring and reports, AI Insights, UXI sensor results, and NAE agents provide baseline data; NAE's Baseline function learns normal values and sets dynamic thresholds.

A baseline must record when and how it was measured so later comparisons use the same method and comparable time windows.

Last updated: October 2026

13.4 Establishing a Performance Baseline

Quick Summary: The Optimize section of HPE6-A85 begins with perform environment baseline and ends with compare results to baseline . A baseline is a documented picture of how the network normally performs: the same metrics, measured the same way, over a representative period. Without one, "the change made it better" is an opinion.

What Makes a Good Baseline

Representative time window: cover a normal business cycle, such as at least a full working week including peak hours, not one quiet afternoon.

Defined metrics: decide in advance what you will measure and where.

Repeatable method: the same tools, sampling intervals, and locations, so a later measurement is comparable.

Context: note anything unusual during the window (an event, an outage, an exam period on a campus).

Stored and versioned: keep the data and a short summary with the documentation (Section 15.4).

The acceptance tests from implementation (Section 15.1) are often the first baseline; operations then refreshes it periodically and before planned optimizations.

Wired Metrics

Metric Why it matters AOS-CX / tool

Interface utilization (peak and average) Shows oversubscribed uplinks show interface utilization ; Central reports

  • Errors (CRC, input errors) Reveals physical problems show interface <port>
  • Queue drops by queue Shows congestion and whether QoS protects priority traffic show interface <port> queues
  • CPU and memory Control-plane health show system resource-utilization
  • PoE allocation and draw Headroom for growth show power-over-ethernet

Spanning tree topology changes Stability of Layer 2 show spanning-tree (topology change count and time since last change)

  • Routing neighbor stability Flapping adjacencies show ip ospf neighbors ; show events
  • MAC moves Hidden loops or misbehaving devices show mac-address-table mac-move
  • Wireless Metrics
  • Metric What "good" looks like Source
  • Clients per radio and per AP Balanced load across neighbors Central
  • Band distribution Capable clients on 5 GHz and 6 GHz rather than 2.4 GHz Central, ClientMatch events
  • Channel utilization Headroom during peak hours Central RF views
  • Noise floor and interference Low, stable noise Central RF views
  • Retry rate Low retries; spikes signal interference or coverage problems Central
  • Signal strength and SNR distribution Most clients with strong signal and good SNR (Section 6.2) Central, UXI
  • Roaming success and time Fast roams without drops Central events, voice tests
  • Authentication and DHCP success and time High success, short times Central, ClearPass, UXI

Remember that AirMatch re-plans on a 24-hour cycle, so measure RF metrics across several days rather than immediately after a plan is deployed.

Service and Experience Metrics

UXI sensors run the same synthetic tests repeatedly (association, authentication, DHCP, DNS, applications), which makes them ideal for baselines: same location, same tests, comparable results over time.

AI Insights learns normal behavior per site and flags deviations, which helps you spot whether the baseline period itself was abnormal.

Application response times from user-facing tests or monitoring tools tie network metrics to what users feel.

NAE Baselines on AOS-CX

The Network Analytics Engine includes a Baseline function for agent monitors (AOS-CX 10.14 NAE Guide). When an agent is enabled, it spends a defined period learning the monitored data, then calculates dynamic thresholds from what it learned and keeps adjusting them as conditions change. Script writers choose high and low threshold multipliers around the learned baseline, creating a corridor in which normal fluctuations do not raise alerts. This avoids one fixed threshold that is too sensitive on a busy switch and too lax on a quiet one.

Recording the Baseline

A one-page baseline summary per site might contain:

  • Item Example entry
  • Window Monday-Friday, 07:00-19:00, two consecutive weeks
  • Scope Building B, floors 1-3, 3 access stacks, 42 APs

Method Central reports (hourly), UXI tests every few minutes from 4 sensors, show interface <port> queues collected at 09:00, 13:00, and 17:00

Key results Peak uplink utilization, peak channel utilization per band, 2.4 GHz client share, retry rate, DHCP and authentication success, UXI pass rate

Notes Training event on day 3 increased client counts in the auditorium

The numbers matter less than the discipline: the next measurement must use the same window, scope, and method.

Worked Example: Baseline for One Access Closet

A team plans to change QoS on a busy floor and first baselines its access stack and APs:

Window: two normal working weeks, recording the peak hour each day.

Wired data: show interface utilization on the uplink LAG members, show interface <port> queues for the uplinks at three fixed times per day, CRC and input errors on all ports, and show system resource-utilization for CPU and memory.

Wireless data: Central reports for clients per radio, channel utilization, retries, and band distribution for the floor's APs.

Experience data: UXI test pass rate and DHCP and DNS response times from the floor's sensor, plus voice-call complaints logged by the help desk.

Summary: one page stating the window, the method, peak and typical values, and any unusual events.

With this baseline, the team can later show exactly which numbers the QoS change moved.

How Often to Refresh

Refresh the baseline after significant changes (new building wing, new application, firmware upgrade), at regular intervals such as quarterly, and whenever monitoring repeatedly flags "abnormal" behavior that turns out to be the new normal. An old baseline leads to false conclusions in both directions.

Common Exam Traps

Measuring once. A single snapshot is not a baseline; use a representative period.

Changing the method later. Comparing hourly averages with one-minute peaks produces meaningless differences.

Baselining during an incident. Note abnormal conditions or repeat the measurement.