Hi board,
I have CUWN base priciple question regarding the split MAC archtiecture. Because I guess my question is technically quite complex (from my point of view), I don't really expect an answer. However it's documented here and maybe some god-like Cisco wireless guru will stumble over this and share some wisdom
So, here's the actual question or discussion I like to start here.
Especially the following key priciples, performed by the WLC are important (split MAC):
- 802.11 authentication
- 802.11 association and re-association (mobility)
- 802.11 frame translation and bridging
- 802.1X/EAP/RADIUS processing
(Source: Enterprise Mobility 8.1 Design Guide)
So the WLC is responsible to process and generate some crucial WLAN management frames for client association. I guess this is true for local mode APs, right? How does the split MAC architecture change for FlexConnect? Does it also depend on whether the WLAN is centrally or locally switched?
So at the end of the day I like a table containing the following information (I already filled out some things):
Role / Job
|
local mode AP |
FlexConnect (central switching) |
FlexConnect (local switching) |
| "802.11 authentication" frame generation |
WLC |
WLC
|
WLC (connected) / AP (standalone)
|
| "802.11 association and re-association" frame generation |
WLC |
WLC |
WLC (connected) / AP (standalone) |
| "802.11 frame translation and bridging" |
WLC |
WLC |
AP |
| "802.1X/EAP/RADIUS processing"* (4-way handshake frames) |
WLC |
WLC |
WLC |
|
|
|
|
* Caution: Don't consider RADIUS packets, because this depends whether the SSID is configured as central or local auth. The important frames are the EAPoL 4-way handshake frames (don't consider 802.11r/FT as well - this would go too far for now )
Key question is, who generates the 802.11 authentication and association frames in FlexConnect central switching?
If you know the answer to this, you may stop reading and hit the reply button now. Because what follows is just my gibberish and theories regarding this topic.
--------------------------
Here's my theory and my point of view. But this is just a theory and has not been proven by any Cisco document I know or in the lab.
Of course I could test it by capturing CAPWAP data frames, but I don't have a lab at the moment.
So, why are local mode APs not supported over a WAN link by Cisco?
Cisco does not support deploying local mode APs using a centralized WLC over a wide area network. If
remote APs need to be supported over a WAN, Cisco recommends implementing the FlexConnect
architecture.
(Source: Enterprise Mobility 8.1 Design Guide)
My guess would be:
- Local mode APs have more aggressive heartbeat timers (may be tunable) comparable to FlexConnect APs
- Because of the split MAC, there could be a high delay in 802.11 association frame transmission by the AP (depends on the actial WAN delay). This is because the WLC generates / processes these frames - thus these frames need to traverse the WAN.
--> Client association may fail, because clients run into timeouts while waiting for association/authentication response frames.
Note: The second bullet point is highly client dependent. I tested this years ago using a WAN emulator and introducted RTTs about 1 second. Most of my clients could handle that - but sometimes association failures occured.
Are there any other points I missed, why it's a bad idea to run local mode APs over a WAN? (not considering, that data frames eventually need to traverse the WAN two times - one time CAPWAP encapsulated, one time decapsulated).
What if, a requirement is there to centrally switch traffic at a headquarter WLC, because of central processing and enforcement of security rules? I would need to somehow tunnel the traffic to the WLC. In case there is a WAN, I would configure the APs to FlexConnect with central switching. Hopefully the 802.11 association process is performed by the AP and not by the WLC in this case, to overcome association issues due to timeouts.
However the Enterprise Mobility Design Guide also states:
The Cisco FlexConnect solution also supports Central Client Data Traffic, but it should be limited to
Guest data traffic only.
But I guess this recommendation is out-dated, right?
So my hope is, that someone gets interested in this and joins this discussion. Please feel free to share your thoughts.
Cheers
Joe
