Posts Tagged ‘WLC’
Control roaming behavior on your Cisco wireless network.
Roaming is just another expectation from your end users. They expect to walk freely around the office to conference rooms or far off cubicles and have their laptop or handheld remain connected while downloading files or in the middle of a conversation. If the roaming process is not quick enough then you could see conversations and clients gets dropped forcing them reconnect to the WLAN, and I can guarantee you your end users will be calling.
Now, if you have done a proper site survey and have solid data to work off of, you can control the roaming behavior of your WLAN clients. The reason you need to know the details of your wireless environment is because you are going to set RSSI limits concerning when your clients should begin looking for a new AP to associate to and, how quickly they are roam between access points. Just keep in mind, making these settings will effect the entire WLAN not just individual sections.
I would also like to mention your clients should be CCXv4 or higher to take advantage of these features. To see if your clients are CCXv4 compliant go to Monitor -> Clients -> click on the client in question.
On your Cisco Wireless LAN Controller, you want to navigate to Wireless -> 802.11a/n or 802.11b/g/n (depending on which frequency you want to customize) -> Client Roaming.
The first thing you need to do when you want to customize these settings is change the mode to custom this will allow you to edit the default values for the rest of the parameters.
The next option is minimum rssi. If a clients RSSI value is below this threshold it will not associate/authenticate to the access point, instead it will continue to look for a better signal from different access points. Valid values for this field are -80 through -90. The understanding is that the signal strength/quality will be so low reliable communication will not be established.
Next we have a setting called hysteresis this value is in dB and states how much stronger the signal of another access point has to be before a client decides to roam to it. This is useful if you have multiple access points in close proximity of each other or clients are moving between the edge of coverage of different access point. The higher this value the closer a client needs to be to an access point for it to associate to the second access point. Valid ranges are from 2 through 4 dB.
Now we have the scan threshold this is another RSSI value range. When the wireless client’s RSSI drops below this threshold the client will begin actively scanning for another access point it can receive a stronger signal from. Valid values range between -70 through -77.
The last field on the page is the transition time this is the amount of a client is going to see a better signal from neighboring access, before it attempts to associate to the second access point. The client determines a better signal when its RSSI drops below the scan threshold and it sees a signal from a neighboring access point higher than the scan threshold.
So all these factors do work together and can be customized for your environment. Normal data traffic is more forgiving since it’s not as delay sensitive, but If you have voice on your WLAN you will want to fine tune these settings to avoid dropped calls.
Cisco WLC Interfaces.
If you have ever worked with a Cisco WLC or have looked through any configurations for a WLC, then you have no doubt seen the interfaces that make it work. You’ve probably also seen that diagram concerning how these interfaces relate to the physical interfaces on a Cisco WLC.
Now their are only five different types of interfaces (Management, AP-Manager, Virtual, Service-Port, and Dynamic Interfaces), I figured I would just take some time to quickly touch on them.
- Management Interface – As you can suspect this interface is for in-band management and handles any communication with AAA servers. This interface will also handle the layer 2 communication between the controller and any APs. Needless to say the configuration of this interface is mandatory and can not be skipped.
- AP-Manager – If you want to have APs on different subnets other then the subnet the WLC is on then this interface must be configured, it’s a requirement for Layer 3 LWAPP transport mode. So as you would suspect this interface handles all layer 3 traffic between the WLC and the APs. Since higher end WLCs can have multiple AP-Managers only 1 AP-Manager interface can be configured per physical port.
- Virtual Interface – Another mandatory interface that must be configured (once again like the management interface you don’t get the option to skip the configuration of this interface). This interface handles any mobility management, VPN Termination, Web authentication, and is also a DHCP relay for WLAN clients. You really want to give this interface a bogus type address (Like 1.1.1.1 or something) since it’s only accessed and used by the WLC, the APs and WLAN clients will not interact with this interface. (Other then it’s purpose as the DHCP relay, but it’s all in done within the controller unknown to the AP’s or clients)
- Service-Port – This is also a physical port for out of band management, so it’s configuration is optional. The port doesn’t even support 802.1Q, so you can’t use it for anything other then accessing the controller. (Note: This is only physical port that is active while the controller is booting)
- Dynamic Interface – Now these are the interfaces you can create and use to link specific SSID’s to specific VLAN’s on the wire. So this is where and how you can separate your wireless client traffic, this interface will also double as the DHCP relay for it’s subnet/VLAN (Note: A WLC can have up to 512 dynamic interfaces)
Cisco WLC redundancy with mobility groups.
While LWAPs and Wireless Controllers can streamline and standardize WLAN deployments, it also tends to provide a not so nifty single point of failure. If you only have one WLC in your network and you lose all connectivity to that WLC, whether it be a mis-configuration or a general failure all your LWAP’s will go down until they can join the controller again (or find another controller to join).
The configuration for this is actually fairly simple (especially if you only have 2 WLC’s). First off you want to issue the sh mobility summary to go over the current mobility settings, all these settings are important but probably the most important one is the Default Mobility Domain this is the current name of the mobility group and both controllers will need to be in the same mobility group. (Important: Mobility group names are case-sensitive). If you wish you can change the mobility domain name by issuing the follow command config mobility group name group_name command.
Now once you’ve decided on a mobility group name and both controllers are in the same mobility group, you need to add each respective controller’s MAC address and IP Address as a member of the mobility group on all participating controllers. This done with the following command config mobility group member add mac_address ip_address. Mobility group members can be removed by changing the add keyword with the word delete. Now, each model of Cisco WLC’s can support a max number of 24 mobility group members. So their is a limit, albeit a fairly large limit but it does exist.
Also keep in mind, all this can be done via the GUI interface under Controller -> Mobility Management and of course in the GUI everything is pretty self-explanatory in labelled fields for you to configure easier. (Just more time-consuming)
Once this is all said and done you want to issue the sh mobility summary again to verify the configuration and verify the status of each mobility group member is up.
A few facts to keep in the back of your mind are mobility group messages communicate over UDP port 16666, you will want to create rules or an ACL allowing that kind of traffic between the controllers (If you have any type of firewalls between them). You can issue the following commands to very connectivity ping, eping, mping. Obviously the ping command is just there to verify layer 1 connectivity, eping will verify the EoIP tunnel between the controller has formed. The EoIP (Ethernet of IP) tunnel is where all these mobility messages are exchanged through, and mping will test communication over UDP 16666.
Cisco.com resources
WLC Configuration Guide Release 7.0, Chapter 14 Configuring Mobility Groups
Note: I would have loved to include my own screen shots, but I do not have 2 WLC’s out of production to work with.
CCIE or Null! 