Tag Archives: WLAN

The Importance of the GGOOE In Cloud-Managed Networking

If you already do cloud managed Wi-Fi or WAN/LAN, you know the value of the GGOOE. If you’re thinking about making the jump to the likes of Aerohive or Meraki for far-off sites, you better make sure you line up a GGOOE, I’ve pulled off some pretty slick networking projects hundreds of miles away and across oceans, but just as much credit goes to the GGOOE.

What’s a GGOOE, you ask? It’s the incredibly valuable Good Guy On Other End, unless it happens to be the Good Gal On Other End. 

The GGOOE is indispensable for cloud network projects, and I salute them. For me, the GGOOEs in my world are named Marco, Kevin, the other Kevin, Fabio, and Patti. They are the right eyes, hands, and minds on the other side of a cloud-managed network that make what I designed stay healthy, or in some cases, to get implemented at all.

Here’s a few real-world examples of the importance of the GGOOE factor:

  • Bringin’ it to Jolly Old. A few years back, I took a leap of faith and did a little project in London. The results have stood the test of time, and our first brush with cloud-managed networking was a smashing success. When I went over, I didn’t know the site or any of the people, but a GGOOE named Marco happened to be there. During installation, he was my right hand man. Three-plus years later, he’s the on-premise resource that shares network administrative duties and guides the day-to-day operations, responding to power issues, the rare user problem, and making sure that the network continues to serve the operational need. 
  • Rocky Mountain High. Well, this has nothing to do with the Rocky Mountains (my clever bullet point hooked you though, didn’t it?), but it is in New York’s Adirondacks. Having gotten comfortable with the benefits of cloud networking, I headed a small team that made a beautiful place a little nicer with a network environment that shines, and that can be managed from the same dashboard I use for London. The GGOOE here? A dude named Kevin (and when he’s not around, alternate GGOOE Amber). Being out in God’s Country, the site is subject to wonky power and DSL service. Kevin and Amber never hesitate when asked to reset a DSL modem, check the power status in a building, or whatever. The GGOOE keeps it going, baby.
  • Parli nuvola, bambino? In the most brash exploitation of the GGOOE factor to date, I just popped up a 5-building LAN and WLAN topology in Italy that is currently serving hundreds of clients a day.

Or did I? 

I certainly conceived the design and selected the product set, but this cloud-managed network came to life 4,000 miles away without me ever getting on an airplane. Yeah- you guessed it: there was GGOOE action on the far end. Kevin and Fabio formed the two-man GGOOE team that made my diagrams and cloud-configs come to life at the physical layer, and will provide ongoing GGOOE service as needed. Life is friggin’ sweet, thanks to GGOOEs.

The examples go on on and on. Like with GGOOE Patti in NYC who has far bigger fish to fry in her role as an Executive Director. But when we Upstate need help with our environment Downstate, it’s Patti that we go to and Patti who helps- every time. 

Make Good Choices 

Here’s what’s really cool about the GGOOEs in my world: none of them are really network people. Some of them aren’t even IT people. But they’re smart, team-oriented, and get the value of being a clear mind and directable hands where needed.

That being said, I have an obligation to make choices that enable the success of my Good Guys On Other End. If I put together a crappy solution and leave them holding the bag, I end up with F(rustrated)GOOEs.

And that’s not good for them, me, or the clients that we all support.

What about you- do you have a GGOOE that you rely on?

Ethernet Is Done. It’s Time To Get Serious About Wireless.

Did you happen to see the PR on the Microsoft Surface Pro 3?


Evidently, there is a killer among us. A laptop killer. Laptops have Ethernet ports. If Microsoft’s new $800 assassin kills the laptop, it also kills the laptop’s Ethernet port. Goodbye, Ethernet, we hardly knew ye. Don’t let the door hit you in the ass.

As I look around at the many computing devices I have in my immediate vicinity, I see other models that have already started chipping away at the TRADITIONAL laptop’s tenure, like these:


For the record, that’s an iPad, a Chromebook, a Nexus 7, and a MacBook Air. Nary a one of them has an Ethernet port…

This is where some of you are thinking “Lee, you’re daft. Microsoft is touting the Surface Pro 3 as a laptop killer, not an Ethernet killer”. And though you’re right on that point, there is a nuance here that should be appreciated. 

