Cisco H-REAP Local Authentication Improvements

A while back I wrote about Cisco H-REAP, how it works, and some considerations and feature limitations.

As a follow-up, I'd like to briefly cover some recent changes in how H-REAP access points perform client authentication, specifically with the H-REAP Local Authentication features since this topic is confusing for most engineers (in-part because of the name).

H-REAP Local Authentication in code version 7.0.116.0 encompasses three distinct options for authentication of clients when "connected" to a WLC or "standalone".

Backup RADIUS Servers (AP as NAS)
This is the long-standing H-REAP feature that allows the AP to source RADIUS authentication to external 'backup' RADIUS servers when in standalone mode and the WLC in unreachable. In this scenario, the AP is the authenticator which forwards requests to the authentication server (RADIUS server). The authentication server must have the APs defined as a NAS.

This permits the APs to accept new clients and successfully complete authentication without reliance on the WLC. This is really a high availability feature for the WLAN to prevent an outage if one or multiple controllers fail.

Define the H-REAP backup RADIUS servers from the H-REAP Group:

H-REAP Backup RADIUS Servers

Update - Based on feedback in the comments, it should be pointed out that the AP and RADIUS server must use the same shared secret as configured on the wireless LAN controller. The AP inherits the RADIUS server definition and configuration from the controller, and it cannot be configured separately. This applies to both AP as a NAS situations.

Local Authentication (AP as RADIUS)
This feature allows the H-REAP access point to assume the role of both the authenticator and the authentication server (RADIUS server). The AP is required to have local users defined and only support a few EAP types, notably EAP-FAST and LEAP.

This feature is what most engineers describe this feature as meaning, without knowledge of the 3rd option below. Having locally defined users and restricted EAP types makes this option not all that attractive for most organizations, but there are some who have obviously requested it from Cisco. It beats static pre-shared keys for security, but creates administrative burden on network administrators to define and manage local users on the H-REAP APs.

Many organizations already have user accounts stored in corporate directory systems such as Active Directory, and definition of users in an alternate database is not preferred or allowed. That said, this feature doesn't make a lot of sense for user accounts tied to real people since corporate security policies usually dictate that passwords are rotated regularly and support personnel don't have access to those passwords, preventing them from being replicated on H-REAP APs. However, it may make sense for non-user IDs attached to embedded devices such as IP phones, Vocera badges, or handheld scanners.

Enable H-REAP Local Authentication (AP as RADIUS) in the H-REAP Group:

Enable H-REAP Local Authentication by the AP

Additionally, define local users and configure EAP-FAST and LEAP:

H-REAP Local Auth User Definition

Local Authentication (AP as NAS)
Historically, when the H-REAP AP was connected to a WLC, all authentication flowed through the controller. In code version 7.0.116.0 this changed. Now administrators can configure H-REAP APs to source client authentication and bypass the WLC, even in connected mode. This is beneficial when the AP is logically closer to the RADIUS server than the WLC and should source authentication itself to improve performance. A remote site that contains both H-REAP APs and a RADIUS server, with a centralized controller across the WAN is one example.

Enable H-REAP Local Authentication (AP as NAS) in each WLAN:

Enable H-REAP Local Authentication in the WLAN

When this option is enabled, the AP sends client authentication requests to servers in this order:

1. WLAN AAA Servers
2. H-REAP Group Backup RADIUS Servers (primary/secondary)
3. AP Local Authentication (local users on the AP)

One other quick note is that the H-REAP APs also support RADIUS fallback. So if a primary RADIUS server fails and subsequently comes back online, the AP will recognize this and begin sending client authentications back to the preferred server.

Hopefully this clarifies some of these new features that aid both high availability and performance.

Cheers,
Andrew

Cisco Flex 7500 Cloud Wireless Controller - What You Need to Know

Everyone wants in on the "Cloud" hype, including
kitchen sinks and now centralized WLAN controllers!
Image courtesy of Accu-Tech.

