Damn You, CAPWAP Tunnels… Damn You All to Hell

There comes a time in every person’s life when they have to face the truth: maybe their CAPWAP tunnels that have been so good for so long actually have a dark side… Maybe them tunnels make you feel empowered, nay- maybe they make you feel invincible when it comes to creatively using VLANs in your overall Wireless LAN construct… and maybe someday that good thing leaves you in a bad place. Maybe.

Let’s pause for some lyrics from the immortal Waylon Jennings’ song “Wrong”:

I should have known it all along
When the future looks too bright can’t be anything but right
Wrong

Everything was going strong
The sky was always blue I thought my dreams had all come true
Wrong
Wrong

Let’s get right to it: CAPWAP TUNNELS SPOIL YOU.

You’ve been using a WLAN solution for a lot of years. It’s been buggy at times, the vendor has left you frustrated on countless levels. You’re thinking “shit I would freakin love to finally ditch controllers and that bloated, semi-functional NMS and move to a cloud WLAN solution for my thousands of wireless access points” – WAPs for some of you (shut it- you know who you are)… But then you run into the CAPWAP tunnel thing and a big honkin Layer 2 quandary down in your switches.

If I have a controller-based WLAN, I can get away with this at the AP uplink port, which clearly gets the Polly Pony Seal of Approval:

But alas, take away the CAPWAP tunnel construct and you are left with something less savory, and Cactus Mike isn’t digging it:

I gotta agree with Cactus Mike- in very large WLAN environments, the thought of no CAPWAP tunnels sucks ass. Sure, maybe a radical redesign of the LAN that underpins the WLAN would help, by pushing L3 out closer to the edge and reducing the need for VLANs. But such undertakings aren’t always a possibility, and if they are a possibility, the timing of redesign opportunities may not line up. Back to topic.

Am I suggesting that by going to a cloud-managed WLAN solution that CAPWAP tunnels aren’t possible? Yes and no… Some cloud vendors recognize Cactus Mike’s conclusion, others not so much. I have not actually used any of the following solutions, but I do appreciate that they recognize that “switching to cloud” and “ditching the controller” isn’t all that easy for those of us with CTA (CAPWAP Tunnel Addiction):

–Arista:

–Aruba: (link is here)

–Extreme definitely has an answer but I’m not finding the right link. Will edit

–Mist: (link is here)

–Ruckus: (link is here)

By no means is this summary meant to be comprehensive. And, if you were to drill in to any of these, I’m not sure they would each stand up as an answer to “how do we ditch our current controllers, terminate VLANs somewhere, yet move the rest of the show out to the cloud while retaining our CAPWAP tunnels and not doing a massive L2 reconfiguration?” as I have not tested any of them.

But- I do appreciate that the situation is being recognized and addressed by major vendors. AND- I am surprised that at least one long-running pure cloud innovating powerhouse vendor has yet to provide an answer to the situation. As long as the only answer is to configure the uplink to a cloud-managed AP as if it was an old fat legacy access point, they won’t be getting an invite to Cactus Mike’s summer bash…

Your thoughts on the topic?

The Idiot’s Guide to Ubiquiti UniFi

BTW- I’m the idiot, in this case. Something about Ubiquiti’s “UniFi” approach to networking can make me feel confused and inexperienced at times. But I’m determined to make peace with it, and to also maybe help save someone else the confusion. Ubiquiti’s product lines are interesting, feature rich, innovative, flexible, and cost-effective. And… also occasionally bewildering if you have yet to Ubiquitize your mind. To this point, let me (hopefully) make the indoctrination to UniFi a little easier.

UniFi is a Management Methodology AND Networked Components

Part of what confused me early on was the name- “UniFi” must surely just be a bunch of bridges and access points… As in, things that do Wi-FI. If you’re thinking that, you’re wrong. UniFi is more like UniFied in that a wide range of switches, access points, security gateways, video components, and more are branded with the UniFi moniker and managed as an ecosystem.  First major point: UniFi isn’t just wireless.

