Client Troubleshooting- Cisco Wireless Controller

hi my name is Kara Desai and I'm at the Cisco wireless stack in this session I will introduce some troubleshooting steps to identify client connectivity issues in a Cisco Unified wireless network deployment the session uses the controller CLI for running specific debug commands to identify and isolate the root cause of client connectivity issues the commands are independent of the platform and should work on a 5508 the 2500 vism 2 and the 4400 controller platform so let's get started before we look at the debug commands let's take a layered approach to the client connection process the client initially sends a probe request to identify all the available s societies or wireless networks available over-the-air based on all the probe responses and the client configuration the client will first go through the open authentication process which is part of the 802 dot 11 protocol following this the client will send Association request once the client has received a successful Association response from the access point it will move to a layer to process of authentication at this point the client is successfully authenticated at layer 1 at layer 2 based on the use of pre shared key or a 22.1 X based authentication there will be several exchanges of a packets if the authentication is successful there will be an each success packet at this time the client is now completed clear to authentication the client will now follow the DHCP process to get an IP address once the client receives an IP address it is ready to pass traffic this is a very simplistic high-level view of how the authentication process takes place at the different layers to troubleshoot client issues the single most important command is the debug client followed by the MAC address of the client in question the command is actually a macro which backs together several debug commands together you can run the zebra command for only one client at a time so don't try to troubleshoot several clients at the same time the D bugs are not process intensive so it should work in a production environment if you expect the client to roam across multiple controllers make sure you run this command across all the controllers simultaneously and ideally you would want the controllers to be NTP time synced also make sure you log the session output because the output goes really fast so if you have a tool like putty or teraterm or any tool of your choice make sure you log the session output once the debug is are captured you can use the debug disable all command to turn off all the D bugs besides the debug command the show client detail command used in tandem can be very helpful in identifying client connectivity issues the policy manager state-provided here on the CLI gives a quick snapshot of the current state of the client our end goal should be always to get the client in the one state besides the policy manager state there are additional information that can be gleaned from the CLI command like the ApS name the SSID on which the client is connected to the channel on which the axis wand is operating on and also the authentication type for the specific client if you prefer the web GUI you can check the status of a client by using the monitor tab under the client section and then selecting a specific client you will see the Policy Manager state the AP that the client is connecting to and the security profile for the specific client in order to interpret the output of the wireless LAN debug it is important to understand the client policy manager state the policy management state indicates the current state the client is then it can be gleaned from the controllers GUI page or also by using the show client detail command on the controller CLI some of the popular states that you would be seeing as the client moves from the initial start state the run state are listed here like for example the eight of drug 1x required indicates that a client is not yet completed layer two authentication the THC be required said indicates that the client has completed authentication if it's using later two authentication but as he's not here to see an IP address web boss required is a special case where the authentication takes place after the client has an IP address and this is used very popularly in the guest access scenario where you have users getting an IP address and logging on to a web portal many times the user is not logged in you would see the client stuck in the box required State and finally there is a one-state which is our end goal if a client is in one state it indicates that from a controller standpoint of view it is ready to pass traffic once you have entered the debug client command and if you were to power up wireless client device the first thing that you will be seeing is the association request here we see the association request is received by the controller on the access point with the following MAC address there are additional details like the vApp ID which indicates the WLAN ID or the SSID that the client is connecting to and the interface which indicates the VLAN on which the client would be connecting to at the end of it you would see an access point sending out an association response with status of zero a status of zero indicates a successful Association response any other status would indicate a failure in association and the client will not be able to proceed further here are some possible reason code for fail Association response for example status 17 would indicate there are too many clients connected to an access point a status of 18 would indicate that the client and the access point do not agree on the supported data rates for example if you had in a society it supported a 2.11 G rates only a client with supports only 82 at 11 B will not be able to join at a society take a quick look at all the other possible reason codes here now let's look at layer two as most of the client connection issues occur at the layer two process head layer two we can broadly classify the authentication process and an enterprise flavor or the portion of the pre shared key flavor an enterprise flavor we have the WPA enterprise and the wpa2 enterprise in both these we use eBay sought indication like peep ETLs eat fast and each leap as possible eeep techniques used as part of the authentication process on the personal side we use a pre shared key which is similar to a web shared key but it's a much stronger encryption based on the use of WPA or wpa2 you would be using tkip as the encryption for WPA whereas AES for wpa2 the configuration if you look on the right right-hand side it's pretty straightforward under the layer two tab you would see you would select WPA plus wpa2 here and then select WPA the tkip and wpa2 with AES if you were to do dot 1x based authentication which is the eath methods you would use a 2.1 X if you were to use the pre shared key you would select the PSK from the drop-down menu additional debug commands like debug dot 1x all enable debug triple-a all enable can be helpful to additional to provide additional details of what the client is doing now there are several things that can cause issues for layer 2 authentication failure but the radius and the client logs can point us in the right direction what aspect about the configuration that confuses a lot of users is how do we select the EEP types and where do I make that change on the controller well if you're using an external radius server there is nothing that you need to do on the controller the type of EEP authentication is decided between the client and the radius server and the controller is just a simple conduit between the two so the e-bot indication or the apex change as part of that there is a processing bill to decide which type of EEP the client and the radius server are going to agree to use unless you are using the wireless controller as the radius server there is no need to define any EEP types on the controller now let's take a close look at the dot 1x authentication process before we look into the debug commands

Channel: Cisco Community

Views: 32,749

Keywords: Cisco Systems (Organization), Wireless technology, Cisco Wireless Controller, client connection issues

Id: 6AOprdssFu4

Length: 9min 25sec (565 seconds)

Published: Tue Apr 09 2013