Jimbo,
See comments inline.
Jimbo wrote:
I'm trying to get my head round the function of the Cisco WLC. I think I undersatnd it, and will document what I think happens here. All comments like "Yes, thats right" or "no, that's wrong, it works like this" greatfully accepted.
So, the WLC sits in the distribution layer of the network. An AP, connected to an ACCESS port (APs don't handle VLAN trunks) in the accesss layer comes on line, grabs a DHCP-supplied address from the DHCP server. The information includes option 43, which tells the AP which WLC to associate with. The AP uses its new address, and establishes a CAPWAP session with the appropriate controller. Thats the AP good to go.Tunnels (built in Layer 3, but looking like layer 2) are established between the AP and the WLC, one for each WLAn configured.
The WLC will does not need to specifically sit in a distribution layer of the network. However for ease of explanation, yes this would be correct. You will want it to sit where it can be physically connected via 802.11Q trunk links and LAG groups if using multiple ports.
The AP's themselves can just be plain old "access" type ports, no need for DOT1Q. The LWAP's when first brought online will attempt to perform several methods for "phoning home" and to join the WLC. You are correct in that DHCP option 43 is one of the methods used. Personally that is my least favorite way to seed an AP. This method requires you to convert the IP of the WLC (management interface) to HEX. The DNS method is usually much more simple especially if you have a large deployment with only 1-2 DNS servers internally.
As for as a CAPWAP protocol this all depends on the version of code you are running on the WLC. I believe since 5.0+ its CAPWAP. If the WLC is running prior to this its actually a LWAP protocol. I would recommend going up to a code that supports CAPWAP for security reasons.
Also as for a layer 2 vs layer 3 tunnel type this depends how you deploy the WLC. I also believe since 5.0+ code only Layer 3 deployments are supports. So the tunnels are actually built using UDP between the AP and WLC.
Jimbo wrote:
Now along comes a client PC, and connects over 802.11 to the AP, connecting to a particular SSID and therefore a particular WLAN. It needs an IP address so it broadcasts a DHCP request, which goes out to the AP, then over the tunnel associated with the WLAN/SSID it is on, to the WLC. The WLC proxies the DHCP request (for mobility reasons) and gets an address for the Client PC.
short answer, yes. You can create virtual interface and then bind SSID's to them in that matter.
EX:
Interface = name:users, vlan 123
WLAN = name:cool_kids, bound to vlan 123, SSID=Cisco
So users connecting to SSID=Cisco will be placed on vlan 123
Jimbo wrote:
The DHCP information for the client PC will have a default gateway stipulated, which will be the address of the VLAN interface configured on the switch to which the WLC is connected (by the same VLAN)
The default gateway would be whatever is set in your DHCP server, so yes it should be the SVI on the switch for that VLAN. Or else your users might not get very far

Jimbo wrote:
What happens now is that the PC wants to send data to somewhere.com, will do a DNS request for it over the tunnel, through the WLC, etc, get the IP of the remote target, and will send its packets over the (apparently Layer 2) tunnel link, through the WLC to the default gateway address on the switch. This will then switch/route the packet out to the correct target site.
Typically most deployments now a days are using Layer 3 tunnels, see note above.
Jimbo wrote:
So that the Client PC can be found, the subnet that it is part of (via DHCP) will be advertised by the switch/router to which the WLC is connected, based upon the VLAN interface address used to connect to the WLC and using whatever is the routing protocol in use.
Thats pretty much how I *think* it works....any comments? Have I got it wrong?
Thanks Jimbo
Yep
HTH
-Derek