Pages

Tuesday, June 22, 2010

In my last twoposts, I detailed Cisco's Hybrid REAP mode of operation.

H-REAP is a feature attempting to fill a critical gap in the controller based wireless architecture. Due to the high expense of deploying controllers at all locations, many organizations are unwilling to make the shift to controller architectures. H-REAP attempts to reduce this reliance on distributed controllers by pushing more functionality back into the access points. Unfortunately, this feature as it stands today is too complex and too limited to be truly scalable and provide the availability many organizations now require for wireless network operation and SLAs.

The industry moved from “Fat APs” which provided minimal or no coordinated services among each other, to controller-based models with “Thin APs” that pushed both management and data plan operations to the controller with a Split-MAC architecture. The downfall of the controller-based model is the reliance on increasingly larger and larger hardware controllers, with specific AP licensing and support limits. This only serves to drive costs astronomically high for large enterprises, especially organizations with a large quantity of distributed remote offices, such as in the Retail industry.

The move to limit the reliance on the controller for network operation is required by these customers, and the wireless industry is being forced to migrate back towards what I call a “Smart AP” model. This will be a hybrid approach where controllers perform centralized management, configuration deployment, monitoring, statistics collection, reporting and alerting on the environment. The Smart APs will perform all 802.11 network functions (no more Split-MAC), client authentications, and all functionality required for the network to operate. Controllers will be placed in centralized data centers or NOCs, the network will function with high availability even if the controller is not reachable, and the required hardware investment in controllers will be dramatically reduced.

Only then will truly viable remote office solutions be practical when deploying controller-based architectures. If this doesn’t happen soon, there will be tremendous opportunity for smaller market vendors with traditionally strong vertical industry presence to gain market share. Aerohive offers a completely controller-less architecture, as Devin Akin eloquentlyrants. He’s absolutely right, the time has come for either controller-less networks or at-least “less-controllers”!

Along that same line, Motorola recently gave an excellent preview for my organization on their Adaptive AP roadmap. I have to give them credit, I liked what I saw and will be anxiously awaiting beta code for evaluation in our lab.

In my last post, I detailed the business case for the Hybrid REAP mode of operation on Cisco wireless access points, and provided an overview of H-REAP operation. In this post, I will build on those basic fundamentals and provide more depth on the recommended deployment guidelines if you're thinking about deploying H-REAP for remote sites. Additionally, feature limitations when using this mode of operation need to be clearly understood by network administrators prior to evaluating and deploying an H-REAP solution.

H-REAP Deployment Guidelines

First, several guidelines are recommended for successful deployment. Administrators should design a solution around these requirements as best as possible.

§WAN bandwidth must be at minimum 128kbps

oCAPWAP utilization overhead is 400-500 bps

oCAPWAP utilization with rogue detection and client location could be 2-3 kbps

oCode upgrades put largest strain on WAN bandwidth when pushing a ~4MB code image to each AP

§WAN latency must not exceed 100ms roundtrip (version 5.2 and prior), 300ms (version 6.0) and 2 seconds (version 7.0.116.0 and later when using H-REAP Local Authentication of clients).

§WAN MTU must be larger than 500 bytes because H-REAP APs only support up to 4 IP fragments

§If H-REAP APs are in the same H-REAP Group but connected to different controllers, all controllers should be in the same mobility group

H-REAP Failover Operation

Failover

When entering standalone mode, the H-REAP access point maintains client connectivity without interruption for all locally switched WLANs. If H-REAP groups with backup RADIUS servers or local authentication is enabled, new and roaming clients can be authenticated and join the network. CCKM clients can use cached keys if established prior to the APs going into standalone mode, since the controller is required to distribute key IDs to all the H-REAP APs in a group. Clients on web-auth WLANs maintain connectivity as well, but the WLAN cannot accept new connections.

Fallback

In versions prior to 7.0.116.0, when re-establishing a connection with a controller using the primary discovery timer (30 sec. in 4.2 and earlier, 120 sec. default in 5.0 and later), the H-REAP access point disassociates all clients, reboots, re-joins the controller, re-applies the configuration from the controller, and re-allows client sessions in connected mode.

In version 7.0.116.0 and later, when re-establishing a connection with a controller using the discovery timer, the H-REAP access point is able to maintain seamless client connectivity during the re-join process.

H-REAP Feature Limitations

Unfortunately, H-REAP does not provide feature parity with full Local mode AP operation. The following features are not supported when running APs in H-REAP mode, whether the AP is connected or standalone. Administrators should understand these limitations when architecting a wireless network for remote offices, and may preclude the use of H-REAP if one or more of these features are critical to wireless network service in your organization.

§AAA Override is not supported with H-REAP

§Static PMK caching (per-AP) is not supported for fast roaming with H-REAP

§Workgroup Bridges are not supported for use with H-REAP access points

§H-REAP Groups limited to 20 groups per controller

oIncreased to 100 groups in WLC version 7.0 J-MR1 and later with a 5500 controller

§H-REAP Groups can only contain 25 APs each

§Multicast traffic forwarding requires the Unicast mode of operation

§Peer-to-Peer Blocking is not supported with H-REAP locally switched WLANs

§IPv6 Bridging is not supported with H-REAP locally switched WLANs

§VideoStream (MediaStream multicast direct) is not supported with H-REAP

§CCKM/OKC roaming between H-REAP and non-H-REAP APs is not supported

§NAC out-of-band integration is not supported with locally switched WLANs

§Passive client feature (version 7.0 code) is not supported with AP Group VLANs

§Cisco Integrated Security Features have limited support with H-REAP.

oMAC Flooding attack prevention is fully supported

oDHCP Rogue Server attack prevention is supported for wired clients when DHCP snooping is enabled on the switch, but is not supported for H-REAP wireless clients.

oDHCP Starvation attack prevention is supported with DHCP snooping with MAC address verification is enabled on the switch.

oARP Spoofing attack prevention is supported for wired clients when DHCP snooping and Dynamic ARP Inspection are enabled on the switch, but is not supported for H-REAP wireless clients.

Wednesday, June 16, 2010

H-REAP (hybrid remote edge access point) is useful for corporations with many small remote sites requiring wireless networks. Since the industry shifted to controller-based architectures, solutions for remote offices have been difficult for many customers, including retail corporations such as the one I currently am employed with. Many customers have found it difficult to justify the large (even enormous) additional expense of distributed controllers at each and every remote site.

H-REAP attempts to fill this gap by allowing corporations to deploy centralized controllers and distribute more brains of system back into the access points. However, the controller typically still performs some level of data-plane operations and is not solely limited to management plane functionality. Some vendors have bucked this trend and have designed solutions that are fully distributed with no controller required. Cisco's approach to this problem has continued to evolve since their Airespace acquisition and jump into the controller architecture.

H-REAP enables customers to configure and control access points in a branch or remote office from the corporate office through a wide area network (WAN) link without deploying a controller in each office. The hybrid-REAP access points can switch client data traffic locally and perform client authentication locally when their connection to the controller is lost. When they are connected to the controller, they can also send traffic back to the controller.

However, this feature still has a significant amount of limitations compared to their current controller-based architecture with Local mode APs. Additionally, many different authentication and traffic forwarding scenarios exist which make H-REAP deployment somewhat complex. Here is a rundown of some of the basics.

Authentication and Traffic Forwarding

WLANs can be locally switched from the AP or tunneled back to the controller. This setting is global for each WLAN. Clients are authenticated centrally through the controller. If the controller connection is lost, clients can also be authenticated locally by the AP, either through backup RADIUS servers if they are configured for the H-REAP group, or through Local EAP on the AP (limited to LEAP and EAP-FAST).

Note that client authentication is ALWAYS performed by the controller if the AP can establish a connection to the controller.

H-REAP Operational Modes

1. Connected Mode – the AP can reach a controller

2. Standalone Mode– the AP cannot reach a controller

H-REAP Operational States

1.Central Authentication, Central Switching(Connected Mode)

a.Controller handles client authentication

b.Client data is tunneled back to the controller

2.Central Authentication, Local Switching(Connected Mode)

a.Controller handles client authentication

b.Client data is switched locally by the AP into trunked VLANs on the access layer switch

3.Local Authentication, Local Switching(Standalone Mode)

a.AP handles client authentication using backup RADIUS servers

b.Client data is switched locally by the AP into trunked VLANs on the access layer switch

c.Valid for Open, Static WEP, and WPA/WPA2-PSK

d.Valid for 802.1x and CCKM if backup RADIUS servers are defined on the H-REAP group or on an individual AP

e.Never valid for web authentication, which is always performed at the controller

b.Valid for locally switched WLANs when the AP goes into standalone mode, including web-auth WLANs, and when no backup RADIUS servers are defined

H-REAP Groups

In order to better organize and manage your hybrid-REAP access points, you can create hybrid-REAP groups and assign specific access points to them.

All of the hybrid-REAP access points in a group share the same backup RADIUS servers, CCKM, and local authentication configuration information. This feature is required for CCKM to work on H-REAP access points. Backup RADIUS servers can also be configured on individual APs, which override the group configuration if present.