As for how the UniFi ecosystem is managed, that’s one of the main areas of getting to know Ubiquiti’s latest stuff that made me feel like a child (and not a very smart child, at that). I have set up and managed my share of other non-UniFi Ubiquiti bridges, where you get to the individual component’s UI and configure to you heart’s delight. But if it’s a UniFi AP, switch or gateway, life gets a little more involved. Forget the individual per-component UI, for UniFi you need to adopt each component into a “controller” and then manage a “site” worth of stuff (or multiple sites) via the controller.  Second major point: you don’t generally manage individual UniFi parts/pieces, you adopt each into a “controller” and then manage them all from the controller interface. I’m not a fan of the term “controller” here, but it is what it is. Think OpenMesh or Meraki dashboards and you’re on the right track.

Maybe Too Flexible?

This is where experienced UniFi users might tell me to go eat rocks, and I’m OK with that. But I have been utterly confounded trying to wrap my head around the various incarnations of the UniFi Controller. One way or another, you need to get to this point:

This inventory view of the Controller shows what devices I have, then from there it’s pretty robust in both configuration and monitoring capabilities.

Once you get your devices into the controller instance, life gets pretty pleasant. I give Ubiquiti a lot of credit for the completeness of the management interface and for putting together a framework that makes perfect sense- once you get there. Getting there, however, can be tricky. To me, Ubiquiti isn’t doing so hot on their messaging that the UniFi controller can take multiple forms and that you have to really know which form you want to use before your bring an environment to life.  I’ve spent a lot of time pouring through Ubiquiti’s web pages, and there seems to be more of an emphasis on dazzling potential customers with grand claims of cloud this and that and SDN blah blah blah than a realization that newcomers to Ubiquiti may need some basic buzzword-free guidance on this controller thing. The UniFi controller can exist in different forms, and you can only use one at a time with a given set of end devices:

• On a laptop. You need to use the controller to manage devices, but the devices don’t NEED the controller to operate, so you might only invoke the controller when you have changes to make. But… here you don’t get the monitoring and statistics that you would with a more persistent controller method.
• On a CloudKey.  Now this is cool. I wrote about my first use of CloudKey here, and you need to know that it’s just another way of managing the UniFi devices.
• On your own virtual host. Load up a controller in AWS, manage a bunch of sites in your own private cloud- but know that you have to provision the devices to get them to your cloud-hosted controller with effort not required in pure cloud-managed systems like Meraki and OpenMesh.
• Let Ubiquiti host it. Recently added to the UniFi offerings is the Elite Controller option. Here, you end up with something that’s kind of like Meraki but not nearly expensive. You pay a modest fee per device, and in exchange Ubiquiti provides cloud hosting of the controller for your devices, and phone and chat support. Unlike Meraki or Open Mesh, this is not plug and play. Your devices do not magically tunnel out to the cloud controller just because you’d like them to! You need to provision the devices, as Justin Paul writes about in his blog. If you don’t do the provision thing right, you’ll beat your head against the wall in frustration.

Third major point: there are several versions of “UniFi Controller”. You have to grasp the differences to decide how you’ll manage a given network, 

I’m currently kicking tires on UniFi hardware and the Elite Cloud option. I will have much to say on both as my evaluation continues, but I do hope that this quick primer can help anyone who is new to Ubiquiti’s UniFi environment.

Open Mesh Adds Switches To CloudTrax

I wrote about Open Mesh right here back in 2014. Though I run a number of “brand-name” networks that range in size from small to humongous, I also have a real appreciation for non-mainstream vendors that bring a compelling story. Open Mesh is at the top of my list in that regard, for a number of reasons:

• I believe in the effectiveness of cloud-managed networking
• I get tired of huge licensing fees
• I don’t believe that every environment needs a feature list longer than my arm, and the pricing and code bugs that go with it
• I like a company that empathizes with the customer when it comes to TCO, versus ramming contrived performance tests down our collective throats to justify stratospheric pricing
• I like rooting for “the little guy” as long as that little guy is legit

Now, back to Open Mesh.. Let’s play a quick game.

Riddle me this: what model AP is in the following picture?

Is it-

