I don’t have any hard statistics to back this up, but I’m willing to fake bet that at least 90% of Mist’s customer deployments use local breakout (LBO) or local bridging as the method of offloading Wi-Fi client traffic onto the wired network. If this is your first time seeing the term LBO, it’s essentially bridging traffic directly onto the switch port that the AP is connected to. It requires a L2 network where your client VLANs are available on the switch(es) that your AP(s) are connected to.
When working with networking vendors in this day and age, AI and ML are terms that are thrown around as features that add value to your team by proactively monitoring and alerting you of interesting or problematic things that may unknowingly exist in your environment. At face value, that sounds great! You don’t have to constantly check your network for issues because the system will bubble them up for you. And in an environment with close to 310,000 APs across multiple orgs and sites, it’s pretty much table stakes. The good news is that I’ve seen this work, as long as you’re checking those alerts because today, these systems will most likely alert, but not automatically remediate any of its findings. The remediation process still requires human intervention in most cases. However, what happens if the vendor’s AI/ML solution isn’t trained to find something in your environment that it should or something that you might be interested in looking at? That’s where knowing how to code and also work with APIs really comes in handy these days. I’m going to walk you through two different scenarios where writing my own code to leverage one of our WLAN vendor’s APIs led to insightful discoveries in our environment to help find a few needles in a massive haystack. One of the scenarios even led to the vendor implementing their own proactive checks into the platform which has sparked an auto RMA process for us.
Continue readingIn my current role, we sometimes receive complaints about the Wi-Fi being slow or not working properly. When we ask what the issue is, we’re often sent responses referring to speed test results only that are supposed to serve as the definitive proof that something’s wrong with the Wi-Fi. What our user base often doesn’t understand is that there are many variables when it comes to speed tests in general, but when running these speed tests while connected to Wi-Fi, even more variables exist. Let me try to explain.
Whether it be wired or Wi-Fi, there are theoretical and real-world throughput maximums in networking that are affected by a number of things. For example, even when you have a 1 Gbps wired connection, chances are you’ll never get full 1 Gbps line-rate speeds in a raw throughput test due to at minimum, the overhead needed to put bits onto the wire, not to mention whether the latency and TCP Window Size (if using TCP) can support the line-rate speed. Latency and the TCP Window Size are two things I’ll come back to in more detail later.
Continue readingMy employer is currently building a new home office (HO) campus. In every building except two infrastructure support buildings, we are installing Mist AP45s which are 6E capable. The two support buildings received AP43s which don’t support 6E, but are Wi-Fi 6 (802.11ax) capable and still very capable APs.
Why is that important? Well, as most if not all of you out there know by now, WPA3 is mandatory in 6 GHz. We haven’t deployed the AP45s in many places yet, so the new HO campus is an opportunity to really get our hands dirty with not just 6 GHz, but also WPA3-Enterprise on our corp WLAN and OWE on our guest WLAN to see how some of our client base would respond and operate. But Keith, didn’t you just say the support buildings had AP43s which don’t support 6 GHz operation? I did, but as I mentioned in the opening paragraph, they are 802.11ax capable and 802.11ax does support WPA3 which isn’t something we had broadly enabled yet in our environments up to this point!
Continue readingI’ve always been someone who has advocated for buying your own tools to test and troubleshoot things. This applied when I was working primarily as a network engineer focused on route/switch, datacenter, and security technologies and it still applies today, now that I’m primarily focused on wireless. In my experience, some companies and/or management are better than others with regards to buying tools for their employees so you cannot always rely on them for help. Investing in yourself and your learning is critical in my opinion so don’t let that deter you. It’s also nice to be able to take those tools with you if you decide to move on to “greener pastures” one day. Unfortunately, not all tools are what I consider to be affordable for the average person, especially if they are somewhat frugal like myself. Just do the best you can, when you can.
Continue reading