10 reasons to take another look at 2015 Cisco Mobility

Let’s face it, Cisco is huge. They’re massive, and occasionally they get things wrong. If you’ve strayed away from Cisco in the past year (or longer) because of a specific issue or gap, it’s high time you took another look. The Cisco Mobility offerings today are a far cry from what they were just an easy year back. Here are 10 great reasons to go get reacquainted with the 2015 Cisco Mobility offerings:

1) 5520/8540 WLCs

The introduction of a Converged Access 60G solution highlighted the gaps in the WLC portfolio in the 20/40G of throughput range. Both of these new controllers (one 20G, one 40G capable) are based on the more mature AireOS codebase running 8.1 and later. While this doesn’t mark an EOS/EOL announcement for the 5508 (clocking in at 8G), it does give that 7 year old platform some good alternatives for lifecycle management.

2) Prime Infrastructure 2.2 then 3.0

Ever since WCS was taken over and moulded into the NCS then Prime Infrastructure products, it’s always bore the scars of a legacy mired in Adobe Flash performance issues. Couple that with a dramatic uptick in features and you’ve got a recipe for disaster. The new versions of Prime Infrastructure are actually performing as well as they should be starting at about the 2.2 version and the new UI of Prime Infrastructure 3.0 completely moves away from Flash and demonstrates a significant re-think of the product – including ‘Make a wish!’.

3) 802.11ac wave 2

Let’s not forget the fun stuff – APs and radios. With competitively positioned 802.11ac Wave 2 products, Cisco is staying in the lead of the latest and greatest standards. With impressive throughput numbers, multiple gigabit uplinks, and fancy new features like MU-MIMO, the 1830/1850 APs are clearly paving the way for the next generation of some pretty obviously numbered future platforms. The only question is, what does Cisco have in store for us next?

4) HALO

No, not the game – the new Hyper-Location Module and antenna array. Cisco is delivering on the promise that the industry made to us oh so many years ago about leveraging your WiFi network as a platform for tracking your enterprises assets. Touting down to 1 meter accuracy, this module for your AP3600/AP3700s will take your location fidelity ‘to the next level’.

5) Mobility Express

Those that don’t like having a bare metal controller and don’t see the need for controller based features (such as centralized data plane), we now have a ‘controller on the AP’ option! This allows us to focus on the smaller deployments without the extra cost and complexity (such as it is) for those customers. This isn’t a ‘one size fits all’ approach that we’ve seen in the past, but rather an evolution of a well thought out strategy to bring enterprise features to every market segment.

6) UI improvements

Along with the Mobility Express product, the ‘metal WLCs’ are sporting a new user interface and out of the box setup experience (Day 0 and Day 1 support). If you’ve felt the WLC interface was a bit dated in the past, go take a gander at the plethora of new graphs, charts, and actual usable data about your infrastructure – all without having to goto a larger NMS platform!

7) CMX Evolution

The MSE product is finally getting some legs under the advanced location pieces. This easy to deploy ‘for everyone’ product starts to bring some pretty insightful analytics to any sized deployment – all the way down to a ‘no maps required’ presence analytics and all the way up to a Hyperlocation enabled, social media engagement platform. With both on premises and cloud based offerings available, it really is very easy to start getting very insightful data out of any sized network.

8) CCIE Wireless version 3

The dated CCIE (Cisco Certified Internetwork Expert, Wireless) exam has been updated to include software and hardware platforms from this year. You can now tackle one of the industries most challenging certifications on contemporary labs that are actually relevant to solutions you’re deploying today!

9) UX domain APs

See my previous blog on the topic for a more in-depth look at the UX products, but for those buying and deploying APs spanning multiple countries, this is a pretty good way to reduce a ton of deployment and ordering complexities. By standardizing on a single SKU globally, you can make quick work of some of the logistics nightmares of the past.

10) Cisco ONE licensing

