How to handle vendor code bugs in enterprise Wi-Fi networking
Too many features in Wi-Fi devices can breed some serious code bugs. One coping mechanism is to seek help from fellow customers and network integrators.
You bought high-end network design tools and invested in training to use the tools properly. You coordinated all the important logical connections and functional relationships to keep Wi-Fi, network switches, routers, authentication servers and other touchpoints in your environment working in harmony.
You update OSes and drivers methodically and have cultivated a network to be envied. It just works -- until it doesn't. When running large networks, you have limited control over one key aspect, and when it brings problems, it can be crippling. I'm talking about code bugs.
Features galore are a double-edged sword
The wireless networks you see in your Wi-Fi utility are just a piece of the overall networking puzzle. All the various components that make up the network require evermore complexity to deliver the features that vendors hope you'll use in return for positive results to their bottom lines.
Unfortunately, it doesn't always go so well. The standards and protocols involved are complicated enough, such as 802.11, 802.3, 802.1X, DNS, TCP/IP and so on. But the add-ons only magnify the complexity.
For example, have you ever turned off an optional feature because it caused more trouble than it was worth for your clients? And, to complicate matters further, did you know each vendor does band steering its own way?
Right now, Wi-Fi 6 products are shipping, and many environments have turned off most of the new magical features because of bugs on both the infrastructure and client sides. It can be a mess.
Be mindful of what features are actually enabled. Turn on new ones in a test environment first, but realize many bugs only show up at operational scale.
Tell me again why you're upgrading your code?
The best thing network professionals can give their users is high-performing stability. Unfortunately, code upgrades on various product sets can work against stability. It's fairly common to trade one set of code bugs for another set of bugs at upgrade time.
Sometimes, the code a vendor recommends to solve a problem creates worse problems. As a result, you find yourself playing code roulette, where you need to disruptively try a few versions and maybe craft a custom "engineering build" or two before you return to that all-important stability.
Your personal and organizational reputation should not suffer at the hands of bad code.
If you do upgrade, make sure it's for a compelling reason and not just to "keep up." There is no shame in being on years-old code if everyone using it is happy and there are no glaring security holes.
Release notes only go so far
In a perfect world, you could open the release notes for a specific code version and have a sense of how polished it is. In reality, that's just not the case. When release notes contain dozens or even hundreds of open and resolved caveats, it can be like looking through a fog.
But here's where the fun starts. Some vendors demand a professional services engagement to guide you through their bugs to find code that you can trust. If you ask your support engineer, you may get a different answer from tech support and from the vendor's own experts who participate in user community forums.
If you have access to a broader community of fellow customers, it could help to tap into what code versions are and are not working for other environments. Also, if you know network integrators who sell and install the systems you're struggling with, then ask them as well. Nothing is better than real-world perspective when dealing with code bugs.
Don't hold the vendor's bug bag
If you've ever been on the losing end of a truly painful code issue, you know the ramifications can stretch from end-user frustration all the way to the C-suite. Those of us who take pride in our networks usually want to own and solve all the problems -- it's what we do.
But, when the vendor hands you something that you have no hand in and cannot resolve yourself because of problematic code, make sure your organization knows where the fault lies. Your personal and organizational reputation should not suffer at the hands of bad code.
