Pages

▼

Thursday, March 31, 2011

Revolution Wi-Fi One Year Anniversary!

I can't believe it, I have now been blogging on Wi-Fi for one whole year!

I launched Revolution Wi-Fi last year with the goal of the site being a personal study aid for the CCIE Wireless lab exam. I had been studying for a short time using other study aides and note-taking programs, but realized I was on a virtual island, alone in my studies. The wireless track was brand new and very few individuals were pursuing this certification, especially local to my residence. Other tracks such as route/switch, voice, and service provider have much larger user bases and are much easier for professionals to network and form study groups. Wireless - not so much.

So I joined Twitter (@revolutionwifi). To be honest, I never really "got it" regarding the whole Twitter thing until I actually joined. A few colleagues of mine used the service and would relate stories or posts from celebrities. Whoopdie, I thought. Then I started tweeting about Wi-Fi, found a few like-minded individuals who led to a few more. I found #WirelessWednesday, I started integrating multiple social networks together (blog, Twitter, Linked-In primarily) and my network grew, and grew, and grew. Now, my network is not huge, in fact it's still pretty small by most accounts (500+ odd followers) and I only follow some 150+ people. But the content, networking, advice, and ideas that come out of this community are amazing! It's like I have a direct line to some of the best wireless LAN experts in the industry, all the time. This level of interaction helps me be a better engineer, and I'd like to think that I help others as well.

Somewhere along the line, another very self-enlightening realization clicked. I found out that beyond just consuming content created by others in the online community, I absolutely love creating content. No longer am I a passive content consumer, I'm actively contributing to something larger. I'm giving back in some small way, and it's highly enjoyable. I'd like to thank Douglas Haider (@wifijedi) for making the light click for me on this topic. Up until his blog post which called me out as a great content creator, I was just plugging along, blogging mainly for myself. After his post the light bulb went off, and I realized that others might actually be reading what I had to say. I realized how the content I create is valuable to some small part of the community, and that is reason enough for me to continue beyond my original goal for the blog.

I believe this realization, and a change in my fundamental approach to content creation for others instead of my own studies, has lead to the readership that I have today. My reader base is not large (12k page hits this last month), but I think it's well-focused. So, thank you to my readers!

Revolution Wi-Fi Readership (May 2010 - March 2011)
I'm creating content for you, my readers. I always love reading comments, questions, and feedback on past topics, and suggestions for future topics. If you have an opinion, please share it in the comments on any post. If you have a question, don't hesitate to reach out to me on this site or through email (linked on the right). Most importantly, I want to create content that you want to read, and I value all suggested topics!

I've kept this site advertisement-free, and I plan on keeping that way forever. My blog is too focused to ever make any money from, and Google certainly doesn't need my help with Ad revenues. Besides that, I'm sure random advertisements for mostly irrelevant products and services would only clutter the site and be a detraction. I have a day job, I blog on the side, and this is community involvement for me, not a source of income. I like it that way, so it's staying that way.

Thanks for your readership! If you like my blog, I would appreciate any word-of-mouth to other Wi-Fi enthusiasts that may enjoy reading it.

Cheers,
Andrew
at 2 comments:

Wednesday, March 30, 2011

Wi-Fi Article Round-Up: 2011/03/30

Here are a collection of Wi-Fi related articles that I have found useful, interesting, or enlightening. As always, for a complete list of articles check out my shared article feed from Google Reader.


My Stuff
General Wi-Fi Articles
Comic for the Week!
Zealous Autoconfig - XKCD




Cheers (and happy reading!),
Andrew
at 1 comment:

Friday, March 25, 2011

Wireless Tech Field Day Article Round-Up

Here is a round-up of the Wireless Tech Field day articles written about the event by both delegates and sponsors.

Additional links to videos, photos, podcasts, and event articles can also be found on the official Gestalt IT Tech Field Day page for this event.

It truly was an amazing experience to be a part of the group. So much wireless brain power in one room was amazing! Special thanks go to Stephen and Claire for organizing the event, and pulling it off without a hitch. Thank you to all of the sponsors as well for sharing product roadmaps and providing engaging demonstrations and discussions.

A large part of the event was engaging the larger wireless community through blogs and twitter. Thank you to everyone who participated on the Internet, your input and discussion was appreciated!

Delegate Articles:
Sponsor Articles:
Presentation Videos:
  • Stephen Foskett Welcomes the community to the event.
  • Several delegates and vendors provide a Day 1 Event Wrap-Up. Go ahead and laugh at my portion (I am!), that light was really bright!
  • Aerohive presentations from the event have been posted. Go check them out!

Cheers,
Andrew

P.S. - When is the next one? Sign me up NOW!
at No comments:

Wireless Tech Field Day - MetaGeek Spectrum Analysis

MetaGeek was the first presenter at Wireless Tech Field Day and kicked off the event with a superb presentation and demonstration of their flagship products, the Wi-Spy DBx and Chanalyzer Pro.

The MetaGeek Wi-Spy family of wireless spectrum analysis adapters offers Wi-Fi engineers a workstation-based wireless physical layer analysis solution at a much lower cost than competitive products such as Cisco Spectrum Expert or AirMagnet Spectrum XT.