Yes, licensing is boring, complicated, and expensive. Cisco ONE addresses all three of those pain points in one easy go. With a ‘count the AP’ approach to licensing, you can now start to take advantage of all of the above products in an easy to consume, deploy, and license fashion – without breaking the bank. For example, if you wanted to replace your old WLC with a new one, in the past, you would end up repurchasing your AP licenses. In this model, all products start at 0 APs and you pick the size that’s right for you – at any scale. Pick the solutions you want to deploy: ISE, Prime Infrastructure, advanced location analytics, etc – and go! A significant departure from the traditional licensing model in Cisco-land.

I know that a ‘recap overview’ blog sometimes seems too lofty, but there really is a ton to see if you’ve been unplugged from the Cisco world over the past year or so. Take a deep breath and plunge back in at any level and you’ll find something new that wasn’t there before. The Cisco ship sometimes turns slowly and sometimes it’s easy to forget that there is innovation happening all over the mobility space in San Jose.

Disclaimer: I was part of the Wireless Field Day 8 delegation to Cisco where we learned about several of the above topics. For more information on Cisco’s appearance at WFD8, go check out the video!

UX Domain APs

In the wireless world, we’re constrained by regulatory requirements. These are, at their core, different rules by which we must abide by when we’re operating wireless equipment. Each country has their own set of requirements and restrictions – each manifesting itself in some iteration of channel availability or power limitation of some sort. Until now, this meant that each country had to have it’s own regulatory SKU to prevent a wireless professional or other ‘non-professional’ installer from exceeding or violating that countries requirements. Cisco has worked around this particular issue with a universal SKU Access Point. In the past you would order a specific AP for a specific country. The astute Cisco-configurator would identify the country code in an AP model number (A for North America, N for Mexico, I for Egypt, etc.). The gory details of country code mapping changed occasionally which meant that it was almost a full time job for international companies to wrangle which SKU went where.

Note the UX domain model of AP, last in the list.

UX domain model of AP, last in the list.

Enter the ‘UX’ SKU of AP. These APs are designated by the country code ‘UX’ and are universal SKU APs, meaning one SKU can be installed in any country. The way we’re able to do this is by way of software defining which country the AP is operating in. Now, the FCC won’t just allow you to ‘claim’ a country code, so there are some specific restrictions to deploying a ‘world capable’ AP. Today, this means tying the AP to a specific user, then using a non-hacked device to determine GPS coordinates of where the AP is installed to ‘prime’ or ‘unlock’ the AP based on what country it’s physically located in.

This blog will review the two ways to ‘prime’ a UX domain AP and get you up and running in no time at all! The first thing you need is an un-compromised (not jailbroken) device with both online capabilities (an Internet connection) and GPS capabilities. Enter the smartphone. Most of todays smart phones meet this requirement:

Step 1) Head to your devices respective app store and grab the Cisco AirProvision application.

Don't ask me what the Android store looks like!

Cisco AirProvision in the Apple Store

Step 2) Plug in your AP and let it join to your WLC (this assumes you have things like discovery already taken care of). There are no UX specific join requirements so if you have regular Cisco APs joining your WLC, this part should be easy. Note that at this point the AP will be flashing ‘bad colors’ at you despite it’s radios being up and operational.

Unprimed AP

Unprimed AP

Step 3) Enable ‘Universal AP Admin’ on one of your secure (PSK or .1x) SSIDs that has internet access (WLAN tab -> WLAN ID -> Advanced tab -> ‘Universal AP Admin’).

Universal Admin

Universal AP Admin

Step 4) Join the above SSID on your unprimed AP.

Step 5) Launch the app on your smartphone and log into CCO (page 1) then your WLC (page 2).

Step 6) Click Configure!

Click Provision!

Configure!

That’s it! It’s a relatively straightforward way for your AP to know what country it’s at.

Primed AP!

Primed AP!

The good news is that you only ever need to prime a single AP in this fashion. Once it’s primed and comes back online, it will automatically include in its Neighbor Discovery Packets (NDP) UX domain info. Any other unprimed AP in earshot of these discovery packets will hear them and automatically pickup the country code of the already primed AP! Once you have primed a second AP by way of the NDP the priming sticks with the AP and you can then prime others off it in a cascading fashion – you can even re-prime the AP that you previously primed with the app!

NDP Primed AP!

NDP Primed AP!

While this may seem like unnecessary work for those that are single country entities, those that have to operate in multiple country codes may find that simplified ordering is a lifesaver – assuming your installers have a smart phone and a free CCO account. This can also help if your company accidentally ordered several hundred of these and you don’t want to RMA them. Remember that the country code priming sticks with the AP across reboots, regardless of location (unless you re-launch the mobile app to reconcile your installation).

Things to remember:

  • Your smartphone must allow location access (it has to know where you’re at after all).
  • You must join the SSID on your unprimed AP. Joining on a different AP won’t help you any.
  • You have to have 2.4GHz enabled on your WLC and SSID – an unprimed AP operates in 2.4GHz only so you have to be able to see your SSID.
  • You must have the country code you’re provisioning enabled on the WLC (Thanks Andrew!).
  • Your SSID must have internet access to allow CCO to be accessible.
  • NDP priming only works on other NDP primed UX domain APs or app primed UX domain APs – not ‘regulatory domain APs’.
  • Did you screw something up? You can reset the UX domain AP by performing a ‘Clear All Config’ on the AP page in the GUI (along with all of it’s other settings)!
  • When your AP primes, it reboots. This is the same if you use the app or NDP. Don’t be surprised if you app-prime one AP and it cascades a bunch of NDP reboots.
*Oct 26 14:16:35.003: %CLEANAIR-6-STATE: Slot 0 enabled
*Oct 26 14:16:41.783: %CLEANAIR-6-STATE: Slot 1 enabled
*Oct 26 14:17:08.719: %CDP_PD-4-POWER_OK: Full power - NEGOTIATED inline power source Writing out the event log to flash:/event.log ...
*Oct 26 14:19:50.339:  **************************** UNIVERSAL AP PRIMING ***********************
*Oct 26 14:19:50.339:  Action completed: regulatory domain values 0x0 0xB are written. Now trigger AP reload
*Oct 26 14:19:50.507: %SYS-5-RELOAD: Reload requested by UAP DIE process. Reload Reason: UNIVERSAL AP PRIMING SUCCESSFUL .
*Oct 26 14:19:50.527: %LWAPP-5-CHANGED: CAPWAP changed state to DOWN
*Oct 26 14:19:50.727: %CLEANAIR-6-STATE: Slot 0 down
*Oct 26 14:19:50.727: %CLEANAIR-6-STATE: Slot 1 down Write of event.log done

You can see above the log from an AP that was previously online. This AP was unprimed when it powered up, came online with radios up and then after several minutes received the NDP prime message and auto-rebooted. Easy, but potentially disruptive!

Cisco releases new WLC UI, Changes default values (finally)

Cisco released WLC code version 7.6.120.0 which brings with it (among other things) a new User Interface for the 2504 WLC. When you use the new simplified setup, it also changes many of the default values that haven’t yet been enabled by default in the base code. The new default values are:

Aironet IE: Disabled
DHCP Address Assignment (Guest SSID): Enabled
Client Band Select: Enabled
Local HTTP and DHCP Profiling: Enabled
Guest ACL: Applied
CleanAir: Enabled
Event Driven RRM: Enabled
Event Driven RRM Sensitivity, 2.4GHz: Low
Event Driven RRM Sensitivity, 5GHz: Medium
Channel Bonding, 5GHz: Enabled
DCA Channel Width: 40MHz
mDNS Global Snooping: Enabled
Default mDNS profile: Add better printer support, Add HTTP
AVC (no Control, only Visibility): Enabled*
Management via Wireless Clients: Enabled
HTTP/HTTPS Access: Enabled
WebAuth Secure Web: Enabled
Virtual IP Address: 192.0.2.1
Multicast Address: Not configured
Mobility Domain Name: Name of employee SSID
RF Group Name: Default

*AVC stands for Application Visibility and Control. Control means remarking or blocking – for the purposes of the default setup, you’re inspecting only, Control is disabled and must be enabled manually. This also requires a current boot loader which should only be important if you’re setting up an older unit that’s been cleared.

