lightweight access point - a "dumb" wireless device that basically just sends and receives traffic from the client and performs some simple encryption. Will not work without a controller to tell it what to do.
Controller - A device that controls lightweight access points, providing the SSIDs, authentication, routing, and security decisions.
Ok, so here is the problem. You have lightweight access points that talk to several different controllers. Now a client has a laptop or a phone, that has connected to your wireless network. They decide to walk around and the client moves out of range of one access point. The client's NIC drivers decide that the signal is too low and begin probing for a better signal, find one, and connect to a second AP. If the second AP is connected to the same controller, then there shouldn't be any problem. The roam from AP1 to AP2 is completed inside the controller with no data drop. Now say they continue walking to a different floor and need to move to AP3. AP3 is not only on a different controller, but a different subnet. Being on a different subnet means the client must request a new DHCP address, a long (say 15 second) process. During these 15 seconds the client's sessions are dropped, the phone call dies, the video stops streaming (your phone starts ringing).
Cisco's solution is a "mobility group". Under the Controller tab, you can expand "Mobility Management" and click mobility groups. This allows you to enter the Mac Address, IP, Mobility Group Name, and Multicast IP for the other controllers in your environment. By putting all (or all within a building or site) your controllers into a single mobility group, the controllers will constantly be talking over that multicast group to each other about what clients they have. When your client decides to move to a new controller, the original controller becomes an "anchor" controller.
Once the client has an anchor controller (C1) and has roamed to the new controller on a different subnet (C2) they send all their traffic through C2, who in turn passes everything to C1 for processing. This allows the client to retain their original IP address and avoid the connection drop that would have occured. C1 then passes the traffic out onto the wire (wired network), and all return traffic is sent to C1 and then passed to C2 and finally the client.
In older code versions, outbound traffic moved from client to C2, and was dropped out onto the wired network directly, and only return traffic proceded through both C1 and C2. The problem people found with this was when there was a firewall between the two controllers (eg. remote site) the outbound IP address was different than the return IP. I will save the firewall posts for another day, but simply put, a firewall will send a packet out, and automatically open a hole for the return packet. If that return packet is coming to a different IP, it doesn't fit in the waiting hole and gets dropped.
I know a drawing always helps me so I will try to provide them regularly. Here you can see the client before the roam on the left, sending traffic in and out of a single controller. After the roam, on the right, you can see traffic sent through both controllers in both directions.
No comments:
Post a Comment