02-04-2015 02:24 AM - edited 07-05-2021 02:25 AM
We have recently implemented a N+N controller configuration. I expected to configure the test APs High Availability option with a primary controller of the new WLC and secondary as the current production WLC, then reset the test AP to have it join the new controller. I'm monitoring the test AP console messages during reboot to see if there is a message indicating it's trying to join the new controller. It seems the test AP, which previously has joined the production AP, makes no attempt to use the pre-configured primary/secondary controllers, it goes directly to the production controller.
The goal is the verify APs will join the controller before making changes to DHCP with option 43. Am it going about this in the correct manner?
Thank you
Solved! Go to Solution.
02-04-2015 07:26 AM
When you set the ap failover on the ap that should trump all other failover methods as u understand it ..
02-04-2015 08:58 AM
Make sure master controller was not enabled? Option 43 and DNS is only for the initial join process when the ap joins and the two wlcs are in the same mobility group, the ap will know of both wlcs setting the primary, secondary and or tertiary like George mentions is used over any other methods. If no primary, secondary and or tertiary is set, the ap should join the WLC with the least amount of access points. When you define a WLC in the high availability and the ap doesn't join, then you have an issue as that is not normal. The wlcs don't even have to have mobility between them for the ap to join your test WLC. Since the test wlc finally had APs joined to them after you reached your 500 ap count, then you know that WLC is working fine. Your best bet is to open a TAC case for them to investigate further.
-Scott
02-04-2015 04:26 AM
How this AP knows about new WLC...is it same subnet or not ?
1. In option 43 did you configured both WLC ip address ?
option43 hex f108------
2. Check AP fallback is enabled on both WLC (its not necessary but still enable it)
3. Try to add them in each other mobility group.
Regards
Don't forget to rate helpful posts
02-04-2015 04:50 AM
The test AP finds the production WLC using DNS. Once the test AP has joined the production WLC, I want to direct it to the test WLC by using the AP's HA options by defining the test WLC as the primary controller. After this is done, the AP is rebooted but it seems to ignore the primary controller setting since it rejoins the production controller.
The reason I'm taking this approach is to avoid having to make a change to the production DHCP by adding option 43.
02-04-2015 05:05 AM
Is AP learning about the new WLC via any method(DNS) ?
paste from AP: show capwap client config
Regards
Don't forget to rate helpful posts
02-04-2015 05:11 AM
Currently, there is only one DNS entry for cisco-capwap-controller and it points all APs to the production controller. I'm trying very hard not to make changes to production DNS or DHCP services that would affect the production APs.
The only mechanism I'm using for the test AP to find the test WLC is configuring the test WLC DNS name and IP address as the primary controller in the test APs High Availability option.
02-04-2015 05:15 AM
I got your point but first WLC must learn about all WLCs. Then it make a list of WLCs in its database.
Then HA tabs comes in picture.
paste from AP: show capwap client config
Regards
02-04-2015 05:43 AM
02-04-2015 06:06 AM
Ok means AP is learning IP address of both WLCs.
Configured Switch 1 Addr 10.233.0.6 Configured Switch 2 Addr 10.233.0.2
and you configured
mwarName wlc-4500N.ens.com mwarIPAddress 10.233.0.6 mwarName wlc-5600.ens.com mwarIPAddress 10.233.0.2
AP must join to WLC1: 10.233.0.6
Regards
Don't forget to rate helpful posts
02-04-2015 06:16 AM
I agree, AP must join 10.233.0.6. Here's some of the console messages from the AP once it reboots, showing the first join request. This is why I say the AP makes no attempt to use the primary controller option.
Translating "CISCO-CAPWAP-CONTROLLER.ens.com"...domain server (10.1.100.23) [OK]
*Feb 3 19:19:46.383: %CAPWAP-3-ERRORLOG: Did not get log server settings from DHCP.
*Feb 3 19:19:56.387: %CAPWAP-3-ERRORLOG: Go join a capwap controller
*Feb 4 13:47:08.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: 10.233.0.2 peer_port: 5246
*Feb 4 13:47:08.475: %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: 10.233.0.2 peer_port: 5246
*Feb 4 13:47:08.475: %CAPWAP-5-SENDJOIN: sending Join Request to 10.233.0.2
*Feb 4 13:47:13.475: %CAPWAP-5-SENDJOIN: sending Join Request to 10.233.0.2
*Feb 4 13:47:13.795: %LINK-6-UPDOWN: Interface Dot11Radio0, changed state to down
*Feb 4 13:47:13.843: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset
*Feb 4 13:47:13.895: %CAPWAP-5-JOINEDCONTROLLER: AP has joined controller WLC-5600
02-04-2015 06:23 AM
check again ur DNS entry for WLC:
it must be like this: CISCO-CAPWAP-CONTROLLER and put the IP 10.233.0.6.
if still not join then try to configure the AP statically.
- Debug capwap console cli
- capwap ap controller ip address 10.233.0.6
Regards
02-04-2015 06:30 AM
I am purposely trying not to change the production DNS to resolve cisco-capwap-controller to the test controller, 10.233.0.6. (I couldn't if I wanted to)
Without a DNS change, shouldn't the primary controller setting direct the AP, upon reboot, to the test controller?
I'll use the debug to see if it shows any attempt to use the primary controller configuration.
02-04-2015 07:26 AM
When you set the ap failover on the ap that should trump all other failover methods as u understand it ..
02-04-2015 07:59 AM
Great, I'm glad to hear you confirm that. At the moment, I'm booting up two more production APs which will put the AP count at 500 for the production controller. With availability on the production controller, maybe this will force the test AP, to use it's primary controller as configured.
if this doesn't work, do you have any troubleshooting suggestions? running debug capwap on the production controller produced too many messages to be productive. I'd need to capture the output then filter it, if that's the best troubleshooting method.
02-04-2015 08:28 AM
exhausting all availability on the 5508 production controller allowed the test AP to use the test controller defined as it's primary controller.
still not sure why this didn't work previously.
02-04-2015 08:58 AM
Make sure master controller was not enabled? Option 43 and DNS is only for the initial join process when the ap joins and the two wlcs are in the same mobility group, the ap will know of both wlcs setting the primary, secondary and or tertiary like George mentions is used over any other methods. If no primary, secondary and or tertiary is set, the ap should join the WLC with the least amount of access points. When you define a WLC in the high availability and the ap doesn't join, then you have an issue as that is not normal. The wlcs don't even have to have mobility between them for the ap to join your test WLC. Since the test wlc finally had APs joined to them after you reached your 500 ap count, then you know that WLC is working fine. Your best bet is to open a TAC case for them to investigate further.
-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