a. Bluesocket (Adtran) 1920 AP
b. AirTight (Mojo Networks) C-55 AP
c. Open Mesh MR1750 AP
d. Any one of several other APs that look like this

The answer? It’s ALL of them. I currently have two of the Open Mesh MR 1750 3×3 11ac APs in test at Wirednot HQ. As you can hopefully see, Open Mesh has opted to use a fairly popular “industry standard” AP form factor (though the other APs listed are actually 11n). This decent-quality AP lists for $225 and requires NO LICENSE to use with the excellent CloudTrax dashboard (shown here).

CloudTrax is peppy, well laid-out, and suffers none of the browser wonkiness of certain NMS systems. Open Mesh has done a great job with providing cost-effective cloud-enabled Wi-Fi, and they have a loyal following despite not being heavy on advertising. That’s a good thing… which just got even better.

Now, Open Mesh has switches.

Like Open Mesh’s APs, the new switches are priced to sell and are also managed WITHOUT LICENSES in CloudTrax. Here’s my own S24.

Between the APs and switches, Open Mesh provides a lot of value. Though the product set is arguably lacking a router/gateway component, it still has to be experienced to be believed. It’s that good, for that cheap.

Caveats: I should mention that I’m not huge on the use of mesh in any WLAN setting. This is where one AP uses radio for backhaul to another AP to eventually find it’s way to the wired network. It cuts throughput way down, and can be wonky depending on the vendor. Open Mesh has a strong history in using mesh connectivity. While I’m a fan of Open Mesh, I tend to run every AP home-run with it’s own UTP except for the absolute rare case where that’s not possible.

In my simple testing, Open Mesh is standing up well to Meraki, Ubiquiti, Ruckus, and Aruba APs in what approximates an SMB environment. I’m not in an HD setting, nor am I attempting to do any sort of conclusion-seeking performance bake-off. At the same time, there’s been nothing I’ve thrown at the MR1750s on the S24 switch that they can’t handle as well as any of the other APs I run. I’m not advocating ripping out your enterprise network for Open Mesh, but I can say that it’s absolutely worth looking at and judging for yourself.

 

 

 

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?

An Outsider Looks At AirTight’s Recent Hires

I don’t get to the Silicon Valley very often, but I am a professional free-lance media type and have been monitoring and covering goings on in the WLAN space for a lot of years. Last night I got an email regarding Steven Glapa leaving Ruckus, and heading for AirTight networks as the company’s new Chief Marketing Officer. I don’t usually give coverage to staff changes in the Valley, as there are just too many of them that happen frequently, and I’m not big on puffing up egos by reporting on individuals’ career decisions. But something about the AirTight email got me thinking beyond their new CMO.

The sender of the email used the words “snagged” and “talent poaching” to describe the luring of Glapa away from Ruckus, and perhaps that’s what set the Hook of Deeper Thinking into my handsomely chiseled jaw. I have no knowledge of what made AirTight appealing to Glapa, or what it is about Ruckus that made him want to move on, and frankly I don’t really give a rip. But being a habitual Big Picture thinker, here’s what Glapa’s move got me thinking about.

