SC-WiFi

Meraki in the Enterprise ASTERISK

June 21, 2023 by Sam Clements Leave a comment

If two decades in the VAR space teaches you anything, it’s that if you want to challenge yourself, learn to say yes, then qualify the relevance of that “yes” to the proposed question. One of the most heavily asterisk’d responses I’ve had to give in the past is in response to the question, “Is Meraki right for the Enterprise”, and I’m of the opinion that it’s high time we start leaving the asterisk off. Look, I’ve been a proponent of Meraki since prior to the Cisco acquisition, but let’s be honest, I’ve clarified that “asterisk’d Yes” in many ways over the years:

Is Meraki right for the Enterprise? Yes*

Over the years you may recall such greats as:

*But they don’t have external antennas, so challenging RF environments are out!

Shortly after acquisition, Meraki did indeed role out External antenna support for their indoor portfolio and it’s been a part of the portfolio since!

*But they don’t have firmware update controls or release notes

Meraki has now one of the best software image management functions available. Or if you’re like most folks, you just want the peace of mind knowing you can refer to it after you’ve set it and forgotten it.

*But they don’t have a way to turn off 2.4GHz radios or have RF profiles so challenging RF environments are still out!

Adoption of RF Profies in the dashboard with no on-premises hardware changes or updates? All delivered seamlessly as part of a dashboard update – and you didn’t have to do anything to get it.

*But they don’t have high gain antennas so challenging RF environments are still still out!

With Smart Antennas, Meraki is able to use the same RP-TNC connectors as other antennas, but this hardware level innovation never got much attention despite the fact that it enabled more complex designs with regulatory compliance assurance.

*But the operating temperature of the AP is on the weak side and I’m concerned that they’ll melt in the rafters long term (or really any other AP centric “quality concern” that could be raised) so challenging RF environments are still still still out!

Meraki adopting the Cisco AP portfolio for a unified approach to the hardware handily assuaged *many* concerns throughout the industry. Meraki APs were fine, but this makes is easy to reconcile for the field. If you can put a Cisco AP in a challenging RF environment, you can put a Meraki AP there now (since they’re the same thing)!.

*But RRM! The Cloud simply can’t do as good of a job at challenging RF environments as my WLCs RRM so challenging RF environments are still still still still out!

At Mobility Field Day, Cisco showed off a unified RRM control plane feature that is a standalone RRM function that either your on premises controllers can use or your Meraki dashboard can use. The goal here is that regardless of the management platform (DNA Center or Meraki dashboard), you should be able to adopt an RRM system that works consistently across both platforms.

*But centralized Data Plane/VLANs/tunneling/<other WLC centric concern here> means I have to abandon the Meraki dashboard, so clearly campus enterprise is out!

Well, this is one that has been sticking in my craw for years, I’ll admit. It wasn’t until last years Catalyst portfolio transition for the Meraki wireless offering, that I had any hope that we’d see what I call “good” guidance on the topic. This has always left Campus Enterprise customers out in the wind to some degree or another. That was until I saw with my very own eyes Meraki pulling a Catalyst 9800 WLC into the dashboard for monitoring. Now, there’s a lot to unpack here and when I first saw this I had about a billion questions. Like:

1) What do you mean I can have my 9800 controllers in the Meraki cloud?

This one I just had to have clarification on – it finally delivers on a huge part of the Meraki/Catalyst integration and yes, you can simply add your WLCs to the dashboard. You then get AP insights (they look just like a Meraki AP!) and of course all of that delicious client info. In short, add your WLCs to the dashboard and you have instantly massive insight into your clients and infrastructure. All without making any changes on your WLC!

2) I’ve been in the dashboard, and there’s no way I can configure all the same things as I need on my 9800 there. How limited am I going to find myself here?

Well, the good news on that front is that for now, this is monitoring only – you retain all of your 9800 functionality and do all of your configuration still on the 9800 directly – no loss of features since there really isn’t much to do from the dashboard once you’ve added it other than bask in the glory of the insights!

