Network-Engineering | 36 min read
Trying out Arista’s Cognitive WiFi™ Solution
Not so long ago we spent a few days field testing Cognitive WiFi, which is the current WLAN solution from Arista. Cognitive WiFi is a term coined by Mojo Network, which is a company founded in 2003 (known as AirTight back then), they were mainly focused on WIPS and AP mesh groups then evolved into a unified cloud-managed WiFi solution.
They were acquired by Arista in 2018, as it seems that both companies have the same vision of how the network should look like, more centrally (cloud) managed and API-driven automation and high leverage on Big Data analytics. Through this text, Mojo (Networks) and Arista would be used interchangeably. Mojo cloud is deployed in the AWS Cloud and consists of several services usable and available in the instance of the end customer. Additionally, Mojo offers different deployment methods:
- Public Cloud (AWS)
- On-Premise VM
- Bare-metal-server (BMS)
The main difference between these options is access to the cognitive engine and big data analytics and who manages equipment and software patches of running services. All 3rd party integration plugins need to be written from scratch or downloaded from Arista (ex. social plugins). Vendor-supplied ones are already available in the cloud instance and are already preconfigured. An interesting side note is that On-Prem VM and Baremetal deployments lack guest management. A query was sent to the Arista Engineer to clarify.
A full list of the On-Premise VM and BMS limitations are as follows:
- Cognitive WiFi:
- Limited drill down of “Client Journey”
- No inference engine
- Limited troubleshooting
- No guest management
- Limited captive portal management
- No analytics
Cloud and On-Prem solution both offer following services and applications used for management of wireless network:
- CloudVision (CV) WiFi – previously known as Aware, front end service, collection of API calls to the Wireless and Guest Manager.
- Wireless Manager (WM) – main configuration services (some parts are already integrated into the CloudVision) for Wireless and WIPS.
- Guest Manager (GM) – defines a workflow for the guest captive portals, collects and processes data related to the guest networks.
- Packets – cloud-based graphical troubleshooting tool, used for conversion and parsing of the wireless packet captures
- Canvas – captive portal design tool, used to create whole campaigns
- Nano – application allowing to manage the wireless network from the phone (limited capabilities)
It seems like the overall plan of Arista is to integrate all services into one portal (CloudVision) and presumably in future add support for their LAN devices as well, which could be a game changer for this vendor. For the reference, all testing was done on service build 8.7.1-03 and CloudVision version 2.4.1-12. The tested version, WIPS was not a part of CloudVision, but it’s now under heavy development and we got information from Arista, that it’s currently in the testing phase.
The test was performed on 3x C-130 Arista (Mojo) access points, they are the flagship of their current WLAN portfolio. C-130 is a 4×4 MU-MIMO tri-radio 802.11ac access point with dual concurrent 5 GHz and 2.4 GHz band radios supporting 802.11a/n/ac Wave 2, 802.11b/g/n, four spatial streams, and data rates of up to 1.733 Gbps and 800 Mbps, respectively. It contains a third 2×2 MIMO 802.11ac radio for dedicated multi-function scanning (WIPS). Other characteristics consist of 2 Gigabit Ethernet port, which can be used as a port bundle or to extend SSID over the wired network, of course, these functions are mutually exclusive. It can be powered either from LAN port (PoE+ is required) or directly from power supply (12V DC), it’s worth mentioning that when powered with PoE (802.3af) AP will be still operational, but certain features are disabled, to adapt to power shortage: LAN2 and USB ports (which is not in use currently anyway) are disabled, 2,4GHz radio would operate in 1×1 mode with 15dBm transmit power, 5GHz radio will operate in the 2×2 mode with 18dBm transmit power, third radio will operate in 1×1 mode. According to the Arista documentation, bandwidth requirements on the internal network are based on device role and are as follows:
- Access point – 0,5kbps
- Access point with sensor – 2kbps
- Dedicated sensor – 1,5kbps
The main entry point for the Arista Cloud WiFi solution is the launchpad portal. It gives access to all available services and applications, it is also used for basic management of the access to the Arista Cloud (as probably in the future will be used for the DC LAN switches management as well). As for the time of writing, there are only two sections on the launchpad: Admin and Dashboard. Admin give possibilities to configure access policies: allowed IPv4/IPv6 addresses, enforce 2FA, add/lock/remove users and assign them appropriate access rights (via profiles or manually), Dashboard is simple splash page for the access to the services and full access view looks like that:
It would seem obvious that before any setup begins, some mandatory actions are needed to prepare your environment. The first step would be cloud service security, which is not mandatory to setup a working WLAN solution, but hey, we live in troubled times and we cannot really express how much infrastructure and management security matters. What Arista offers is something which comes close to an industry standard, password policing and 2FA wrapped around with restricting login access from certain subnets (only IPv4). For more paranoid users, there is an additional option for denying access to Arista Networks administrators. Users permission can be assigned manually or by inheritance from profiles, there are two system-defined profiles: admin – which can do everything and custom – which is the placeholder for manually, per-user, changed permissions. For more granularity, service permission has different predefined user roles, currently, there’s no possibility to create your own roles. Second, to security, would be to actually register AP fleet to proper service/account and start doing some networking. One of the neat features is that as soon as devices are connected and visible to the CV/MNM, it would be upgraded to the newest available software version.
Assuming that this is a green field setup, we have only one user which was created by the Arista initially, we need to add additional ones so we can split our responsibilities among other… and share the burden! Users are configured in the Admin section of the launchpad portal, permission can be assigned manually or by inheritance from profiles, there are two system-defined profiles: admin – which can do everything and custom – which is the placeholder for manually, per-user, changed permissions. Currently, it is a mystery to me how exactly Mojo segments it’s accessed right, as for some services it hides them when the user does not have access, but others will just display a pop-up with a statement that “you do not have rights to view this resources”. For example, after configuring user which had only access to the Guest Manager as the Guestbook Operator, his launchpad dashboard was seen like that:
We can quickly see that certain apps are missing due to the permissions (which is expected behavior), but others are sitting there, just waiting for the click, or for trying to mess around with access rights. Even access to the Admin section is still there, just calling out to be clicked. I would naively assume that Guestbook Operator would only see:
- CloudVision (since in the end, it will be all-in-one service)
- MGM (since he has got actual access there)
- … and this “WiFi – *” tiles (since it’s a FAQ and internal KB)
and in the later releases, only CloudVision.
After some digging, I think the reasoning behind it is simple, you can manage access directly to only some of the applications, rest will just check if you have access to the services on which they rely on and block you. So admin can disable access to the Packets, hence they will disappear from the dashboard, but Canvas and Nano will still be there, they will be just not usable if users do not have permission for MWM (Nano/CloudVision) or MGM (Canvas). For more granularity, service permission has different predefined user roles, which they describe what can be done in the services that users have access to. As previously mentioned, there’s no possibility to create roles. There’s a full permission-to-role matrix described in the built-in help (access to the launchpad is of course required to view that).
Initially before devices (AP) can be used, they need to be registered into the Arista Cloud and assigned to the proper service. This part was already pre-populated for us by Arista, so it was skipped, during testing. Devices can be added manually or by importing CSV file containing all required fields. This is a rather straight forward task and is done directly from the launchpad page in the WiFi Device Registration. The two pieces of information needed to register an AP into your own managed service is its serial number and registration key with can be found on the back of the AP, just below the serial number.
Pulse Policy Secure was used as a RADIUS server for the WLAN setup, to check if it can be integrated its built-in server into the final product/solution. Since RADIUS client implementation is not complicated and well defined by the standard, any other RADIUS server could be used with some success (for ex. FreeRADIUS). On the Arista side, RADIUS integration was very simple and requires only creating the profile for each used RADIUS server and then use the mentioned profile in the SSID configuration.
It’s worth mentioning at the very beginning that CloudVision has great help feature. When enabled, it will color “known” options in the purple color and enable tool-tips, which will explain what certain options do. Of course tool-tips based systems are not something new, but Mojo has done the fine job into doing it intuitive and not hurting users eyes.
Since everything in Arista Cloud Wireless solution is based on the device location (device templates, events, WIPS), it’s important to first create company structure, so that everything can be already placed in its appropriate position. Most of the features rely on Auto Location Tagging so that devices or events should be inherited location-based on the nearby managed APs signal strength. Locations (also called Folders) are grouped into the tree structure, where the company being root and consisting of folders and floors as the “end” of the branches. CloudVision gives the possibility to add multiple locations, using indentation like syntax. Floor plans can be placed to visualize the placement of AP and plot RF convergence maps, various file formats are supported (.jpg .png .gif) and additional .spm file can be used, which is the output of Mojo Planner (could not found it on Arista page) and already includes floor dimensions. The main difference in terms of functionality between MWM and CloudVision is possible to include map view in the MWM and place locations (hyperlinked) in there since it’s not included in the CV, it will probably be gone in future. Floor plans work for both without any differences (apart from the UI). I’ve encountered some strange bug with the floor plans, which caused all changes made in the CV to be discarded and only accepting changes made in the MWM, this could be possible due to the fact that I started to configure everything in the MWM. Additionally, one of the AP got duplicated, as long as not all AP were placed on the floor plan… since I fixed that, I was unable to reproduce that error.
When the device is assigned to the location, it inherits a device template, which is the collection of configuration blocks, this ensures that all devices are configured consistently. AP configuration is split into two groups in MWM and different configuration tabs in the CV). There are generally no differences in the configuration between the two services, apart that MWM has a more complex Radio Settings part (which is not present in the CV), where WiFi Profiles or Mesh Profiles can be attached directly to the radio, which is in a different place (SSIDs) or cannot be done at all in CV (mesh profiles).
Most important configuration options in these settings are:
- Device password and SSH access policies
- NTP settings
- Access logging (external Syslog)
- 3rd party analytics integration
- SSID wired extension
- RF Scanning
- WIPS device marking (VLAN monitoring + monitored channels)
- WIPS offline mode
- Channels used by each radio
- Radio modes
- WMM Admission control policy
- Client/band steering
- Tx power
Since it was not so obvious I want to document possible configuration options for the VLAN monitoring, by default AP monitors VLANs on which its SSIDs are configured in NAT or Tunneled mode and the VLAN it uses to communicate with the server.
- SSID VLAN — will additionally discover and monitor VLANs which are used by the Bridged SSIDs (will fetch IP for that VLAN).
- Auto VLAN — when the device detects activity on a VLAN, it starts monitoring the devices on that VLAN.
- Additional VLANs — monitors specified customer-defined VLAN, not assigned to any SSID.
The Screen above is the best description of how CloudVision works, here we see some profiles created by the configuration in the CloudVision, which are transferred to the Wireless Manager using API calls, hence the generic description “WEBAIP”.
When we already have devices and templates ready, it’s time to actually set up some WiFi and start to broadcast into the air. SSIDs are configured location wise (as a part of device templates) or can be inherited from the parent folder. The most basic configuration that needs to be done is, of course, SSID name (which will be visible by clients) and profile name, most of the time these two values will match, but this is not mandatory. The profile name is used to tie SSID object to other services, it’s better visible when configuring via MWM, where we create SSID profile (hence profile name) and then tie it to the radios in the device templates. SSID type will specify how devices connected to such SSID would be classified, for example, if an authorized user will connect to the guest network, he will trigger event and alarm.
It does not specify that this SSID will use captive portals, as they can be configured even on non-guest networks (private). It’s even possible to configure WPA2 Security settings on the Guest SSID. There’s a strong emphasis on security, as there are many possible options to configure like:
- Client Isolation – mimics isolated private VLAN port, blocking all client-to-client communication going through managed APs for selected SSID
- Client Authentication – WPA2 will authenticate the device, and the client can be additionally authenticated using either Google Authentication (requires Google integration) or RADIUS MAC Authentication
- Standard black/whitelisting of clients
- Client Redirection
- Bonjour Gateway – to enable Apple multicast service (only for Bridged or Tunneled SSIDs)
- Role-Based Control – which requires either 802.1x WPA2 authentication or Google Integration, to assign per role firewall rules and QoS settings (and works only for Bridged or Tunneled SSIDs). Role profiles need to be configured. Roles actually have the same configuration as RBC, hence there’s a possibility in the Role configuration to inherit it from SSID, or have an explicit configuration. Additionally, for the Bridged/Tunneled SSID, VLAN can be overridden by the Role specific one … no longer AVP 64,64,81 are necessary from RADIUS, but can be done using Google auth!
- Application Firewall Rules – can allow or block traffic to/from predefined applications (currently around 1964), so requires Application Visibility to be configured as well (supported only on 802.1ac Wave2 APs)
- L3-4 Firewall Rules
- SSID scheduling – which gives the possibility to set when SSID should be active within a week timeslot (with 30min resolution), and set start and end date for SSID activity.
SSID can work in one of 3 “modes”:
- Bridged – SSID is associated with VLAN and APs will act like L2 switches, of course, one SSID can be mapped to one VLAN only.
- NAT – APs will be gateway and DHCP for all clients, traffic will be NAT’d to the “communication” VLAN, AP uses to communicate with the server.
- Tunneled – APs will encapsulate all traffic into GRE and send it to the configured endpoint (EoGRE).
Guest SSID/Captive Portals/campaigns
For this, we would need these portals… ok we could ignore either CloudVision or Wireless Manager, but let’s test everything:
Splash pages and rest of the campaigns (container for your guest engagement content) are created in Canvas application. Then Portal is configured in the MWG, and tied to the SSID via the splash page. The first step would be to create a campaign in the Canvas, there are two types of them: Basic and Pro. Basic is what most of the mortals need, just a splash page and collection of authentication plug-ins, Pro campaigns are for more advanced usages, like guest engagement (showrooming), SMS/MMS advertisements, paid portals, mostly aimed for the retail shops, where guest users are often customers – target marketing. Showrooming is the practice of examining merchandise in a traditional brick and mortar retail store or other offline settings, and then buying it online, sometimes at a lower price.
|Feature||Basic campaign||Pro campaign|
Coupons are MMS messages that are sent to the WiFi user when he is browsing configured domains (up to 10), it’s marketing element which can be used as a part of user engagement. They require that the user will fill in his mobile phone number during sign-in, preferable through the web form. Text messages work the same as coupons but are aimed for the client devices which are not supporting MMS.
Multiple elements can be created (ex. multiple splash pages), but only one from each category can be published and active at the same time. Elements are configured from predefined templates. Usage of Canvas is quite simple, you create a campaign (Basic/Pro), add elements and then publish the whole campaign. The configuration of elements is initiative, using a built-in editor, where all elements can be modified (text, images, plug-ins) and moved around. If so desired and feeling limited by predefined templates, the custom page can be uploaded as well (zipped). Since Pro campaign, it is not something enterprise customers are interesting and because it relies on paid 3rd party SMS/MMS gateways (which are not part of demo kit), it was not tested fully, instead Basic was used to great guest WiFi access for the office network.
If any site needs to be accessible by the splash page, like plug-in login pages, linked images, then need to be added to the Walled Garden or Authentication sites in the SSID configuration. Of course, better do it only in the MWM or CV, depends where you configured SSID-to-Portal association, otherwise… you will lose portal probably.
Note: Walled garden refers to a limited environment to which an unauthenticated user is given access. Once authenticated, the user is allowed to leave the walled garden.
Next step would be to create a captive portal, using already created campaign. When creating a new portal, mandatory data needs to be specified (portal name and shared secret) and at least one plug-in needs to be enabled, for the portal to be active. With the exception of clickthrough, all plug-ins are configurable.
|Social||Facebook, Twitter, LinkedIn, Google+, Instagram, Foursquare, WeChat…|
|Guestbook||Uses Guest Manager hosted user database, delivery method: SMS/email; can use self-registration which eliminated guestbook involvement|
|SMS||Requires 3rd party gateway that exposes HTTP(s) endpoint for sending SMS…|
|Webform||Self-registration which collects additional data before sign-in|
|Clickthrough||Allows users to authenticated just by accepting ToU.|
|RADIUS||The RADIUS plug-in is mutually exclusive from the rest of the plug-ins.|
Data that could be recorded from social plugins:
- Facebook: user id, full name, gender, email address, birthday, likes, location, profile picture
- Linkedin: user id, full name, profile picture, email address
- Google+: user id, display name, full name, gender, preferred language, profile picture, email address
- Twitter: user id, location, language, profile picture
- Instagram: user id, full name, profile picture, followers count
- Foursquare: user id, full name, gender, location, phone number, profile picture, birthday
There’s a big change in the social plug-in section pending:
Guest Manager currently fetches profile data of opt-in WiFi users from several social plugins supported in the product (Facebook, Twitter, LinkedIn, Google+, Instagram, Foursquare). The user profile data is stored and rendered under the ‘Profiles’ tab on the service console/UI. This functionality is subject to change starting Guest Manager version 5.1, which will be installed in the Arista WiFi cloud soon after March 31, 2019. The reason for this change is the new Facebook policy going into effect in April 2019, which stipulates the following:
- Facebook will now require developers to provide a callback URL that can be queried by Facebook to delete a particular user’s data from the developer’s system.
- Age range and gender data will be available only to apps that undergo a vetting process and/or sign contractual agreements with Facebook.
Due to these heightened compliance requirements, starting version 5.1, Guest Manager will stop storing and rendering WiFi users’ opt-in profile information from the Arista-managed Facebook app. For customers who want to continue to gather WiFi users’ opt-in Facebook profile information, they can get their own apps registered with Facebook and, if necessary, duly vetted and/or contractually agreed with Facebook. These apps can then be plugged in Guest Manager. Guest Manager will then fetch WiFi users’ profile information from the customer’s app and post it to the customer specified URL endpoint, but neither store it nor render it in the Guest Manager UI.
WiFi users’ Facebook profile data that is already stored in the Guest Manager prior to upgrade to version 5.1, will be permanently deleted from the Guest Manager on April 30, 2019.
In anticipation of similar policies from other social media vendors, the above change will be made in Guest Manager 5.1 for not only Facebook but also all other social media plugins supported in the product.
Each sign-in plug-in can have separate QoS settings limiting maximum upload/download bandwidth for users using them, additionally, each method can have a separate timeout for login and blackout timer, which blocks the user for reconnection for the specified time duration. Furthermore, depending on the used method, users can be redirected to the specified URL. The last step is to embed proper campaign into the captive portal, special care needs to be taken, so that splash page will have the same plug-ins visible as captive portal uses.
To tie in a captive portal with the SSID, we need to record splash page URL and it’s shared secret:
Then do configuration in the SSID profile in the MWM (in the Captive Portal section):
or in the CV SSID (also in the Captive Portal tab):
I was not able to find another way around to force CV to use Cloud Based splash page – which the one hosted in the mgm-atXXX.mojonetworks.com – actually is, other than pointing this address as 3rd part hosted portal. Then Arista/Mojo magically detects it’s actually in the Arista Cloud and aligns. Directly in the Cloud-based, there’s no option to select predefined campaigns/portals, there’s only option to create splash page from scratch. Of course, if only a splash page is needed, there’s an option to create it directly in the CV (Cloud-based option), which will give the same functionality as Canvas gives. It still should record data in the MGM, as this will auto create a portal in there with the name <SSID>-<creation_date> (ex. NG_AristaFree-2019-02-23_10-28-35), as well as campaign in the canvas aware-<creation_date> (ex. aware-2019-02-23_10-28-35). Since there’s an autovivification feature on the CV, it works as well in the backward direction, but this is explained below.
|NEVER DO THAT!|
At least at the time of writing, NEVER, under any circumstances, configure captive portal created in the MGM, as an external splash page in MWM and as Third Party Hosted in CV for the same SSID. For me this removed portal completely from MGM… and cost me 30min to figure out what actually happened.
If you configure it only under MWM – CV will automatically sync it as Cloud Hosted portal.
If you configure it only under CV as Third Party Hosted – it will switch over to Cloud-based after it’s saved, and MWM will sync.
When you remove SSID in the CV which is using Guest Manager configured portal as Cloud-based, it will remove that portal as well…
Based on recorded data, the Guest Manager can display various data in the dashboard and reports. The dashboard is the first window, which is presented after login into the MGM, it provides basic information which it gathers from Anonymous and Association analytics. Association analytics relates to the data gathered from users logging into the guest wireless network using their social media credentials, anonymous associations are both devices associated to our guest network or not, it just needs to be in the range of AP. A dashboard shows these metrics:
- Conversion – shows the relation between ‘inside’ (RSSI threshold within -30 to -70 dBm and for at least 5min) and ‘outside’ users.
- WiFi users – how many of the footfall users associate in the end with our wireless network.
- Demographics – gender and age distributions, relies on social plug-ins.
- User frequency – new vs. repeated users and how long it takes in avg. between each visit (for frequent users).
- Dwell time – measures how long users stayed within our network range.
I guess our wireless network is not very appealing to people in our building.
Guest Manager fetches the visibility and association analytics information from the Wireless Manager. Guest Manager analyzes guest user information for each portal and provides location-aware graphical and tabular representations of this data. It’s pretty neat and scary, how much information is collected about users. Certainly helpful for retail business, which wants to know if their brand is recognizable and how many potential customers they lose/gain.
- Presence – gives footfall and dwell time representation, based on duration/day time and location.
- Demographics – will give statistics for the login methods and various data gathered from social plug-ins.
- Profiles – records profiles of logged in users from social plug-ins, web forms, guestbooks, and self-registration.
- Conversion – shows conversion rates between ‘inside’ and ‘outside’ users and the loyalty of guests.
- WiFi Usage – data transfer statistics, obvious.
- Floor Map – shows where most of the users are visible, the floor plan needs to be properly configured prior.
- Interception – shows overall redirection and user engagement (SMS/MMS) of the monitored domains.
Reports can be created, which will combine any of the presented graphs from either the dashboard or the analytics section. Such reports can be scheduled to be created in the reoccurring fashion and send to the predefined recipient list.
Hence LAG having a full paragraph, it will not take long to explain, how simple it is. When in the device template, link aggregation is enabled, when a 2nd ethernet cable is plugged in (to the LAN2 port), it will try to form LAG with the upstream switch, using LACP. Since there’s no much to configure, only a slow period is supported (LACP default values). It is kind of self-explanatory, but when this option is enabled, SSID wired extension configuration is ignored, just to be (mojo)aware of that.
SSID Wired Extension
I tried it briefly and had some problems, some of them coming from hardware incompatibility… I didn’t have an ethernet port on my laptop, so I had to use the USB-C hub to have some LAN port to work on. SSID extension work only for the uppermost NAT SSID (if more then one SSID has wired extension enabled) and will extend the wireless network throughout its LAN2 port, acting as the gateway to the devices connected directly or via the switch. To extend multiple VLANs, the VLAN extension must be used and if both are configured, the VLAN extension will take precedence. I found a lot of documentation entries (Aware User Guide 2.4) stating that it will only work with the W-68 model and did not have enough time to try to test if this works on C-130 regardless of that information. I tried some idea that came into my mind and didn’t find information anywhere in the documentation, what will happen if I will extend SSID with 802.1x authentication enabled, will security setting be extended as well? First I had to disable LAG because as stated in the previous paragraph, it will disable SSID wired extension. After configuring it, which actually was only enabling one checkbox in the Network tab of SSID and waiting a few minutes, my laptop got the IP address on the interface which was connected to the LAN switch. If someone is concerned about the security of such a solution, it can be achieved by enabling 802.1x on the LAN switches and Arista has already on the roadmap to include 802.1x on the extended port as well. There’s something that would be nice to have, so that dashboard would actually tell you somewhere that you have wired extension somewhere, maybe it is somewhere, but it is not intuitive.
CloudVision studies the behavior from the historical data of clients, APs and applications, automatically calculates a baseline. The baseline is calculated at an interval of 15 minutes. Any behavior that deviates significantly from the baseline is considered to be an anomaly and highlighted in the graph. The baseline feature is instilled in a number of graphs across Dashboards and Access Monitoring, such as Average Latencies, Baseline – Client Affected by Poor Performance, Baseline – Clients Affected by Failures and so on. Baseline functionality is no available for customers not using cloud solutions. CloudVision dashboard provides quite a nice portion of information at first glance, and it is not so overwhelming as the one used in the MWM. It’s divided into 3 tabs:
- Connectivity – shows statistics tied to the health of all the clients and devices that are present in a WLAN network (like Client Journey). Client journey can be shown for all clients or for one particular when searched using a magnifying glass icon.
Performance – related to clients and network health
- Applications – should show application experience with various voice/IM apps. It requires Application Visibility to be configured, to work properly.
Arista/Mojo gathers a lot of information which can be useful in troubleshooting connectivity problems and performance problem since it already data related to the usage and traffic patterns. MWM gives more flexibility on the dashboard configuration, as you can project any information collected by the service on the separate pane as a graph or list. Multiple dashboards can be added, and each can host up to 9 widgets.
A dashboard is the first presentation of the information, giving an overall status of the network and its client. The monitoring tab gives a more tabular view of the assets and network. There is no difference between the data store and displayed in the CV and MWM, apart from the presentation plane and WIPS, which currently not implemented in the CV. The monitor tab gives us a view on:
- status of managed devices (APs)
- status of each radio
- status of connected or known clients which have connection problems
- status of active SSIDs
- application traffic graphs
- status of configured tunnel interfaces
- alerts (which for needs to be configured first in the SYSTEM) based on the predefined events and thresholds.
What MWM does better in terms of monitoring, is a little bit more control on data, but this could be related to the missing WIPS part, as for example, in the CV you cannot set user device as an approved device (smartphones and tablets).
Nano is a mobile application, that gives remote control of access points and wireless networks from a streamlined workflow. It as well displays some of the WIPS events (major ones) that require an instant response.
Nano can be set up from different hidden SSID, to give administrators direct access to it, based on authenticated client redirection. It’s very limited in its capabilities, in comparison to the CV or MWM. It seems that it uses always root location, as I did not find any possibility to change it. Possible options currently:
- Turn SSIDs on/off
- Add new WiFi networks, but settings there are very basic (type, security, SSID scheduling, DHCP) – so probably only for rapid deployment
- See dashboard (active networks, active clients)
- See WIPS alerts (rouge networks)
Troubleshooting in CloudVision
One of the very cool features of CloudVision is embedded troubleshooting capabilities, which can be run directly from the customer journey, client monitoring section or from client view. We have the ability to get full packet capture and analyze it by ourselves or let Packets do that. Packet capture is not limited only to the clients who failed to associate fully with the network. It’s a great feature as you do need to cooperate with the end user to get full packet exchange. There two ways to get packet capture: manual or automatic, auto-packet traces can be enabled on per SSID basis and it will record packet captures of users who fail to connect.
As previously stated, Packets, if used to analyze WiFi packet, captures… and not only the once that were captured using CloudVision. Packets will process uploaded packets and plot all relevant (and known to the packet) information, of course, the raw data view is as well available. After it finished processing Packets will visualize client path and
Live Client Debugging
I view client live debugging as a combination of event logs and packet captures in the most appealing representation possible, the CLI style. It will give a list of what exactly happens when the customer tries to associate to the network. It enables us to troubleshoot clients connectivity issues. The documentation states, that there’s the possibility to run 10 simultaneously client debugging sessions.
Client Connectivity Test
For the AP models which has three radios, we can run a Client Connectivity Test, where AP will mimic the user and will try to connect to the selected AP on selected SSID, additionally, the various metric can be gathered using embedded iperf3. To do that, first, we need to create a test profile, which specifies frequency, used SSID and which test should be performed. The test can be run once or scheduled to be run daily, weekly, or on whatever timeslot is required… just don’t run it on the same timeslot where SSID scheduling is tested to disabled such SSID. While scheduling we need to specify which AP will take over the client role, and which AP will be tested. I think currently there’s no possibility in one test to perform one-to-many testing. After the test is finished, its results are stored in the cloud/VM, up to 50 connectivity tests are saved.
- Basic connectivity test – check if “client” can associate and authenticate, then measures response time from DHCP, DNS, and latency of LAN (gateway ping) and WAN (google.com ping).
- Application test – identifies the latencies to the predefined sets of applications/websites (productivity, social, communication), or configure custom one
- Productivity group: Office 365, Salesforce, Box, Google Drive, GitHub, ZenDesk, JIRA
- Social: Facebook, Twitter, LinkedIn, MySpace, Instagram
- Communication: Skype, Cisco WebEx, Goto Meetings, Slack, Yammer
- VoIP test – third radio of AP acts as a VoIP client and initiates a call on the target AP
- Throughput test – test WiFi and Internet throughput (upload and download speeds)
- WiFi test – uses iperf3
- Internet test – uses speedtest.net
Test results are displayed in the neat sectionized list, where quick status can be identified based on the dot color, and expanded if more information is needed.
It gives insight into the interference in the RF environment (including non-WiFi). Since it gives a graphical plot of both spectrums, it helps in identifying channels that are dense and ones that aren’t. Only tri-radio AP will support this feature.
Very important remark at the beginning of this paragraph: WIPS was not tested in order to not disturb the office network. Only it’s marking and classification features were enabled (which are enabled by default). Another additional important piece of information is that WIPS is only implemented in the MWM, it cannot be configured in the CV. From very basic, in computing, a wireless intrusion prevention system (WIPS) is a network device that monitors the radio spectrum for the presence of unauthorized access points (intrusion detection), and can automatically take countermeasures (intrusion prevention). It aims to detect and react to certain threats like:
- Rogue AP (Karma Attack) – an access point that is installed on a network but is not authorized for operation on that network, and this poses:
- APs attached to the LAN without permission
- backdoor to the enterprise network
- Soft AP – software-enabled access point and this consists of:
- network interface bridging
- ICS (internet connection sharing)
- ad-hoc connections
- evil-twin AP
- SSID vulnerability scanning
- connection to the rogue APs
- Misconfigured AP and users
The first requirement for the WIPS to work is to properly classify AP and users. To classify users, Arista (Mojo) uses their patented Marker Packet solution (US7970894), which is based on the active network scanning, instead of passive MAC address correlation. As far as I understand, the scanner will send a crafted broadcast packet on the LAN segment and listen for it in the “air”, then based on very simple assumption, if the device is on our network and is not authorized (managed by us), then it is rouge AP or soft AP. WIPS scanning can be done in two ways:
- background scanning
- real-time scanning
which will mainly impact the time of discovery of “threats”, since background scanning has to split it’s scanning time between working as an access point and working as a scanner. Because of that dedicated scanners, will always be more in favor of security latency.
Sadly I was not able to capture marker packet but I guess it would be some arbitrary packet, which you would normally see in the networks so that it cannot be easily blocked by the malicious device and break Rogue AP detection – policies that would block connections to the External APs should still work. Based on the initial classification devices are put into appropriate folders in the MWM. It is important to note that the Rogue AP category is sticky, which means that once an AP is moved to the Rogue folder it is never automatically removed from the Rogue folder, even if it is later detected as unwired to the enterprise network or its security settings change. This is not the case for the External APs, as AP in the External folder will be automatically removed from the External folder and moved to the appropriate folder if it is later detected as wired to the enterprise network. Authorized WLAN policies are used to initially identify Authorized APs, and constantly check that the actual Wi-Fi access parameters provisioned on the Authorized APs meet the security policy. Any mismatch is used to detect misconfigurations of the Wi-Fi access network. We can even configure isolated networks that are not allowed to have any Wi-Fi APs connected to them, which is called “No Wi-Fi”. If an AP at the location is connected to a “No Wi-Fi” network, it will be treated as a Rogue AP even if it matches an Authorized SSID policy applied at this location.
Clients are classified based on their association and this behavior can be configured where it is possible to put clients into specified baskets:
Category would be assigned to the client based on the type of AP/SSID they connect to, RSSI… and based on the Client Auto-classification settings. By default, only external and authorized clients are discovered, with externals being an initial category for all uncategorized clients.
When clients and AP are already categorized, WIPS can enforce configured policies, which will block specific category-to-category associations, for example: block authorized clients trying to associate to rogue AP.
Furthermore, we can configure additional devices that are banned from connecting to operated networks (Banned Device List) and lock configured locations, so that no new device could be added (authorized). For the transition phases or interoperability with the existing WLC based environment, there’s an option to configure integration with Aruba, Cisco, and HP MSM controllers. The integration allows our service to fetch information about managed AP from controllers and based on that automatically mark all AP discovered that way as authorized.
WIPS configuration (only from MWM):
- AP classification: Configuration → Authorized WLAN Policy; Configuration → AP Auto-classification
- Client classification: Configuration → Client Auto-classification
- WIPS: Configuration → Intrusion Prevention; Configuration → Intrusion Prevention Activation
WIPS can be monitored from two tabs (only from MWM):
- Monitoring → Security (APs, Clients, Networks)
Just to make this summary short and not extend this lengthy article, I will use simple bullet points.
What I did not like:
- Having two portals/applications (CloudVision/Wireless Manager) to configure the same service. I assume most of the problems I had was because I configured everything in both places.
- Having differences in features in those applications (WIPS), but when Arista would finalize CloudVision, I guess this two point will go away.
- Cloud lock-in, pricing model and features limitation (guest manager), makes it hard to use it in an enterprise network if the customer is not happy to use:
- Accept subscription model
- Whit the current state of documentation on the Web, I get an impression, not all Mojo content was published by Arista. But I know from a reliable source, that Arista is working on it.
What I like:
- Very easy and mostly intuitive to configure
- Great built-in tool-tips in CloudVision
- A number of statistics and metrics collected
- Built-in troubleshooting features
- Extensive guest portal features (which with dropping of social plugins will be less extensive, but still it’s mostly ‘must have’ for the retail customers)
- Maybe it’s irrelevant but Aware portal is just graphically appealing
- Dedicated scanning radio
Looking at the business model and what kind of data is currently gathered, I would say the main target for Mojo are Enterprise and Retail customers. However, Arista has a bigger ambition and wants to expand to other sectors as well (previously not aimed by Mojo), still rooted in the well-known controller-based solutions with (web) management system for central management (for example Cisco Prime).
|BMS||Bare Metal Server|
|CV||CloudVision (ex. Aware)|
|MGM||Mojo Guest Manager|
|MWM||Mojo Wireless Manager|
|WIPS||Wireless Intrusion Prevention System|