A way around CISCO-LWAPP-CONTROLLER.corp.cox.com ?

Unanswered Question
Nov 12th, 2008

I have been running two 4402 controllers and about 40 LWAPP access points locally (region) for some time now. I have been leveraging the option 43 I believe in DHCP and specifying my controllers for some time now since I wasn't going to bother with DNS resolution for CISCO-LWAPP-CONTROLLER.corp.cox.com


Well now someone at a corporate level has gone and setup DNS resolution for CISCO-LWAPP-CONTROLLER.corp.cox.com and my AP's are now resolving this and connecting to those controllers.


Even when I connect via the console to the AP and try to specify lwapp controller ip address I get:


ERROR!!! Command is disabled.


I know Cisco tried to make life a little easier for others in doing this but its pretty stupid.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
krishanmistry Wed, 11/12/2008 - 09:26

Once an access point joins a controller the lwapp commands in the console windows are disabled, the only way to reinitialise those commands is by adding a new username and password on the AP or my downgrading the AP to Autonomous mode then back to Lightweight.


nathan.a.reeves Sun, 11/16/2008 - 17:34

Only other suggestion I can think of is to not give DNS server addresses to your AP's. This assumes that you are running seperate subnets for them and control the DHCP server. This would prevent the dns lookup (I'm guessing)

jeff.kish Mon, 11/17/2008 - 05:51

This solution here is to use Primary, Secondary, and Tertiary controller listings for your APs, and then (optionally) configure the controllers for AP Fallback Mode. The DNS lookup is only really used when an AP first comes on the network. At that point you need to log into the controller and give it the needed info. If you have AP Fallback enabled, you're done. If not, you'll need to reboot the AP.


If you have a listing of controller names (not IPs) for each AP, then when it boots it will connect to its primary controller, not what the DNS states.


You'll need to make sure all your controllers are configured for the same Mobility Group for this to work.

l.mourits Tue, 11/18/2008 - 03:52

I've seen similar issues, where it got a little bit more complex since the controller where the DNS entry resolved to was part of a different mobility group. In this case I had to remove the dns entry, then clear all config, ensure DHCP was set up and reboot the AP to get it back to work.


HTH,


Leo

Actions

This Discussion

 

 

Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode