Aruba forces customers into Cloud: Offers no way out

Authors note: Aruba has addressed this satisfactorily by removing the offending release of code. Further details are available in the comments section of the post below. This header was added as a post-script to the original blog which remains below for posterity. Well done Aruba.

Software updates are a matter of life. Developers and coders aren’t perfect, bugs need to be fixed, new features need to be rolled out, new hardware needs to be supported. As networking professionals, we’ve come to terms with the sometimes continual churn that patch vehicles have enabled – the Internet as a distribution mechanism has made it commonplace for manufactures to ship incomplete features or functionality under the guise of ‘by the time you complain about it, we’ll have a download ready to fix it”. They all do it. We all consume it.

Sometimes a manufacturer does something so egregious and underhandedly reprehensible that it simply cannot be. Aruba release their 6.4.0.0 ArubaOS on Feb 15th, 2014 and snuck in a ‘phone home’ feature. They state twice that they’re enabling this feature by default:

Once buried on their dashboard if you happen to navigate to their code by clicking on the words in their tree, not the ‘+’.

You'll miss the warning if you use the boxes!

You’ll miss the warning if you use the boxes!

The second is in their release notes. I applaud their efforts to make their customers aware that they will be changing the default values in their release notes, but the download page navigation needs some help. Their release notes clearly state:

The PhoneHome Automatic Reporting feature is enabled by default. PhoneHome feature can be disabled by selecting the Disable option under Maintenance > Aruba TAC Server section of the WebUI.

What they do not tell you is that even if you have explicitly disabled this option previously, when you update your code to the afflicted 6.4.0.0 build, it automatically re-enables this feature without warning you! Aruba intentionally snuck in an information gathering option and mislead their customers by stating that it was only enabling the ‘feature’ by default. In common english, this means when you’ve accepted the default settings – for example on a new build or a controller default, this option will be enabled. What they did not tell you is that there is no ‘opt-out’ way of having this turned on during a code update! They certainly give you guidance on how to disable it post-installation, but by that point in time, it can safely be assumed that your controller has phoned home and divulged all of your enterprise wireless configurations – information that you may not want to send to them – such as your PSKs, your RADIUS shared secrets, your default local administrator credentials – all without warning their unsuspecting, and all-too trusting customers, that Aruba was going to be maintaining a list of their most secret enterprise data.

Aruba is secretly compiling data from all of their existing enterprise customers regardless of any opt-out that was previously set.

What if your company had a security policy in place that stated that no configurations were to be shared outside of your organization? What if you had no Cloud strategy? How does having Aruba keep a copy of your configuration expose your organization to compliance issues? How will that impact FIPS compliance? Seemingly no one at Aruba cares about these issues and as far as I’m aware, there are only two ways to prevent this from occurring – and both need to be planned for before you update your software:

  1. blackhole or ACL off your controllers from talking to the Aruba cloud until you can log into the controller.
  2. disconnect your controller from the network during your update and console into it to undo the command.

Either way is intrusive and difficult to manage and if you were not aware of this data-heist prior to your update, you have no way of confirming if your data has already been compromised. In my opinion Aruba needs to do damage control here real-quick like and:

  1. Pull the malicious and infected code off of their downloads section immediately.
  2. Apologize for negligently harvesting customer data.
  3. Clearly articulate what customer data was stolen and how it was stored.
  4. Clearly articulate how long once a controller has come online that it ‘rats your configs out’ to the manufacturer.
  5. Give customers the option to have their data removed from Arubas servers and have a third party audit this removal for confirmation.
  6. Modify the code to obey previous opt-out configurations and re-post it.

Until then, you may want to let your SOC, CTO, IT Director, or resident person in charge that if you did the 6.4.0.0 code update from Aruba that you should consider your network keys, shared secrets, and local admin accounts compromised and start working on a remediation plan immediately.

MythBusters WiFi: Xirrus

I’ll be the first to admit that when I see something ‘out of the norm’ I shudder and have a knee-jerk reaction that is not always positive. There is so much success around the tried and true enterprise approach to wireless of using omni directional antennas that when you see someone intentionally deviate from it, it can be jarring to say the least! I’ve had the pleasure to be present at the Xirrus Wireless Field Day sessions for WFD5 and WFD6 and I can honestly say that they did a superb job of taking a contentious topic and addressing it head on. For those that are unfamiliar with the Xirrus product, their unique approach to wireless is to stack multiple Access Point radios into a single housing and use highly directional antennas to create an ‘Umbrella Corporation logo’ of coverage:

Image likely copyrighted by Capcom

(it should be noted that I do not believe that Xirrus is somehow evil, involved in genetic engineering, or otherwise a bad company – the logo is simply an easy way to represent a high degree of directionality from a centralized point)

Adding multiple radios into a single housing is not a unique approach. Most everyone on the market starts with two radios in their Access Points and you can even find a handful of three-radio solutions, but Xirrus takes this approach to the next level by stacking as many as 16 radios into a single Access Point! The challenge that other manufacturers do not need to address is overlap. In a standard two or three-radio approach, you typically operate one radio in 2.4GHz and the other in 5GHz (and for those rare 3rd radio guys, they usually stick that radio in monitor or listen-only mode). Tack some omni directional antennas on those bad boys and you’ve got yourself an AP! Xirrus however, intends to have multiple radios in a single AP operate on in the same frequency. This presents some challenges about the efficiency you can gain from having more than one radio in the same frequency in the same physical package (AP). At WFD5, there was much gnashing of teeth regarding how you accomplish this in one package. I’ll not go over the gory details, the video is posted here. Xirrus came back to WFD6 and brought with them their Director of RF Engineering, Avi Hartenstein and tacked the conversation head on.

My goal was simple with this post. I wanted to prove that directionality does exist in the Xirrus product once and for all. I was able to acquire a 4 radio array and decided that the best approach to visualize this purported phenomenon was to actually survey with an AP in an area with no obstructions (scientific, no?). I took the array, statically assigned one of the radios to a fixed channel, turned its power down to -15dBm (yes, they go *that* low!), and took it outside. The results speak for themselves:

 Umbrella logo likely copyrighted by Capcom

Ladies and gentlemen, you saw it here first (or maybe not) – the myth of the Xirrus wedge is real! You can see near the bottom of the image where the AP was placed (at random orientation). I peeled this wedge view out using Ekahau’s Site Survey application after quite a walk outside in the cold. This directionality is fairly easy to see even with my coarse sampling outside. It should be noted that it will be near impossible to visualize this dramatic of a wedge indoors however due to the prevalence of those pesky attenuators otherwise known as walls and furniture.

I’ve seen my fair share of wireless deployments, I know what I’m comfortable with, I know when I move outside of my comfort zone. An experience I reference often is an educational facility that was using directional patch antennas indoors on 10 ft ceilings pointed at the ground. While this is a startling design, when I dug deeper into their design methodology, I discovered that they surveyed using the exact model of antenna and AP that was deployed, correctly visualized the resultant zone of coverage, and validated that this met their applications need. While not a solution I would lead with, there was no fault with their design methodology or implementation, and the infrastructure operated as designed. When you tackle a Xirrus deployment, I would advocate the same approach: understand your needs (throughput, density, coverage, etc), and design to meet those needs using the gear you will be deploying. Survey what you deploy, deploy what you survey. In the Xirrus world, this presents a few design choices to consider:

1) Orientation of the AP.

The Xirrus array has a compass in it. Use this compass to determine the orientation of your array during the survey and ensure that when it gets deployed that this lines up correctly (use the logo on the housing if you need to).

2) Oversubscription.

You must pay close consideration to the number of uplinks to your array and balance this with your deployment expectations. Oversubscription is nothing new so don’t let this scare you – just be aware that you’re moving your uplinks (and potential bottlenecks) further up the line (closer to the AP). This is going to be particularly important as you consider updating your array to newer technologies such as 802.11ac.

3) Powering the Array

Ensure that you have made concessions for powering the array. This will likely require an external power injector but sourcing them along with the array should not be problematic.

4) Antennas change with the modules.

One of the most insightful things I learned from the WFD sessions are a reinforcement that the antenna is part of the radio module. When you replace that module, you replace the antennas that are a part of that module. This could potentially impact the RF of your deployment and will most assuredly change the visualization of your survey data.

Xirrus uses highly directional antennas in a unique way to extend the reach of a radio. This coupled with a low powered radio gives you a number of excellent design pieces for most any wifi environment or need. Pay close attention to the number of radios that you need, apply some logic and reason to your design (don’t expect 8 of your 16 radios to operate in 2.4GHz for example) and make sure your celling has sufficient mount points. The arrays can be weighty. :)

