The Cisco WLAN Scape

This blog is about all the varieties of Cisco WLAN right now — the Cisco WLAN Landscape. If you have been paying attention, you will have noticed the Cisco announcements about the 3850 switch and the 5760 controller. If you haven’t, I included some URLs below that should provide some food for thought. Along with the relevant videos from Network Field Day 5, embedded below.

We’ll start with the new products, the Cisco 3850 switches and 5760 controllers. We’ll then lightly cover the rest of the Cisco WLAN products.

Some Background

For a few years, I’ve been bugging my Cisco contacts with “when’s the N x 10 Gbps controller coming out?” The answer I usually got was “we aren’t seeing that kind of traffic level in practice.” It turns out that may have been true or perhaps a bit disingeneous. The part I missed: terminating LWAPP or CAPWAP tunneling is a performance bottleneck. So until recently, there wasn’t much point to putting in a lot of bandwidth from controller to LAN since the controller could only handle so much CAPWAP encaps/decaps load anyway.

Do the math: 802.11n at nominally 200-300 Mbps per AP, say 200 Mbps x 500 APs = 100,000 Mbps. Since users compete for access to RF timeslots and shared bandwidth (in effect), usually in 15:1, 20:1, or worse ratios, I’ve always been concerned about adding LAN and controller oversubscription on top of that.

For the coming 802.11ac WLAN, multiple by, say, 5. Big problem!

How do you scale some computing or networking problems? Distribute the load!

About the Cisco 3850 Switches

The 3850 switches have a new chip (or several) in them that handle the CAPWAP termination. It is called UADP (Unified Access Data Plane). The CAPWAP tunnel runs from AP over the Ethernet cable and terminates at the 3850 switch port.

The 3850 switches also contain a new improved version of 3750 StackWise, named StackWise-480. It provides “stack bandwidth” of 480 Gbps, described as 480 Gbps non-blocking!

And the 3850 switches also contain a built-in controller that is configured via IOS.Which perhaps facilitates deployments where  AP density didn’t formerly justify a controller.

And the point is … that distributes the load quite nicely, thank you!

Claimed performance and other info from the datasheet:

• Up to 40G of wireless capacity per switch (48-port models)
• Support for up to 50 access points and 2000 wireless clients on each switching entity (switch or stack)

Features:

• 1 RU stacking switches and power (some minor limitations right now)
• Up to 40G of wireless capacity per switch (48-port models)
• Up to 50 access points and 2000 wireless clients on each switch or stack
• PoE+ with 30W for all ports
• IPv4 and IPv6 routing, multicast, QoS, Flexible NetFlow, and universal image with licensing
• Dual redundant power
• Uplink modules (choose one of):

• 4 x Gigabit Ethernet with Small Form-Factor Pluggable (SFP)
• 2 x 10 Gigabit Ethernet with SFP+ or 4 x Gigabit Ethernet with SFP
• 4 x 10 Gigabit Ethernet with SFP+ (supported on the 48-port models only)

The 3850 terminates CAPWAP locally as default “Mobility Agent” mode (IP Base image). If you license “Mobility Controller” mode, it does mobility coordination, RRM,and CleanAir coordination within a mobility domain. (Per-AP licensing for that.)

Note that the uplink modules may be the bigger constraint than the StackWise-480. That is, the stack can move data between ports quite nicely but you’d need a lot of uplinks to get high capacity out of the stack. On the other hand, at 50 APs max per stack, if they do 1 Gbps each that’s still only 50 Gbps out of the stack.

Do read the Q&A sheet (URL below), there are a lot of conditions and caveats in there. Early hardware and code, to be expected. Older APs not supported. That sort of thing. Read the fine print carefully, this is new technology!

By the way, one thing that came out in the NFD5 sessions (video below), is that you cannot cascade say 3750 switches with connected APs into 3850 ports and use the CAPWAP termination. The AP has to be plugged directly into the 3850 switch, and this is verified and enforced. Thus you have to migrate a building “vertically”, putting 3850s wherever you need them and perhaps new APs, and leaving other chains of 3750s with WLC / Prime-controlled APs as is. This perhaps works a lot better (well, simpler) as future proofing: upgrade WLAN-less 3750s to 3850s, then add the APs.

Something I haven’t seen or caught is whether the Prime GUI can configure the 3850 controller functionality, to what extent, and how easy it is to do. Or perhaps IOS only configuration of the controller functionality is all that is planned.

The Q&A document says “The Cisco Catalyst 3850 can be managed using the Cisco IOS Software CLI or using Cisco Prime^™ Infrastructure 2.0.”. Of course, what does “managed” mean? CLI command push? GUI? Apparently a switch GUI might be added later … or not. 