There’s a certain significance to Microsoft trying to “kill” laptops with it’s new tablet (of course, you need to buy the add-on keyboard if you want to actually put bullets in the gun that will do the killing, in this case). Why? Well, because for the last several computing millennia, Microsoft has gotten fat off of it’s operating systems running on… wait for it…laptops! With the messaging that accompanies the Surface 3, MS is saying “we now commit our client access future to the tablet.” And tablets don’t have Ethernet adapters.

Right now, the client access world (forget about game consoles and the whole IoT malarkey for now, we’re talking “people clients” here) features:

  • Smartphones
  • Tablets
  • Laptops
  • Desktops
  • Thin clients

And not much else. Though desktops and thin clients typically are connected via Ethernet, they certainly don’t have to be as there are a range of wireless adapter options in this space. And if Microsoft fulfills its (rather silly) prophecy of making laptops extinct, the list of devices that come with stock Ethernet capabilities shrinks even further. To me, when I add a keyboard to a Surface 3, it just became a laptop again. But now it’s like the Chromebook and MacBook Air; a laptop with no Ethernet.

None of this rises to the level of epiphany, I realize. At the same time, Microsoft’s message that it’s willing to contribute to the erosion of Ethernet by killing off a class of device that ships with Ethernet adapters in favor of another class that doesn’t is worth holding up to the light and contemplating. For many of us, Ethernet switches have already become glorified VLAN-capable power blocks for our wireless access points. And I personally can’t recall the last time I’ve plugged a laptop into the wall to get on the network.

History will show that The Age of Mobility and The Age of Ethernet For Access absolutely had to have had overlap as technology evolves. But it’s interesting that Microsoft is beating a drum pretty loudly that leads further away from the wire and deeper into wireless.

Whether the Surface Pro 3 sells well or not is almost irrelevant, in my mind. It’s the message that comes with it that means our WLAN environments just got that much more important to network users. This should resonate with network designers, helpdesks, and bean counters alike. 

Interesting times…




Contemplating Lofty WLAN Things To Come

Don’t think me pie-eyed, or off-kilter. The following comes from having a good long break at the holidays, crappy weather, and lots of books to read. Books on wireless. Books on Software Defined Networking. Books on IPv6. Management books. Some cloud networking articles. And a book about American nurses and medics trapped behind enemy lines in Albania during WWII. (OK, that last one has nothing to do with this post.) Put it all together, and dare to let the mind wander forward… and you may start feeling the same dull, painful throb in the head that I’m feeling.

Why the angst on my part? I’m a WLAN architect, system admin, troubleshooter, advocate, defender, and realist. I’m also a network engineer that has to have a solid grasp of things on the wired side of the enterprise. I’m fairly innovative, and regularly have to create solutions where there are no obvious solutions to be had, and also am trusted to know where creativity ends and folly starts. I love my work, and also am cursed/blessed with being a big picture guy.

My boss is rightfully pushing my colleagues and I to get up to snuff on SDN. Like many, we’re starting with a Data Center-centric SDN philosophy as we get used to the idea. We’re also pecking at IPv6, despite artfully using private IP addresses, short DHCP lease times, and the occasional NAT for efficient preservation of our Class B network (yes, I know IPv6 isn’t just about IP address counts). We’ve ventured into the cloud a bit for various things, and are individuals in an organization that know why, how and when to evolve (personally and a s a team) for the most part. It’s an absolutely fascinating time to be a networker, given the new technologies at hand. Each of us that like what we do should thank the IT Gods for letting us be witnesses to this transformative period in networking history.

Yet my head hurts.