Meraki: The bolt on Cloud that wasn’t

When Cisco acquired Meraki last year, there was much confusion. Being ‘down in the trenches’ I struggled as much as the next guy trying to wrap my head around the acquisition and I believe I have a good handle on it. Others not so much. I regularly consult with customers that are just as confused today as they were last year. Cloud is such an over used buzz word and so many vendors are trying to jump on the buzzword bandwagon de jour that it’s easy to get lost admist the jargon and solutions, much less the technical merits or differences in the platforms. I’m here to offer some advice on the strategy and perhaps a perspective on the acquisition that you haven’t yet considered. First some advice:

Don’t purchase Meraki Access Points. You read that right. Don’t do it. Also, don’t purchase Meraki switches. For that matter, don’t buy the Meraki firewall either. If you purchase a Meraki Access Point, a Meraki switch, or a Meraki firewall, you’re not buying an Access Point, you’re not buying a switch, you’re not buying a firewall. You’re buying ‘The Cloud’. When you consider purchasing infrastructure equipment that is ‘Cloud Enabled’, this should be a purchase that lines up with your organizations Cloud Strategy first and foremost. Don’t have a Cloud Strategy? Don’t be so sure. There are a few questions to ask yourself before you jump to that conclusion. Does your organization use DropBox? Salesforce.com? Office 365? Webex or Goto Meeting? Google Mail? All of these are examples of Cloud Applications. If you use these, someone, somewhere in your organization has made the determination to embrace services from ‘The Cloud’. Understand this strategy. Understand what this enables. Understand what this means to your data and where your data lives. Then (and only then) should you consider purchasing ‘Cloud Managed Infrastructure devices’.

Let’s be frank about it, there’s nothing special about the hardware in a Meraki Access Point. There’s nothing special about the hardware in a Meraki Switch, nothing special about the hardware in a Meraki firewall. When you purchase Meraki equipment, this gear is purpose built to be Cloud Managed with features driven by that Cloud Management. When you make a Meraki purchase, purchase an end-to-end Cloud-enabled infrastructure. If it’s right for one component, it’s right for all of them. If it’s not right for all of them, it’s not right for any of them.

Now some perspective. Everyone is talking about Cloud. Everyone wants in on the Cloud action. Everyone is ‘bolting on’ Cloud to their existing products in some fashion or another. When Cisco purchased Meraki, they made a decision to not ‘bolt on’. They decided to pick the one organization that understood Cloud from bottom to top and embrace that strategy despite the fact that there was some hardware overlap. The Meraki acquisition wasn’t about Access Points, switches, or firewalls. It was about finding the one organization that was never built for ‘on premises’ management and this shines through in every aspect of their products. Others tout ‘free protocols’, ‘cloud provisioning’, or a variety of other nonsense but at the end of the day, these are bolt-on solutions that are all afterthoughts. I would encourage you to revisit the Meraki product portfolio but when you do, ask yourself the following questions:

  • What are my existing Cloud Applications?
  • How do I rely on ‘the Cloud’ today?
  • Do I want to leverage that existing strategy in my infrastructure?
  • Do I want a solution that is built from the ground up around ‘the Cloud’ with a no-compromises featureset or do I want to deal with someone bolting on features to their existing ‘heavy gear’?

Then go buy a Meraki AP.

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? :)

Please stop asking for an 802.11ac site survey

You are likely reading this post at the recommendation of someone. You have likely asked something along the lines of ‘Will you do an 802.11ac site survey for me?”. This is an easy mistake to make, and I hope that this clarifies a few things for you. First and most importantly, any site survey should always start with the customer requirements, then you position the technology to fit those requirements. If you ask me for an 802.11ac survey, this means that you want a deployment that supports 802.11ac modulation. Modulation occurs at most areas of your cell and as you get further away from your Access Point, your speed decreases, but this does not mean that you don’t ‘get an 802.11ac data rates’. The 802.11ac specification allows for as low as 6.5Mb/s and as high as ‘gigabit wifi’ and all sorts of speeds in-between. With 802.11b/g/n it was possible to ask for ‘the best, and make it pervasive’ and you could theoretically design an environment to support the highest supported data rates in all locations. With 802.11ac, this is no longer possible due to the very strong signal strengths required and the very wide channels required to achieve ‘max throughput’. It is unreasonable to expect an enterprise wireless deployment to support 1300Mbps (or whatever your Access Points spec sheet claims as the max) in all locations for all clients.