3) Monitor only? What if I want to configure my 9800 from the dashboard and I can’t?

Well yes – that is the current state of the integration – but believe me when I say, the trajectory that Cisco laid out at MFD is clear – Meraki and Catalyst everywhere that DNA Center is “too much”. I think it’s safe to assume that based on the current features available across the EN portfolio (especially on the MS and MR platforms) integrated into the dashboard – that Cisco isn’t done here.

Regardless of where you stand on on your definition of Enterprise requirements (campus or otherwise), it’s clear that if you haven’t been watching the Meraki integrations happening over at Cisco, you really need to spend some time making sure that any of those pesky preconceived blockers you may have in the past aren’t quite so show-stopping now a days…

Filed under Access Points, Cisco, Meraki, Wireless, Wireless Tech Field Day, WLC

Wi-Fi 6e, 6GHz and the Wi-Fi Professional: an introspection

April 12, 2021 by Sam Clements Leave a comment

As I post this blog from a computer with a Wi-Fi 6e adapter, connected to a Wi-Fi 6e Access Point over 6GHz, I’m struck at just how far behind the times the average Wi-Fi Professional is. It goes without saying that the COVID-19 pandemic changed the landscape of our world, and the uptake of Wi-Fi in the home environment for production/corporate/commercial use has obviously skyrocketed. What does this have to do with the average Wi-Fi Professional being behind the time? Let me rewind the clock just a few weeks. I fielded an escalation from a corporate executive that was working from home. This is obviously nothing new given the Work From Home adaption that we’ve all had to accommodate, but this executive in particular was fed up with his experience at home and went out and bought a new router to go with his newly issued corporate laptop. After unboxing and setting it up, he was having issues and so did the most obvious thing – engaged his support team. Here’s where things go south quickly. His new laptop has an Intel AX210 Wi-Fi 6e client (which has been available for months at the time of this writing) and his new router sported “the fastest Wi-Fi connections available” – yes, over 6GHz. Fast forward to today and I’m saddled with a support case for an executive that is using technologies that I don’t have access to or tools to troubleshoot (much less design). I did what any dutiful Wi-Fi Professional would do in this case, I bought the same things he did and got to wrenching. The experience of troubleshooting a Wi-Fi connection without tools is one that I thought was long behind me. Having no Spectrum Analyzer, no channel scanner, no packet captures, no nothing – means that I was basically taking shots in the dark trying to figure out what was going on. This is the inverse of what happened to me the first time I saw a channel scanner, saw an CCK spectral mask on a spectrum analyzer, captured my first 4 way handshake – the elation of visibility came crashing down around me so rapidly, it was like someone turned off every light in my vicinity and left me wandering in the dark.

A Wi-Fi Professional is only as good as their tools. Yes you need learning, yes you need to understand what your tools tell you, yes you need to train on them so you can learn them properly, and yes – that skill contributes to a Wi-Fi Professionals overall efficacy, but what do you get when you have a Professional that knows what should be going on, knows where to look for the problem, but is left without being able to do so? You have a lame Wi-Fi Professional. Unfortunately, the Wi-Fi Professional has suffered a few significant blows in recent memory. The first was when Work From Home really started to kick in and we realized that none of our tools were built for supporting that kind of environment – and now, 6GHz isn’t just “coming soon”. It’s not coming next year, not coming next quarter, not coming next month. It’s here today and real people are using it for real work. The world has changed and adapted, but we haven’t. The Wi-Fi Professional is hurting today and for all the bluster of the marketing around Wi-Fi 6e – the only real strategy we have is to stick our heads in the sand and recommend that people do not adopt 6Ghz solutions because we’re not ready. This puts us behind the curve, and for a group of professionals that are proud to be on the leading edge of market trends and supporting those around us that are passionate about technology, it’s embarrassing.

Filed under 6GHz, 802.11ax (Wi-Fi 6), Wireless

So long, and thanks for all the great times