I think I can boil it down to this: if you contemplate out a few years, it’s really hard to see where all of the “new stuff” comes together, at least for me right now. To bulletize the comets of thought shooting through the night sky of my cabin-fevered mind:

  • IPv6 is mature, and has been in development/trials for some time. It’s “standards based”, and once you learn the basics, the scariness fades.
  • IPv6 on big wireless systems? Not so clear cut, and largely dependent on the WLAN vendor, their version of code, and which way the wind is blowing today.
  • SDN got it’s start as better way to do Data Center networking, then the adventurous dared to stretch the paradigm out into the LAN as well. But where LAN meets WLAN, even in this age of “unified networking”, the end-to-end SDN crystal ball gets muddy.
  • SDN is quite immature. It may shake out as well-designed framework built on standards (akin to Ethernet or TCP/IP) or it may fragment and get as ugly from the “every man for himself” perspective as how WLAN vendors do things under the hood.
  • The Cloud is becoming more acceptable for WLAN management and Networking-as-a-Service, yet it can still feel like a one-off depending on how you implement and how far you go with it.
  • WLAN and mobile networks are very much cutting into Ethernet’s turf, yet there are pockets where Ethernet will likely stay predominant for many years- even if Wi-Fi surrounds the corded network devices.
  • There are things more easily done on the LAN (multicast, for example) that WLAN vendors and engineers still struggle with doing- without causing other problems.
  • As we approach the heyday of 802.11ac, we’re still trying to sort out hype from reality and the WLAN industry continues to flat-out botch the message on how to cable for 11ac and what comes after Wave 2 (you may disagree), which complicates planning in large environments.
  • The WLAN industry is sooooo silo’d and proprietary right now. System A is not compatible with Systems B or C, and and every vendor has their own way of doing things from the AP’s antenna stub back into the WLAN core pieces.
  • Unification of wired and wireless is at different places for different vendors, not all WLAN vendors have switches, and where a vendor has both it again gets funky for interoperability.
  • With data breaches aplenty happening and bound to happen as mobile device counts skyrocket and everything gets connected to something that has a target on it’s back, more regulatory influences are no doubt coming to a network near you.

Gone are the days when a big box connected to a bunch of Ethernet switches that connected to a handful of APs, and the entire thing was easily diagrammed out and explained as a single system.  This I know.

I also know that coming is a time where wired and wireless aren’t so delineated, where SDN reaches across the LAN-WLAN airgap, where it all runs on IPv6 (with implementation and feature parity across the vendor landscape) and big parts of it may be in or managed by the cloud. There’s an assumption that one day it’ll all be truly seamless, any and all applications will run and configure the same on both sides of the LAN/WLAN continental divide, and it’ll be so well designed that even the office secretary can manage the Enterprise without knowing anything of underlays, overlays, Dual-Stack Pattywacks, distributed or centralized Fruited Planes, address lengths, spatial stream counts, or any of the other network marshmallows in our new bowl of Lucky Charms.  

I know it’s inevitable, but my mind just can’t yet grasp how (or when) it’ll all come together.

Ah well- too much daydreaming can be a bad thing… time to go shovel the driveway.


Mersive’s Solstice- A Nice Alternative To Complicated Presentation Paradigms

UPDATE: https://wirednot.wordpress.com/2014/02/20/so-close-yet-so-far-with-mersives-solstice/ my take on Mersive’s pricing.

Mersive is a company that only recently made it to my radar, but I’m glad they did. I covered their interesting Solstice product for Network Computing back in March ’13, and was so smitten with the promise of what Solstice could do that I nominated them for Best of Interop award consideration. Fast forward to today, and I’m liking Solstice more, as it has gained some polish and added features.

Here’s a quick summary of the problem that Solstice solves, as I see it: since wireless became mainstream, users have wanted to walk into a projector/display-equipped room and quickly mirror the screen on their laptop, tablet, or smartphone to the in-room display for all to see.

Options to accomplish this have been clunky at best. There are ad-hoc wireless connection protocols and thingys that don’t play well in the enterprise for a number of reasons, and that paint the single user that might leverage them into a corner of sorts where they can only project (usually while causing interference to the corporate WLAN) and not be on “the network” at the same time. There are new Wi-Fi direct hardware options that also create odd little islands of radio noise where used. Then there is Bonjour, the limited, dated protocol that requires what I consider to be ugly rejiggering of the LAN/WLAN to make desired display functions work only for select Apple devices.

In other words, there has not been an easy-to-implement, OS and network friendly (and agnostic) way to solve the simple paradigm of letting users show what’s displayed on their devices on the big screen without plugging in.

Back to Mersive and Solstice.

The cats at Mersive are computer scientists and display experts that understand getting pixels where they need to be, and generally don’t give a rip about hardware. Mersive’s software magic powers most of the biggest, most impressive video walls you’re ever likely to see, and they approach the boardroom/classroom display problem differently from all of the clunky alternatives that came before.