Overview of the Cisco Flex 7500 Wireless LAN Controller Solution
Last week Cisco announced a new wireless LAN controller platform named the Flex 7500 Series. This solution is aimed at providing a large-scale, centralized wireless LAN controller solution using Cisco's existing Hybrid Remote Edge Access Point (H-REAP) architecture. Along with this new release, Cisco is re-branding the H-REAP solution to Flex controllers and FlexConnect access points. The FlexConnect wireless architecture distributes data plane (traffic forwarding) operation out at the edge, while centralizing control plane operations in a controller in the data center.

Having acquired hands-on lab time with a pre-release version of the Flex controller, our team was able to run it through its paces to evaluate everything from high availability and failover to performance.

This solution is aimed at the remote branch office, utilizing data center consolidation of expensive wireless controllers. Cisco calls this architecture the "Lean Branch" due to the reduction of on-premise equipment and IT staff in remote branch offices. This seems to align well with limited IT budgets by reducing the duplication of network hardware out in every branch office.

Essentially, the Cisco FlexConnect architecture amounts to an extension of existing H-REAP foundational technologies, and provides enhanced solution scalability to support thousands of access points and tens of thousands of users, across hundreds of branch locations (per-controller). It also bundles some enhancements to previous H-REAP capabilities to address remote site survivability and high availability requirements that are  required in a centralized architecture when the WAN or central services are unavailable.

Also, a quick note on usage of the term "cloud". Enterprises have had central services hosted in private data centers for a long time. Just because an architecture relies on services hosted in a data center does not make it a "cloud" solution. True "cloud" solutions implement on-demand provisioning of services and capacity across multiple data centers. This is typically accomplished through elastic architecture, hardware abstraction, and virtualization of some form, and provides inherent client mobility. In my opinion, the FlexConnect architecture only meets one of those principles, inherent client mobility, and should not be called a "cloud" solution. The term is definitely over-hyped in the technology sector.

Value Proposition
The value of the Flex 7500 series is a platform by which Cisco can offer a large-scale controller-based solution that can compete against fully distributed wireless intelligence at the edge.

There is no doubt that the wireless LAN architecture is shifting back from a centralized control and data plane model pioneered a decade ago by Airespace and Trapeze, to distributed intelligence back at the edge in access points. As Bob O'Hara explains, the shift to wireless controllers made sense to enable advanced control plane functionality and coordination (dynamic radio management, L3 mobility, guest networking, key caching, etc.) among access points with limited processing capability. However, the advancements in silicon manufacturing are now at a point where this is no longer a restriction of hardware processing capacity, but of software development to enable intelligent AP coordination. Additionally, as wireless network bandwidth capacity continues to grow with the release of 802.11n, and subsequently with .11ac and .11ad, the controller can quickly become a bottleneck for both data plane traffic and access point control capacity.

It's apparent that Cisco and other large market-share wireless LAN manufacturers cannot dive straight into distributed access point intelligence due to cannibalization of existing controller product line revenue and support for their existing installed customer base. Therefore, Cisco must approach this market transition with a phased migration strategy. The Flex 7500 is large step in that direction.

Therefore, the value proposition of the Flex 7500 platform can be described as:

• Lower capital expense by eliminating the need for distributed controllers at each branch location. Going by list pricing, the Flex 7500 offers 43-47% cost savings versus the 5500 series controllers to support the same amount of access points.
  
  
• Less wasted controller licensing because multiple remote branches can utilize the same controller, thus pooling licenses into more of an enterprise-wide model. Cost savings will vary greatly depending on the exact size of branch AP deployments. At first release, the Flex 7500 will support up to 2,000 APs and 20,000 clients per-controller, with future software releases and licensing upgrades promising support for up to 5,000 APs without hardware upgrades.
  
  
• Lower operational expense because fewer pieces of hardware have to be managed and supported, and controllers are removed from remote branches relieving the need for local IT support or truck-rolls. I highly doubt an enterprise with an efficient branch model would have unnecessary local IT support and this isn't likely to result in much expense reduction for most organizations with well-established procedures already in-place. The largest savings is likely to come from reduced SmartNET expenses.
  
  
• Consistent policy enforcement across the organization with greater visibility and centralized control of access point configuration. This is arguably a function of any good management platform, including Cisco WCS and the forthcoming Cisco Prime NCS, so I don't really buy this as a value of moving to the Flex controller platform.
  
  
• Simplified controller management and upgrades because less hardware is required. This should actually benefit large controller installations, where the time necessary to upgrade large amounts of equipment can become time consuming. Coupled with AP image pre-download across the WAN, these should save network administrators many hours of tedious work.

All in all, the benefit for customers is really a large-scale controller solution that is much more cost-competitive than distributed controllers. Additionally, Cisco is looking to retain existing customers that are running their legacy Aironet Autonomous infrastructure and have found distributed controllers cost prohibitive to deploy, but are increasingly requiring features and functionality only found in their Unified architecture.

Hardware Platform

The Flex 7500 is built off the IBM x-Series server platform, specifically the x3550 M3. The system physically mounts into a standard server rack (not a 2-post telecom rack us network folk are accustomed to using), and occupies 1U rack space.

On the internals, it's specified with 2x Quad-Core 2.4GHz Intel Xeon E5620 processors, 12 GB DDR3 1333MHz RAM, 2x 146GB 15K RPM SAS hard drives, and optional redundant power supplies.Cisco is attempting to reduce the complexity associated with typical server builds by pre-configuring the server with standard components and offering minimal substitutions, such as the redundant power supply for example. This should provide most customers easier ordering and less confusion when moving from wireless controller appliances (4400, 5500 series) to the new server-based platform. It's also unclear at this time how the hard drives are configured for high availability, but it's most like a RAID-0 setup.

The Flex 7500 provides a  myriad of network ports, but most are dedicated for specific purposes.

For network connectivity, a myriad of ports are provided on the back of the unit (as shown). However, in order to keep complexity minimal and provide a consistent software image and configuration process with existing WLC appliance product lines, the network ports are dedicated for specific uses, as follows:

• Fast Ethernet is provided for system management by IBM and is not configurable from the WLC software.
• Port 1: 1G is used as the WLC Service Port.
• Port 2: 1G is reserved by the WLC for future use with High Availability enhancements.
• Port 1: 10G requires an external 10G SFP and is used as the WLC Management Port, similar to the existing WLC Distribution System ports on the 4400 and 5500 Series platforms.
• Port 2: 10G is reserved by the WLC as a backup Management Interface in the case of port failure of the primary port.
• Option Gb Ethernet ports are not used. 
• Serial Port is used for local console connections for staging and configuration of the system.

It is important to call out that the system only supports fiber 10G SFPs (SFP-10GB-SR) for the WLC Management Ports. This in-turn requires the Flex 7500 to connect to a 10G capable switch or line card. Additionally, the system does not support link aggregation (LAG) as the existing controller platforms do.

From a deployment perspective, image management and system configuration are almost identical to existing controller platforms. The systems uses the same initial setup and configuration wizard, CLI software command interface, and graphical user interface. Network engineers familiar with the current Unified Wireless Network solution will have a very short learning curve migrating to the Flex 7500 platform, mainly with the physical installation and cabling requirements.

Feature Enhancements & Limitations
Most of the feature enhancements included in the Flex 7500 platform are a function of software enhancements made in the latest release of WLC code version. I provided an overview of the major enhancements in this release in my previous post Cisco WLC 7.0.116.0 New Features.

As a recap, here are the major improvements previously described, as well as a few others that are of note specifically with the Flex 7500 platform:

• WIPS Enhanced Local Mode provides a subset (~73%) of Adaptive WIPS capabilities into access points that also handle client connections, eliminating the need for dedicated monitor mode APs or a 3rd party overlay WIPS solution. Note that the Cisco WCS / Prime NCS and the Mobility Services Engine (MSE) are still required for WIPS services. Additionally, since most of the processing occurs on the AP prior to sending data back to the MSE, there should be minimal WAN bandwidth impact.
  
  
• H-REAP Fault Tolerance provides enhanced site survivability when the link to the Flex controller is unavailable. This is an improvement to Standalone mode operation of the AP to provide seamless client connectivity throughout the failure and fail-back processes. This is a source of competitive advantage for Cisco, as they handle these processes significantly better than any other controller-based vendor today (not controller-less vendors). However, customers should be sure to review branch office design for critical services such as RADIUS, Active Directory, DHCP, and DNS to ensure complete site survivability in a WAN or data center outage scenario.
  
  Cisco also claims complete branch office survivability when using H-REAP local authentication. However, this requires static definition of users and passwords pushed to each AP for local authentication by the AP using LEAP or EAP-FAST (in either connected or standalone mode). Most customers will find this lacking in true scalability as well as a point of risk for the organization from a security perspective.
  
  
• Increased H-REAP Group Scalability allows up to 500 groups to be defined per-controller (hence the 500 branch site limit of the system) and up to 50 access points per-group to support larger branch sites. H-REAP groups are the primary method used to distribute wireless key cache for fast roaming support using CCKM and OKC, and for common configuration of RADIUS backup servers and local authentication users.
  
  
• Increased WAN Tolerance allows up to 2 second WAN latency between an H-REAP access point and the controller, but only when using H-REAP local authentication. The same 300ms WAN latency limit is in place when using external RADIUS / AAA authentication, mainly due to client timeout for the authentication to complete.
  
  
• AP Mode Auto-Conversion allows the Flex 7500 platform to ease deployment of new or existing Local mode APs. Upon joining the Flex controller, the system can be configured to automatically convert all APs to H-REAP mode without administrator intervention. Alternatively, they can be converted to Monitor mode instead, or this feature can be disabled. This should come as a welcome feature for network admins during migration!

Along with the good, come the bad. Unfortunately, the FlexConnect architecture is simply an enhancement to H-REAP, and therefore inherits the existing H-REAP feature limitations previously discussed.

In addition to the standard H-REAP guidelines and feature limitations, FlexConnect is also missing a few other features in the first release. Most notable among these are lack of support for location tracking and mesh networking. Location tracking is on the roadmap for inclusion in the next major software release, it just didn't make first shipment. Certain AP modes are not supported by the Flex controller at this time due to solution scalability concerns, including Local, Sniffer, Rogue Detector, and Bridge/Mesh.

Minimizing Operational Risk
There are also a few other items to be aware of when deploying centralized controllers. Since a large portion of the distributed wireless network is being controlled from a single point, a greater potential exists for large network disruptions due to mis-configuration or administrator error. This highlights the need for thorough lab testing of changes and upgrades prior to production rollout. Customers deploying the FlexConnect architecture should ensure adequate change control procedures exist, including test, implementation, verification, and backout plans. Additionally, granular administrative access should be enforced, and support procedures should be reviewed to minimize the chance for error during incident response.

From a hardware perspective, server hard drive failure should be integrated into standard server monitoring and maintenance activities to identify and replace failed units promptly. The reliance on mechanical hard drives in the Flex controller may result in increased support issues versus embedded flash drives found in existing wireless LAN controller platforms. However, when properly planned for this should not be a major concern.

Revolution or Evolution? - Andrew's Take
The Cisco Flex 7500 centralized controller platform is an enhancement of Cisco's previous H-REAP architecture, now re-branded FlexConnect. This solution is an evolutionary advancement of the controller architecture which improves scalability and high availability, while reducing customer expense of deployment versus a distributed controller architecture. It is aimed squarely at highly distributed organizations where the economics of branch site deployment are of paramount consideration. Many customers will find this evolution a welcome addition to the Cisco portfolio. However, Cisco still has a long road ahead on the migration path to a fully intelligent edge access point architecture, and will continue developing products that allow the company to replace existing wireless LAN controller revenue with new distributed features.

Cheers,
Andrew


Additional Flex 7500 Resources:
- Cisco Cloud Services for Branch Offices Press Release
- Cisco Flex 7500 Series Product Page
- Miercom Lab Report on Cisco Flex 7500 versus Motorola WiNG and Aruba RAP

Other Posts You Might Like:
- Hybrid REAP Overview
- Hybrid REAP Deployment Guidelines and Feature Limitations
- Cisco WLC 7.0.116.0 New Features
- AP Image Pre-Download
- Wireless Access Point Feature Matrices
- Cisco Unified Wireless Network Ports
- Well-Known Cisco WLAN Intervals
- Cisco Location Tracking Overview, Location Tracking Setup, Location Accuracy Tips, and Location Protocols

Cisco WLC 7.0.116.0 New Features

Cisco just released wireless LAN controller code version 7.0.116.0, which includes a laundry list of new features. Many of these new features have been in development for quite some time, and both partners and customers have been anxiously awaiting several.

Visit Cisco's website to see the full release notes for this code version.

Here are some of the notable new features and what they will mean for customers:

• WIPS Enhanced Local Mode
  This feature places a subset of Adaptive WIPS capabilities into access points operating in Local or H-REAP modes. Traditionally, Cisco aWIPS required Monitor mode APs. Now customers can get most of the benefits of an in-depth aWIPS deployment with the same access points that service client connections, without having to spend additional money on dedicated monitor APs. The solution still requires the WCS and MSE platforms, but can reduce CapEx and OpEx costs for customers. It is designed primarily for retail customers with distributed branch offices needing to maintain PCI compliance in the face of expanding mobile retail initiatives.
  
  By my count, ELM supports detection of 35 of 48 attacks available in the full aWIPS solution (~73%). The majority of missing attack detections are comprised of some RF DoS and Zero-Day attack detection capabilities, which are arguably not the most severe attacks (DoS) and are notoriously hard to baseline against false-positives / negatives (Zero-Day).
  
  Additionally, the focus of ELM attack detection is on the current operating channel of the AP, and has limited visibility into off-channel attacks through RRM off-channel scanning. This makes sense since the network infrastructure is performing double-duty serving clients and detecting attacks. This should not be an issue for larger network deployments with multiple APs covering most or all of the available channels. For smaller installations, this could present a serious problem however, and reduce effectiveness of the solution. However, this solution is arguably aimed at the larger retail deployments where the expense of deploying dedicated Monitor mode APs has been a problem.
  
  All in all, larger customers should take a look, while smaller customers will probably opt for a dedicated WIPS solution.
  
  
• H-REAP Fault Tolerance
  Cisco has been improving Hybrid REAP mode functionality in leaps and bounds in order to compete in distributed WLAN architecture scenarios, with the likes of Aerohive's Cooperative Control, Aruba's Instant virtual controller, Motorola's Adaptive APs, etc.
  
  H-REAP fault tolerance improves operation by removing the requirement for H-REAP mode APs to reboot when moving from standalone back to a connected state. Previously, H-REAP APs move into standalone mode without affecting locally-switched clients, but when re-joining a controller they were required to reboot and download a complete configuration which caused a service disruption during the fail-back process. Now the AP is able re-join the controller without impacting client service or rebooting, assuming it can verify the configuration matches.
  
  In addition, H-REAP WAN latency may now exceed 100ms (upwards of 2 seconds) provided customers use H-REAP Local Authentication of clients using the internal user list pushed to the access points.
  
  
• H-REAP Opportunistic Key Caching (OKC)
  Previously, H-REAP access points only supported CCKM key caching for fast roaming. Now it supports both CCKM and OKC, which should provide much broader support for fast roaming with many more clients in typical customer environments. Note that both CCKM and OKC still require the 802.1x/EAP key derivation to be completed through the controller. Any keys derived while the H-REAP AP is in standalone mode (disconnected) will not support fast roaming between multiple APs.
  
  I will also be awaiting 802.11r Fast BSS Transition support in H-REAP APs once broader market support and adoption are achieved through the Wi-Fi Alliance Voice Enterprise Certification (due out in 2011).
  
  
