APoS survey with Cisco 802.11ax APs

In case you hadn’t heard, Cisco has launched new Wi-Fi 6 (802.11ax) APs. This generally presents issues for those on the bleeding edge of doing Wi-Fi designs – especially if you rely on empirical data for your AP locations before hanging your APs. Cisco has a tendency to get gear out the door and usually enables site survey through autonomous (on 802.11ac wave 1 or earlier APs) or Mobility Express (read my writeup on 802.11ac wave 2 APs here) at a later date. The new Catalyst 9115, 9117, and 9120 APs are no exception. We know that Mobility Express is coming on these platforms, but between now and the time that we get Mobility Express for site survey mode, we’re very much out of luck.

We have a few customers that rely on empirical validation of their APs using APoS so we had to come up with a workaround. No, it’s not graceful, yes it’s a touch on the cumbersome side, but it works – and until we get the fully baked Mobility Express from Cisco, it’ll have to do…

Things you’ll need:

  • A real WLC running AireOS 8.9 code to support 802.11ax hardware (temporarily)
  • A wave 2 AP that can be dedicated to Mobility Express
  • 2x Site survey batteries
  • A console cable and this guide
  • Some network cables to hook it all up

This guide will walk you though configuring your 802.11ac wave 2 AP as a Mobility Express controller, then joining your 802.11ax AP to it so you can bring it’s radios up. Leveraging the built in WLC on the wave 2 APs running AireOS based Mobility Express, you can then configure radio power levels, channels, etc – all as needed for your AP on a Stick designs. You’ll need to carry two APs (and site survey batteries) with you, but for now – it’s what we have.

Start with a WLC running 8.9.100.0 (or a newer build that supports 802.11ax APs) and join your two APs to it. Ensure that your APs have the build on your WLC as both their primary and secondary images. Verify this using the ‘show ap image all’ command. This is important do to because once you have this all built out, you’re not going to have a lot of opportunity for monkeying with AP release images and you could save yourself some heartache if one of your APs decides to boot off of it’s secondary image. If you’re image numbers are different, use the ‘archive download-sw capwap <ap_image>’ command on your APs console to get it to update properly and reboot.

APs with same primary and backup

APs with same primary and backup

Once you get your AP image versions matched, take your 802.11ac wave 2 AP and convert it to mobility express for site survey using the guide I wrote previously. There are one or two things you should note when you’re doing this – we’ll be eventually using your 802.11ax AP as a subordinate AP to the one you’re now converting to Mobility Express and it won’t start it’s CAPWAP process without a pingable default-gateway. In this instance, we’ll have to make sure that, when we build our DHCP scope, we tell the scope option for the default gateway to be the IP address of the WLC – yes, even though the WLC can’t actually route packets. This will ‘fool’ the subordinate AP into thinking that the default gateway is reachable and will let it complete its eventual CAPWAP join. You’ll also want to make doubly sure that you’re converting it to the same release version of Mobility Express as is on your APs.

Match your default GW and WLC address

Once you have your converted 802.11ac wave 2 AP operational, hook it up to your first site survey battery, then hook your second site survey battery to your first using the ethernet (non-POE) interfaces. One you do this, you can hook your 802.11ax AP onto your second site survey battery POE interface to allow it to boot. You’re effectively creating a chain that goes AP <-> battery <-> battery <-> AP and using the ethernet passthrough for the master AP running Mobility Express to talk to the subordinate AP. Once all of your APs are up and talking to the Mobility Express controller, I’d recommend renaming the Mobility Express AP to WLC and the 802.11ax AP to ‘ap’ for the rest of the commands in the previous blog post to work properly.

Two batteries, two APs

802.11ax temporary rig, ready to go!

If you’re concerned about battery performance of your WLC AP, you can also issue the ‘config ap disable WLC’ (after you’ve renamed it properly) to save some power and to make it’s radios not show up in your survey!

Name your APs, disable the WLC AP!

Functional site survey!

Of course we’re looking forward to a complete Mobility Express instance to allow us to do site surveys with a single battery and AP, but until then, this will do if you’ve got the necessary parts and pieces!

The Wi-Fi 6 elephant in the room

