13.4 Establishing a Performance Baseline
Key Takeaways
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.
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 utilizationon the uplink LAG members,show interface <port> queuesfor the uplinks at three fixed times per day, CRC and input errors on all ports, andshow system resource-utilizationfor 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.
Which approach produces a valid performance baseline before optimizing a building's WLAN?
Collect defined metrics with the same tools over a normal working week, including peak hours
Ask a sample of users each month whether the Wi-Fi feels fast and record their answers
Take one screenshot of the Central dashboard on a quiet Saturday and keep it as the reference
Record the number of APs and their firmware versions, since these determine performance
What does the NAE Baseline function do for an agent monitor on an AOS-CX switch?
It replaces spanning tree priorities with values learned from the network over time
It learns the monitored values for a period, then sets dynamic thresholds that adjust
It copies the running configuration to a remote server every day for later comparison
It reboots the switch when CPU usage exceeds a fixed value learned during setup
Why are UXI sensors especially useful for baselining user experience?
They raise AP transmit power automatically when they detect weak coverage nearby
They replace the need for access points in the areas where they are installed
They store all user traffic so that it can be analyzed later against the baseline
They repeat the same synthetic tests from the same places, so results are comparable
Sections you finish are checked off in the contents.