A Culture of Innovation
Ryan and Trent started off the presentation describing MetaGeek's roots as a company. Back in 2005, Ryan worked as a wireless protocol developer for semi-conductor company that manufactured parts for wireless mice. The company began experiencing problems with 2.4GHz mice not working properly, and narrowed the problem down to times when large amounts of Wi-Fi transfers were occurring. Ryan was dispatched to Japan to work with partners to resolve the issue.

As any IT engineers is well aware, the first step in troubleshooting is to accurately replicate the issue on-demand. At first, an intern was assigned the task of repetitively drawing circles with the mouse for data collection (poor schmuck!). And the cost of an industrial automated mouse tester proved prohibitive. However, Ryan developed a more elegant solution to automate the process using an unconventional technique that geeks will especially enjoy: Legos!
Lego Mouse Tester
The Lego mouse tester (it's official name) was controlled by a Lego RCX unit to provide variable speed and timed tests. The mouse tester allowed the company to accurately replicate the issue and provide a volume of data necessary to identify the interference issue, quantify impact, and develop a resolution. What's more important, is the experience got Ryan thinking about how to create an effective spectrum analyzer to observe and quantify the source of the problem, the RF environment. Thus, the first Wi-Spy adapter was born from the modification of a wireless mouse dongle!

MetaGeek still provides employees with 20% time to work on side-projects and keep innovation alive (as they have time and time again over the last 5 years)!

Product Features
The Wi-Spy adapter family and Chanalyzer software have evolved over time to provide a feature-rich spectrum analysis solution for inexperienced and "multi-hat" administrators, as well as professional wireless engineers. The Chanalyzer software's main display provides core RF information in the density and waterfall graphs, with additional relevant information such as duty cycle, networks, and channel data in tables in the lower pane.

Chanalyzer Density Graph
The best feature of the product, without a doubt, is the density graph (displayed above). This density graph shows similar data to the real-time fast fourier transmission (FFT) of other products by displaying RF data in an amplitude over frequency format. However, the RF energy is color-coded either by density (the collective amount of energy at specific points over time) or by amplitude (the energy intensity). This really make RF signal patterns "pop" as data is collected over time, allowing much easier pattern recognition by the user. This is what makes the tool simple and intuitive for users inexperienced in RF spectrum analysis. MetaGeek pioneered the use of the density view in 2007, and has since been adopted by AirMagnet (but not Cisco/Cognio). I still find MetaGeek's implementation the best.

Chanalyzer Pro
Timescale
Another great feature of the product is time segment analysis using the waterfall timescale panel on the left in Chanalyzer Pro (shown left). This allows the user to capture, pause, and rewind spectrum data to isolate and review potential issues. Additionally, the configurable time span being viewed allows the user to focus in as narrowly or broadly as required to pinpoint the pattern requiring further analysis. Spectral anomalies can easily be identified in the timescale, and hovering over a section presents a preview of the density graph at that point in time. Time segment analysis unifies the data in all other graphs and tables for complete replay capability. The feature is invaluable when performing spectrum surveys or for remote analysis by an expert after the issue has occurred. Competitive products also offer time segment analysis, but not as intuitively or comprehensively as Chanalzyer Pro in my opinion, offering recording and playback but not timescale previews that allow the user to quickly navigate to the point in time of most interest.


Chanalyzer Pro includes numerous other features, such as a report builder, device signature overlays, Wi-Fi network identification and overlays, and channel statistics.

Product Previews
To wrap up their presentation, MetaGeek showed us advanced previews of a few products and features they are actively working on. This provided the delegates opportunity to provide insights into how they use spectrum analysis products and desired features.

Ryan showed a live prototype of an iPad application for playback of recorded spectrum captures, which was a hit with the delegates to be sure! The need for portable Wi-Fi tools is always top of mind for wireless engineers, and MetaGeek has their sights on targeting that need in their products.

Ryan (right) and Trent (left) preview iPad integration

Other previews included work being performed on directional antenna prototypes for device locationing (similar to the current Device Finder antenna they offer), and remote spectrum sensors embedded in Pogoplug units. This will allow remote monitoring of spectrum at distributed offices, or on-demand shipment of a spectrum analysis solution to sites and installation by on-site personnel with minimal training involved. This reduces travel expenses for organizations to resolve wireless interference issues when expert staff is centrally located. Coupled with on-board storage and a remote access to the unit, this solution could be a killer feature for medium and large organizations.

Revolution or Evolution? - Andrew's Take
MetaGeek is a clear innovator in spectrum analysis. The company is focused on product differentiation and aggressively developing features to meet customer needs. What's more, the product provides comparable capabilities, and even better in many instances, than higher priced alternatives. The Wi-Spy is a great tool for both the inexperienced as well as the professional wireless engineer.

What also excites me about MetaGeek as a company is their solid grasp of customer requirements and a simple yet powerful user experience. Ryan, Trent, and team really listen to customer feedback and use it to drive product direction that makes sense for the company and remains relevant for users.

The Chanalyzer software does have a few gaps that should be noted. MetaGeek does not provide an in-house wireless site survey solution, but partner to integrate Wi-Spy into the VisiWave tool to map interference. Also, device identification has been a feature in flux for the company. They have created a large community forum for users to upload and share device signatures, and have integrated a few verified signatures into the Chanalyzer software. However, automatic device identification is not available; users must manually correlate observed RF patterns to the signatures.

MetaGeek also offers InSSIDer for Wi-Fi network discovery, Device Finder for interferer location via a directional antenna, and GPS integration with Google Earth maps.

Cheers,
Andrew

Other Posts You Might Like:
at 1 comment:

Tuesday, March 22, 2011

Wireless Tech Field Day - HP Review

The Wireless Tech Dield Day delegates working in the HP EBC conference room
Day 2 started out at the HP Executive Briefing Center (EBC) for an overview by Rich, Chris, and Andres of their wireless architecture from the 2008 acquisition of Colubris. HP has been playing the shell game over the last few years trying to figure out their wireless networking strategy to compete in this market, as they previously did not offer an in-house solution but opted to OEM Symbol gear until their acquisition by Motorola.

HP Wireless Architecture
The HP / Colubris architecture is built around the now-common wireless LAN controller and "smart" APs, calling the collective solution an "optimized wireless LAN". I find this to be a case of marketing hubris, as the pushing control and data planes to the controller can hardly be called optimized. This architecture was pioneered 5-7 years ago by Airespace to solve serious challenges around system-wide wireless network coordination (RRM, QoS, security, roaming, etc.) which was not prohibitively expensive with AP hardware and silicon of the time.

Unfortunately, HP is late to the game and trying to play catch-up. They are just now offerring solutions that  competitors have had for at-least 4 years or more. What's worse is the Colubris acquisition appears to making their job harder because they are trying to re-design an existing controller architecture into a modern distributed architecture which is proving difficult (as it is for other vendors as well). HP may have been better served to design a solution internally from the ground up, which was fully distributed from the beginning. As it stands, the HP solution is typical of most controller solutions with central traffic forwarding, optional distributed traffic forwarding directly from the AP, and serious feature limitations when APs process traffic locally.

In addition, I have serious concerns of the solution's high availability capabilities. A license upgrade is required to move from an "Access" controller to a "Mobility" controller, which enables layer 3 roaming and controller teaming for redundancy. Isn't that the point of a wireless network, to be mobile and highly available?! Additionally, the management platform seems to be an afterthought. Up to 5 controllers teamed together can be managed using the RF Manager software on the controllers themselves. For greater scalability the HP ProCurve Manager must be used, but it doesn't support all system features (such as WIPS/WIDS reporting). The graphical interface also leaves much to be desired, looking like it was designed in the mid-90's and does not appear to have been updated using modern HTML standards. I would expect frustration and a maddening workflow for system configuration.

Access Point Announcement
HP's recent announcement of the 3-stream MSM-460 and 466 APs looks promising, but the devil is in the details. The APs use a 3x3:3 configuration, and the 3rd spatial stream will likely be limited in range, especially given the loss of extra radio chain which prevents Maximal Ratio Combining (MRC). MRC is quite possibly the second most important advancement in 802.11n behind MIMO. Also, the MSM-466 is the only model which supports dual-concurrent 5GHz operation on both radios. Running both radios of an AP in the same band is tricky because of severe adjacent channel interference caused by RF side-lobes of each radio when in such close proximity. The radio antennas either need to be shielded properly from one another (which they are not in the MSM-460), or spaced a minimum of 4 feet apart (which is possible with external antennas on the MSM-466).

The OFDM spectral mask shows the relative power reduction at distances from the center channel frequency (in dB).
AP radios located too close will cause severe interference with each other without sufficient Free Space Path Loss.
Performance Demo
Andres, the self-proclaimed "lab rat", provided a live iperf throughput demonstration. The performance with distributed traffic forwarding and 3 spatial streams was comparatively high, at 231 Mbps downstream without competing traffic and clients at close range. I would have liked to see performance at greater ranges and under varying loads, but the time was not available for an in-depth demonstration. A second test resulted in 191 Mbps downstream with a simultaneous single video stream running to the client (I can't remember the video resolution).

The Future of Wireless
The HP visit wrapped up with a lengthy, detailed discussion on the future of wireless technologies. The delegates focused conversation around the changing requirements for mobile device security of both corporate-liable and personal-liable devices. Emphasis was placed on the need for greater context awareness of both users and devices not possible today, and dynamic policy enforcement at the edge of the network (not upstream, disconnected from device network access). Additional talking points included  a discussion of the need for layer 1 physical RF assurance and stability. This is a pain point for most wireless admins today, as the variance of device performance is directly attributable to vendor implementation variances. Greg (@etherealmind) mentioned the poor transparency in the IEEE standards process, causing vendor greed in delaying or stalling standards process.

Revolution or Evolution? - Andrew's Take
HP's wireless portfolio appears to have been a quick fix for a missing product in their solution catalog. They are just now releasing products that can compete with competitor's solutions from 3 years ago, and are struggling to maintain feature parity. This will continue as competitors migrate to distributed architectures. The product mainly appeals to existing HP customers who prefer a solution from a current vendor, and this product fills that gap. Unfortunately, I doubt HP is winning many customer evaluations based on the larger market.

Cheers,
Andrew



Other posts you might like:
at 2 comments:

Monday, March 21, 2011

Wireless Tech Field Day - Day 2 Recap (HP, AirMagnet, Fluke)

HP Executive Briefing Center (EBC) Entrance
Day 2 started out at the HP Executive Briefing Center (EBC). At HP we discussed the company's wireless product history, from Symbol OEM to Colubris acquisition in 2008. Today, the HP portfolio consists of wireless mobility controllers and APs. Rich and Chris presented the current network architecture, detailing central vs. distributed traffic forwarding, control and data plane implementation points, high availability options, and thin versus fat APs (which Greg @etherealmind calls 'Big Boner APs').

Discussion continued around access point hardware capabilities, focusing on the new MDM-460 and MDM-466 three spatial stream APs. Andres provided an iperf throughput demonstration to highlight the hardware is capable of up to 231 Mbps, which is a step above current two stream APs, but not earth shattering given the raw data rates up to 450 Mbps.

The HP visit wrapped up with a lengthy discussion on the future of wireless technology. The HP team solicited feedback on current wireless issues observed by the delegates. Topics included security architecture, mobile device support, personal devices, layer 1 RF complexity, and secure hotspots.

Delegates then headed over to Fluke offices for discussions with AirMagnet and Fluke Networks. AirMagnet was up first, and brought Bruce and Jesse in for a presentation of their product portfolio and demonstrations. The presentation covered AirMagnet solutions for wireless LAN planning, design, analysis, and troubleshooting.

In-depth demonstrations of Wi-Fi Analyzer Pro, Spectrum XT, and Site Survey Pro by Bruce allowed delegates to dive into technical features of the products. Since most delegates use these products on a regular basis, much of the discussion focused on product enhancements in the most recent versions, delegate feedback on pain points and desired features, and product roadmaps.

Jesse then presented the AirMagnet Enterprise WIPS/WIDS solution. Focus was placed on their capability for dynamic threat update protection, which is decoupled from the wireless infrastructure, allowing more regular updates without impacting wireless network operations. The ability to quickly respond to security threats is required in modern Wi-Fi networks, which are becoming mission-critical and carrying increasing amounts of sensitive cardholder and patient data. Additional solution benefits included extended channel scanning, forensics capabilities, and minimal WAN outage impact.

The final presentation was given by Carolyn and Paul from Fluke Networks. The presentation covered the Fluke AirCheck, a portable product designed for the 1st level field technician. Paul, a "real" engineer, walked us through the design process and an example use-case scenario. Although a bit dry, the points were spot-on. Additionally, access to an engineer of Paul's high calibre was reward enough, as the delegates were able to pick his brain on many technical details of the AirCheck. An amazing amount of thought and detail went into the product to implement complex functions in a simple and intuitive manner. For instance, AirCheck automatically detects the current country of operation using 802.11d, and offers a simple coloring of the current regulatory channels for the technician. The product is optimized for simple yet effective workflow,  drop resistance, fast power-on (2 seconds by my timing), high portability, and a long batter life (5 hours of constant use).

The Fluke team then allowed all the delegates to get hands-on time with an actual unit, bringing out 16 AirCheck units. Stephen fired up his portable 3G router and delegates were asked to find it. The AirCheck device finder function builds a line graph in real time and beeps similar to a geiger counter. It was amazingly easy to find the device, and quite fun. At first, I was skeptical that the product was too basic a tool for engineers. However, after having one in my hands, I was completely wrong. The tool has a place in any engineer's bag, and fills a gap for quick network analysis without booting a computer or using overly complex software.

Day 2 was full of great discussions and product demonstrations. The delegates were truly amazing, and it was great to be part of this event. I look forward to continuing to contribute to the strong wireless online community.

As a reminder, everyone can follow Wireless Tech Field Day on Twitter using the hashtag #TechFieldDay, following the @TechFieldDay lists for wfd1-delegates and wfd1-sponsors, or by watching the soon to be archived video streams at http://www.techfieldday.com.

Cheers,
Andrew


Other posts you might like:

at 1 comment:

Friday, March 18, 2011

Wireless Tech Field Day - Day 1 Recap (MetaGeek, Cisco, Aerohive)

Ryan Woodings and Trent Cutler from MetaGeek,
presenting at Wireless Tech Field Day
Today started off with MetaGeek presenting their Wi-Spy spectrum analysis product and Chanalyzer Pro software in the morning. Ryan Woodings and Trent Cutler provided a live demo of features in real-time as they presented product features, which was great. Having a look at the topics being covered and a live reference in front of the delegates worked great! Ryan provided a background of the company beginnings, ran the delegates through the product feature set, previewed some features and product enhancement in the pipeline, which were ALL so cool. Every delegate in the room was engaged in the roadmap discussion and excited to see where they were taking the product. Expect to see some amazing innovation coming out of MetaGeek, they’ve got a great sense of the market and product features that customers will want.

Mid-morning, we shipped off to Cisco for presentations on several wireless products. First up, Jim Florwick discussed media rich applications, outlining key success factors for modern mission critical Wi-Fi networks. Next up, David Stiff discussed challenges with spectrum management, the need for integrated spectrum analysis, and Cisco’s CleanAir technology. The bulk of the information was presented in PowerPoint format and did not include any demonstrations, which was a bit unfortunate as the technical delegates seemed more excited throughout the day when seeing features live. The back-to-back spectrum analysis discussions of MetaGeek and Cisco prompted some great comparison points and different use-cases for each technology, which was a recurring discussion theme throughout the day.

After a brief lunch break, David continued the Cisco presentation with information on the MobileAccessVE partner solution for in-building cellular coverage improvement. The solution seems to be a good fit in the U.S. in many urban and rural indoor locations that have poor coverage. The draw for the product is the reduced expense for cellular enhancement by leveraging existing UTP Cat5e/6 cable plant instead of distributed antennas systems (DAS) or overlay cellular infrastructure. However, the need for the MobileAccess controllers and access pods to be in-line between the AP and LAN switch limits the cost-effectiveness to small installations with minimal IDF closets. The duplication of the controller hardware in multiple IDFs can quickly become cost-prohibitive.

The next Cisco presentation focused on next generation hotspots by David Stephenson, an engineer that helped write the IEEE 802.11u amendment. An engineer at heart, you could tell David was passionate about the solution and had a lot of pride in ownership of the capabilities being brought to market by Cisco Service Provider Wi-Fi. The need for secure hotspots and improved user experience is clear, and 11u will initially enable cellular carriers and independent hotspot operators to offer seamless roaming from cell to Wi-Fi. Unfortunately, not much work has been done to accommodate non-carrier hotspots, which is my opinion is the bigger market segment. I was able to ask about secure anonymous hotspot authentication, but it appears that not much is being done to directly address these networks outside of the hope for Wi-Fi Alliance extensions to 802.11u or continued IETF work on EAP protocols. I am really dis-heartened by this news, as it is my firm belief that guest Wi-Fi in hospitality, retail, and many other verticals has become a basic commodity service that is free for customers in most cases (at-least in the U.S.) and required to stay competitive in the market. The need for ease-of-use for layer 2 security on these hotspots is a huge untapped potential.

Finally, Jameson Blandford provided a brief overview of some 802.11n technology after the live stream was cut. Most of this discussion was confidential analysis information and I won’t be able to write much more about the topics covered.

Aerohive was the final presenter for day 1. There is only one word to describe the session at the Aerohive offices, “amped”! We received a surprise visit from Bob O’Hara (yes, the Bob O’Hara!), who enlightened the delegates on Wi-Fi history of scalability issues and the evolution of the modern wireless controller architecture. His takeaway from that evolutionary phase was particularly insightful. The biggest benefit was not the controller architecture but what it enabled – the transformation of Wi-Fi from a niche product to a mass-market solution. I definitely sensed the pride from Bob in his involvement in this transformation. It must have been truly awesome to be an integral part of a cultural and societal transformation that is now enabled by ubiquitous mobile information access through Wi-Fi. Wow!

Next, Devin Akin shot through the Aerohive product market position and feature set information like a bullet! His technical depth and excitement of the product and innovation being done within the company couldn’t have been more visible. The delegates focused questions on key slides that contained critical product differentiation points.

Paul, Andrew, and Abby then kicked off a serious of ridiculously well-executed product demonstrations! They really kept the delegates engaged showing features live, while managing to throw in some impromptu acting skills. They covered Private Pre-Shared Key (PPSK), TeacherView, Mesh operation, HiveAP Active Directory integration and credential caching (super-cool BTW), Dynamic Network eXtension Protocol (DNXP) for Layer 3 roaming and tunneling between subnets, and failover protocols with layer 2 routing (yes, layer TWO routing). Then Paul performed a complete system factory reset and ground up configuration in under 14 minutes, highlighting the product ease of use and “time to value”.

All in all, a it was a packed, hyped, amped, red-bull energy day. I don’t think I could have asked for more!!!

As a reminder, everyone can follow Wireless Tech Field Day on Twitter using the hashtag #TechFieldDay, following the @TechFieldDay lists for wfd1-delegates and wfd1-sponsors, or by watching the live (and soon to be archived) video streams at http://www.techfieldday.com.

Tune in soon for day 2 activities.

Cheers,
Andrew
at 1 comment:

Thursday, March 17, 2011

Wireless Tech Field Day is now LIVE!

The Wireless Tech Field Day starts now! Tune in live below, or at http://www.techfieldday.com


Cheers,
Andrew
at No comments:

Monday, March 14, 2011

Aerohive HiveAP Provisioning Basics

Honeycomb modular furniture, courtesy Disney.
(This is what I imagine Aerohive's
corporate offices looking like :)
Aerohive offers an innovative wireless product that does not require wireless controllers, which seems ideally suited for branch, remote, and home offices where duplicating hardware controllers is prohibitively expensive. One of the company's advantages that make this possible is the "ground-up" design effort that has gone into this product, unencumbered by design choices made 5-7 years ago when the controller-based model emerged to provide system-wide coordinated intelligence required for many wireless LAN functions (radio management, configuration management, key caching, etc.). This gives Aerohive a fresh swing at innovating without the R&D and customer support of legacy product hampering budgets and resources.

For more information about Aerohive and their solution, see their website and resources. Part of the excitement of working in Wi-Fi is the current state of the market, which is extremely innovative, fast-paced, and heating up competitively.

Recently, I've had the opportunity to gain some exposure to Aerohive's line of equipment. As I work through learning and understanding their solution, I'd like to take the opportunity to share what I find.

What is a "Hive"?
In Aerohive's architecture, a "Hive" simply refers to a logical collection of wireless access points that exchange control plane information with one another to facilitate distributed system-wide network intelligence. The HiveAPs coordinate the following functions:
  • Consistent QoS policy enforcement
  • Seamless layer 2 and layer 3 roaming
  • Dynamic best-path routing of client data
  • Automatic radio frequency and power selection
  • Client traffic tunneling between APs for layer 3 roaming and guest termination
HiveAP Provisioning
The first (post-design) implementation step in deploying a network of HiveAPs is to setup the management console and provision APs.

HiveManager is the company's management console, which I will dive into piecemeal throughout my exposure to their product line and features. Therefore, I won't go into much depth in this post on HiveManager, except to note that HiveManager is strictly a management platform for centralized monitoring and management. It is not in the critical path for network operation (control plane or data plane). The product is available as both an enterprise appliance for hosting within customer premises, or as a virtual appliance hosted by Aerohive as a managed service in the cloud.

Once HiveManager is operational, provisioning of APs can begin. HiveAPs can be configured individually or can be connected to the HiveManager for easier configuration deployment, especially for networks of more than a few access points. I will cover provisioning using HiveManager, as that is the likely scenario for most customers.

If using HiveManger Online (HMOL), upon purchase of a HiveAP customers will want to ensure that the AP serial or MAC addresses are properly registered with the HMOL Staging Server. The staging servers acts as a landing pad for HiveAPs when they cannot discover a local HiveManager appliance through discovery mechanisms listed below, or need to connect to a HMOL hosted server. The staging server redirects HiveAPs to the correct HiveManager appliance, either internal or hosted, as configured by the administrator. To ensure HiveAP registration in these instances, login to your HMOL account and navigate to the Staging Server section.

In the "Monitor > HiveAP Access Control List" sub-tree, ensure the purchased APs are imported using either the AP serial numbers or MAC addresses.


In this instance, I am using a HMOL hosted server and the APs were registered with the staging server automatically when purchased. I'm not sure if this an automatic process for all customers or is unique to my account at this time.

HiveAPs follow a very similar discovery and connection process for HiveManager as most thin-AP architectures for controller discovery. HiveAPs use the CAPWAP protocol for management, and perform the following steps for HiveManager discovery:
  1. Manual Configuration - Manually configure the HiveManger IP address or domain name through the AP command line interface. Login to the AP via console using the default username "admin" and password "aerohive". Configure the HiveManager with the command "capwap client server name <name_or_IP>".
  2. Layer 2 Broadcast - HiveAPs broadcast within the layer 2 domain (subnet) for a HiveManager appliance or Virtual HiveManager (VHM) appliance.
  3. DHCP Options 225 & 226 - Specify the HiveManager server in a DHCP option returned to the AP. Option 225 specifies a domain name and option 226 specifies an IP address. Only one option is required.
  4. DNS Resolution - If no HiveManager server was specified by DHCP options, then the HiveAP attempts to resolve "hivemanager.localdomain", where the local domain name assigned through DHCP is appended. If this name resolves to a valid IP address the HiveAP attempts to join the HiveManger at that address.
  5. HMOL Staging Server - HiveAPs attempt to reach  the HMOL Staging server at staging.aerohive.com. If the staging server has the AP registered, it will redirect the AP to the configured HiveManager server. If the client is using a VHM cloud appliance then the AP is redirected to hm-online.aerohive.com.

Basic HiveManager Connection Protocols (not an exhaustive list):
  • CAPWAP (UDP port 12,222) - Used between the HiveAPs and HiveManager appliance for AP management.
  • SCP (TCP port 22) - Used by HiveManager for full configuration and image uploads to HiveAPs.
  • NTP (UDP port 123) - Used by HiveAPs for time synchronization with HiveManager.
Determine the method you will use for HiveManager discovery, deploy the necessary configuration to DHCP, DNS, or firewalls, then power on the HiveAP. The AP should then discover the server and connect.

If using the HMOL staging server, check the redirection status of the AP on the "Monitor > HiveAPs" sub-tree:


Once the HiveAP has discovered  a HiveManager appliance, verify the HiveAP has connected using CAPWAP by logging into HiveManager and looking at the "Monitor > Access Points > HiveAPs" sub-tree section:


Verification can also be performed from the HiveAP with the following CLI command:
HiveAP#show capwap client
CAPWAP client: Enabled
CAPWAP transport mode: UDP
RUN state: Connected securely to the CAPWAP server
CAPWAP client IP: 10.10.10.60
CAPWAP server IP: 168.143.86.118
HiveManager Primary Name:hm-online.aerohive.com
HiveManager Backup Name:
CAPWAP Default Server Name: staging.aerohive.com
Virtual HiveManager Name: XYZ_Company
Server destination Port: 12222
CAPWAP send event: Enabled
CAPWAP DTLS state: Enabled
CAPWAP DTLS negotiation: Enabled
     DTLS next connect status: Enable
     DTLS always accept bootstrap passphrase:Enabled
     DTLS session status:Connected
     DTLS key type: passphrase
     DTLS session cut interval: 5 seconds
     DTLS handshake wait interval: 60 seconds
     DTLS Max retry count: 3
     DTLS authorize failed: 0
     DTLS reconnect count: 0
Discovery interval: 5 seconds
Heartbeat interval: 30 seconds
Max discovery interval: 10 seconds
Neighbor dead interval:105 seconds
Silent interval: 15 seconds
Wait join interval: 60 seconds
Discovery count: 0
Max discovery count: 3
Retransmit count: 0
Max retransmit count: 2
Keepalives lost/sent: 1/3185
Event packet drop due to buffer shortage: 0
Event packet drop due to loss connection: 1
HiveAP#
Now that the HiveAP is connected to HiveManager, we're ready to begin configuration!

Overall, the HiveAP provisioning process is straightforward and simple. Check back for more information on the Aerohive solution as I work through my lab deployment!

Cheers,
Andrew
at 1 comment:

Friday, March 11, 2011

Preventing DHCP Starvation Attacks

Wireless expert, and fellow Wireless Tech Field Day delegate, Steve Williams recently blogged about DHCP starvation attacks using a tool called Yersinia.

I thought the topic was very pertinent as a security topic that is often overlooked in modern networks. In particular, the mobile nature of wireless clients makes DHCP pool scalability and stability of paramount concern. In this post, I'd like to address what options are available for network administrators on both wired and wireless networks to mitigate DHCP starvation attacks.


DHCP Starvation Overview
DHCP starvation attacks are designed to deplete all of the addresses within the DHCP scope on a particular segment. Subsequently, a legitimate user is denied an IP address requested via DHCP and thus is not able to access the network. Gobbler, Yersinia, and Metasploit are public domain hacking tools that perform automated DHCP starvation attacks. DHCP starvation may be purely a DoS mechanism or may be used in conjunction with a malicious rogue server attack to redirect traffic to a malicious computer ready to intercept traffic.

Attack Mitigation on Wired Networks
For wired access, port security can currently prevent a DHCP starvation attack launched from a PC connected to a switch that is using a tool such as Gobbler. The inability of the attack to succeed is due more to a limitation of the tool than the mitigation offered by port security. The only reason such an attack fails is that Gobbler uses a different source MAC address to generate a different DHCP request and can be mitigated by port protection.

However, if an attacker is able to use their MAC address in the Ethernet packet and simply changes the MAC address in the DHCP payload (the field is called chaddr), port security would not stop the attack. In this case, DHCP snooping must be enabled and configured to verify the source MAC address in the frame matches the client address field in the DHCP packet payload.

Here is an example configuration for port security on ports 1-48 for end-users, and DHCP snooping on VLANs 1-10 with trusting of DHCP information on port 49 for the uplink to the server:
3750(config)#interface range GigabitEthernet1/0/1 - 48
3750(config-if)#description Access Ports
3750(config-if)#switchport port-security
3750(config-if)#switchport port-security maximum 4
3750(config-if)#switchport port-security aging time 5
3750(config-if)#switchport port-security aging type inactivity
3750(config-if)#switchport port-security violation shutdown
3750(config-if)#exit
3750(config)#interface GigabitEthernet1/0/49
3750(config-if)#description Uplink to DHCP Server
3750(config-if)#ip dhcp snooping trust
3750(config-if)#exit
3750(config)#ip dhcp snooping
3750(config)#ip dhcp snooping vlan 1-10
3750(config)#ip dhcp snooping database tftp://remotehost.company.com/3750dhcpsnoop.txt
3750(config)#ip dhcp snooping verify mac-address
3750(config)#end
3750#
DHCP Starvation in Unified Wireless Networks
In a Unified Wireless deployment, the vulnerability to perform a DHCP starvation attack depends on whether the WLC terminates the user traffic or an H-REAP AP terminates the user traffic.

Due to the 802.11 protocol definition, MAC address spoofing by wireless clients is prevented through the 802.11 association process. This prevents clients from spoofing the source address of the frame in addition to the DHCP client field in the payload.

The WLC protects the network from DHCP starvation attacks because it examines DHCP requests to ensure that the client MAC address matches the chaddr. If the addresses do not match, the DHCP request is dropped.

In the case of H-REAP, the user VLAN is terminated locally, the DHCP request does not go through the controller, and an analysis of the chaddr cannot be performed. In this case, the same security considerations apply for this method of access as they do for wired access. A smart (wireless) attacker uses the MAC address with which he or she is associated to the AP to generate the random DHCP requests, and then simply changes the requesting MAC address within the DHCP packet payload. To the AP, the packet looks valid because the originating MAC is the same as the MAC used to associate to the AP.

H-REAP can protect the network from DHCP starvation attacks when coupled with DHCP snooping on the switch.

Attack Mitigation on Wireless Networks
WLC Mitigation Steps:
  1. The 802.11 association process prevents MAC address spoofing.
  2. Verify DHCP Proxy is enabled on WLCs to prevent DHCP chaddr spoofing. This feature is enabled by default.
(Cisco Controller) >config dhcp proxy enable

(Cisco Controller) >show dhcp proxy

DHCP Proxy Behaviour: enabled

(Cisco Controller) >
H-REAP Mitigation Steps:
  1. The 802.11 association process prevents MAC address spoofing.
  2. Enable DHCP snooping on client VLANs on the switch to verify the source MAC address matches the chaddr address. Do not use DHCP rate limiting using the DHCP Snooping feature on switch ports connected to H-REAP APs because a violation will result in the switch port being shutdown.
Note – Do not enable port security on switch ports connected to H-REAP APs to prevent the switch from shutting down the port when a violation occurs due to wireless client roaming (MAC address seen on multiple ports) or excess MAC addresses (on a single port).

Armed with the proper tools, DHCP starvation can be prevented.

Cheers,
Andrew
at 6 comments:

Follow Wireless Field Day Next Week

Just a quick reminder for all of the network heads out there:

Wireless Tech Field Day is next week!

Follow all the action with RSS feeds, live event streaming, podcasts, and videos.

The line-up of presenters and delegates are both set, and the event promises to be a blast as the top minds in the field gather to discuss all-things-Wi-Fi!

The presenters include:

Aerohive@Aerohive
AirMagnet@AirMagnet_Inc
Fluke Networks@FlukeNetworks
HP@HP_Networking
MetaGeek@MetaGeek


One presenter is still in the works, but should be joining the group officially soon.

Cheers,
Andrew
at No comments:

Explaining DHCP Server 1.1.1.1

Often times, I am asked by other network engineering and security teams to investigate a potential problem or security issue with the corporate wireless network because clients are obtaining a DHCP lease from an apparently non-existent server with an IP address of 1.1.1.1.

I calmly explain to them that this is expected behavior and is nothing to worry about. However, the conversation usually does not stop there. This only seems to prompt more questions because my answer sounds, on its face, to go against every "preconception" network engineers hold to be true. In order to satisfy their curiosity, it's necessary to explain in a bit more depth how DHCP proxy and web authentication function in the Airespace wireless world (now Cisco Unified Wireless Network).

First, let's level-set the expectations:

  • DHCP server 1.1.1.1 IS perfectly valid for wireless clients
  • It is NOT a mis-configuration
  • It is NOT a security issue or risk
  • It will NOT cause an operational or performance issue for wireless clients
  • The server address CAN be changed (and is now recommended, more on that below)
  • DHCP proxy functionality on the controller MAY be changed, but most times should NOT be

Here is what is going on:

The wireless LAN controller perform DHCP proxy functions using an internal non-routable interface, called the virtual interface. Almost all public documentation by Airespace and Cisco show examples assigning the virtual interface an IP address of 1.1.1.1, which has become the de-facto standard for most deployments. The virtual interface is not attached to any physical ports, is not routable across the network, and is only used by the WLC internally.


DHCP proxy is useful for wireless client roaming in mobility anchoring scenarios to aid faster network connection re-establishment, particularly when performing Layer 3 A-Symmetric mobility tunneling to prevent the client from attempting to get an IP address in the new subnet. Instead, traffic tunneling between controllers allows the client to maintain their original IP address.

The WLC intercepts client DHCP discovery packets, inserts it's own IP address configured on the egress interface into the relay agent field, and unicasts the DHCP packet to the configured DHCP server. Here is an example packet capture from the wired port on a controller:


Here we see that packet #1 was the client DHCP broadcast discovery (carried inside the LWAPP tunnel from the AP to WLC), and packet #2 is the WLC relaying the packet to the configured DHCP server, which in this case is the subnet gateway address. Notice the relay agent information inserted by the controller.

Note - packet numbers 1, 4, 5, and 8 are all inside the LWAPP/CAPWAP tunnel between the AP and controller.

Once the server response is received by the WLC in packet #3, it modifies the DHCP offer and changes the DHCP server ID to the virtual interface address, as shown in packet #4 below.


Clients on the wireless network will perceive their address to be assigned by the server at 1.1.1.1 and will send all renewal requests to this address. This is perfectly normal and acceptable.

It is also important to note that web authentication uses the WLC virtual interface address, and will be seen during web login as the captive portal redirect page.

Changing the virtual interface IP address is now recommended because the 1-block (1.0.0.0/8) was assigned by the IANA to APNIC in January 2010, and is now a valid Internet address. Therefore, wireless clients attempting to reach a valid host at 1.1.1.1 on the Internet would not be able to successfully unless the WLC virtual interface has been configured to use a different address. It is now recommended to use an RFC1918 private address or an RFC3330 Test-Net address (such as 192.0.2.1/32).

To summarize, the DHCP server address of 1.1.1.1 is perfectly valid for wireless local area networks and does not cause operational, performance, or security concerns when used.

Cheers,
Andrew
at 13 comments: