02-04-2009 08:00 AM - edited 07-03-2021 05:06 PM
For those of us that are familiar with the process by which an AP finds its controller, we know that there is L2 broadcast, Option 43, DNS resolution, and shared neighbor information via OTP, as well as the final option to statically assign a controller IP via the 'lwapp ap controller ip address x.x.x.x'. If you watch the process via 'debug lwapp client event' process on an AP, you will see that each IP address is categorized as to how it was learned using a number (0-4). Here's my question: Are these numbers used in a priority order when an AP attempts to join a controller? I had a 1252 on a 2106 running 5.2.157.0 and no domain (the AP got its controller IP via 'option 43 ascii x.x.x.x' from a DHCP scope on a 2960 switch). Then I moved it to my lab setting, where it's a 4402-25 running 4.2.130.0 and a domain. I expected the new resolution of CISCO-LWAPP-CONTROLLER to be successful and have it join my controller. However, all I saw was the stored entries in NVRAM from the previous controller to which it was joined. I had a couple of options to force it to join my lab controller, and I chose Option 43. That seemed to work and the AP happily downgraded its code. Any thoughts/comments? I'm just surprised that the new DNS resolution (which did work b/c the debug showed 'translating [OK]') didn't allow the AP to join my lab controller.
Regards,
Scott
02-04-2009 08:46 AM
After we turn on debugging, what is the command to view the debugs??
02-04-2009 09:08 AM
laxcis -
When you turn on debugging, it should show up rather immediately. If you are not getting any debug information, that means that your AP is not getting its data to the controller. If you are running debug from the controller, you can use the following:
1. debug lwapp events enable (shows all)
2. debug client
If you are running the debug from the AP, the following will help:
1. debug lwapp client event
2. debug lwapp client packet
3. debug lwapp client error
I would recommend only running one debug type at a time so that your output isn't mixed up. You must be consoled to an AP in privileged/exec mode to run the debug commands. The default login is still Cisco/Cisco, unless it has been changed by the administrator (from the controller, use this to change the password on the AP 'config ap username
You can use Cisco.com, the TAC search tool, Cisco's Support Wiki, and the 'net at large to find many relevant docs for troubleshooting the AP join process. If you need some docs specifically, I have a few I can share.
Hope that helps.
Regards,
Scott
02-04-2009 09:13 AM
I do have a open case with TAC and they want me to do the following. After I enable this though, what do I do next to see the debug? Where do I go to see them?
debug mac addr
debug lwapp events enable
debug dhcp message enable
debug dhcp packet enable
debug pm pki enable
02-04-2009 09:35 AM
nevermind, figured out the debug. I sent it to TAC.
02-04-2009 09:40 AM
Laxcis -
Be sure and post back what your issue was and how you resolved it. Your response 'nevermind, I figured it out" is going to leave a lot of people reading the thread hanging. The NetPro forums are for professionals to help ourselves and eachother. Without subscribing to a PROBLEM/SOLUTION methodology, this thread would otherwise not be useful to others.
Regards,
Scott
02-04-2009 10:45 AM
of course I would post what I find. The "nevermind I got it" was in reference to how to see the debugging going on. But I finally realized it just shows up on the screen. My AP's still are not locating the right WLC, and I am waiting for TAC to get back to me.
02-04-2009 10:48 AM
Have you run debug on an AP? It will tell you what controllers it has learned about and how. Once you know if and how your APs are learning about your controllers, you can begin to figure out where it is breaking down. If you don't see the address you want listed, review the configuration for that method (i.e. Option 43, DNS, etc.). For the short term, you'll make the most progress by hard coding one of your APs with the controller address you want.
Regards,
Scott
02-04-2009 11:07 AM
Would you be able to tell me how to hard code my AP with the controller I want? That would be terrific. It's a 1242.
02-04-2009 11:33 AM
Sure. Plug your AP into a power source but leave the network port disconnected. The AP will boot and realize it has no connection to the rest of the network and won't attempt the LWAPP join process. Then you can run the following commands to set it up:
clear lwapp private-config
lwapp ap controller ip address x.x.x.x
As for the DNS entries. There was a time I thought the same thing. You actually create the same 'A' record multiple times, each time using a different controller IP address. So each DNS record is named CISCO-LWAPP-CONTROLLER.domain. What happens when an AP joins is that it gets all records returned. Then it sends a join request to ALL of those controllers. Which controller it ends up on is due in part to several factors, but most important is the AP load. It will choose the controller with the least load (this information is sent to the AP by the controller in its 'DISCOVERY RESPONSE'). You can override this behavior with a controller configured as 'Master Controller.' However, this is recommended for provisioning APs in a controlled lab environment, and is not recommended for production. In your case, what will probably end up happening is that it will join a controller you don't want it joined to. Then you go into the config for that AP via the controller and set the PRIMARY, SECONDARY, and TERTIARY controller names. Once saved to the AP's NVRAM, it will unicast to join that controller first the next time around. Once you save it, you can safely reboot it. The names you put in for the controllers need to be the HOST names of the controllers, and may or may not actually be DNS records depending on how you have set your DNS up. In code version 5.0 and up, these fields also have an IP address field.
Regards,
Scott
02-04-2009 12:16 PM
When I try and run these commands on the AP CLI, it says "Error!! Command is disabled"
I googled it and it appears I need to change the username/pwd. Easy to do?
02-04-2009 01:02 PM
Did you log in as exec user first? If the AP has not ever been on a controller, or if the controller is set to default for user/pass, it will still be Cisco/Cisco. If the AP gives you the 'command disabled' error, that usually means that it has run its LWAPP process. I found that leaving the AP disconnected from the network usually works. Give me a min to test and I'll get back to you.
Regards,
Scott
02-04-2009 01:08 PM
Got it - you can't run the command 'clear lwapp private-config' UNLESS the default user/pass HAS been changed. Once those parameters are changed, you'll have the ability to run that command. However, in this case it isn't necessary. Just use the 'lwapp ap controller ip address x.x.x.x' command and you should be all set. Never hurts to use the reset button too. Just hold it down for 1-2 sec. while powering on the AP and let go when you see the LED go amber.
Regards,
Scott
02-04-2009 01:14 PM
Still get the same message about command is disabled. Looks like i need to change the username/pwd. I'm not quite sure on how to do that though. Or can I get by with just changing the pwd?
02-04-2009 01:30 PM
It's been a while since I did that, and it's coming back now. It wasn't an issue for me b/c I have a couple of 2106 controllers that I take out into the field with me to help with troubleshooting. You can't run any of those commands without changing the password. So what I would do is hook the AP up to my 2106 (it uses local layer 2 broadcast to join) and then change the username and password. You can do this from the controller using the comand 'config ap username user_id password passwd [all | ap_name ]'. This allows you to restrict it to the one AP you have, but since you can't join it to a controller you can't do that. Send me the same debugs you sent Cisco TAC and I'll look at them. Do you have admin access to your infrastructure, or are the switches/controllers under someone else's provisioning?
spickles@vpnsystems.com">spickles@vpnsystems.com
Regards,
Scott
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide