 |
| Everyone wants in on the "Cloud" hype, including kitchen sinks and now centralized WLAN controllers! Image courtesy of Accu-Tech. |
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.
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.
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:
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. |
- 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.
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!
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
Andrew,
ReplyDeleteSo it seems to me the major limitations are still no dynamic vlan support and a lack of security controls if the link to the controller goes down. Is that right?
Your post seems to imply that with a local backup RADIUS server that its possible to do new 802.1X-PEAP or TLS logins and that its possible now to have fast roaming support when the controller link is down. Just wanted to clarify if that is the case.
Although this and other manufacturers distributed data plane solutions is helpful along the road to a fully controllerless solution I am still seeing that there is some pretty significant loss of functionality and control over the system when the controller link isn't there. Of course it will depend on the use case as to whether this is acceptable or not.
Andrew,
ReplyDeleteCouple of points:
1) Centralized controller architecture was not pioneered by Airespace or Trapeze...it was Symbol Technologies back in 2003 that developed and sold the first commercial controller based solutions
2) How is this new Flex controller architecture different from Motorola's WiNG or Aerohive?
Hi Andrew,
ReplyDeleteThanks for your insightful review and for sharing your thoughts on where the industry and vendors are going in terms of wireless architecture. I agree with your take on it, and also think Cisco will continue down this path of development and transition.
Cheers,
Pablo
Chris,
ReplyDeleteYes, there are still several H-REAP / FlexConnect limitations I have listed in a separate blog article, including AAA override for dynamic VLAN support.
However, in regards to security controls, I have found that most organizations that use a Cisco WLAN infrastructure enforce security at a different point in the network, not on the wireless controller. Such as the upstream router or firewall.
Also, the FlexConnect APs can use a backup local RADIUS server with any EAP type(if present), or use local authentication on the AP itself using LEAP or EAP-FAST only. Also, fast roaming is only supported for clients authenticated through the controller prior to it becoming unavailable, since the controller distributes the PMKs to the APs in the group.
Cheers,
Andrew
Anonymous,
ReplyDeleteTo my understanding, Airespace pioneered controllers back in 2001-2002, with FCS in Feb. 2003. See Bob O'Hara's talk linked in the article. In any event, that's not really important at this point in the industry. Heck, vendors are always claiming to be 1st to market over top of one another, so there's nothing new there.
Also, Cisco Flex is different from Motorola WiNG because the remote APs can scale beyond 24 APs which is a limitation of WiNG. Also, in speaking with Motorola, one of the APs must still be virtual controller even when there are central controllers, and it can only handle up to 24 APs at a site. So, Motorola really can't scale beyond 24 APs per site. For larger installations, they will need local controllers on-site. The same limitations apply to Aruba's Instant product feature set, with a smaller limit of 16 APs.
Finally, Aerohive does not require controllers at all since they implement AP coordination completely in software. This architecture is fundamentally different from all controller vendors and removes the complexity in planning for controllers (either local or central).
Cheers,
Andrew
Hi Andrew,
DeleteAruba instant latest firmware release (v.3) is now 'unlimited' - unlimited number of APs, unlimited number of clients. OK, realistically, I don't see this scaling to more than 64 APs and more than 1000 client devices on a single backend VLAN because (Aruba instant does not support VLAN Pooling).
Given the upcoming 802.11ac standard, I believe that decentralized strategies are best to cope with the eventual client bandwidth demand.
Best regards,
Paul ;-)
Paul,
DeleteLet me preface my response by saying that I now work for Aerohive, an Aruba competitor. But I have always been, and continue to be an engineer with independent analysis as much as I possibly can. I think my history bears that out.
Yes, I have seen the latest release notes on Aruba Instant stating unlimited APs. But remember that Aruba Instant loses many features that are only in their controller. So they effectively perform minimal coordination between each other.
Some of the features lost include:
- No layer 3 roaming across subnet boundaries
- No wireless bridging
- No client load balancing between APs
- No high availability or client session preservation if the primary virtual controller AP goes down. A backup can take over, but all clients must re-auth and re-establish all their sessions.
- Device identification / fingerprinting requires an external system (ClearPass)
- Only one captive web portal, which must meet all use-case scenarios.
- No Bonjour application support
Furthermore, if you look at what Aruba is telling customers, they are saying to use Instant as a "start small" approach with full migration to their controller architecture as they grow larger. If Instant were so awesome, why would they do this? The fact is that they lose features with Instant and have lower margins (MUCH lower in fact). So they are really using Instant as a marketing tool to get in the door then up-sell customers on controllers.
I also agree with you on 802.11ac and distributed forwarding as being the only real option moving forward in the industry. That is why all the major vendors have distributed forwarding capabilities today. But don't make the mistake of thinking that distributed forwarding in their solutions equals distributed control and coordination between APs, because it is NOT. In every controller-based vendor solution for distributed forwarding, you lose features. Period.
The only truly distributed forwarding, distributed control, and full featured solution is Aerohive. Frankly that's part of the reason why I left the customer side and went to work for them.
Cheers,
Andrew
Hey Andrew,
Delete@ozwifi here. One of our SEs pointed me in this direction, thought I would write couple of things down.
We have started developing Aruba Instant few years ago, given the memory/CPU/flashRAM space now available on our 11n APs - you know the story better than I do. We started at a small scale (16) per virtual controller and basic set of WLAN features. That was our release 1.0. We are now at release 3.0 and we have made quite a bit of progress. More will come down the road... for instance Aruba AirGroup for Bonjour is not there now but it will be, it is in the roadmap. We are committed to making both platforms alike feature-wise.
By the way, L3 roaming is coming in 3.1 - just demo'ed it for the first time at Airheads Nice :) That actually what makes it infinitely scalable given the VLAN/subnet limitations at the edge of the network considering best practice LAN design.
On features... wireless bridging works today - even if you do not have DHCP server in the network! ... it is pretty cool. Client load balancing is there, spectrum load balancing (sharing load across channels instead of radios) is not but it is on the roadmap. Virtual controller AP going down does not disconnect all clients in the WLAN, just the clients associated to that AP - just like it would in any other WLAN, they roam to the other most nearby AP. Device fingerprinting has been there and we added device specific policy enforcement in 3.0. For branding and customization in captive portal, we offer ClearPass (ex-Amigopod) that's correct, similar to Aerohive's guest manager (which I believe is still Amigopod OEM?) - nothing new there.
Let's talk about the sales strategy you mentioned from Aruba... we want to offer flexibility to the customers. There is no bait & switch here. No sales guy can sell a Mobility Controller to a customer today if they do not want to buy and deploy it. It's a change for us since we now offer both options so it is going to take time to train channel/direct-sales but the flexibility of offering both is where we are headed. That's our value-prop when it comes to WLAN architecture discussion basically.
The key point is many large campus customers (Ohio State Univ, SAP, Google, Quinnipiac etc.) they prefer to centralize their network (L2/L3, DHCP, DNS) services or the security services (content filtering, NAC, FW) so Mobility Controller is a great solution for them - they love what it does. Instead of managing 20 VLANs at the edge of the network on access switches for wireless users and configuring ACLs/routing for those VLANs in aggregation and distribution, they prefer to do it centrally. It is a network design decision.
Regarding 802.11ac - I have heard the same story of "Aruba mobility controllers will be obsolete" with 11n as well. Same thing I told then, I tell now... one needs to look at the core network bandwidth and internet pipe before thinking about mobility controller speeds and feeds. Aruba mobility controllers will always match the bandwidth requirements customers require at the core of the network for wired/wireless. I have yet to see a customer who will say simultaneously 4Gbps encrypted or 20Gbps unencrypted traffic capacity for an M3 controller (512 campus APs, 1024 remote APs) is not enough... and I have talked to a lot of customers over the years :)
Always enjoy talking Wi-Fi tech with you!
Ozer
BTW, I just thought of it... interesting place to talk about Aruba Instant and Aerohive, considering your blog article title, haha :)
DeleteOzer,
DeleteThanks for dropping by my blog and providing an update on Aruba Instant! I always appreciate the discourse on technology when I chat with you, and on traveling to Turkey :)
It sounds like Aruba Instant has some big features on the roadmap. Glad to hear that.
On the sales side, I can only attest to what I've read in Aruba marketing that gets placed in front of customers. Specifically, it states that Aruba Instant is ideal for initial small deployments, and controllers should be purchased as customer deployments grow larger. From my vantage point, that sure sounds like pushing Instant as a lower cost entry point, then up-selling to controllers. There's nothing wrong with an up-sell strategy, but I think customers should be made aware of that recommendation from the beginning, not at some point later down the line when they are just growing their deployment and are hit with that smacker ($$$$) in the forehead. Hopefully that is the ethical tact your sales teams are taking... (not making any inferences, just hoping for the best here).
That leads me to my major question -- if Aruba is committed to making Aruba Instant and Mobility Controllers alike feature wise, then why should customers ever buy Aruba controllers? I get the "less VLANs at the edge" design discussion, but that same design objective can be met with stateful firewalls within the AP and collapsing edge VLANs where feasible. Every edge closet typically has a data and voice VLAN anyways, so what trouble is it to either place the wireless users into an existing client VLAN, or drop them into one more edge "wireless" user VLAN? If the Instant solution is fully capable at some point down the road, haven't you just cannibalized your own controller product line? Ultimately, I'd love to hear where the differentiation exists between the two product lines down the road.
Perhaps a topic for discussion at Wireless Field Day 3... which I can't participate in as a delegate anymore, obviously since I work at the Hive :) But I'm interested nonetheless!
Again, thanks for the discussion! Always appreciated!
Cheers,
Andrew vonNagy
Hey Andrew!
DeleteSorry it has taken me awhile to write back - busy as hell now that I am back from Turkey after a week break... did not check emails if you can believe it! I am glad that you enjoyed your time in Turkey too, weather in Istanbul was really nice... and yes, Ortakoy is awesome, you can spend a full day or two in that small town and not get bored... Alright back to tech.
Yes, we essentially have built a product line that early adopters of the WLAN technology loved - it scaled, it was secure and it accomplished many things. But the late adopters who start small or who will always stay small are coming of age... we did not have a normal WLAN product for normal people if you know what I mean. BTW, let's say 30-50 APs when we say small WLAN although I think that number used to be 10-15 few years ago.
With Instant, we are expanding our product offering instead of replacing the controllers - customers are presented both options. Instant and controllers are suitable for all customer types but from what we are seeing (sales numbers, vertical penetration, customer interviews).
Instant is the product of choice when customer requirements are not as complex, their WLAN is migrating from an autonomous AP deployment, smaller in scale. And controllers is the product of choice when there is a large campus WLAN in place, when centralized enc is important to customer, when centralized NAC/FW/IPS enforcement is important, when the "employee" SSID needs to be supported by 10+ VLANs (due to subnet size requirements) and centralizing VLANs make sense, when remote APs, VPN users, site-to-site VPN is required... perhaps we can list more.
We obviously give the customer the option to migrate from Instant to Mobility Controllers while keeping the AP hardware the same (similar to Cisco autonomous to Cisco Thin, although our Instant APs do far more than Cisco autonomous similar to Aerohive APs as you know). So if the conversation / requirements move towards the list of items in the latter part of the previous paragraph, then Mobility Controllers creates interest with the customer.
Given the differences in the network design and the ability it gives us to deploy APs in all possible locations in a customer environment (home, branch, small office, campus, etc), we are committed to keeping Mobility Controllers and Instant alive and kicking... it is an expansion of product line for us, not a change. We believe there is a no one model of deployment for customers and they need to presented with the option to choose - as long as we are honest about what each option means! :)
Yes, we will miss you at #WFD3 - it is a great WFD topic of discussion for sure!
Gorusmek uzere,
Ozer
During the sales cyl
Hi Pablo,
ReplyDeleteThanks for your feedback! I have enjoyed reading your posts as well, especially the 3-stream capable products hitting the market.
Andrew
I was a Beta site for the WLC 7500 controller, and have since deployed the controller. So far we are NOT disappointed with the products or feature sets. Cisco has just scratched the surface with the features it will support with the new controller, the Beta documentation shows several new features coming out real soon.
ReplyDeleteCisco once again puts itself at the top of the wireless market with this product.
I need some answers to compare this with Aerohive. Can this do Bandwidth steering, Zero touch config and do the AP's have 3x3 Mimo and 3G backup option?
ReplyDeleteHi CoG,
ReplyDeleteThe features you reference are really capabilities of access points, not the controller. That said, various Cisco APs can do Band Steering (referring to frequency bands, not bandwidth), all CAPWAP APs are zero-touch config, and the new 3600 AP actually has 4x4:3 MIMO radios. None of the Cisco APs offer 3G/4G backhaul, however.
You should also review my post on Wireless Access Point Feature Matrices.
Cheers,
Andrew
for effective BYOD solution role derivation based on device type is imperative. How does this HREAP solution address that.
ReplyDeleteIt requires integration with Cisco's ISE platform.
ReplyDeleteHi Andrew,
ReplyDeleteI'm currently deploying a pair of Cisco Flex 7500 Cloud Wireless Controller using latest Firmware version 7.3 and I just want to share my current experience:
1- HA mode between two data centers is apparently not supported by Cisco TAC. Even if latency is lower than prescribed 80ms.
http://www.cisco.com/en/US/prod/collateral/wireless/ps6302/ps8322/ps10315/qa_c67-714540_ps2706_Products_Q_and_A_Item.html
Cisco requires more testing to make sure HA mode is functional and this might be related to bug CSCub52499. The HA mode feature will be supported across data centers in Firmware version 7.4.
2- Cisco AIR-CT7510-K9 Wireless LAN Controller does not support port channel. This will be supported in Firmware version 7.4.
3- HA mode requires both primary and secondary firmware versions to be identical. This poses a problem when upgrading firmware as it requires a complete service outage. In mission critical environment this implies a full RADIUS re-authentication of all client devices when Access Points will re-join the Wireless LAN Controller. Firmware updates need to be carefully planned via the use of Cisco Prime NCS AP templates to shutdown radios and progressively re-activate RADIOS.
4- RADIUS Capacity planing is crucial. All RADIUS authentication are coming from the same source IP Address when using central authentication in combination with HA mode. RADIUS Load Balancing cannot be made based on the source IP address making it more complex and risky...
5- New FlexConnect Local Authentication mode is prone to several problems:
a) CSCub50981 GTK key update breaks for clients on FlexConnect AP using local authentication.
b) We also observed that client devices supporting 802.1X pre-authentication are sending EAPoL authentication requests via all surrounding Access Points. This is resulting in an unexpected increase in the number of authentications for each client devices.
c) Cisco Prime NCS cannot help troubleshooting client’s connexions: ‘Client Troubleshooting is not supported for H-REAP Locally Authenticated clients’
I suggest for those interested in this new Cisco Flex 7500 Cloud Wireless Controller to carefully plan the following:
A) RADIUS authentication strategy and capacity
B) Firmware upgrade strategy
C) Not use FlexConnect Local Authentication mode (at least for the time being)
D) Wait for Firmware version 7.4 before deploying HA mode
Best regards,
Paul Gallant, Eng.
CWNA, CWSP
Hi Andrew,
ReplyDeleteI am a big follower of your Blogs, this is a great Blog Page...I like the Value Proposition section.....Kudos
Regards
AKRAM