• Cisco Identity Services Engine (ISE) Support
  Cisco's next-generation ISE product provides context based access controls and integrates several services into a cohesive platform, including the Cisco Secure ACS authentication and Network Admission Control (NAC / Clean Access) products. This platform enables organizations to enforce network access policies based on a combination of user and device identity, and will be integrated into wireless, switch, and router platforms with software updates.
  
  ISE addresses customer needs for granular access control beyond VLANs and IP subnet policies, acknowledging the need for deeper insight into the context of the client session to drive policy enforcement. A common scenario for this today might be differential network and application access based on user and device, differentiating access by an employee on a laptop versus an iPad. ISE is part of the Cisco TrustSec solution.
  
  
• VLAN Select
  This feature enables pooling of multiple VLANs into a group for assignment to a single WLAN SSID or AP Group. Large wireless installations have traditionally required a single large subnet and broadcast domain to accommodate the number of wireless clients on a single SSID, dynamic VLAN assignment, or the use of multiple SSIDs which can introduce roaming latency and problems. VLAN Select allows client connections to a single SSID to be round-robin load-balanced into multiple network VLANs to reduce subnet size and broadcast / multicast forwarding concerns.
  
  Another use-case for VLAN Select is with guest termination in a DMZ environment. Large guest networks also traditionally required large subnets or multiple anchor controllers to segment the client population into smaller broadcast domains. This resulted in additional CapEx to buy more anchor controllers, since a single anchor controller could only use a single VLAN attached to a WLAN. Now, multiple VLANs can be tied to the same WLAN through VLAN Select, reducing the need for multiple anchor controllers.

I have update my post on H-REAP Deployment Guidelines and Feature Limitations to include these new enhancements, as well as a few others including security feature integration with Cisco switches. It's worth a read to review the current state of H-REAP functionality and limitations with the new 7.0.116.0 code release.

Cheers,
Andrew

H-REAP Deployment Guidelines and Feature Limitations

Updated on 2011/04/17 based on 7.0 J-MR1 code release enhancements (7.0.116.0)

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

o   CAPWAP utilization overhead is 400-500 bps

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

o   Code 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

o   Increased 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.

o   MAC Flooding attack prevention is fully supported

o   DHCP 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.

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

o   ARP 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.

§  Fortress Layer 2 encryption on a locally switched WLAN requires the “Learn Client IP Address” box to be un-checked, otherwise the controller periodically drops the client connection because it cannot learn the client IP address

H-REAP Standalone Mode Limitations

In addition to feature limitations that apply to all H-REAP operational states, the following limitations also apply when the AP goes into standalone mode after losing connection to the controller.

§  CCKM/OKC fast roaming is only performed for existing keys that were created when the AP was in connected mode to the controller.

o   New keys created once in standalone mode cannot be distributed between the APs in an H-REAP Group without a controller.

§  H-REAP Groups only support local authentication using LEAP and EAP-FAST for up to 100 users when in standalone mode (PEAP and EAP-TLS are not supported)

§  NAC and IDS integration are not supported when in standalone mode

§  RRM features are disabled when in standalone mode (DFS/TPC is still supported, however)

§  CCX layer 2 roaming features for clients are not supported in standalone mode (AP assisted roaming, enhanced neighbor list request (Intel E2E), roam reason report, directed roam request)

§  Bandselect will not function if an H-REAP AP is rebooted while in standalone mode

§  Multicast traffic forwarding is not supported in standalone mode

§  Error reports cannot be forwarded to the controller when in standalone mode

§  Peer-to-Peer Blocking is not supported in standalone mode

§  RLDP rogue connections are not supported in standalone mode

§  Rogue containment is not supported in standalone mode

§  Infrastructure MFP validation is not supported in standalone mode (Client MFP is supported)

§  IPv6 bridging is not supported in standalone mode

§  Link Latency Troubleshooting is not supported in standalone mode

§  Location services are not supported in standalone mode

§  CleanAir features are not supported in standalone mode

§  L3 seamless roaming is not supported in standalone mode (requires mobility tunneling)

§  WLC ACLs are not supported in standalone mode

§  TSPEC bandwidth reservation (part of WMM QoS) is not supported in standalone mode

Andrew