If the goals are:

  • Require no additional hardware
  • No network changes and make it work across subnet boundaries (piss off, Bonjour)
  • Let any mainstream OS project to the central room display
  • Don’t let the users in one room hose their neighbor’s display
  • Make it simple to use
  • Keep it affordable

Then Solstice’s latest (1.2.1) hits the mark *almost* perfectly. I have been experimenting with it for a couple of weeks, and like what I see. I have the server software installed on my mocked-up “podium PC”, and free Solstice app software on several Android and iOS mobiles, along with Win 7 and 8 laptops all on different wired and wireless subnets on the same network.

And it just works.

There is the briefest of learning curves, excellent documentation, adequate security, and it all is simply an add-on to what you already have for network topology. Specify the name or IP address of the Display server from the client device, hit “connect”, and display away. Reliably,  for both pictures and video, or for the whole device desktop.

You can get a little fancier with Solstice’s operation, and allow for several users to collaborate by all projecting their content to a common display simultaneously (it is touted as a collaboration tool) and do a few other advanced options that may or may not fit for individual use cases.

Though I am only  kicking the tires right now, I can say that after years of fighting the display paradigm fight, I have found the best weapon I personally have ever seen in Solstice.

Did I mention that you don’t have to touch the network to make it work?

It’s not cheap at list price of $3,500 per server instance, but then again, this is a quality solution that instantly takes care of a number of display headaches.

Oh yeah- and you don’t have to touch the network. Me so happy.

Look A Bit Beyond WLAN RF

The RF part of wireless networking is often what keeps good IT folks from really getting proficient with WLAN, and many good WLAN types never look beyond the frequency ranges used in 802.11 technologies to see the bigger RF world that we live in. It’s understandable, especially for those without some sort of professional or hobbyist background with signals. The world of WLAN spectrum can be hard enough to wrap your head around, but every now and then there is value in seeing the bigger “comms” picture. The more you understand about the way different frequencies behave in the most basic sense (and what services use those frequencies) the more comfortable you’ll become with really understanding the more mysterious parts of both access-type WLAN and point-to-point bridging.

There are masters’-level classes on RF and radio technologies, tech training courses, and infinite online tutorials and calculators covering all the variety that falls under the broad heading of “learning about RF and RF systems”. This is one of those areas that you never, ever stop learning about. And once the bug bites, it’s not uncommon to become a radio-technology junkie who’s interested in far more than just the goings on in the 2.4 and 5 GHz slices of the electromagnetic spectrum.

Let’s look at just a bit of information on “commonly used” frequencies:

  • How long are their wavelengths
  • What are their natural “free space path loss” characteristics (how they “fade”)
  • At a common power and antenna config, how do they behave compared to each other?

Sounds like heady stuff, yes? It’s really not that bad- so stay with me here.

The following frequencies have meaning to me, and certainly to many of you as well. I’ll give you the wavelength of each, and tell you how much the signal fades after 1 km based on these values applied to each frequency:

      • 100 mW (or 20 dBm) of power
      • Simple 3 dB antenna at the transmitter and receiver

Whether the signal would be usable (any signal left after path loss)


(Table created by me, there is some minor rounding done)

Again, we see that with same power and antenna gain/sensitivity, the frequency in play makes a dramatic difference to what’s available (or not) at the receiving end.

The frequency is a product of wavelength;  the lower the frequency gets, the longer the wavelength is. Lower frequencies also tend to require bigger antennas.

But this little exercise is of limited practical value, beyond helping to understand basic aspects of RF behavior at each of the frequencies I chose to show. High gain antennas, increased power levels (some technologies like Wi-Fi are limited to miniscule power levels while other technologies measure their outputs in Kilowatts), and environmental factors all influence the basic RF goings on at each frequency. Modulation types, quality of engineering, CPU and other silicon behind each given technology all also define performance of whatever technology is in play for a given spectrum. As I mentioned before, it does get complicated.

One of my favorite communications-oriented RF tutorial sites is at National Instruments. Although the American Radio Relay League (ARRL) is often thought of as a ham radio organization, they have a wealth of resources on all sorts of RF-related technologies and industry happenings.

If you’ve never built an antenna of some sort or another, you should. Whether it be a simple project for Over the Air TV or something weird for wireless penetration testing, its worth doing at least once. Research it, build it, improve upon it, and see how altering it changes the performance of whatever your application is (could be using a scanner to hear the local police comms or doing your own point to point wireless bridging), it’s fascinating to design and build something RF-related, at least once. You’ll find that seemingly unrelated wireless disciplines really do enhance the understanding of the actual wireless part of wireless networking.

Wireless Standards Just Aren’t Enough

First the love:

Anyone in the wireless game, like really in it, knows that wireless networking is incredibly complicated under the hood. That the IEEE and the Wi-Fi Alliance could herd enough cats to get us to where we are today- enjoying our 11ac honeymoon- far from the days of early 802.11 is amazing.

Let’s pause for a moment and think about how far we’ve really come, because it is impressive indeed. From a technology that was an expensive accessory at one point, with low data rates, high prices, and anemic security, to being the preferred method of access today for most of us, with rates and security features that are fitting for any environment (when installed right), wireless has grown up.  A huge thank you to everyone involved, as you’ve given me the best job in the world- that of a WLAN professional.

Now the lament:

As impressive as the modern WLAN is, somehow we ended up with some crazy market fragmentation and mindsets. Even though interoperability testing mostly keeps the wireless train on the rails, we still end up with enough in-place chaos to make life pretty miserable for wireless clients and support staff at times.

Maybe we try too hard for backwards compatibility. Perhaps device makers are lazy or out of touch, or could it be that the BYOD comet just hasn’t caused enough pain to really get everyone’s attention? For sure, the fuzzy, often-bludgeoned distinction between consumer and enterprise-grade components doesn’t help matters.  Here’s what I mean:

– In a world where we’re talking about “Gigabit Wireless”, we still have device and instrument manufacturers churning out chipsets that need 1 and 2 Mbps data rates to behave right. These devices are frequently intended for networks that aren’t likely to have those rates enabled.

– Printer manufacturers have far deeper roots in the business environment than does wireless. Yet, we can’t get printer makers to understand what their devices need to do for desired functionality on the “business WLAN”.

– What we call BYOD is actually BYOD/T; that is bring your own device AND TOYS to the WLAN. If it works at home on the living room network, you know damn well people are going to want to use them at work. Like AppleTVs and Google Chromecasts. To the uninitiated, you look at the specs on the packaging and see “compatible with 802.11n/g” or whatever, and jump to the conclusion that it must work because that’s the kind of network we’re using. The  warning label that should say “check with your networking department before buying this for office use” never makes it to the packaging.

But… rather than having to explain to users why this gadget or that can’t work on the WLAN, or killing ourselves to put in hyper-complex, house-of-cards-quality work-arounds, wouldn’t it be nice if somehow the Community of Wireless Client Device Makers could get with the times and build compatibility for both consumer and enterprise networks in to begin with?

Just supporting enterprise security would help immensely, and likely add little to the device cost. (I’m astounded at how out of touch the business printer/projector makers seem to be). There are certainly other nuts to crack as well before everything is perfect between the WLAN and BYOD/T devices, and Apple could be an absolute leader here. Bonjour has long had it’s day, as I’ve bitched to anyone who will listen.  “Apple TV is perfect for the boardroom” provided that you have one small flat network and one boardroom. But when you have hundreds of boardrooms/classrooms and complicated LAN topologies, devices like the Apple TV are a supreme pain in the assbone. If Apple could do right by the customers who continue to fatten the company’s immense bottom line and give us something better than Bonjour for their devices in the workplace, maybe other device makers would follow suit. (Did you know that higher ed is begging Apple to provide relief from Bonjour headaches?)

Maybe we need tighter “categories” from the Wi-Fi Alliance- with devices that are labeled either “Enterprise Ready” or “Consumer Grade”. This would give incentive for the lower-end stuff (including Apple’s Bonjour-based devices) to step it up. It would also give a clean delineation for networkers to point to for device support. If done right, We could say “if it’s got the Enterprise-ready label, we support it” and if not, don’t bother bringing to us. Everyone would know where they stand, as the criteria that goes into an “Enterprise Ready” compatibility testing program would be based on far more than just whether radios can talk to each other. It’s a nice thought anyways.

Ah well- end of rant. Now if you’ll excuse me, I have to go explain why Chromecast doesn’t work on our 802.1x-based WLAN.

What Meru and Xirrus Need to Do

I’m not a big deal, but I know a guy who is. And- I have pulled off San Jose’s most brazen balloon theft. These two facts combined qualify me to advise multi-national wireless networking companies on communications strategies. Here’s my advice for Meru and Xirrus, after visiting with both companies for Wireless Field Day 5.

Both companies are headed by obviously intelligent technologists who are passionate about their product lines. Each has well-spoken customers willing to testify on the effectiveness of their gear. Both are still in business in a pretty competitive space, and hoping to grow their shares of the WLAN market. And both have unique technical stories that set them apart from their industry peers.

And here is the problem.

For years, I’ve listened to a number of briefings with Meru and Xirrus and always walked away with a nagging sense that each is actually a bit uncomfortable talking about their  “specialness” to any depth when dealing with Classically Trained WLAN Types. Xirrus does the array thing, and Meru rocks the single-channel architecture groove. Both companies want to talk about their bigger stories, but many of us don’t feel satisfied with terse “trust us, it works” explanations on features that are radically different from industry norms. So… briefings grind to a halt because tech-analysts want to know why we should accept that these companies have actually found a different way to do things. But the companies’ speakers obviously don’t want to spend their camera time on these years-controversial details, and neither party quite feels great at the end of the experience.

And here’s the fix.

There’s certainly a fine line between disclosing intellectual property and being open with those asking pointed questions about your technology. But that line needs to be walked when you build product lines on unique technical approaches. Sam Clements and Keith Parsons are well within their professional purview to challenge Xirrus on how they can pack so many antennas into such a little box without them creaming each other, especially when other vendors sometimes bash Xirrus for their designs. And Chis Lyttle is proper in asking a few times for more info on Meru’s “special sauce” even if it slows down Meru’s onboarding demo. Tech people want to hear what tech people want to hear, and neither company tends to want to get into the nitty gritty that would get us all to shut up already and let them get our full attention on their latest announcements.

Each company should embrace the living hell out of their uniqueness. Lead with it, don’t tap-dance around it. Stick it in our faces with good, digestible white papers and diagrams that clear up the mysteries once and for all without giving away IP. That way, when we all get together again, Xirrus and Meru can not only deliver the Message of the Day, but actually get us to listen to it instead of badgering them for information on the little things they do that many of us have been trying to comprehend for years.

We’d all be better for it, especially Meru and Xirrus.

Wireless Is So Not About Wireless Networking Anymore

Lee you fool, you’ve gone mad. How can wireless not be “about” wireless? 

Before you run off to another blog, let me clarify: today, as we stand in THIS SPOT in the wireless networking universe, never has the WLAN paradigm been so complicated. Yeah, we still need to get APs out there and provide access to wireless clients, but sitting through the sessions at Wireless Field Day 5 has me waxing philosophical. 

Like frogs in a pot, we’ve all been slowly boiling in increasingly complex waters over the last few wireless years, and it’s easy to not notice that it’s happening. Having sat through excellent sessions with WLAN vendors (Aerohive, AirTight, and Motorola- with Xirrus and Meru on deck) and toolmakers (Fluke Networks, MetaGeek, and WildPackets- with 7Signal later today), it’s safe to say that to be in the wireless game today means being more diversified in skills and general IT sensibility than ever before. 

As the 11ac tide starts to rise, we’re all faced with decisions:

  • When do we start taking our own networks to 11ac?
  • When do advise our customers to move to 11ac?
  • Is moving to 11ac a given for everyone?
  • Is 11ac the juncture where we consider changing WLAN vendors?
  • Is 11ac the juncture where we look more at cloud-managed options?”

These are easy enough to grasp, and behind each of these questions there are other questions regarding the states of our installed network wiring, what generation switches we’re running, what version of PoE we’re on, etc. But these issues are rather pedestrian compared to what else is afoot right now under the umbrella heading of “wireless networking”.

While marketing departments still like to lead with “we have the best APs! Look how freakin’ fast we are!”, there is a lot more to consider as our WLANs modernize.

Along with the radio technology and bandwidth sides of 11ac, we’re facing an onslaught of factors to grapple with- like:

  • a slew of analytical capabilities and ways to use that data
  • device onboarding that can be as nuanced as your mind can dream up
  • the ability to assign access privileges to device types, user types, application types, locations, times of day, and combinations of any and all of these
  •  application visibility and taking action on what you see
  • the system administration of complicated management systems that frequently fall on WLAN types (somebody has to keep them up)
  • the increased number of bugs that come with the floodwaters of new features
  • a procession of ancillary services and servers that don’t directly have anything to do with client devices talking to APs, yet each is part of the bigger picture

You can make the point that none of these really have anything to do with 11ac per se and are better suited for policy and staffing discussions, but here are my counter points to that:

  • To “go” to 11ac, you likely have to upgrade code on controllers, management systems, or whatever magic is afoot in cloudland
  • When you upgrade, you get lots and lots of features that you didn’t ask for- you’re already buying them (unless they take stand-alone licensing, which is its own story in inconstancy across vendors)
  • The more features you use, the more you have to troubloeshoot, debug, define policy for, educate users and support staff on, and watch over for issues
  • The ancillary services in use for our WLANs frequently take more effort to keep on the rails than the wireless environment itself does
  • Almost any part of the environment has the ability to convince users that the WLAN itself is borked, when the problem may actually be off in the hinterlands of the ecosystem 

Put it all another way- 11ac makes WLAN more complicated, but the accompanying backdrops and backstories of our networks are also getting dizzyingly busier. So busy in fact that they can make talking about 11ac itself seem like the easy part of the equation.

I’m not bitching, mind you- but just taking note. These are complicated times for wireless networkers, and sometimes “wireless” really has nothing to do with wireless.


Bluesocket Lives, Evolves Into Managed WLAN Services Offering Under ADTRAN

Back in the day, Bluesocket was THE commercial captive portal for wireless networks. As WLAN in general gained broader acceptance and the market widened, Bluesocket also started providing access points and morphed their captive portal appliance into a controller (like the WLAN big guns were starting to use with thin APs.) As this was playing out, Cisco, Aruba, and at the time Meru, were largely dominating the market and Bluesocket  didn’t generate a lot of buzz anymore. But- nor were they “over”.

My Own Bluesocket History

I have covered Bluesocket through the years for my column in Network Computing, like when the company introduced their initial controller offering, and then their virtual controller option. Network Computing also covered ADTRAN’s acquisition of Bluesocket in a piece done by colleague Steve Wexler.

On the personal front, I helped pre-ADTRAN Bluesocket develop a new guest access feature set that perfectly fit the needs of my University when our native Cisco wireless guest option was anemic by comparison. To this day we still  use the Bluesocket portal for guests, and though it may be a bit dated, it still has amazing administrative flexibility and works great for letting guests self-sponsor or be sponsored based on cell phone number as user name. (I made more than one plea for both Bluesocket and ADTRAN to spin this off as a separate product but they didn’t bite.)

Bluesocket also donated controllers that I took to Haiti on a humanitarian IT visit  that serve as the functional heart of two networks on University of Haiti campuses that me and my fellow volunteers created.

You could say I have a bit of a soft spot for Bluesocket given my history with the company and their products.  But after the ADTRAN acquisition, the already small player in the WLAN space seemed to get even quieter. But wait…

With their latest announcement, ADTRAN’s Bluesocket may be on to bigger things.

Following similar recent announcements by Meraki and PowerCloud, Bluesocket is throwing their hat into into the cloud-managed hosted WLAN ring.

ADTRAN calls their new offering ProCloud, and it hopes to empower channel partners, integrators, and service providers with the ability to provide hosted enterprise-grade WLAN offerings to customers built on established the Bluesocket vWLAN magic-in-the middle.

Also announced are ProStart (installation, service, and training for customers that can’t do their own wireless for whatever reason)  and ProCare (customer-selectable maintenance support options.)

See ADTRAN’s page on ProCloud,     and Business Wire press release.

Wireless is certainly a competitive landscape to begin with, and the expanding managed WLAN pot is starting to simmer with interesting players jumping in.  Though I get that ADTRAN and competitors see the hosted WLAN thing as an easy service-add for partners that don’t yet really offer wireless, I hope those who follow this path all don’t lose site of the fact that “easy wireless” doesn’t  automatically equal “good wireless” and that proper design and policy are still the cornerstones of successful WLAN.