Supported APs (per the data sheet): 3600, 3500, 2600, 1600, 1260, 1140, 1040.

So What’s the Big Deal? #1: Speed and 802.11ac support via the UADP chips and a distributed approach. In particular, the controller to switch bandwidth is no longer a (major) bottleneck. #2: You can apply ACLs and QoS the same to both LAN and WLAN traffic. Hence “Unified Access”. Let me repeat: Your CAPWAP tunnel runs from AP to switch along the Ethernet cable. That’s it. There’s no more CAPWAP across the LAN. For those of us (including me!) who tried to apply QoS and were defeated by CAPWAP (tunnel conceals all info about payload, got to trust the AP or controller), that’s a big deal!

What is the Future Role of a WLAN Controller?

The controller will likely no longer terminate tunnels. It remains a central control point for WLAN. That is, a point of configuration so you don’t have to individually configure all the APs. (Remember IOS autonomous controllers. Fun to deploy — if  you have the time!)

To paraphrase quies custodiet ipsos custodes (who guards the guardians — one of the 4 Latin phrases I seem to retain): who controls the controllers? Put another way, if you deploy 3850 switches all over your campus, do you have to configure each and every one? Or will there be a central controller controller (controller^2 ?) with GUI?

Of course, if the controller IOS commands are simple enough, cut and paste cookie-cutter deployment may work rather well. Boilerplate configurations from Prime? (Detail to be explored in a lab by the reader?).

About the 5760 Controller

From the datasheet:

• IOS-based controller
• Wire-speed 60-Gbps throughput with services (SFP+)
• Up to 1000 access points per controller and 72,000 access points in a cluster
• Up to 12,000 clients per controller and 864,000 clients in a cluster
• Flexible NetFlow version 9

Ok, here the math does say “potential bottleneck” to me.

And my first question is: OK, it is IOS-based (CLI), but does it also have a web GUI?

The Rest of the WLAN Scape

• The Cisco SMB products provide smaller scale controller or GUI and AP support.
• Meraki provides low cost APs. The price includes 5 years of support, with cloud based controller. (No controller or software to buy, no software to install, no servers to manage!) Attractive for schools and smaller businesses who don’t need the cost of a controller, management software, servers, and admin hassles. How the features stack up is something I’ll have to leave for another blog. Is Cisco going to merge product lines, perhaps provide cloud control as an option for all its APs, or is Meraki intended as matching a niche?
• For what it’s worth: Meraki also cloud-manages security devices and switches. Their website is pretty impressive.
• “Traditional” controller based WLAN. But you know all about that or you probably wouldn’t have read this far!
• Outdoor / mesh wireless. Yet another large topic, more in the Service Provider space.

References

Cisco 3850 Switch: http://www.cisco.com/en/US/products/ps12686/index.html

Cisco 3850 Data Sheet: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps12686/data_sheet_c78-720918.html

Cisco 5760 Controller Data Sheet:  http://www.cisco.com/en/US/prod/collateral/wireless/ps6302/ps8322/ps12598/data_sheet_c78-722607.html

3850/5760 Q&A Sheet: http://www.cisco.com/en/US/prod/collateral/wireless/ps6302/ps8322/ps12598/qa_c67-726507.html

Videos from Network Field Day 5

NFD5: Cisco Catalyst 3850 Converged Access Switch Overview Video

See http://vimeo.com/61490430

NFD5: Cisco Catalyst 3850 Converged Access Switch Demo

See http://vimeo.com/61490422

NFD5: Cisco Wired and Wireless Demo

See http://vimeo.com/61490416

NFD5: Stephen Foskett’s NFD5 YouTube Playlist

http://www.youtube.com/playlist?list=PLObjX_zORJMACsq1Yj0qf2jbinZ5cble6

A Word from … Me!

I do love bad puns.

For those who are wondering, what about the CCIE prep content you started and then didn’t deliver on? It’s coming, I just have a backlog of thoughts stirred up by NFD5, and want to get them into blogs before the memories fade.

Disclosure

The vendors for NFD 5 paid for my travel expenses and perhaps small items, so I wish to disclose that in my blogs now. The vendors in question are: Cisco, Brocade, Juniper, Plexxi, Ruckus, and SolarWinds. I’d like to think that my blogs aren’t influenced by that. Yes, the time spent in presentations and discussion gets me and the other attendees looking at and thinking about the various vendors’ products, marketing spin, and their points of view. I intend to try to remain as objective as possible in my blogs. I’ll concede that cool technology gets my attention!

Stay tuned!