ExamFinch.com My Study

Study guide

13.5 Comparing Results to the 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.5 Comparing Results to the Baseline

Key Takeaways Explain This Topic AI

After an optimization, measure the same metrics with the same method over a comparable time window, then compare them with the baseline.

Change one variable at a time so any improvement or regression can be attributed to that change.

AirMatch deploys plans on a 24-hour cycle, so RF optimizations should be judged over several days, not minutes after a change.

Keep changes that meet their success criteria, roll back changes that cause regressions, and record the result and the new baseline.

Typical comparisons include band distribution and retries after WLAN tuning, queue drops for priority traffic after QoS changes, and dropped broadcast counters after rate limits.

Last updated: October 2026

13.5 Comparing Results to the Baseline

Quick Summary: The final Optimize objective is compare results to baseline . After applying a WLAN or LAN best practice, you measure again, using the same metrics, tools, and time window as the baseline, and decide whether the change achieved its goal. Keep what worked, roll back what did not, and update the baseline so the next comparison starts from the new normal.

The Optimization Loop

Loading diagram...

Making a Fair Comparison

Same metrics and tools: if the baseline used Central hourly reports, compare with Central hourly reports.

Comparable windows: compare a normal week with a normal week, and peak hours with peak hours. A Monday after a holiday is not comparable to a regular Monday.

One change at a time: if you change channel widths and QoS on the same night, you cannot tell which helped.

Allow settling time: AirMatch re-plans on a 24-hour cycle and clients adapt over days, so judge RF changes over several days.

Note confounders: a large event, an outage, or a new application during the window can explain the difference on its own.

Defining Success Before the Change

Write the success criteria into the change request. For example: "Reduce the 2.4 GHz share of capable clients in the auditorium, lower peak 5 GHz channel utilization, and keep UXI pass rates at or above the baseline, with no increase in authentication failures." Clear criteria prevent the common habit of declaring success because something improved while something more important got worse.

  • Example Comparisons
  • WLAN example: auditorium tuning

Problem from the baseline: high retries and channel utilization during lectures, and many dual-band clients on 2.4 GHz. Change: use 20 MHz channels in the auditorium's 5 GHz radios to create more non-overlapping channels, as recommended in Section 6.2, and confirm ClientMatch band steering is active.

  • Metric (lecture hours, weekdays) Baseline week After-change week Assessment
  • Peak 5 GHz channel utilization High Lower Improved
  • Retry rate High Lower Improved
  • 2.4 GHz share of 5 GHz-capable clients Elevated Reduced Improved
  • Peak per-client throughput Higher Slightly lower Expected trade-off of narrower channels
  • UXI test pass rate Baseline level Same or better No regression

(The table illustrates how to read a comparison; your own numbers come from your measurements.) Decision: keep the change, because the goals were met and the narrower channels' lower peak per-client throughput was an accepted trade-off.

LAN example: QoS for voice

Problem from the baseline: voice quality complaints, and show interface <port> queues on the uplink shows drops in the queue carrying voice during backups. Change: trust DSCP from phones and the uplink, and make the voice queue strict priority in a schedule profile (Sections 13.1 and 13.2). Comparison: voice-queue drops during the backup window should fall to near zero, while overall drops may shift to lower-priority queues. If best-effort users now complain, adjust DWRR weights and compare again.

LAN example: broadcast rate limits

Problem from the baseline: a misbehaving device floods broadcasts on access ports. Change: rate-limit broadcast <pps> on access ports. Comparison: show interface <port> qos shows broadcast drop counters; confirm that normal ARP and DHCP still succeed (DHCP success rate unchanged) and remember that the rate limit only contains the symptom, so the device still needs to be fixed.

Deciding What to Do

  • Outcome Action
  • Goal met, no regressions Keep the change, document it, update the baseline
  • Goal met, minor accepted trade-off Keep, document the trade-off and who accepted it
  • No measurable effect Consider rolling back to keep the configuration simple; revisit the analysis
  • Regression Roll back (for example with a checkpoint on AOS-CX), then investigate
  • Updating the Baseline

After a change is accepted, the new measurements become the new baseline . Record the date, the change that created it, and the method. Without this step, the next comparison would be made against an outdated picture.

Reading the Numbers Carefully

Peaks and averages: a change can lower the average while the peak hour, which users notice, stays the same. Compare both.

Distributions, not single values: look at how many clients have good signal and SNR, not only the average. A few far-away clients can drag an average down.

Enough data: one day of results is easily distorted by a single event; prefer the same multi-day window as the baseline.

Related metrics: an improvement in one metric should not hide a regression elsewhere. Check authentication success, DHCP success, and UXI pass rates alongside the metric you targeted.

Reporting the Result

A short comparison report helps stakeholders and future engineers:

  • Section Content
  • Change What was changed, where, and when (with the change ticket)
  • Goal The success criteria written before the change
  • Method Baseline window and after-change window, tools, and scope
  • Results Before and after values for each metric, with notes on confounders
  • Decision Keep, adjust, or roll back, and who approved it
  • New baseline Date from which the new values apply
  • Rolling Back Cleanly

If the comparison shows a regression, return to the previous state in a controlled way: checkpoint rollback <name> on AOS-CX (after checking checkpoint diff ), the previous template or setting in Central, or the previous RF settings for the affected APs. Then measure again to confirm the network is back to its baseline before trying an alternative.

Common Exam Traps

Comparing different conditions. A busy weekday cannot be compared with a quiet weekend.

Bundling changes. Several simultaneous changes make the result impossible to attribute.

Judging RF changes too early. Give AirMatch and clients time to settle.

Forgetting to update the baseline. Future comparisons need the current normal.