I wish ADTRAN and my old Bluesocket friends best of luck in their new venture, and I’m sure I’m not the only one who will be following how managed wireless services will impact our industry.

Pondering WLAN Innovation

The modern wireless network, regardless of who creates the components, is certainly getting complicated. But is it innovative?

Asked another way- does sheer complexity equal innovation? And who decides what constitutes an innovative feature or component? Is it the vendor? The customer? A developer thousands of miles away from both?

Here’s where I pause, and assure readers that what follows is not meant to bash any company, I’m simply pondering what innovation means to today’s WLAN, and whether it couldn’t perhaps be stewarded along a bit more collaboratively as the world gets increasingly more dependent on the fruits of our wireless labor and our systems get fatter with features.

There are a lot of definitions of Innovation, and some pretty fascinating reads on the topic. For the purpose of what’s on my mind, I’ll call innovation a good idea that serves customers well with some meaningful market duration while making the originator a profit. Simple enough. If I had to give innovation a formula, it might look like:

(Good Idea + Customer Acceptance) x (Time on Market + Affordability) =  Amount of Innovation
Or something like that.

Back to the question of who decides what constitutes innovation? If a new feature or product is marketed as “an innovative new offering”, my first thought would be “how do you know it’s innovative if it hasn’t proven itself in the market yet?” Time judges innovation, not the person who came up with the idea. Sure, HP’s TouchPad was an engineering accomplishment, but if it was really innovative, it wouldn’t have tanked, would it have? Or maybe it’s too harsh to say that “failed innovations weren’t really innovative after all” (Perhaps some would-be innovations come along at the wrong time- again, I’m just pondering.)  Whatever- it’s heady stuff to contemplate at the analytic level.

Back to wireless networking. I look at some of the systems I use (both for client access and WLAN management) and see a mix of innovation and feature bloat. Sure, there are nice aspects that bring value to the typical customer, but also ill-conceived features that obviously were never presented to a WLAN Admin Focus Group. Because they are all packaged together, you have have to tolerate the non-innovative distracting stuff to get into the innovative features, It’s just the nature of the beast. Maybe this overall affect could be improved. Maybe we should start hyping BYOI as much as we hype BYOD.

What’s BYOI? It’s Bring Your Own Innovation- and we need more portals for it between customers and WLAN makers.

Wireless network administrators know what they need. Arguably, they can be serve as the advisory panel for features likely to be good innovations, and also judges for when an innovation has “expired” and needs to be replaced (why I am thinking of Apple’s Bonjour protocol?) Sure, vendors give us hyper-complicated systems bursting with graphics and endless menus, but that doesn’t mean we’ve been given innovation. And innovations don’t have to be crazy disruptive and life-altering for the entire WLAN space, they can just be simple little changes that we’d buy more of because they are needed.

Without a clearly defined method of getting feedback and feature requests to decision makers within WLAN companies, it is my conjecture that innovation suffers. Meraki came close to getting it right with their Make a Wish mechanism (i remember being thrilled when I asked for alerting on DHCP pool exhaustion and then it showed up shortly after), but even after I made my wish, there was no way of knowing whether it was heard. Or whether others had asked for it as well. For many big companies, the culture seems to be “you the customer can just wait for us to innovate on your behalf, and if you feel like getting frustrated feel free to talk to your SE who also has no clue what’s coming”. Again- no bashing; the WLAN industry is generally amazing. But some of us would like to influence the innovation we pay for and help the mothership to realize when they get it wrong in the name of innovation.

Wouldn’t it be cool if each vendor (or the industry itself) had a portal for  “What Admins Love and What Admins Hate About The Current System”? Ideally, it would be visible to at least other customers of the same system so we could see what our peers are also thinking. And if once a year, the feedback was aggregated, sorted, and put in a Top 5 of Loves and Hates with vendor commitment to answer them in some meaningful way (“Yes, we see that 98% of you hate the new Flash Interface, we’ll try to work on that by 12-months out”, or “75% of you would like to see ______ but here’s why that is technically impossible” kinda stuff). Or if not a feedback dashboard, some mechanism that accomplishes the same thing.

We The Wireless People would love to have more of a hand in innovation, for everyone’s benefit. We’re closest to our clients, we know what we need, and we know what we don’t. And if it doesn’t get used, it isn’t innovative.