The User Experience Insight sensor can be configured to test a maximum of 4 networks in total. This could be wired only or wireless only or any combination of wired and wireless networks.
The sensor will connect to a network and run Core Tests followed by the Internal and External tests configured for that network. The sensor will only run one test at a time, but the testing process is continuous and runs in a round-robin fashion as illustrated below.
Core network tests check the network environment, network services, and external connectivity.
These tests include:
AP Scan: Examines the Wi-Fi environment around the sensor and collects BSSIDs, RSSI values, channel information, and related information
SSID Check: Checks whether the configured SSIDs on the sensor are available in the Wi-Fi environment
AP Association: Determines if the sensor can and how long it takes to associate with the configured SSID/access point
Allocate IP: Tests if the sensor is able to obtain an IP address using DHCP (skipped if a static IP address is configured)
Gateway: Tests if the provided (DHCP) or configured (static) gateway is reachable by the sensor
Primary DNS: Tests if the primary nameserver is able to resolve cdn.capenetworks.io
Secondary DNS: Tests if the secondary nameserver is able to resolve cdn.capenetworks.io
External Connectivity: Checks if the sensor can connect to http://cdn.capenetworks.io/auth (confirms if the sensor has external connectivity)
Once all the core tests have been successfully completed, the sensor will run the internal and external tests that have been configured for the network. See the following articles for information on the available predefined tests and custom test templates that can be configured. Pre-defined and custom test templates have optional frequency and rate limit settings so administrators have the ability to control the frequency of tests to avoid impacts on applications. More information on frequency and rate limit settings can be found here.
When all the tests have been completed for a network, the sensor will release the IP address if it was obtained from DHCP and de-authenticate from the network, and move on to the next network to test.
When an error is encountered with a test, the sensor will automatically attempt to triage the issue by repeating the sequence of procedures leading up to the test failure. This can help you drill down to the step where the issue occurred. This triage process happens in sequence with the test cycle and will, therefore, delay further testing until it has completed its analysis.
A test cycle duration on the sensor or agent depends on the number of internal and external tests configured on it and the number of ongoing issues happening on it. The best way to see this time is to select the last hour in the timeframe and hover over into WiFi metrics test results to check the test cycle duration and the time gap between the two tests of AP association time.
For an agent, the test cycle delay is 5 mins that means it waits for 5 mins after the completion of the previous cycle before starting the next one.