Whew! It takes a few passes to understand all of that, doesn't it. Now, try designing a remote site solution to take into account all the possibilities and architect a stable solution. Easier said than done.

In my next post, I'll detail H-REAP deployment guidelines and some of the H-REAP feature limitations you should be aware of.

Saturday, June 12, 2010

It's been just shy of 2 years now since the IEEE ratification of the 802.11r amendment in July 2008, and there is little sign of vendors, either infrastructure or client, moving to implement it.

Perhaps this is a testament to the value of pre-standard fast roaming techniques such as CCKM and Opportunistic Key Caching (OKC). OKC has been available on Windows platforms since Windows XP, albeit administrators were required to install a special package (KB917021). Funk Odyssey has also included support for OKC for quite some time prior to their purchase by Juniper. CCKM, meanwhile has only been implemented by a marginal subset of client vendors due to the more proprietary nature of the protocol, and usually only when pushed by large customers with Cisco infrastructures.

However, the value of a standards-based fast roaming method cannot be underscored. It's value will be tremendous with the growth and adoption of voice of wireless technologies, especially as ABI Research and Gartner have released studies predicting large adoption of VoWiFi and Fixed Mobile Convergence (FMC) in the enterprise by 2014. Smartphone adoption of WiFi is set to explode as well.

Also, I am disappointed by the slow progress of the WiFi Alliance in developing interoperability certifications for fast roaming. They have been talking about releasing the Voice-Enterprise certification for some time, but have been slow to act in developing this program. They have released the Voice-Personal certification, but that only includes testing of voice quality on single access point, and does not include enterprise-grade equipment with multiple access point deployments requiring client roaming. What's the deal WiFi Alliance, let's get this program moving!

I am encouraged by some recent developments by the largest wireless vendor, Cisco. In their latest release of controller code just last week, version 7.0 includes the ability to enable 802.11r fast BSS transition on a per-WLAN basis. Kudos to Cisco for stepping out in front and putting a stake in the ground saying "let's get this technology moving people." Now it's time for other vendors to follow (I'm talking to you client vendors!!!).

Here are the commands to view and configure the 802.11r fast roaming in WLC 7.0 code:

Wednesday, June 9, 2010

I highly recommend that wireless professionals, new or seasoned to the field, watch this video about 802.11 medium contention by Meru's CTO. Bharghavan goes through the basics of medium contention in random access networks (versus controlled access networks such as token ring/bus, TDM, etc.). He does a great job of explaining in simple terminology how the standards define the protocol operation, and then goes further to relate the importance and advantage of some of Meru's proprietary enhancements that work within the standard.

I've had the pleasure of getting an in-person presentation by the Meru staff and they definitely have innovative technology.

Much of the content in this video is equivalent to a Master's degree level course I took in Data Communications and Computer Networks. I encourage individuals to learn and develop the protocols of the future to investigate graduate degree programs in these types of fields.

Tuesday, June 8, 2010

I work for a large corporation, and so have little need or use for adedicated wireless toolkit. Sure, I use most wireless tools on anregular basis, but have nothing packed into a toolkit. By toolkit, I'mspeaking about a grab-bag of essential Wi-Fi tools, software, andaccessories that consultants and contractors have packed at all times,ready to pickup and go on an assignment at a moments notice withoutforeknowledge of the situation they're being called into.

I've started a list, but would like tips from engineers using such atoolkit in their everyday routine.

Saturday, June 5, 2010

Starting in WLC code version 6.0, new unified code images can be pre-downloaded to wireless access points to reduce network impact during the upgrade process. The current primary or backup boot images on the controller can be selected to pre-download to the access points.

In addition, each access point now holds a primary and backup image in flash to facilitate failover in the event of a corrupt image and for easier image swapping between multiple versions.

Currently, these features are only available through the controller CLI.

To configure AP image pre-download, perform the following from the controller CLI:

Swap primary and backup images on an AP. The AP must be rebooted after swapping images for the new primary image to be used during runtime.

config ap image swap { all | ap-name }

Also, watch for future enhancements to allow image staging off an existing access point or other local TFTP/FTP server. This can reduce image download times to access points by locally staging an image on an AP or server rather than traversing a low-bandwidth, high-latency WAN connection to download the image from a centralized controller.

Tuesday, June 1, 2010

In order to ensure that an attacker cannot impersonate the approvednetwork infrastructure AAA server, enable client-side server validation.

This setting instructs the client to compare the presented servercertificate credentials during EAP phase 1 to the list of approvedservers, and to only continue the authentication process if connectingto a valid server.

This can prevent RADIUS server impersonation by tools such asFreeRadius-WPE.