Everyone is talking about Wi-Fi 6 (802.11ax). From product launches, to technical briefings, to product technical launch briefings, it’s all the Wi-Fi space is abuzz with. Everyone loves talking about “the shiny new”, after all – it’s the technological advances that bring evolutionary and revolutionary changes to our technical lives but there is always that one person (Lee, I’m looking at you) that asks the question: at what cost? I’m not talking capital outlay, I’m not necessarily talking about operational outlay, I’m talking political cost. Our users have long memories and when we mess up (either as an industry, an implementation, or for whatever reason) the political damage that a flubbed product, widget, service, feature, or deployment gone awry can cause is pain that we don’t readily recover from. Everyone wants Wi-Fi 6, no one wants to get it wrong. Frankly speaking, one of the reasons this is so particularly painful is because the last technology ‘upgrade’ we went through (802.11ac wave 1 to wave 2) was painful for a lot of users. Even though this represented a ‘minor’ technical upgrade, in Cisco land, the pain was palpable for more users than not. In order to understand why this was the case then, and not the case now, we have to go back in time. Way back in time. Like, to 1995…

did-you-know-the-famous-microsoft-sound-in-windows-95-was-created-on-a-mac-520844-3.jpg

The venerable Windows 95!

If you have grey in your hair, you’ll remember Windows 95. It was awesome. It was great. it had a strong heritage robust peripheral support, and performed well. For its day, (OS/2 users aside) you could do no better. That is unless you were ultra-geeky and decided to spring for one of those SMP (Symmetric MultiProcessing) capable multi-CPU motherboards. In my instance, I was rocking a dual slot-1 motherboard. When the Pentium II CPUs came out, I was first on the list and once I had two of those bad boys installed in my gaming rig, I booted it up to test out some Quake… and was disappointed. You see, Windows 95 (and Windows 3.1 and DOS, etc) were single threaded Operating Systems. This meant that the OS that ran my gaming machine couldn’t see more than one CPU so no matter what I threw at it, I was never better than one CPUs worth of performance. It wasn’t until the brave of us switched to Windows NT 4.0 (don’t talk to me about NT 3.51) and later Windows 2000 – that we were able to ‘unlock’ that hardware’s potential because the Operating System itself, was now SMP capable and could not only see, but take advantage of both CPUs!

Screen Shot 2019-05-03 at 4.36.28 PM.png

Windows NT4.0 with SMP support showing 2 CPUs!

Fast forward to the Cisco 3702 Access Point. This is an 802.11ac wave 1 AP and sports a host CPU of a Freescale P1020 running at 800MHz as confirmed by the clock speed shown on the AP boot messages:

PowerPC CPU at 800Mhz, revision number 0x2151

While not a terribly shocking revelation, there are plenty of data sheets around that detail that the P1020 is indeed a dual-core CPU (thank you, Moores law), but what most people don’t realize is that the venerable IOS operating on the AP3700 (and all other APs back to the AP350!) is a single threaded Operating System. This then means that Cisco was building some awesome dual core capable APs for quite some time now, but was still ultimately limited by an OS that could only execute a single thread at a time. They were ultimately bottlenecked, much like Windows 95 running on my dual Pentium II machine. Now, the Cisco development team aren’t idiots. They knew about this problem and have been working on it for many years – but it reached a critical point prior to the 802.11ac wave 2 APs being launched. This was the inflection point where it because no longer possible to ignore the wasted hardware resources in the AP platform due to a deficiency in the OS. Enter AP-COS. This is Cisco’s rebuilt from the ground up Operating System for all AP platforms moving forward – starting with the 802.11ac wave 2 platforms (the 1800, 2800, 3800, and 4800s). Speaking frankly, it took Cisco some time to get this right. If you were on the leading edge of the 802.11ac wave 2 platform adoption 4 years ago (yes, the 1852 was launched in June of 2015!) you felt the pain of a newly developed Operating System. Let’s park this particular side of the conversation for a moment though…

 

ac AP boot

Cisco 2802 boot messages showing two CPUs

Now, Cisco is well known for their special sauce. Ever since the Cognio acquisition (that us old timers can’t talk enough about), they have ‘rolled their own’ radios. While not precisely true, they have licensed their Intellectual Property to Marvell, the chief supplier of the radios for Cisco for several years now. As my good friend Dave delves into in his blog post, the 802.11ax platforms from Cisco mark a departure from Cisco working with Marvell to build their own radios in their flagship APs. As of the 9120 802.11ax (thanks Pat for the correction here!) (Wi-Fi 6) Access Point, Cisco has moved their special sauce into a discreet add on card and are now using commodity radios from Broadcom and Qualcomm Atheros (QCA) for their client serving radios. The upshot of this is that Cisco is not the only manufacturer using these radios. You could see how, when Marvell was the only radio supplier, firmware, hardware, drivers, etc – all coming from a single proprietary supplier could be a bottleneck from a development perspective. What if there was a radio-reset bug? What if there was a new feature? What if there was a client issue? In short, Cisco would be the only one impacted. This created several unique scenarios where the radio may have needed some attention (for a variety of reasons) but there was only on vendor tackling the problem. Cisco’s move to commodity radios presented a notable step towards stability in the market and they lost none of their proprietary hardware functions, now that things like CleanAir were moved off to a discreet hardware component. In short, the best in stability without sacrificing the things that make Cisco, Cisco.

 

ax AP boot

Cisco 802.11ax AP boot messages with 4 CPUs

Fast forwarding to Windows 10 – I mean, Wi-Fi 6 (802.11ax) platforms from Cisco. We now have a mature Operating System on our APs. We now have radio hardware (and all of the follow-on components such as firmware and drivers, etc) that represent the industry standard in compatibility and stability. These two things mean that the major reasons that we had all of the consternation from the 802.11ac wave 2 platforms have completely disappeared. Now, Cisco is an organization comprised of people, and people are fallible, but my personal experience with the Wi-Fi 6 (802.11ax) platforms from Cisco have been nothing short of rock-solid. We always have the benefit of hindsight, but in this instance, I believe that our past is well and truly behind us. Who knows what the fully ratified 802.11ax specification will bring us (okay, those on the IEEE board do!), but there are several tangible indicators that we’re very much over our growing pains of the past – the most important of which are hands on experience which have been smooth sailing, even under some pretty significant load. If you ask me, Wi-Fi 6 (802.11ax) from Cisco represents a huge leap forward on several fronts – performance, features, compatibility, and most importantly of all, stability.

Analyzing analytic offerings

In case you’ve been living under a rock recently, the calm before the 802.11ax storm seems to increasingly be around Wi-Fi Assurance and/or Analytics. In particular, how is your Wi-Fi network performing and how happy are your clients (devices, not users). Most solutions on the market leverage a healthy dose of buzzwords to accomplish answering this question – most notably Machine Learning (ML), Artificial Intelligence (AI), Big Data, and don’t forget Cloud – to make you, the consumer feel like you’re genuinely on the bleeding edge of what a health related system can give you. It struck me during the recent MFD3 event that each of these solutions has a different way to approach the Assurance/Analytics problem, and of course each touts theirs as being ‘the best’ way to get all of the data needed to give you actionable data. Here is my take on the pro’s and con’s of some of the leading/competing solutions:

1) Mist Systems

Mist Systems claims to be the the First & Only AI-Driven WLAN – a bold statement indeed! Their primary source for retrieving statistics about users performance is directly inline from AP. This ‘at the edge’ approach allows them a deep insight into the radio and first hop performance of applications on their network. With a healthy punting of metadata to the Cloud, they claim to achieve “Automation & Insight through AI”.

Pro: A great example of ‘Cloud enabled’ Analytics and they do seem to genuinely seem to be hyper-focused on WLAN performance.

Con: Requiring Mist infrastructure means rip & replace for many organizations. Being hyper-focused on WLAN hardware leaves many organizations splitting their LAN infrastructure between vendors and that certainly diminishes the ‘one throat to choke’ troubleshooting. Visibility is at the AP layer only, ultimately leading to assumptive troubleshooting when issues outside of their visibility arise. Being a nascent company (and one of the last WLAN-only players) makes me wonder how long before they’ll be acquired.

Consumption: Cloud with a premium capex spend as well as ongoing required opex.

Bold claims!

Bold claims!

2) Cisco Meraki

Since being acquired by Cisco in November 2012, Meraki has continued to deliver on bringing features to market through their flagship product, the Meraki dashboard. The closest anyone comes to a ‘single pane of glass’ management portal, Meraki continues to shine for those Cloud-friendly organizations that have hyper-value on a single point of administration for their network. Generally, these tend to be the highly distributed organizations as opposed to the campus enterprise. Meraki’s ‘Wireless Health’ feature is in beta now and was ‘automagically’ delivered to existing customers.

Pro: Meraki’s AGILE product development targets the 80/20 rule pretty squarely. It’s ‘good enough’ for a lot of folks, and it’s ‘free’ to existing customers (if you don’t consider opex an expense of course).

Con: Wireless Health is Wi-Fi only – with no end to end correlation of their switches or security appliances, and it fragments the message around full-stack solutions. While focusing on making an ‘okay for most’ product, they certainly lose out on much of the deeper technical data commonly found in some of the larger platforms.

Consumption: Cloud with a premium capex spend as well as ongoing required opex (free to existing paying customers).

Slap a beta logo on it, call it good!

Wireless Health from Meraki

3) nyansa

Arguably *the* pioneer in Wi-Fi Assurance and Analytics, they were founded in 2013 and have a head start on most of the players in the market. Interestingly enough, nyansa is the only player in this space that not only doesn’t manufacture hardware to pitch at you, they work with an ever-growing number of existing infrastructure providers (including most of the major ones!). Leveraging an onsite ‘crawler’ to gather the data and to punt metadata to the Cloud, the onsite components are generally lightweight and assuming you’re already a VM friendly organization, no real hardware requirements (including any ripping and replacing of APs) is needed.

Pro: They’ve been at it a longer than anyone else and are clearly ahead of the game. They accept data from a variety of network sources including your LAN infrastructure so their ability to more accurately pinpoint issues is likely to be more accurate than a Wi-Fi only solution. Being able to ‘compare’ your data to peers of your own ilk is an interesting proposition and clearly one of the premier features they hang their hats on.

Con: Having an analytics only platform that’s not tightly coupled with your infrastructure leads me to wonder about the long-term stickiness of the solution. The perceived high-cost of the solution, has lead many to ‘deploy, diagnose, then remove’ – very much defeating the long term goals of Analytics and Assurance platforms. Ongoing success when ‘all is good’ is very hard to demonstrate and the vendor neutral approach leaves them vulnerable.

Consumption: Primarily an opex play since there isn’t really a capex component to speak of (no APs or appliances to install).

That's not creepy at all.

nyansa

 

4) 7signal

7signal has been fairly quiet on the Assurance front as of late, but they’re worth a mention. Being the pioneer in sensor driven tests, hanging an ‘eye’ to connect to your network and measure/gather various statistics about how well it’s performing has been their pitch from day 1. Falling more on the ‘stats digestion’ side of the house rather than on the ML/AI side of the spectrum, 7signal is worth noting due to their synthetic testing that closely mimics what a client sees on the network.

Pro: Client first is the best way to view the network and a sensor (or embedded into a client) is the only way to get this data.

Con: Having *only* client data means that correlation has to happen in a guesswork fashion. Coupled with a difficult install and a user interface that could stand a healthy dose of sprucing up and the platform overall is feeling pretty stale.

Consumption: Capex spend for the sensors and ongoing support and maintenance. On premises deployment model with ‘lightweight-at-best’ analytics.

5) Aruba

Aruba acquired Rasa in May of 2016 to become part of the Aruba Clarity team. They’ve since changed gears and are rolling the Rasa features into NetInsight. They’ve been relatively quiet on the productization front here, opting instead to show it off at events like Aruba Atmosphere and Mobility Field Day events. They get some interesting insights out of the education campus use case they show but I’ve not seen any readily actionable insights that don’t require some level of Data Scientist level of queries. They have the potential to move the needle in the industry here, but making it easy to use is clearly something they’re struggling with.

Pro: Buying a ready made analytics company reduces their time to market and clearly Aruba is moving aggressively to get into the analytics game here. If you’re an Aruba Wi-Fi, AirWave, or Clarity/NetInsight customer, they have some big things in store.

Con: Today the data is clearly difficult to get at. Usability leaves a lot to be desired and there is some pretty unclear things about where the platform is going. Between the legacy Clarity offering, the Rasa integration, NetInsight, and don’t forget about the recent Niara acquisition on the security side. There are lots of moving pieces here and Aruba will have to bring some quick clarity (hah!) to their consumption model.

Consumption: NetInsight productization is currently TBD, but I expect it will be Cloud-first, if not Cloud-only by the time you can get your hands on a production ready solution.

Doing thoughtful things.

Thoughtful people

6) Cisco Enterprise

Cisco has been focused on DNA-Center, the successor to the APIC-EM platform. The platform runs ‘apps’ on top, and one of the flagship applications shipping today is DNA Assurance. This platform is the ‘all-in’ Cisco assurance platform that takes data from everywhere you can think of – netflow feeds from your WLC and/or switch, radio data from the AP, synthetic data from sensors, and feedback from actual clients. In short, they take the best of all worlds and attempt to lump it into one big platform without giving people the heebie-jeebies about their data being in the Cloud.