January 30, 2021 by Sam Clements 7 Comments

Cisco posted the EOS notices for their stalwart Wireless LAN Controllers yesterday, covering the 5520 and the 8540 (and VM). This, coupled with the EOS notice for the 3504 model just the week prior marks the end of all of the hardware/virtual AireOS controllers from Cisco. It’s worth noting that the embedded AireOS (called Mobility Express) is not included in this months announcements. Mobility Express aside, this marks an ending of an era that began with the Aironet acquisition by Cisco in 1999. 22 years of service out of an acquisition is a pretty good run if you ask me. As I reflect on the past two decades, we’ve seen a ton of changes – not only on the Cisco front, but industry wide. We saw 802.11 evolve from hotspot networks of connivence to being mission critical, redundancy focused, pervasive solutions that our business critical applications rely on. We’ve also seen an industry where every single enterprise WLAN only manufacturer has been absorbed by those looking to address “access layer” technologies all in, regardless of physical medium. We saw Cisco mature the Wi-Fi portfolio with some pretty significant milestones:

Migration of APs running VxWorks to Cisco IOS
Cisco acquire meraki for their Cloud infrastructure offering
Rolling some pretty awesome tech from Navini into the core product offering (Beamforming)
Turning “real” spectrum analyzers from Cognio into everyday table stakes (CleanAir still can’t be beat!)
26 major WLC releases in the AireOS family (more on this below)
Converged Access (although we largely gloss over this milestone)
Cisco APs migrate from IOS to AP-COS (with it’s heritage in ClickOS from the meraki acquisition)
WCS to NCS to Prime Infrastructure to DNA Center management platforms
Merchant silicon from the 1242 days to custom silicone in Marvell radios, and back again to QCA/BCM based solutions intermixed with custom RF ASIC
Driving fixes back into 802.11 through custom Wi-Fi extensions in the CCX program (802.11r and others)
Countless forays into industrial and outdoor Wi-Fi solutions along with some pretty cool innovations (PRP over Wi-Fi, FSR, MRC, and on and on…)
Cisco transitioning their core WLC architecture over to IOS-XE and not screwing it up (frankly, like everyone expected them to do)

I’ll admit, it’s easy to beat up on Cisco – they’re a large target – but the fact remains that a very large percentage of Wi-Fi in the world today is driven by AireOS networks and it’s worth stopping down for a moment to acknowledge that Cisco devoted well over two decades of development and maturity into the product. Since we’re looking at the close of a generation, I wanted to share a list I’ve been working on for sometime now that marks each and every AireOS code name and the version/release it went with. It’s well known that the AireOS founder is enamored with wineries so all major release has been named after a winery – and here they all are, in alphabetical order:

Release	Version	Code
A	3.20	Amberhill
B	4.00	Beringer
C	4.10	Concannon
D	4.20	D-Cubed
E	5.00	Edgewood
F	5.10	Franciscan
G	5.20	Grgich hill
H	6.00	Heitz
I	Never built
J	7.00	Jwine
	7.10	Unnamed
K	7.20	Kenwood
L	7.30	LaReserve
M	7.40	Mosaic
N	7.50	NineHills
O	7.60	Oakcreek
P	8.00	Pineridge
Q	8.10	Quintessa
R	8.20	Riesling
S	8.30	Sherry
T	8.40	Testarossa
U	8.50	Uva
V	8.60	Veuve
W	8.70	Wente
X	8.80	Xurus
Y	8.90	Yara
Z	8.10	Zucca

Not sure why, but this fascinates me – 8.10 being the last release, did they run out of letters or wineries?

When Cisco launched the Catalyst 9800 almost two years ago, it was well acknowledged that they actually delayed the release more than once to allow time for the product to mature – integrating 2 decades of features into a new product take time and I must admit, Cisco has done a pretty fantastic job of keeping new features rolling over the past two years in both AireOS and cat9800 platforms – something that’s difficult to do (especially as we reflect on Converged Access). With this weekends announcements, it’s safe to say that new APs from this point forward will require Catalyst 9800 WLCs. Consider yourself warned, especially as we look into 2021 and 2022 with every one eyes forward on getting to 6GHz (Wi-Fi 6e). If you’re still on AireOS, regardless of where you may be in it’s (which has been significant), the not-so-new-anymore kid on the block is the Catalyst 9800 WLC. I won’t gush on endlessly about what others have written, but suffice it to say, if you’re not getting on the 9800 bandwagon, you’re being left behind. Get up on the IOS-XE based 9800 sooner rather than later and start understanding how your migration looks, especially around models of APs that are supported. Check out the EOS notices for the 3504, 5520, 8540, and Virtual WLC at these links, and check out some of the CCIE preparedness videos I helped with here. Regardless of where you’re at on your journey, if you’ve got virtualization resources available to you – you really should be running a 9800 in a lab, or really anywhere you can.

Filed under 802.11ac, 802.11ax (Wi-Fi 6), Access Points, Cisco, Meraki, Wireless, WLC

Cisco 802.11ax site survey (single AP method)

December 3, 2019 by scwifi 9 Comments

You may already be familiar with my Survey with Wi-Fi 6 APs workaround blog post previously where we used an AireOS WLC running on a second AP to do a site survey. Now that Cisco has launched the Embedded Wireless Controller (based on the CAT9800 platform), we can now use that functionality to do an APoS battery powered survey with a single AP! This is known as the Embedded Wireless Controller on Catalyst 9100 Access Points (or eWC for short). This is similar to 802.11ac wave 2 APs in that the WLC software runs on the AP after boot time, but the config model is notably different.

Prerequisites:

• Production 802.11ax (Wi-Fi 6) Access Point
This is unlikely to be an issue for most of you, but it should be noted that if you’re using a pre-production AP, it may not have the proper certificates required for this process. If you have issues with APs joining, please make sure you’re using a production AP.
• Local power source for your Access Point (this guide uses the Ventev VenVolt site survey battery pack)
• TFTP server (this guide uses the TFTP server Transfer from Adrian Granados)
• 802.11ax (Wi-Fi 6) Access Point (at the time of this writing, this is a c9115, 9117, c9120 or c9130 AP)
• A serial console cable to watch/configure your AP

Applying the correct image to the platform:

Step 1) Assuming your AP is currently in CAPWAP mode, you will first need to update the AP with the proper CAPWAP image prior to flashing it with EWC code. You MUST upgrade the CAPWAP image on the C9100 Access Points to AireOS 8.10.105.0 or IOS-XE 16.12.1s. Both these code versions are available on cisco.com.

Attach your AP to the VenVolt PoE out port. Boot your AP with the serial cable attached. Wait until you get to the AP prompt and configure the APs IP address to be on the same subnet as your workstation (192.168.1.2/24) using the following command:

AP7069.5A76.5460#capwap ap ip 192.168.1.2 255.255.255.0 192.168.1.1

Statically assign an IP address to your workstation (192.168.1.3/24). Put the update files into your TFTP server directory. Attach your workstation to the Ethernet port on the VenVolt. Run the following command to convert your AP to eWC mode:

For the 9115/9120:

ap-type mobility-express tftp://192.168.1.3/ap1g7 tftp://192.168.1.3/C9800-AP-iosxe-wlc.bin

For the 9117:

ap-type mobility-express tftp://192.168.1.3/ap1g6 tftp://192.168.1.3/C9800-AP-iosxe-wlc.bin

If you’re using a different AP, ensure you’re using the proper image file name (ap1gx) for your upload here. Once the AP has finished downloading the requisite code, it should reboot. At this point, you should be able to do all management from the GUI, although CLI commands for reference will be included later. If by chance you run into the following messages, it is likely your code was corrupted:

AP2CF8.9B21.50C8#EWC-AP in Recovery Mode...
Please use 'archive download-sw ewc-ap' to upgrade or rollback the controller image.
Please use 'show flexconnect ewc-ap launch-log' to check EWC-AP launch log.
 EWC-AP in Recovery Mode...

Download the code again and run the following command:

archive download-sw ewc-ap tftp://192.168.1.3/C9800-AP-iosxe-wlc.bin

Once the code has pushed successfully you should see the typical WLC config prompts.

        --- System Configuration Dialog ---

Would you like to enter the initial configuration dialog? [yes/no]:
Num of cpu cores     4
Maximum number of AP's supported   100

Step 2) Wait for the CiscoAirProvisioning SSID to show up in your networks list. It should be noted that in the first builds, this site survey mode may take a while (15 minutes) to show up for the first time. You may need to be patient during this part of the setup. Once the SSID shows up, it will include a unique SSID based on the MAC address of the AP to prevent confusion when multiple ME APs are being setup. Find the SSID that matches your AP and join it using the PSK “password”.

Step 3) Open up a new web browser – if the Day-0 web page doesn’t open up, go to https://mywifi.cisco.com/ and accept the self-signed certificate warnings. Log in using:

Username:       webui
Password:        cisco

Step 4) Define the following values in the webui. For site survey functionality, it is recommended to use:

Username:       admin
Password:        Cisco123
IP Address:     192.168.1.1
Subnet Mask:  255.255.255.0

Click + Add, and define a site survey SSID:

Click the Finish button.

Click Yes.

Step 5) Wait for the eWC to apply the configuration. In the eWC product, the WC code does not reload, but rather immediately applies the configuration. The radios should come immediately available.

Step 6) Once the SSID comes up, join it using your defined PSK, and open your web browser to https://192.168.1.1/ . To set the transmit power and channel of the radio, navigate to Configuration -> Access Points -> 5 GHz radio or 2.4 GHz radio -> select the AP. From here you can change the channel and transmit power of your APs radio by changing the Assignment Method from Global to Custom, setting the required values, then clicking ‘Update & Apply to Device”:

Step 7) Do your survey!

CLI reference:

For those of you that are more comfortable with the CLI method of configuration, once you finish Step 5 above, you can connect to the WLC by either a serial console session or by ssh. Once you’re at the CLI and have enabled, you should rename the AP as shown below for simpler CLI config:

WLC7069.5A76.5460#show ap sum

Number of APs: 1

AP Name                            Slots    AP Model  Ethernet MAC    Radio MAC       Location                          Country     IP Address                                 State        

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

AP7069.5A76.5460                     2      9115AXI   7069.5a76.5460  6cab.0562.e680  default location                  US          192.168.1.2                                Registered   

WLC7069.5A76.5460#ap name AP7069.5A76.5460 name ap

WLC7069.5A76.5460#show ap summary

Number of APs: 1

AP Name                            Slots    AP Model  Ethernet MAC    Radio MAC       Location                          Country     IP Address                                 State        

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

ap                                   2      9115AXI   7069.5a76.5460  6cab.0562.e680  default location                  US          192.168.1.2                                Registered   

WLC7069.5A76.5460#

You can then change the channel and tx power of the AP radio using the following commands:

ap name ap dot11 24ghz channel X
ap name ap dot11 5ghz channel X
ap name ap dot11 24ghz txpower X
ap name ap dot11 5ghz txpower X

For FRA mode APs, you can change the channel of the dual-band radio using:

ap name ap dot11 dual-band channel 1
ap name ap dot11 dual-band channel 140

Filed under 802.11ax (Wi-Fi 6), Access Points, Cisco, Surveying

APoS survey with Cisco 802.11ax APs

May 24, 2019 by scwifi 5 Comments

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

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.

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!

Filed under 802.11ac, 802.11ax (Wi-Fi 6), Access Points, Cisco, Surveying, Wireless

The Wi-Fi 6 elephant in the room

May 18, 2019 by scwifi Leave a comment

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…

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.

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.

Filed under 802.11ax (Wi-Fi 6), Access Points, Cisco, Spectrum, Wireless

Analyzing analytic offerings

October 7, 2018 by scwifi 6 Comments

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!

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).

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).

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.

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!

Filed under Access Points, Aruba, Cisco, Meraki, Packet Analysis, Wireless, Wireless Tech Field Day

AirCheck G2 gets a v3

September 21, 2018 by scwifi 2 Comments

You may recall my blog post year lauding the version 2 firmware for the Netscout G2. I’m very pleased that Netscout has continued product development, taking feedback from users (including myself) on ways to further improve the already-awesome AirCheck G2. I’ve been working with the v3 firmware for the AirCheck for a bit over a month now and I’m happy to report in with my new favorite improvements – all delivered via a software update under a current support contract!

1) Improved packet captures

One of the things I didn’t write about last time was the ability to do packet captures that was introduced in v2. Admittedly, it felt somewhat half-baked and there are two very important enhancements that make this the tool I always hoped it would be. Firstly, we get the ability to slice packets. Those of you familiar with packet captures will know that in the vast majority of cases, we’re interested with the beginning of the 802.11 frames (since the payload is commonly encrypted). The ability to slice packets means that we can get very valuable packet-level analysis without capturing the entire frame!

Packet slicing

Secondly (and leading directly into my next favorite thing) is a *much* easier way to get the actual packet captures off of the AirCheck. In the past (and in addition to dealing with file sizes that were needlessly cumbersome), you’d have to grab the AirCheck G2 Desktop software and hook your AirCheck up to a computer to copy the capture off. Now you can just plug in an ethernet cable and the upload the tests right into the Link-Live service that comes included with your AirCheck! From there, you can download the raw .pcap file for use in your favorite packet capture analysis tool (Omnipeek, CloudShark, WireShark, Wi-Fi Analyzer, etc).

.pcap files in Link-Live

2. Cloud (Link-Live all the things)

You may have guessed from my above comments that the Cloud enablement is right up there on my list of awesome things that this update brings. With a notable decrease in reliance on the Windows-only desktop application, the improved Link-Live integration now supports a whole slew of AirCheck uploads including:

Full AutoTest results
Session files
Screenshots
Packet captures (mentioned above)
Job, location, comments

Further reliance on the Link-Live portal is clearly a huge focus for the AirCheck team and they’ve delivered on many key integrations to help our field teams get data off of the AirCheck G2s in a timely fashion. In addition to being able to pull files off of the AirChecks enabled by Link-Live, the ability to push profiles lands squarely in the ‘awesome to have’ column. Being able to upload pre-configured profiles to your fleet units removes much of the inconsistencies that large teams can sometimes run across.

3. Over the network firmware updates

Last, but certainly not least of the new features, the ability to do over-the-network firmware updates means that you no longer have to have access to a USB cable and Windows machine just to get all of the future improvements that Netscout is clearly on track to deliver. For an awesome product that continues to get software based improvements that genuinely move the needle, this feature changes the game for getting current software onto our AirChecks. Simply plug the unit into a working network connect and click the ‘Check for Software Updates’ and you’re good to go!

Software Update

Way to go Netscout team for bring a truck load of features to an already indispensable tool. Making new features that people will actually use (as opposed to the bloat we commonly see) is not only a refreshing take from the Netscout team, but continues to make the AirCheck G2 the best in Wi-Fi handheld triage tools. If you’ve not gotten your hands on an AirCheck G2 by now, you’re missing out.

Filed under NETSCOUT, Surveying, Wireless

Management Frame Detection?

August 30, 2018 by scwifi 1 Comment

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/

Filed under 802.11ac, Access Points, AirMagnet, Aruba, Cisco, NETSCOUT, Security, Wireless, Wireless Tech Field Day, WLC

Meraki gets smart

April 6, 2018 by scwifi 1 Comment

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:

Make sure that the antenna cables are attached to the proper port using the silkscreen indicator on the RP-TNC connectors
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.

Filed under 802.11ac, Access Points, Cisco, Meraki

← Older posts