Client Connectivity Test Using a Tri-radio Access Point
With a tri-radio Arista access point (AP), you can turn its third radio into a client that can connect to another AP you want to test. This gives you the ability to proactively validate network assurance, the reachability of network services, and the quality of experience for critical applications such as VoIP. The AP being tested is called the Target AP. Acting as a client, the third radio of the tri-radio AP connects to the target AP and runs tests to assess network health and identify problems if any. In CV-CUE, you can select the applications you want to test and set up a recurring schedule.
For example, you could test VoIP applications at important meeting locations.
- Association
- Authentication
- DHCP
- Gateway
- DNS
- WAN Latency
- Application Test
- VOIP Test
- Throughput Test
Broadly, running tests using the third radio as a client consists of three steps: create a test profile, schedule a test or run it on demand using the profile, and analyze the test results.
Test Profile
- The SSID being tested
- The frequency band being tested and
- The tests that you want to run on the SSID and that band.
A test profile allows you to test client experience based on the use case. For example, for a corporate SSID, you could define a test profile that includes VoIP test and productivity applications. For a Guest SSID, you could exclude VoIP from the test profile and include only some social and custom applications. If your VoIP Wi-Fi clients are expected to primarily use the 5 GHz frequency band, then you could specify that in the test profile for testing VoIP quality of experience. The figure below shows an example of a test profile for a corporate SSID. A single test run carries out all the tests included in the test profile. Thus, for the corporate SSID test profile shown in the figure below, a single test run would consist of the Basic Connectivity Test, application tests for the Productivity applications chosen, the VoIP test, and the Throughput test.
You can run tests manually or on demand by selecting the AP to be tested.
Alternatively, you can schedule tests for a location (see the Schedule section below for details).
- You must create a test profile before you run a client connectivity test.
- When you create a test profile, you can save it and use it multiple times. If multiple APs broadcast the same SSID, then a single test profile can be used to run tests on all the APs.
- To run a test on a target AP, make sure that the target AP is broadcasting the SSID that is in the selected test profile.
Schedule
Scheduling periodic tests can help you optimize network performance and proactively unearth any issues on an ongoing basis, thereby avoiding reactive network troubleshooting fire drills. A schedule can comprise a single test run or multiple test runs recurring every few days or weeks.
When you set up a schedule for client connectivity tests at a location, the schedule automatically applies to all its child locations. Note that the parent location and one or more child locations could be in different time zones. In such cases, the time you select is interpreted by each location as its local time.
Selecting APs for a Scheduled Test
Target AP | Tri-radio Client AP |
---|---|
Target APs are selected at random to avoid testing the same AP repeatedly in a recurring schedule. | At least one tri-radio AP should be able to see the target AP with good RSSI, e.g., -70dBm or greater. |
The SSID and frequency band of the target AP must match those in the selected test profile. | The third radio of the tri-radio AP must not be busy in other activities such as intrusion prevention, troubleshooting, or another test. |
The target AP must not be busy with another test. | The tri-radio AP that sees the target AP with the best RSSI is chosen to act as the client, provided its third radio is not busy. |
Results
- Grey: The test run could not be completed.
- Green: All tests in the test run succeeded.
- Red: One or more tests in the test run completely failed.
- Orange: Partial success (or failure) of a test. A partial success could mean, for example, that some of the applications in the application test failed but others succeeded (see the Application Test Results section below for a detailed explanation).
Application Test Results
![](/assets/images/user-manual/ug-cv-cue/Graphics/Client%20Connectivity%20Test%20Using%20a%20Tri-radio%20AP/HTTP%20GET%20Success%202.png)
- Page Size
- HTTP Response Code (codes 100-399 represent a success)
- Page Loading Time. You can hover on the Page Loading Time to see the breakdown in terms of:
- DNS Lookup Time
- Initial Connection Time
- SSL Connection Time
- Green: All application tests succeeded.
- Red: All application tests fail.
- Orange: Anything other than Red or Green for a completed test run.
Test Result Descriptions
Field | Description |
---|---|
General information |
|
Access point acting as a client (tri-radio AP) |
|
Association |
|
Authentication |
Note: The latency is shown if the security mode is 802.1x.
|
DHCP |
|
Gateway |
|
DNS |
Note: When any one of the DNS servers has a failed status, the overall status of the DNS server test is set to "Partial". If the overall the status of the DNS test is "Partial", the Client Connectivity test result is set to "Failed".
|
WAN Latency |
|
Ping Test |
|
HTTP GET | If successful, it captures the following:
|
VoIP Test |
|
Throughput Test |
|