MSM760

[Erez-Ronen]

Hi
I have msm760 controller and AP's 460
i changed controller IP address to other subnet network and set the new ip address in DNS
the problem is that all AP's didnt connect to the controller
after i did a reset factory default to the AP it can find the controller
Is there any other way to connect the AP to a controller without reaching to AP and do a reset factory

[parnassus]

How APs were configured (controller mode)? how was/is the VLAN tagging on controller LAZn and APs involved ports? a defaulted AP once connected on the very same Layer 2 segment is automatically able to be recognizable by the MSM controller.

[Emil_G]

Hello, 

The fact that you created an entry on the DNS server probably means that your APs are not in the same subnet with the IP of the controller. You probably configured hostnames cnsrv1 till cnsrv5. The APs are trying to resolve this names by default when they are looking for a controller.

As far as I understood some of the APs reconnected successfully but others didn't.  So the DNS discovery was working for a part of them. 

According the MSM manual the discovery occurs differently for provisioned and unprovisioned APs. page 154/155

http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c04868787-1.pdf

....

Unprovisioned APs
Once an unprovisioned AP has received its IP address from a DHCP server, it attempts to discover
a controller using the following methods, in order:
• UDP broadcast
• DHCP
• DNS
These discovery methods are applied on the following interfaces, in order:
• Last interface on which a controller was discovered. (Only applies to APs that have previously
discovered a controller)
• Untagged on Port 1
• All detected VLANs (in sequence) on Port 1

Provisioned APs
If connectivity settings are provisioned on the AP, then the AP uses only the provisioned settings
(see “Provisioning connectivity” (page 177). The following connectivity settings are available on
provisioned APs:
• Interface: Wireless port or local mesh link.
• VLAN support: Allows a VLAN to be designated. Discovery will then take place on the VLAN.
NOTE: If discovery is configured to take place on a VLAN over a local mesh link, a second
VLAN must be defined to send traffic over the local mesh link. The same VLAN cannot be used
to carry the control channel and local mesh traffic.
If discovery settings are provisioned on the AP, then the AP uses only the provisioned settings (see
“Provisioning discovery” (page 179)). The following discovery settings are available on provisioned
APs:
• DNS discovery: Enables custom controller names and domains to be used for discovery.
• Discovery using specific IP addresses: Enables the AP to find controllers operating at specific
IP addresses.

......

If your APs are only trying to reach the old IP of the controller and dont try any other discovery methods then I suspect that they were provisioned with the old controller IP address. This can be checked by saving a packet capture on the port of the APs. The discovery protocol uses UDP source and destination port 38212. If you only see unicast packets to the old controller IP, no discovery broadcasts and no DNS queries for cnsrv1 then the AP was provisioned with the old controller IP. In this case only the factory reset will change the discovery behavior.

If the APs are not physically accessible and factory defaulting is not possible maybe you can plan a workaround involving reconfiguring the old IP on the controller. This should give you again access to all APs. Then you can check the AP provisioning settings on the controller and change them or disable them.  After an AP has been updated with provisioned settings, these settings do not become active until the AP is restarted, or a Remove and rediscover action is executed on the Controlled APs >> Configured APs page.  After you have changed or disabled the provisioning settings you can continue with the migration to the new controller IP and the DNS discovery should be working for all APs.