You should note that to get these default values auto-set, you must use the new setup wizard – if you do the regular CLI setup of your controller, or if you just upgrade an existing controller without clearing it’s config, these are not set. You should also note that, for now at least, this only applies to the 2504 controller, not the 5508, WiSM2, 7510, 8510, or Virtual WLC platforms.

WPA/TKIP only going away in Cisco WLC release 8.0

Cisco is readying the next major release of their WLC code, version 8.0. At the advocation of the WFA, this will bring with it a very significant change in security capabilities that you may find impacting if you’re caught unaware. In an attempt to raise awareness, Cisco has approved an discussion of this change first mentioned here. Cisco, in accordance with the new WFA guidelines, will no longer be allowing an SSID configuration with WPA/TKIP only security. If you are currently using an SSID that has WPA/TKIP only security, your configuration will automatically be updated to enable WPA2/AES connectivity as well as WPA/TKIP. You may want to start validation testing now if you are currently supporting legacy devices on a WPA/TKIP only SSID today. The easiest way to ensure you’re not caught by this change is to enable WPA2/AES along with WPA/TKIP and check to make sure your devices still behave as expected. I have confirmed in the lab that this change will be automatic:

WPA-TKIP only configuration pre-8.0

WPA-TKIP only SSID configuration, Pre-8.0

WPA2-AES added post-update

Same SSID with WPA2/AES enabled post-update.

 

To summarize of the variety of allowed and disallowed potential configuration options you have available and if they’ll be supported in WLC 8.0:

WPA1-TKIP (Disallowed due to eliminating TKIP)
WPA1-AES (Allowed by Extension Policy)
WPA1-TKIP/AES (Disallowed since not used in conjunction with WPA2-AES)
WPA2-TKIP (Disallowed due to eliminating TKIP)
WPA2-AES (Certified and allowed)
WPA2-TKIP/AES (Disallowed due to WPA2-TKIP)
WPA1-TKIP + WPA2-TKIP (Disallowed – no AES support)
WPA1-TKIP + WPA2-AES (Certified and allowed)
WPA1-TKIP + WPA2-TKIP/AES (Disallowed due to WPA2-TKIP)
WPA1-AES + WPA2-TKIP (Disallowed due to WPA2-TKIP)
WPA1-AES + WPA2-AES (Allowed by Extension Policy)
WPA1-AES + WPA2-TKIP/AES (Disallowed due to WPA2-TKIP)
WPA1-TKIP/AES + WPA2-TKIP (Disallowed due to WPA2-TKIP)
WPA1-TKIP/AES + WPA2-AES (Allowed by Extension Policy)
WPA1-TKIP/AES + WPA2-TKIP/AES (Disallowed due to WPA2-TKIP)

Other SSIDs and security configurations are not impacted, including Open SSIDs, any SSID that currently has AES enabled, and WEP SSIDs.

 

UPDATE: Due to user feedback, Cisco and the WFA finally settled on making the above restrictions in the GUI only. If you still have a business need for a WPA/TKIP SSID, you can configure it from the CLI. If you were building an SSID on a Cisco WLC with an ID of 6, you would use the following commands for example:

config wlan create 6 TKIP-ONLY
config wlan security wpa wpa2 disable 6
config wlan security wpa wpa1 enable 6
config wlan security wpa wpa1 ciphers tkip enable 6

Using the show commands you can validate that this configuration took at the CLI:

show wlan 6

Wi-Fi Protected Access (WPA/WPA2)…………. Enabled
WPA (SSN IE)…………………………. Enabled
TKIP Cipher……………………….. Enabled
AES Cipher………………………… Disabled
WPA2 (RSN IE)………………………… Disabled

Bridging networks on a VM

So, you’ve got your shiny new Mac and you’re in that ‘in-between’ time where you’re running a VM to support all of your Windows needs. You decide that your VM needs to be connected to the same Layer 3 network as your physical box so you decide to change your VM network settings from ‘NAT’ to ‘Bridged’. This seemingly simple configuration change has some pretty significant ramifications in the Cisco wireless world however so you may be shocked to find out when you take your beloved Mac back to work that your VM stops getting an IP address! As it turns out, there is a feature enabled by default on a Cisco lightweight wireless infrastructure that is spelled out thusly:

In the controller software Release 5.2 or later releases, the controller enforces strict IP address-to-MAC address binding in client packets. The controller checks the IP address and MAC address in a packet, compares them to the addresses that are registered with the controller, and forwards the packet only if they both match. 

Since your Mac(intosh) uses a single adapter (your WLAN adapter) for the connection to the network, the controller only sees a single MAC address. This means that it will only let a single IP address talk on the network since it’s expecting a 1:1 mapping of MAC address to IP address. The quickest way around this is the following global command on your WLC:

config network ip-mac-binding disable

Which will remove this 1:1 mapping expectation. Don’t forget to save your config and you should be good to go with IP addresses issued via DHCP to both your real machine and the Virtual Machines living behind the bridged VM network!

It should also be noted that many ‘security appliances’ serving as your DHCP server will refuse to issue multiple IP addresses to a single MAC address, effectively recreating identical symptoms (a VM that get’s no IP address). As far as I know, there is no workaround aside from not using a security appliance for your DHCP server. This is believed to afflict both Palo Altos as well as ASAs and is likely to impact anything else under the guise of a ‘security appliance’. Your best bet is to try and put DHCP services on a real server (Windows DHCP or Linux ISC-DHCPD) or try running it in IOS on your next hop Catalyst switch. You *do* have a next-hop Catalyst switch, right? 🙂

The Unstoppable MetaGeek – now with CleanAir!

Rarely does such an organization come around that expresses it’s agility and prowess with as much regularity as MetaGeek. The most recently of which is their ability to use Chanalyzer Pro (their premium Spectrum Analyzer software) to talk to the Cognio chipset in a Cisco CleanAir Access Point. PC based Spectrum Analyzers have had a sordid history to say the least. Way back when, Cognio made what you would call ‘the best of the best’ PC based Spectrum Analyzer. This took the place of many of the bulkier, more expensive Spectrum Analyzers and proved to the world that a) it was important to get Layer 1 visibility for enterprise WLANs and b) that they could make it affordable for most services based partners. Everyone OEM’d the Cognio analyzer, AirMagnet, Fluke, and WildPackets. Along came Cisco. They purchased Cognio, killed off all of the OEM agreements, rolled the hardware into their Access Points, and started selling the Cognio product with the Cisco name on it (Cisco Spectrum Expert). Unfortunately, they didn’t do much with the CardBus product and let the non-AP components stale. The aging interface form factor left quite a few holes in the market and along came a few people here and there to make it all shake out like this (generally):

  • Cisco Spectrum Expert: Highest resolution, CleanAir AP and CardBus form factor, Cognio based
  • AirMagnet Spectrum XT: Middle resolution, USB form factor, bandspeed based
  • AP based Spectrum Analyzers: Low resolution, integrated into many APs, Atheros based
  • MetaGeek Wi-Spy: Low resolution, USB form factor, keyboard controller based

Ryan and team over at MetaGeek did an excellent job of using very affordable components to give us an alternative to the aging CardBus adapter and the newer, more expensive AirMagnet adapter. They were an awesome product for the money but never really achieved huge market penetration due to the fact that the Cognio and bandspeed products still offered higher resolution. With the Cognio hardware all locked up in the Cisco Access Points, it seemed inevitable that we’d never have a good way to access it. Imagine our surprise when at this years Cisco Live event, MetaGeek was there – showing off their integration between Chanalyzer and the CleanAir Access Points! Ladies and Gentlemen, this is the *exact* same Cognio hardware, high resolution Spectrum Analyzer goodness that we all know and love from the old days. When I first heard about this, there was much trepidation about MetaGeek perhaps not being able to address the ‘full power’ of the Cognio (ahem, CleanAir) chip in its rawest form, but I’m here to tell you, when compared side by side with a legacy CardBus based Cognio adapter, the data is identical! The user interface is the updated, Chanalyzer interface with all of the modern enhancements they’ve made over the years with the WiSpy products, but you’re using the high-fidelity data that Cognio gives us. Here’s how it works:

You can connect to a CleanAir AP that is autonomous or lightweight (registered to a WLC) and it can be either servicing clients or in dedicated ‘SE-Connect’ Mode. You get the highest resolution, widest image when it’s in this last mode so let’s start there. Log into your controller, select your AP from the wireless tab and change it from ‘local’ to ‘SE-Connect’. Click Apply and let the AP reboot and join back to the WLC.

Screen Shot 2013-08-12 at 9.02.03 PM

Once it’s joined back, select the AP again and you’ll find both the IP address of the AP and something called the NSI key:

Screen Shot 2013-08-12 at 9.08.06 PM

Lauch Chanalyzer Pro with CleanAir and goto the File Menu. Select the intuitive ‘Connect to a CleanAir AP:

Screen Shot 2013-08-12 at 9.12.25 PM

Once you do that, enter the values from the AP page that you previously saw including the IP address, NSI key and a friendly name for this AP:

Screen Shot 2013-08-12 at 9.13.07 PM

Once you’ve done that, mash the Connect button and you’ll start to see the familiar Chanalyzer Pro interface with all of the wonderful resolution we all grew so fond of all those years ago! For reference, I ran Chanalyzer Pro with CleanAir on the same machine at the same time as a Cisco Spectrum Expert instance (using the CardBus adapter). Aside from the waterfall flowing up in the Cisco product, and down in the Chanalyzer product, you’ll see striking similarities in the respective waterfall views:

Screen Shot 2013-08-12 at 9.21.24 PM

Screen Shot 2013-08-12 at 9.21.41 PM

and at the same time, getting all of the other awesome details out of the Cognio SaGE like interferer auto-classification and AirQuality Index. Proving once again that MetaGeek are the top kids on the block when it comes to innovation and integration – but don’t take my word for it, head on over to MetaGeek, grab yourself a copy and give it a spin!

Full Disclosure: As an delegate of the Wireless Field Day event, I was given a copy of Chanalyzer Pro with CleanAir to play with without promise or commitment to write anything – much less something positive. 🙂 MetaGeek is a regular supporter of the Tech Field day events and generally makes awesome products and is regularly engaged in Social Media – you should go follow them at @metageek and catch up on the NoStringsAttached Show where Blake Krone and I also talk with MetaGeek about Chanalyzer with CleanAir!

Aruba wants you to stop buying the AP-134 and AP-135. Offers no alternative.

Every once and a while, I stumble across articles that make no sense, are poorly worded or constructed, or flat out wrong. Last week, I ran across one such article that was so out of left field that I felt compelled to address it directly here in my own words. The article is over on the Aruba Networks official blog site (presuming it’s still up). Take a moment, head on over and give it a read (article preserved here for posterity). I was so flabbergasted by the article and its combination of FUD and flat out incorrect information that I used the ‘leave a comment’ link on the bottom. Once I did that, it dawned on me that my comments would likely never get posted – I then realized that I have my own forum to respond to this in, so the next portion of this blog post is the comments I left (with a few typographical and edits to make it flow):

Begin reply post

Wow – there is so much FUD in this article, it’s laughable.

Regarding the 1252 comment:

Remember the Cisco 1250 access point? This pre-standard AP offered future-proofing with an upgradable 802.11n radio meeting the ratified standard. It didn’t work out as it was costly and difficult to upgrade, and didn’t meet the promised performance benefits. 

This is flat out untrue. It ‘didn’t work out’ because it didn’t *need* to work out. The 802.11n pre standard was rolled into the final 802.11n spec. This (upgradability) was only there to ensure users that, in the event the specification was not implementable in the 1252 hardware, that they had an option to field upgrade the units. The performance was on par with other first generation 802.11n products and the 1252 was the wifi alliance test bed for compatibility – it was basically *the* reference 802.11n platform for a very long time.

Difficult to deploy: The 3600 11ac module must plug into the base of the access point, exactly where the mounting brackets are located. This means users will need to remove a deployed AP from operation. This is not a simple plug-in but more akin to opening your laptop for a RAM upgrade. 

Have you actually *seen* the 802.11ac module or a 3600? There is a piece of tape on the back of the AP and two thumb screws. This is more like replacing the battery in your laptop instead of opening it up for a RAM upgrade. This upgrade also will not compromise the thermal venting that is required in lesser manufactures Access Points since the main unit remains sealed.

Lack of promised performance: The IEEE 802.11ac standard promises increased performance over 11n technologies, but the 3600 11ac module’s throughput is dependent on its two-year old processor and RAM, which only scales to 11n rates. This means that although you will be able to connect with newer 11ac clients, there will be questionable increase in performance by doing so. Why spend money for increased performance when you won’t notice it? 

Really? You’ve done performance testing to empirically validate your claims? No? I didn’t think so. Cisco knew well in advance that 802.11ac was coming and the CPU and memory in the 3600 is significantly greater than in the 3500 – specifically for this reason. Until you can show us numbers to back up your vapor-stats you have no evidence that the CPU/memory subsystems of the AP will hinder its performance.

Constrained RF: The 3600 11ac module has its own antennas, and since Wi-Fi rates depend a great deal on antenna design, shoe-horning antennas into the small space of the module will yield less than optimal performance to clients. The result will be your 11ac clients will connect to stronger RF signals from 11n radios. 

Have you discussed the RF design characteristics of this module? Do you know how it will integrate with, instead of replace or work against, the (integrated) 802.11n radio? You assume this will be a discreet radio operating independently of the 802.11n radio. Don’t assume – know. Once you can declare the design is somehow faulty and back it up with block diagrams from Cisco on how the module will (or won’t) interoperate with the host AP, you’re basically guessing and spreading FUD.

Inconsistent feature set: The 3600 11ac module will use a new, untried chipset that may be incompatible with existing Cisco WLAN controller code. So if you add the 11ac module, you have the same hardware, but different features. That will lead to a management challenges and increased operational expense. 

The mindset of ‘don’t move because it’s a new chipset’ or ‘it may require new code’ is a completely invalid conversation. When Aruba releases its 802.11ac AP don’t you expect it to be a) a new chipset or b) to require new code? This is going to happen for every infrastructure manufacturer – Aruba included.

More upgrades coming: The 3600 AP itself requires you have the latest 5500 series or WiSM2 controllers as well as NCS management. So if you have older 2400, 4000, WiSM or WCS, it is that time to write your Cisco tax check again. Make it out to, “Cisco Catalog of Compromise”. And consider this- the 3600 11ac module is pre- standard and will not meet promised performance increases, so you will likely be replacing those 3600 APs at some point in the near future. 

You position the requirements for the 3600 as having a very narrow list of supported controllers (which is misleading) – it is also supported on the 7500 controller, the 2504 controller and the SRE controller. Are you telling me that every modern Aruba AP is supported on every past Aruba controller? At some point you have to lifecycle manage your gear – even Aruba. I don’t even know what a 2400 is.

All told, the expectation of having a Cisco 3600 AP + module will a) give you better performance today with 3 spatial streams and the cost of the module plus the 3600 will be far less expensive than purchasing an Aruba 3 SS AP today and replacing it with an Aruba 802.11ac AP tomorrow. There is no upgrade assurance with the Aruba. The message is loud and clear – if you’re an Aruba customer, do *not* purchase the AP-135. You will end up needing to forklift it out when you move to 802.11ac next year. Buy a Cisco 3600 + 802.11ac module and you’ll have spent far less money than buying two Aruba Access Points (1 now, 1 later).

-Sam

End reply post

Now, I realize it’s laughable to infer that Aruba is advocating you not purchasing their flagship Access Points and it’s a leap assume that since Aruba has no upgrade investment protection that this means that you should stick with your old Aruba equipment, but this leap is a small step – more akin to jumping off of the bottom step of your stairs to the ground floor. The leaps that Aruba makes regarding 802.11ac and the module from Cisco are more akin to Arubas entire executive team finding the tallest building in San Jose and jumping off it all the while waving their fists in the general direction of Tasman Drive. Shame on Aruba for not fact checking their article. Shame on Aruba for spreading FUD. Shame on Aruba for picking a fight with baseless facts and accusations – declaring facts about a product that they’ve not even laid hands on.

-Sam