• The notion of Validation has gotten used often lately. Cisco buying Meraki validated cloud-managed wireless, which also made Aerohive and PowerCloud happy.  More recently, Aruba Networks released their opening cloud volley, followed by an interesting offering from Enterasys– again, validating the model. AirTight is part of the growing cloud-managed WLAN space, and though it’s roots are in the love-it-or-hate-it security overlay realm, has picked a hot direction to evolve given all of the validation of cloudy wireless going on these days.
• AirTight also recently “poached” a couple of high profile staff assets from Aerohive Networks, in the forms of one Devin Akin and one Andrew von Nagy. Again, staff moves aren’t my kind of news as a rule, but there is a significance here- cloud-managed wireless has matured to the point where cloud vendors can steal each others’ expertise, as there is now an experienced cadre of cloud-savvy networkers to court. This wasn’t the case not so long ago.
• Perhaps a “shaking out” of this market sector is imminent? AirTight gained a CMO from Ruckus, two “Evangelists” (I’m starting to of tire that term, Jimmy Swaggart) from Aerohive, and all three companies are arguably “small”. Though wireless itself is a big and growing market, could these sorts of moves reflect some hidden gloom at the “donor” companies? This is pure speculation, obviously, but also a natural mental path to wander down. How many smaller and/or cloud-managed companies can the market sustain at this point?
• AirTight better make a splash soon, as none of these guys are probably working for cheap. Akin certainly has name recognition as a WLAN deity, with von Nagy no slouch in this regard. I don’t know much about Glapa, but given that Ruckus has been on fire at times, he must have a good business touch. So three strong HR adds have been made to a company that has a product line that needs to do some catching up before (in my opinion, at least) it legitimately competes with Meraki and Aerohive for robustness of feature set. Hopefully the new guys hasten that development for AirTight’s sake, given that payroll seems to be swelling for a company “new” to the WLAN access market.
• Despite all of the growth and media coverage of cloudy WLAN of late, the controller-based folks still own the market. But… the division between controller-based and cloud-managed is being blurred as more vendors are doing unholy things to the control and data planes and diluting the bajeezus out of the controller model at times. The point? There is still an awful lot of industry evolution to be done. Each and every vendor in the mix has the daunting task of evolving while not losing customers or overwhelming them with constantly changing license models, lexicon, and topologies. Whether controllers completely age out and the cloud wins, or whether we end up with options in a few years remains to be seen. Meanwhile, the religious wars surrounding each kind of WLAN will rage on.

And that pretty much ends my lunch hour of deep thought- back to work I go.

Features, Products, Services… The Differences According to Aerohive

I recently visited Aerohive’s home turf as one of the delegates at Wireless Field Day 5. It was wonderful getting to meet, in person, many Bees I frequently interact with via email and social media.

My own history with Aerohive is built largely on covering their evolution from the early days, writing about them professionally in Network Computing Magazine. As with other vendors, sometimes Aerohive gets the spotlight and sometimes they get compared against when analyzing what competitors are up to. I have my own small Aerohive environment, and have first hand familiarity (not mastery, mind you) with Hive Manager and a couple of AP models.

Aerohive has been a major player in minor-but-growing cloud-managed wireless network space that includes Meraki (Cisco), AirTight Networks, and PowerCloud. 

Ah, cloud-managed networking. I’ve become a fan where I use it (and I do use it in a number of sites). I like that one of the running campaign themes of cloud-based networking in general is reduced hardware counts with no convoluted licensing schemes. 

Though Aerohive has done a good job with pushing the value of “here’s a new feature, and you’ll just get it with your next Hive Manager upgrade at no additional cost!” message to customers, I was taken a wee bit aback during the Field Day briefings on Aerohive’s IDManager and Client Management services because they were called “new products” that require licensing.

Both offerings will no doubt be welcomed by existing Aerohive customers, and are easily marketed at prospective customers looking for a robust, all inclusive solution. My own little private shock at the licensing requirement doesn’t detract from my overall opinion on Aerohive, and after thinking about it , I know where the surprise comes from: we’ve gotten so used to rich feature sets being “free” that we instinctively expect the gratis model to apply to any and all “features” Aerohive develops. Which really isn’t fair to Aerohive, but is how we’ve been conditioned on the customer end.

I wont pretend to understand why Aerohive has “given” so many enterprise-grade services away to date that others license for, but draws the line at IDManager and Client Management. Nor do I care enough to get hung up on it, as other vendors seem to be licensing their Onboarding services as well after hearing their briefings. 

For those keeping score at home, here’s a breakdown of some of what is included with Aerohive’s Cloud Manager and licensed APs under the heading of “it’s just in there”:

• Spectrum analysis
• Application visibility and control
• Statefull firewall
• QoS
• VPN
• Partner MDM hooks
• Planner software(free to non-Aerohive customers too)
• Bonjour gateway software (also free to non-Aerohive customers)

And what you have to license seperately:

• Client Management (license blocks of 100)
• IDManager (tiered licensing, starting at 250 guests)
• StudentManager (blocks of 1000)