With increasing popularity in Secure Access Service Edge (SASE) architecture in WFH/remote environments, user experience onsite and remote branch sites are gaining momentum for customers. The Aruba UXI offers Wifi-5 and WiFi-6/6E sensors that can be deployed to customers' sites to allow flexibility and functionality of network operations.
Many customers are using UXI sensors like new employees who do not take holidays and continuously run tests and monitor networks 24x7. While some customers use UXI as before and after logs collector for environment change management or doing POC for Silver peak SDWAN or Aruba APs.
To find more in-depth information on what model of the UXI best suits your needs, please refer to the UXI sizing guide.
We also have a Validated Solution Guide for UXI Campus Deployment:
https://www.arubanetworks.com/techdocs/VSG/docs/020-campus-deploy/esp-campus-deploy-112-user-experience-insight/
Deployment options:
Sensors are usually deployed 1 per 5-8 access points or one per retail location or one per small building floor. This is a recommended design to validate the user experience for that area. Like any other client, the sensor connects to the best available AP. This does not necessarily mean best RSSI, it could be a combination of things including client load balancing and other RF metrics. Basically, like any other client, the sensor connects to whichever AP is available to respond to the probe request. The aim is to simulate client experience rather than test each individual AP in the area.
Also, it's worth noting that if a sensor is deployed with enough coverage (i.e., one per 5-8 APs broadcasting the same SSID), and if one of the APs in the area goes down or is not working, it will be transparent to the end-user/client. If users can connect to the SSID and browse the internet and required resources, they will likely not experience a degradation in user experience.
We recommend mounting the sensors 4-5 feet high from ground level where users normally sit like near workstations, cubicles, cafeterias, hallway, conference rooms, etc.
It is important to remember that the sensor disconnects and associates to the Wi-Fi once a test cycle. Often at the time of association, the best BSSID to connect to can be a different one because of changes in the network environment. In addition, the sensor will also roam as a normal client will during the test cycle.
Wireless and Wired network settings:
There is no limit to the number of networks you can configure on the dashboard, however, a sensor can test up to 4 networks (wired or wireless), any combination.
That is,
you can configure 4 SSIDs or 4 Ethernet networks
you can configure 2 SSIDs and 2 Ethernet networks
you can configure 3 SSIDs and 1 Ethernet or 1 SSID and 3 Ethernet networks
Note: A sensor can test 4 VLANs in a wired-only setting.
For more info please refer to this Testing multiple networks.
Design Example:
Let's walk through an example of the architecture of big customer site deployment using UXI sensors.
Step 1: Onboarding of sensors – one by one or bulk onboarding
Having a huge list of sensors and adding them one by one using mac address and serial number is a time-consuming process hence you can leverage the “Add multiple sensors” option under settings > Sensors > +Add sensors tab. You will need to create an excel sheet in .csv format with headers as ‘SENSOR SERIAL’ and ‘MAC ADDRESS’. Once you upload the file you should be able to see the sensors under the “unconfigured sensors” section.
Step 2: Creating groups
Once the sensors are added, the next step is to create groups for the added sensors. You can group the sensors the way you want, for example, store number or site name or geo-location name or IDF name or area names like conference hall, cafeteria. You can add a group by navigating to settings > Groups > +Add Group.
Step 3: Adding sensors to groups
Now that the required Groups are created, we can add the sensors to their respective groups are rename them accordingly.
Go to the ‘Unconfigured Sensors’ list in the ‘Sensors’ tab of the ‘Settings’ page.
Type or Copy-Paste the sensor serial number of the sensor you want to add in a particular group (for example, Store 1234) in the ‘Filter’ field in the right.
Click on the ‘Configure sensor’ icon. The ‘Add Configuration’ window opens.
In the ‘Name’ field, type the name of the sensor according to your naming convention.
Select the required group from the dropdown list in the ‘Group’ field.
Select wireless SSID or wired VLANs from the list and then click ‘Add’. The sensor is renamed and added to the required group.
Repeat the above steps till all the new sensors are renamed and added to their respective groups.
Step 4: Adding tests to the groups
After all the new sensors are added to their respective groups, the next step is to add the existing and/or configure new tests to these groups.
Click on the ‘Service & App Tests’ tab in the leftmost column of the ‘Settings’ page.
Click on the ‘Change Selection’ button in the top right corner. The ‘Selection’ section of the page expands showing all the available groups and networks under the ‘Selected Groups’ and ‘Selected Networks’ subsections respectively.
Unselect the ‘ALL GROUPS’ check box under the ‘Selected Groups’ subsection and ‘ALL WIRELESS’ and ‘ALL WIRED’ under the ‘Selected Networks’ subsection. All the checkboxes of all the groups and networks get unchecked.
Only check the boxes of the newly configured Groups. To find them, you can press CTRL+F keys and type the name of the group.
Check the box of only one SSID/VLAN Network under the ‘Selected Networks’ subsection, for example, XXX-WiFi or VLAN X.
Note: Make sure only the required Network is selected. The Networks for which the tests are already configured must be unselected before proceeding to configure the tests to the next Network.
Click ‘Close Selection’. The ‘Selection’ section of the page collapses.
Scroll down to the ‘Internal Services’ section. Enable the required internal tests by either adding a new test or selecting ON or OFF for existing tests. You can repeat the same for ‘External services’ for configuring external tests.
Note: It might take a little while for the status of the tests to come up on sensors on the UXI dashboard.
Post-deployment considerations:
You can enable Threshold violations by setting up threshold per WiFi or network or internal or external tests. Note: This setting gets applied to all sensors in that UXI account dashboard.
If you are having 20+ sensors in one UXI dashboard you can turn ON AIOps Incident detection for better reception of alert notifications.
You can configure integration with UXI dashboard like webhooks integration, Single Sign-on, Aruba Central integration, Data Push destination. This integration helps you leverage UXI data like test results, issue data from sensors, in a more efficient way and will keep you ahead of time.
Q&A
Q. I want to configure the UXI in a different place and then move it to another place where an internet connection through ethernet is not available. Does the sensor hold the configuration on the non-volatile flash memory? Or is the sensor fetching the configuration from the cloud every time it reboots?
The device receives a configuration for the networks which it needs to test, these will be obviously Wi-Fi SSIDs and their accompanying passwords or authentication details, as well as ethernet details. The ethernet details, if it's an open ethernet, will have no special configuration.
If the end-user wants to "onboard" a device using an open ethernet network, the device will use that open network to download its configuration. If it is in an environment where those configured networks are not available, it will still retain its configuration and simply just raise appropriate errors on the dashboard about those failures.
If the configuration DOES NOT include the targeted ethernet network, so the ethernet networks are unspecified, and the sensor is onboarded using an open ethernet network and then later moves to a network that is blocked there will not be any issue.
There is ONE very important point though, the device communicates with our cloud using the URLs specified here. It's the same URL where the sensor downloads its configuration but also uploads its test results. At least one of the networks which the sensors have MUST have access to these URLs.
If the targeted environment has a blocked ethernet network WITHOUT access to the URL, and the sensor is only able to communicate with our cloud through its configured Wi-Fi SSIDs then it could very well lose all communication to our cloud should the network go down. This isn't a recommended deployment case for our sensor because, if it loses connectivity to the Wi-Fi networks (because of a password change for example) and the ethernet connection blocks cloud connectivity, then obviously the device will become "orphaned". And even if you changed the password that's configured on the dashboard to the correct password the sensor will have no way of actually communicating with the cloud to collect that new configuration. In such a situation you'd need to unplug the sensor and move it back to the location with unrestricted ethernet.
If this is the use case then it will work but it's at the end-users own risk, should the network change the sensor will become isolated.
The alternatives are as follows:
Obviously, use a sensor that has a cellular modem, this is a backup connection that will allow the device to get the correct configuration should it lose cloud connectivity.
Secondly, you could onboard the sensor using the Bluetooth app, which uses your cellphones connection to download the config for a particular sensor, it then sends that config to the sensor, but obviously, you'd need to be in physical proximity to the sensor
The third option, and most recommended option, is to add a bypass rule to the ethernet network so the sensor will always have cloud connectivity to our URLs through the ethernet network.
Finally, if the network configuration is static and will not change, then yes you can absolutely onboard a device (give it the required network configuration for the needed SSIDS it should test), leave it plugged into the open ethernet network for a while to make sure A) it receives all it's needed updates and B) it starts correctly logging information to our could, and then finally you could move it to the final location where the ethernet network which it's connected to will be restrictive.