Pro: Ambitiously Cisco is taking the ‘whatever you can feed me’ approach to Analytics and Assurance. The more feeds you can send to it, the better. This allows organizations to deploy the solution components that make sense to them and add more later if they want improved fidelity. Deploying an Analytics platform that you can actually run onsite in a 1RU appliance is no small feat and will be an undoubted boon for those Cloud adverse.

Cons: All of that horsepower isn’t cheap. Coupled with Cisco’s somewhat tarnished reputation as of late around code quality makes some people nervous about ‘one box to rule them all’, but this should generally be a mitigated concern for out-of-band analytics. Of course, this all works best if you’re Cisco end to end and that could be perceived as a negative to some.

Consumption: On premises hardware appliance fed by Cloud updates for the applications. Your Cisco ONE licensing consumption model and Smart Licenses will be key to getting this off of the ground, but so far there is no ‘break if you don’t pay’ approach.

I hope that the roll-up was a useful overview to the Analytics and Assurance market as it sits today. Did I miss anyone? Let me know and I’ll try and get a summarization up for you ASAP!

Management Frame Detection?

Nope! But MFD does stand for something even more exciting! Mobility Field Day (3!) is just around the corner! As a long time delegate with a few minutes to burn on the family PTO trip, I thought I’d take a moment to reflect on the upcoming event. As you can see from the Tech Field Day page there are tons of great sponsors lined up. Here is my take on the coming week, the sponsors strengths, weaknesses, and what I’d like to see. In order of presentation:

Arista (http://techfieldday.com/companies/arista-networks/, @AristaNetworks)

Arista has made a splash in the Wi-Fi space with their recent acquisition of Mojo Networks (nee: AirTight). I’m happy to see Mojo get scooped up, especially in the ever diminishing landscape of infrastructure providers especially since they have a strong story about ‘hardware agnostic’ solutions. Their story since the AirTight days has been one of open platforms and this strength has carried them to the success they’ve had so far. Arista has not. Admittedly I’m not a strong Data Center switch guy, but I don’t see a similar story of how the open, commodity hardware platforms with custom ‘better than you’ software on top meshes well with their corporate messaging. I’d love to see some reconciliation on that front, and a clear vision for the Mojo team moving forward. Please spare me the ‘HP acquired Aruba’, ‘Cisco acquired Meraki’, and those companies are fine story. Paint me a genuine story of market leadership backed by strong technical chops that promise to survive the acquisition.

Aruba (http://www.arubanetworks.com/, @ArubaNetworks)

Aruba (a Hewlett Packard Enterprise company) has been touting ‘industry leadership’ on several fronts recently. They have clearly claimed leadership on several fronts including WPA3 and some intriguing messaging around 802.11ax. Their strength is messaging. They do it well, but I fail to see how Aruba single handedly ‘landed’ WPA3 and how their messaging around 802.11ax (buy when *we’re* ready, but not anyone else) is anything more than corporate marketing fluff. I’d love to see how they are helping the industry move forward *as a whole* on more than just ‘standards stuff coming down the road’. Help me understand why Aruba’s implementation of QCA radios is better than someone else’s. Help me understand why their switches brings more value to an enterprise other than an ABC play. Help me understand why end to end networking with the Aruba logo on it is better.

Cisco (http://www.cisco.com/, @Cisco)

Cisco, the 800 lb. gorilla that everyone loves to hate. Cisco is a machine unlike any other. They have critical mass despite themselves and are painting some intriguing messaging around Assurance products that seem to resonate well with the on-premises enterprises. All other networking aside (routing, switching, security, Data Center, etc), Cisco Wi-Fi has seemingly lost its way as of late. Their adoption of QCA radios (CleanAir is awesome, unless they sell an AP without it!), their continued duality around the Meraki acquisition (it’s right when it will land a sale), and the feature gaps as new platforms come online has always stuck in my craw. The 802.11ac wave 2 APCOS change (the OS on the APs) debacle has left many with souring appetites for a monolithic beast of an assurance platform. I’d love to see how Cisco is involved in driving standards (WPA3, 802.11ax) while allowing their ecosystem around CCX fall to the wayside despite not having a standards based equivalent to 100% of those components (DTPC anyone?).

Fortinet (http://fortinet.com/, @Fortinet)

Fortinet (nee: Meru) has always been intriguing to me. If there is a dark horse in the Wi-Fi space, this is it. Out of left field, some strange security company acquired ‘those SCA guys’ which raised more than a few eyebrows in the industry. I’m not super passionate about firewalls so when someone touts that their strong suit is plopping some security stuff onto an already delicate Wi-Fi ecosystem, I get nervous. I’d love to see what Fortinet is doing on the SCA front (other than the occasional corner case deployment). How are you fostering the technology that made Meru, Meru? If you’re going to be the one exception in the CWNP curriculum, own that. Embrace it, get the delegates to see what makes it special. Get into the nuts and bolts of how it works, what makes it tick. Get your radio firmware developer into the room and nerd out with us for a bit. Don’t be afraid to put that unpolished guy on stage that only knows protocol. We love that kind of stuff.

Mist (http://mist.com, @MistSystems)

Mist is on the short list of Wi-Fi only players that I suspect will be acquired soon. Between them and AeroHive, there aren’t many players left and to be fair, Mist came out of nowhere when Cisco ‘spun out’ (my speculation) the previous owners of the AireOS legacy. They claimed virtual BLE was the next big thing, now it’s AI driven Wi-Fi – what’s next? Do they realize that the ‘heritage’ that they claim ownership of has turned off more people than it’s attracted? When someone claims to be at the helm of Cisco Wi-Fi during the Meraki acquisition, or to have the father of controllers (and RRM) in the drivers seat, how is that a compelling story when so many of todays woes are centered around those two topics? I’d like to hear how Mist has those people at the helm, but how they’re not destined to repeat the past. Mist claims to have an AI driven interface but fails to answer some pretty plain english queries. Tell me how Mist is better. How the AI is not just a bunch of if statements. Burning Man Wi-Fi, I hope not!

NETSCOUT (http://www.netscout.com, @NETSCOUT)

NETSCOUT (or is it netscout or NetScout?) has long held the mantle of go to wired insight products and only recently entered into the Wi-Fi foray with the Fluke (nee: AirMagnet) acquisition. They inherited an impressive product in the AirCheck G2, but also a legacy of tools that are, quite frankly, stale. What is next for the G2? Many of us in the industry love our hulk green Wi-Fi diagnostics tool and the G2 v2 additions were welcome. Is there enough left in the AirCheck to hope for a v3? I’d love to see a cleaner picture about link-live and how it plays a role in the beloved AirCheck G2. I’d love to hear a definitive story on the likes of AirMagnet Survey Pro, Wi-Fi Analyzer, Spectrum XT – all of which are *very* stale. Let’s put these to bed or make something of them that the industry can use.

nyansa (http://www.nyansa.com, @Nyansa)

nyansa has been that strange analytics company with the funny name that promises to fix all of our ails through machine learning and comparative analytics. They’re doing some neat things with ‘just a bunch of flows’, but is it enough? It seems like everyone is jumping on the analytics bandwagon now a days, but with the hefty price tag for a point-in-time resolution product, it feels somewhat estranged. Do you know what happens when your help desk has 9 dashboards all with different data in it, and you try to aggregate and correlate it into a meaningful dashboard? Your help desk now has 10 dashboards. I’d love to see why your data is better (of course), but tell me how it gets rid of data I don’t use today, and tell me how it does it at a price point that makes it a no brainer.

Dear reader, what do you want to see? Feel free to reach out to me by comment, or privately, or on twitter before or during the event and I’ll make sure you get a response. Till then, see you at MFD3 on September 12 through the 14th – make sure to tune in at: http://techfieldday.com/event/mfd3/

Meraki gets smart

I’m a fan of antennas. They’re pretty awesome components of Wi-Fi networks and I think they’re one of the most under-appreciated and oft-overlooked components, so when someone introduces a new antenna related technology, I tend to sit up and take notice!

 Recently, Meraki released their new external antenna model APs, the MR42E and MR53E. In the past, if you needed antenna flexibility in a Meraki solution, you had to use their outdoor rated AP. This introduction, in addition to rounding out their AP portfolio, snuck a new innovation into the market that Meraki has dubbed ‘Smart Antennas’. With the promise of auto-identifying an antenna to the AP, I couldn’t not know more about it! One of the more notable aspects of using external antennas is the potential risk to exceed regulatory compliance. While not terribly complex, the risks for getting it wrong could see the Feds breathing down your back – and nobody wants that! In addition to self-identification for compliance reasons, the new models of APs include more connectors than one might otherwise expect – 5 connectors for the MR42E, and 6 for the MR53E! This breaks down to 3 Wi-Fi antennas, 1 security/scan antenna, and 1 BLE/IoT antennas for the MR42E, and the same compliment on the MR53E with one more Wi-Fi antenna to support that 4th spatial stream. Without delving into each individual component, I really wanted to get a feel for if this thing did what it promised it would do, so I hooked them all up to their respective ports:

That’s a lot of cables!

Fired up the AP, claimed the hardware in my dashboard account and went poking on the antenna settings! Sure enough, where you would normally define an antenna, the exact model number of the antenna array I had was shown!

The cloud got it right!

Hoping it wasn’t fluke of some sort, I powered off the AP, disconnected them all, and tried again. Sure enough, this time, the dashboard presented me with the expected drop down list of available antennas.

The cloud still wants to help out.

I was impressed, it was magic, it worked automatically and wonderfully – and I had to know how. One screwdriver later (the tool, not the drink), I had done the unthinkable, and performed the ill-advised dissection of the shiny new antenna looking for something out of place:

No stranger to the inside of an antenna, the culprit jumped out at me pretty readily:

What appears to be a Maxim Integrated DS2431 1-wire EEPROM was sitting inline just before an antenna element. I traced it back to the connector and found it belonged to the externally-labeled IoT connector:

So, I dutifully connected just the IoT port to the AP, fired it up and viola! The dashboard indicated that the antenna was identified properly despite the fact that only 1 of the 6 connections was attached. This seems to reinforce that Meraki has indeed found a pretty intuitive way to integrate a digital component onto an analog line (as opposed to Cisco that has actual digital connectors in the DART) for a one-time polling of the antenna ID. This was further reinforced by booting the AP without the IoT port connected (so it did not identify the antenna correctly) and then re-attaching it without powering down the AP. After a day of uptime, the AP never properly re-identified it’s antenna. This means that, if you’re using the Meraki smart antenna solution:

  1. Make sure that the antenna cables are attached to the proper port using the silkscreen indicator on the RP-TNC connectors
  2. Make sure that if you change any antenna ports (especially the IoT port), you should reboot the AP so it can properly identify itself to the AP, and subsequently the cloud

It remains to be seen what kind of ecosystem Meraki intends to develop with 3rd party antenna developers, but rest assured, if you want to use a 3rd party antenna today on these new Meraki APs, you certainly can – you just need to log into the dashboard and make sure you pick the equivalent Meraki antenna that closest matches the gain of your 3rd party antenna.

Hands on the Cisco 3504 WLC

Not only are WLCs not dead, they’re not even on life support. Continued investment into the WLC platform is a clear indicator that there are still several use cases for centralized data, control, and management plane functions. Cisco has a long heritage of building awesome Wireless LAN Controllers (WLCs) and the 3504 is the next in a long line of purpose built WLCs. If you’re familiar with the Cisco WLC portfolio, the 5520 and 8540 WLCs are basically UCS based appliances with hardware offloading cards added in. The 3504 returns to the heritage of a ‘from the ground up’ design of a purpose built desktop WLC solution and it’s aimed pretty squarely at the aging 2504 and 5508 platforms. As many people are moving forward with 802.11ac deployments, a look at your infrastructure controller may be warranted.

IMG_8526.JPG

Without going into the details that are readily available on the data-sheet, I’ll instead focus on one or two key items of the platform that I find the most compelling.

1) Feature parity. This WLC marks the first time the entry level boxes have feature parity with the larger WLCs. If you peruse any of the release notes, you’ll see a list of exceptions for various platforms especially on the low end. The 3504 was launched out of the gate expecting to support all of the features of the 5520 & 8540 making the differences between the three platforms strictly speeds, feeds, and capacity. This should be a comfort to those that regularly struggle with the feature gap in the Cisco WLC portfolio.

IMG_8527.JPG

2) Quiet operation. Let’s be honest, there are more than a few deployments where the equipment is sitting table top or on a cabinet out in the open somewhere. The 3504 supports ‘fan off’ operation at temperatures up to 86 F (30 C). For the overwhelming majority of situations, it’s difficult to get up to 86 degrees and maintain it with any level of comfort. This basically means that for most deployments, you’ll never hear a sound coming out of the WLC – even if it’s in your home lab.

IMG_8530.JPG

3) mGig support. Multigigabit (or NBASE-T) is becoming more and more prevalent on switching infrastructure and this marks the first time we can break the 1G link speed on the infrastructure side without having to deploy a full on 10G infrastructure. Those of you that read my posts regularly may recall that I’m a fan of being able to deploy solutions that break the 1G barrier on my existing copper runs. This was commonly APs but if you’ve been investing in the latest and greatest and ignoring the FUD about not needing mGig, this is another opportunity to leverage that investment.

IMG_8528.JPG

All of these coupled together mean that you can get a quite elegant solution for most any environment now that we’re able to breath some life into the low end of the Cisco WLC portfolio. The 3504 is a notable improvement on the hardware and scale of the 2504 but don’t let it’s ‘desktop friendliness’ fool you – if you’re a 5508 customer today, there are going to be tons of places where ‘stepping down’ into a 3504 makes really great sense. With the rack mount kit available for it, you could easily put two 3504s in HA/SSO mode in 1RU and have all of the same features as the 5508 with a bit less capacity. Regardless of your current deployment, you really should make sure you take a peek at the 3504 as you’re considering lifecycle management of your gear.

IMG_8525.JPG

Disclaimer: I was provided a 3504 from Cisco as part of an early field trial and formed my opinions on my own. This post is my original work and I composed it without an expectation from Cisco.

Portable power for APoS

Newer APs often come with some pretty hefty power requirements. Standards such as the 15.4W 802.3af specification are increasingly insufficient on APs that are more power hungry. Enter the 802.3at standard that can support all the way up to 30.0W! While runtime operation of these (over PoE switches) is a topic all of itself, the Wi-Fi professional has always had issues with doing AP on a Stick designs (site surveys, empirical measurements) – especially when your AP power requirements exceed some of the more tried and true solutions. I’ve hashed out several different solutions over the past year, and thought it was time to write them all down.

The staple of AP powering has been for a very long time the Ventev / TerraWave – MIMO Site Survey Battery Pack. On its own, it only supports the older 802.3af specification. This all in one solution is portable, but since it’s based on old lead-acid technologies, it tends to fall on the heavier side of the solutions. Venerable, heavy, doesn’t support newer APs, but everyone has them.

Old, heavy, not a lot of juice.

The Terrawave Site Survey Battery Pack!

Enter the Tycon Systems DC To DC Converter And POE Inserter. This bad boy becomes an integral part of most of the rest of our solutions – and it’s very important to understand that it comes in a variety of input voltages. You must mate it to the power solution you’re using.

Where have you been all my life?

The Tycon POE injector.

Using the Ventev MIMO Site Survey Battery pack, you can see from it’s data sheet that it supports an external 56V output. If you use the included 56V cable, cut the ends off and mate that with the Tycon that has 802.3at power output, you can retrofit existing site survey battery packs to support newer high power APs! Sadly, physics wins out at some point. Since you’re drawing more power, invariably your battery will not last as long. If you have an older unit, you may be having problems holding a charge or any other number of other issues, but if you’re in a bind, it’s a potential solution.

If you think this Tycon solution looks familiar, Scott Stapleton wrote about a similar solution in his blog. Using the injector that he stated (TP-DCDC-1248GD-HP, note the 10 to 15VDC input change), along with commonly available batteries such as the RAV power units, you can extend the run time of your APoS efforts by interchanging either larger capacity batteries or additional units. In my tests, I used two of the RAVPower 2300mAh batteries along with the Jacobs interconnect to complete the solution.

Shhh - don't tell him!

Image shamelessly stolen from Scott Stapleton.

Thanks to Keith Parsons for this next solution, which is a variation on Scott’s using a battery from Hardened Power Systems. The ReVolt G2 is a large capacity battery that uses 12V powerpole connectors that is *very* light (27 ounces) due to the LiFePO4 battery technology. This, mated with correct Tycon solution using the 12V powerpole connectors gives you a far more portable solution (one high capacity battery, one injector) that can last all day long!

High Capacity Battery, lightweight.

While these all address in varying ways different requirements, they’re all considered a touch on the bulky side and carrying around multiple pieces has always been a challenge for a road warrior that doesn’t want to lose or break bits and pieces. Enter the Ventev VenVolt solution that they were showing off at Cisco Live US 2017. While this isn’t shipping yet, they had a prototype to show off that looked awesome! Lightweight, all in one solution, all day battery on modern technology. Stated dimensions for the unit are 9 3/8″ x 4 3/4″ x 3″ according to Mike Parry. I for one can’t wait for a fully integrated solution to finish baking and come to market!