If you ask for an 802.11ac site survey without any other clarifications, you can safely expect massive cell sizes and generally poor throughput which is likely not what you want. Examining your Access Points data sheet will give you some idea of the wide range of signal strengths required (not to mention channel widths) to support a variety of 802.11ac data rates. The Cisco AP3700 data sheet for example, shows that -61dBm is required to support VHT80, MCS 9, 3 spatial streams (the ‘highest 802.11ac’ supported on the Access Point at 1300Mbps) all the way down to -92dBm for VHT20, MCS 0, 1 spatial stream (the ‘lowest 802.11ac’ supported on the Access Point at 6.5Mbps). All of these qualify as ‘supporting 802.11ac’. This wide swing in capabilities is the reason that you cannot simply ask for ‘an 802.11ac site survey’. Instead, you should always start by gathering your requirements upfront:

  • What are my throughput requirements?*
  • What are my density requirements?*
  • What are my client types?*

Then turn those expectations into leveraging a technology for the deployment. If you do not set those expectations upfront, or have a good understanding of what your clients requirements are, how can you claim success? You need to mutually agree upon design requirements, then prove that design back in whatever fashion you agree on. Set expectations, design for those expectations, meet those expectations, then prove that you’ve met those expectations. And please, stop asking for an 802.11ac site survey.

* There are many things that go into a proper RF design, not to mention supporting other applications such as BYOD technologies that I’m intentionally glossing over. This is just a small sampling of some of the questions you can use to suss out your customer requirements and is by no means the only way of doing it.

Aruba just doesn’t get Investment Protection

This week, Cisco launched their modular 802.11ac Access Point, the AP3700. The FUD that started almost instantly was unbelievable. This petulant mud slinging is coming from from none other than our good buddies over at Aruba who are trying with all their might to convince all of their AP134/135 users to go buy a new Access Point. While this rip-and-replace mindset has boosted their volume sales over the past several years, I think it’s time that we all revisit what modularity means and why it’s good. We’ll get this bit out of the way first however since it seems to be a common misconception about modularity: Modularity is not only about 802.11ac, it is about investment protection. Aruba wants to spin this to convince you that you a) need to buy a new AP and b) while you’re at it, let’s try and sell you a controller! This slight of hand and misdirection is really in poor form and we should all take a moment to bring this conversation back to the real world. The 802.11ac wave 1 module is one of 4 modules, and one of two Cisco 802.11ac platforms to select from. No one is forcing you to purchase a module to get 802.11ac. Cisco has a ‘rip and replace’ option as well. If you’re okay with the rip and replace approach to 802.11ac (as an Aruba customer you should be used to this by now), by all means – let’s compare a head to head AP3700 against the AP-225 (I’d do this, but for some reason they’re reluctant to send me an AP-220) using clients that are available in a the real world today. By the way, wasn’t it Aruba just a few months back complaining about Cisco using Miercom and proving that the 5760 beats the stuffing out of the 7240 controller and that the AP3600 whomped all over the AP134/135?

Let’s recap the FUD: When the AP3600 was announced, Aruba predicted:

  • That modularity doesn’t work: FALSE – Modularity does work, and has worked since the Cisco 1220 (802.11b to 802.11g migration).
  • That Cisco won’t ship modules ever: FALSE – Cisco has shipped two modules and is on track to ship an additional two.
  • You’re better off buying a new AP: FALSE – well, maybe not false. If you’re an Aruba customer, you have no choice.

This last one is really the sticking point. Most of the customers I talk to can’t stomach a new AP upgrade every year. They’re more along the lines of 3 to 5 year refresh cycles. Realistically speaking, if my upgrade cycle hit last year I could have done one of two things:

  1. Purchased Aruba AP134/135s. This means that I cannot get any sort of 802.11ac without ripping and replacing.
  2. Purchased Cisco 3602s. This means that if I need it, I can deploy 802.11ac (wave 1 or wave 2!), monitor mode, or indoor cell DAS modules at a fraction of the price of a new AP.

At the end of the day, modularity is not intended to be a one size fits all approach to technology. It’s right for some people, it’s not right for others. When it comes down to it, you can either buy more Access Points, or less Access Points, and still get current technology. If you’re considering the Aruba platform today, I’d encourage you to ask the following questions:

  • What do I do with last years APs?
  • How do I get to 802.11ac wave 2 when it comes out?
  • How do I deploy indoor cell DAS leveraging my existing APs?
  • How do I do wIPS without buying a whole new overlay solution?
  • Why aren’t you comparing against the AP3700?

