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.

 

 

 

WiTuners Wants to Optimize Your WLAN

Some days it feels like there’s nothing new under the wireless sun. But every now and then a unique offering wiggles its way onto your radar, and if you’re the curious type you just have to dig a little bit beyond what meets the eye. Recently a Wi-Fi colleague asked me if I’d heard of a startup called WiTuners, which is the impetus for this blog. It turns out, I had not heard of WiTuners. But, being both a crack analyst and master sleuth, I set out to find out more about this intriguing company with the peppy website.

My first question about WiTuners was “are they still in business?” or are they a ghost ship like Nira Wireless seems to have become- having a flashy website and interesting premise but no update announcement in like a bazillion years. I looked at the WiTuners Twitter account and saw little to no activity over the past year and figured that this company must be a mis-fire. But then I put my powers of interrogation to work and asked them via a webform “hey, are you guys still in business?” The reply came quickly and decisively, and my inquiry was met with an inquiry- “Sure we are. Who the hell are you, and why do you ask?” (or something to that effect). And that’s how I came to know Luke Qian, President and CEO of WiTuners (and long time wireless industry veteran). We exchanged a few emails, and eventually connected via telephone so I could learn a bit more about this company that promises to help you optimize the performance of your pricey WLAN. (Luke conceded they’d gotten inattentive to their Twitter thing, and the account has since gotten much more active.)

Please note: I have yet to try WiTuners, and this blog is in no way an endorsement of the capabilities offered by the company. But WiTuners is an interesting story, and I salute anyone who attempts to bring a new performance angle to our important WLAN environments (well, except for these guys.)

So WHAT IS WiTuners about? I can’t say that I yet fully understand the model, but I do grasp large parts of it. When you’re done reading this blog, pop over to this WiTuners page to hear it in their own words. Here’s a stab at it:

• There are no hardware components, only software
• Survey and planning utilities are available
• There is a cloud approach to much of what WiTuners does
• It’s aimed at both MSPs and enterprises
• WiTuners doesn’t replace RRM and such, it complements it
• Optimization can be done on demand or automagically with continuous monitoring
• You can see proposed optimizations before invoking them after doing a quick audit
• The framework does not replace NMS, though it does promise certain life-cycle and system monitoring capabilities
• SNMP figures largely into what goes on here, leveraging standard MIBs to “significantly reduce … costs of WLAN deployment and maintenance while simultaneously…[providing] better WLAN performance.”
• Is compatible with Cisco, Aruba, Extreme, Ruckus, Moto/Zebra, Juniper, and other modern WLAN systems
• Optimizations can be proven by reported decreases in channel utilization or by the survey tool with boots on the ground
• WiTuners aggressively keeps up with code/MIB updates from the vendors they support

This list is far from an eloquent portrayal of the WiTuners model, I realize. I’m providing it more to spark your curiosity in case you’d like to learn more than to act like an expert on the offerings as I’m still trying to wrap my head around the whole thing. WiTuners is a well-funded startup, and Luke is a good ambassador for the company if you get a chance to talk with him (it turns out that Luke and I know some of the same people in the WLAN industry). WiTuners expects to become more visible to target customers later this year.

Whether there is room and demand for the WiTuners optimization services remains to be seen, but anything that promises to make busy WLANs perform better is at least worth hearing out. 

For me, I’d have to see WiTuners in action before I could pass judgement. But I would be curious to hear what you think about the notion of WiFi system optimization as a service offering. Please leave a comment, and thanks for reading.

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?

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.

 

Outsourced Wireless- Enterasys’ New Offering

By now, cloud-managed wireless has certainly gained legitimacy. To over-simplify, cloudy WLAN is often touted as both an alternative to hardware-heavy and maintenance-intensive controller-based Wi-Fi solutions, as well as being marketed as a good fit for environments that have limited IT staff at distributed sites. Enterasys is now taking that second point even further; the company is offering a completely outsourced cloud-managed solution that you pay someone else to worry about- from planning to installation to daily operations.

Sure, outsourcing is dirty word to many of us in the IT world, but Enterasys’ strategy has merit for certain situations. With every new technology release (both on the infrastructure and client device sides), wireless networking gets ever more complex. Many businesses simply can’t afford to have wireless professionals on staff to keep it all on the rails, yet business Wi-Fi is pretty much a must any more for most of us. Rather than limp along on a Hail Mary solution pieced together by consumer-grade parts or blowing HR budget to get a WLAN pro on staff, there likely is a sweet spot out there in Customer Land for the Enterasys Experiment.

Here’s the Important Stuff:

• Enterasys has partnered with PCM, Inc for the customer-facing end of the 100% turn-key service offering
• The WLAN hardware is the IdentiFi line, while OneFabric provides the cloud/management magic
• Remember, this is managed all the way- the most the end customer gets is a read-only glimpse of what’s up
• PCM or it’s subs will plan, design, upkeep, respond to trouble, and even do AP upgrades when it’s time as part of the service
• The solution is aimed at small-to-medium businesses that need reliable wireless but don’t have the staff to pull it off

Find out more here:

My Own Take On Enterasys’ Offering

It’s a big wireless market, and only getting bigger with more nuanced use cases. There should be room for what Enterasys is attempting, but at the same time I offer:

• I know little of PCM’s capabilities or track record. Enterasys’ success in this venture depends on the quality of the PCM Cloud Wireless Service experience and how it’s executed for each customer.
• In any local market, how the actual support model plays out will be interesting. I’d hate to be a Syracuse, NY customer that has to wait for service from a technician in New Jersey or Boston. I don’t know that this would be the case, but similar services in other technologies (CCTV, security, etc) often have enormous service areas.
• It’s one thing to say that “this is 100% turn-key”, but if it ties into a business LAN, eventual finger pointing is inevitable when something isn’t clicking as it should, whether it be PoE or DHCP/DNS. Potential customers need to be aware that if the entire network isn’t outsourced but wireless is, sooner or later you’ll need to provide a resource or two to help with issues.

As managed services becomes more a part of major WLAN vendors’ blueprints, I’d expect to see more of these announcements.