Product Review

Third party visibility into your Wi-Fi infrastructure

Posted on by Mike Bolitho

Wyebot presents at Mobility Field Day 10

It has been over a month since Anil Gupta, CTO and co-founder of Wyebot, presented at MFD-10 and there’s a good reason why I haven’t posted about them quite yet. I didn’t really have the time to get my hands on the sensors and dashboard. Over the holidays I had some time to play around with the sensor on my home network and man, I really like what they have to offer. Let’s get into it.

We’ll start out with the sensor. First off is the form factor, it’s about the same size as your typical indoor omi AP and it runs on .3at POE (mine is currently pulling 11.5W). There are three radios in each sensor. Two are fully passive for PACAPS and spectrum analysis. They will follow the nearest AP channels automatically or you can manually set it to follow a specific SSID or BSSID. The third radio is where you can select what flavor you need. There are Wi-Fi5, 6, and 6E capable options out there for you. The third radio is what they call multiple personality which allows you to perform passive scanning (especially important if you have a 6GHz capable network), wireless backhaul if you don’t have the ability to connect back to a switch, and third which is a whole host of network testing.

The test feature is where the device really starts to shine. It connects to your network via Wi-Fi and over the wire. It is capable of dot1x authentication on the Wi-Fi which is nice because you can actually test against your production WLANs rather than just a PSK test WLAN. You have 11 fully customizable test types available at this time. Tests can scheduled or run them on demand. My favorite so far is the video conferencing test that emulates a Zoom call. This is a great way to prove it’s not the wireless when you’re having Zoom issues on a single client, for example.

Something else I really like is the Link Doctor which gives you a quick snapshot of connectivity, DHCP performance, reachability to the gateway, DNS, and somewhere on the internet as well as resolving hostnames. All of these are customizable but out of the box reaches out to Google for most of these. It’s a super quick “at a glance” style visibility tool. All of the graphical output is also downloadable into reports you can provide clients or your stakeholders which is a really nice addition.

The last thing I want to touch on here is the PCAP function. There are tons of different ways to capture packets and we all have our favorites. I think where the Wyebot sensor brings a ton of advantage over some competitors in the space is with the rolling PCAP function. When capturing headers, you get about three days worth of data using internal storage alone. When paired with an encrypted USB micro SD adapter you can extend that out to several weeks depending on traffic. How many times have you received a call from someone on helpdesk telling you there’s a Wi-Fi problem that happened three days ago with no further information? It is extremely difficult to chase down some of these issues because you have to be sitting there with you capture device in hand and be lucky enough to have the failure happen at that moment. With the Wyebot, you can go back in time to snag the issue. I tested this by connecting to the network on my phone and then going back three hours later to pull the PCAPs and it worked perfectly. I was able to pull them into Wireshark and dig through.

The latest new addition to the Wyebot family is their client application. These app is currently available for Windows machines with a promise of MacOS, iOS, and Android coming soon. If you have ever played around with 7Signal’s Mobile Eye it is very similar. It provides you information from the client perspective which is invaluable data to have.

There are lots of other really cool features available to you on the dashboard and I encourage you to go watch their full presentation here. I mentioned above that there are a couple of vendors in the space and honestly, each of them have their advantages and disadvantages. I really like the easy plug-n-play setup of the Wyebot and especially the PCAP functionality. I think anyone running a large wireless network really does need third party visibility. I’m not saying our vendors are lying to us about the network in their own dashboards, but they can only tell us so much. When you’re using the same devices to test themselves they’re going to work better together. This is where the third party device comes in handy.

Cisco Presents at Mobility Field Day 10

Posted on by Mike Bolitho

At Mobility Field Day 10, Cisco presented on several new features and APs. It was a bit like drinking from a firehose. There are a lot of great things already in the ecosystem and a lot of exciting things to come. Rather than just recap the whole presentation (you can watch it here), I wanted to focus on one specific area. The Cloud-Enabled model of deploying wireless solutions.

There is a big rush to cloud management across the industry. There are several big-name vendors that are cloud first or cloud only. This isn’t a bad thing or wrong by any means. It’s just a different philosophy. Cisco continues to be an on-prem first model within the Catalyst ecosystem. If you want cloud managed, you have the Meraki line available. I think they both have their places depending on your business model and size. My place employment is a large hospital system and we are very much an on-prem first organization. However, it would be nice to have some of the features that Meraki has built in available to us. Enter the Cloud-Enabled/Hybrid option.

Cloud-enabled allows you to retain control on prem using Catalyst controllers while bringing in the cloud monitoring and troubleshooting tools available in the Dashboard to your fingertips. In my opinion, this is a huge win especially for larger companies with more siloed teams. With the Meraki Dashboard you have a single pane of glass for delivery assurance, troubleshooting, and performance monitoring. This takes a lot of easier tickets off of the wireless SME’s desk and keeps it down at your helpdesk or tier 1 support. A few low hanging fruit issues that can be quickly identified as well as a couple of new features:

  • Event correlation and monitoring
  • Problem analysis looking for larger root cause issues impacting wireless
  • Performance, utilization, and capacity monitoring
  • Change tracking and configuration drift analysis
  • API integration for easy data exfiltration

Another added value is Catalyst and Meraki in the same place. We deploy Meraki in a few smaller sites and now we can see those sites in the same place as our traditional on-prem controllers. This is a pretty big value add for me since we do have some Meraki deployments.

“But Mike, what about licensing costs?” Ah, no worries! Your existing DNA licenses allow for Dashboard integration so you don’t have that concern.

“Is this a replacement for Catalyst Center (the management platform formally known as DNAC)?” No, this is mostly for easy and quick monitoring and troubleshooting. Catalyst Center and Assurance still have their place for deeper dives and more complex device configuration and management.

“What requirements are there to put my 9800 into the Dashboard?” I’m glad you asked. You need to be on 17.12.3 or 17.15.1 or later in order to put them into Dashboard monitoring. There is also a max of 2,000 APs and 20,000 clients per controller. You also need to make sure your MRs and Catalyst APs are in different “Dashboard Networks”. If you’re familiar with Meraki, this is pretty straight forward.

“How difficult is it to integrate my 9800?” It’s as easy as creating a new network in Dashboard and using the device ID you pull from your 9800 to adopt the device. It’s basically exactly like adopting Meraki devices. Very straight forward, especially if you have Meraki experience.

A couple of quick takeaways for me. I’m really excited to get a pair of lab 8900s up to 17.12.3 to drop them into the Dashboard. I’m looking forward to providing another tool for our operations group to efficiently troubleshoot “Wi-Fi issues”. It will also be nice to monitor the overall health of different hospitals at a quick glance. My job is primarily design and deployment on projects but I do get pulled into a lot of t-shooting calls. Sometimes those things are pretty simple, and while I don’t mind helping out and training up folks, I would prefer to keep that time dedicated to other things.

What are your thoughts? If you currently deploy Catalyst controllers do you plan on adding them to Dashboard for monitoring?

The Dashboard presentation can be found here.