In the meantime, let’s keep Aruba pointed in the right direction shall we? The modular platform argument is one that Cisco battles time and again – look at all of the people that used to hate on the Catalyst 6k platform? They had nothing to compare so, certainly modularity was bad! Modular is good, investment protection is fiscally responsible, and flexibility means that I can get some of todays technology where I need it, when I need it without breaking the bank on forklifting my infrastructure. By the way, let’s do a speeds and feeds with an AP220 and an AP3700 and see how those bar charts look…

In short, it doesn’t matter who’s infrastructure gear you’re buying. Moore’s law means that there will always be a pie chart or bar graph trying to convince you to buy something shiny and new. Modularity is about getting some of that shiny new, without having to forklift your gear – investment protection.

Troubleshooting done Motorola style!

The packets don’t lie. Any CWAP will tell you that. They’re the foundation of what we do in networking and one of the most troublesome things to get your hands on at times. One of the most significant challenges is that you rarely get to capture the ‘radio view’ of your packets. It’s usually a conversation about getting close enough to a radio, or putting an adapter or radio into promiscuous or sniffer mode and listening to what you can hear – this has always seemed somewhat ‘best effort’ to me since there’s always a small chance you’re not listening at the time that a packet is on the air. Wouldn’t it be much better to just have a copy of the packets that hit your Access Points radio interface just copied off somewhere for you to explore at your leisure? That way you have an honest view of what the actual infrastructure is either sending or receiving. Well, that’s exactly what Motorola allows us to do with a superbly easy to use, yet very powerful feature of their Wi-NG 5 Operating System. Once you have a radio up in Wi-NG 5, you can telnet/SSH to the Access Point and use the service pktcap command to capture your packets – while servicing clients!

In order to explore this feature, we need to know what we want to capture (1 client, all packets, arp traffic, etc), how much we want to capture (x number of packets), what direction we want to capture the packets (inbound, outbound, both), and where we want to save the packets to (terminal buffer to look at them, tftp, tzsp, etc). There are far more features that I’m glossing over for the sake of brevity, but this short look should be enough to get even the newest person up to speed! In my example, I want to capture the next 100 packets of all traffic that comes into all radios and I want to save it off to a tftp server.

ap6521-E3BEF4#service pktcap on radio all count 100 direction any write tftp://192.168.3.10/motorola.cap 
Capturing up to 100 packets. Use Ctrl-C to abort.
100
ap6521-E3BEF4#

Let’s dissect this command:

service pktcap on radio all

This tells the Access Point to start a packet capture on all radio interfaces and is the first component of ‘where to capture’ the packets from. You would usually pick a singular radio by using the numeric index (1 through 1024) or just leave it at all for seeing all packets in the air.

count 100

This tells the packet capture service to capture the next 100 packets and can be 1 to 1000000 packets.

direction any

Tells the packet capture service to capture inbound, outbound, or packets in both direction (coming into or leaving the radio).

write tftp://192.168.3.10/motorola.cap

Tells the packet capture service to copy the capture file out to my tftp server (192.168.3.10 in this case – expect yours to be different) and what to name the file (motorola.cap in this case). You can followup this command with a filter keyword to select type of traffic, src, dst, and a whole host of other options to pare down your capture.

Once you’ve captured the file, get it off of your tftp server in whatever way pleases you best (I run samba on my tftp server and can do a direct network neighborhood browse for it) and double click it. If you have wireshark or OmniPeek installed, it should open up into the default view for the packet analyzer and start showing you packets!

Screen Shot 2013-08-27 at 4.28.02 PM

Screen Shot 2013-08-27 at 4.28.09 PM

In all, a very elegant way to get packets out of your Access Points. These are the packets of your clients and the ability to capture them live off of your infrastructure (similar to a wired span port) is an invaluable feature when troubleshooting.

Full disclosure: As a delegate for Wireless Field Day 4 and 5, Motorola gave me an AP6521 and an AP6522 without commitment to comment or blog. If you want to know more about the Motorola wireless portfolio, you should follow @MotWireless on twitter!

Follow

Get every new post delivered to your Inbox.

Join 32 other followers