WLAN Poller "yes" prompt response?

[andrew_cooper]

Hello, I'm lab testing a migration of 3702i AP's to 9800 and trying to leverage WLAN Poller to assist with this operation.  I'm struggling with getting the 3702i's to reload via the script.  Most documentation lists the need for "%confirm% reload" but this doesn't seem to work for me with the 3700 AP's. 

When doing this directly via SSH I have to first issue the command "debug capwap console cli" to get access to the reload command.  Then if I issue the "reload" command I am hit with 2 prompts.  First asks me if I want to save config (yes/no).  The second is the reload confirmation prompt.  I believe the %confirm% will take care of the final prompt but I've been unable to get past the "save config" prompt which requires a "yes" or "no".  

Can anybody help me with this?  Thanks in advance!

[Rich R · Accepted solution]

1. The archive software install command can include reload with the /reload option.
/reload Reload system (if no unsaved config changes) after successful sw upgrade
So that might not work if it thinks there are config changes.

2. IOS has a command "file prompt quiet" which disables most of those prompts.  Also using "write mem" instead of "copy run start" eliminates most prompts.  So before trying to reload you could try:
conf t (if it allows this)
file prompt quiet
end
wr mem
Then config is already saved and file prompts are disabled before you try to reload.

[andrew_cooper]

Thanks for the response.  I just tested (manually without script) and even after doing "file prompt quiet" and "write memory" and unfortunately I still get the "Save?" prompt.

[andrew_cooper]

@Rich R  one last thing - your suggestion #1 does work if I use "/force-reload".  It forces a reload without prompts after the software update.  The problem is I cannot assign "capwap ap primary-base name1 x.x.x.x" without the AP trying to join that controller on its own and screwing up the process.  I was under the impression it would not re-associate until you issue the "capwap ap restart" command or reload but that's not proving to be the case.

[Rich R]

@andrew_cooper that's controlled by:
(WLC) >config network ap-fallback ?
enable Enables AP Fallback.
disable Disables AP Fallback.
and
(WLC) >config advanced timers ap-primary-discovery-timeout ?
<seconds> Configures AP Primary Discovery Timeout value between 30 and 3600 seconds.

And on 9800 those are both configured in the ap profile:
9800(config)#ap profile <profile-name>
capwap timers primary-discovery-timeout <time in seconds>
capwap fallback or
no capwap fallback

So you could disable fallback or change the timer.

[andrew_cooper]

The reason I'm attempting to use the reload command instead of "capwap ap restart" is that I've found I can pre-download the c3700-k9w8-tar.153-3.JPJ11.tar image and the AP extracts / sets its boot path to that image while serving clients. If you issue the "capwap ap restart" command the pre-download is rendered ineffective as the AP re-downloads from the new controller.  Instead, if I issue "capwap ap primary-base name1 x.x.x.x" and then reload the AP will reboot and join the new controller with only roughly 3 minutes of downtime.  This is a hospital environment.

Since I am going from 8.5.x.x to 17.9.6 I first need to go through my "test" controller which is which is running 17.3.8a. staged for this purpose and able to serve clients.  Then I repeat this process to get to my final controller running 17.9.6 so whatever time savings there is by not having 465 AP's download and extract image files while not client serving will be time saved 2x.  

So worst case scenario I can do this migration just using the following commands in the script:

"capway ap primary-base <WLC-Name> <WLC-IP-Address>"

"capwap ap restart"

The disadvantage is time.  With only 1 AP downloading it takes about 8 minutes to discover controller, identify image incompatibility, download, reboot, and join.  8 minutes is not terrible, but I'm not sure how much that will increase when I execute on 465 AP's instead of just 1.  Again, this has to be done twice.

Essentially if I can leverage the "reload" command I can have a downtime of about 3 minutes x2 vs 8 minutes x2.  And if I'm downloading 465 APs from the controller during downtime, I don't know how much longer that 8 minutes will become.   

[Rich R]

Understood.

On AireOS instead of reload on AP CLI you could try using:
(WLC) >config ap reset ?
<Cisco AP> Enter the name of the Cisco AP.
I think (hope) that should bypass the prompt.
On 9800 the equivalent command is:
9800#ap name APNAME reset

Also worth knowing on AireOS:
(WLC) >config ap tftp-downgrade 1.2.3.4 abcd.tar ?
<Cisco AP> Enter the name of the Cisco AP.
and on 9800:
9800#ap name APNAME tftp-downgrade 1.2.3.4 abcd.tar
Note downgrade is misleading - it's just download - can be upgrade or downgrade.

[andrew_cooper · Accepted solution]

@Rich R I'm marking your answer as the solution.  I have tested the following process, and it results in a sub 3-minute client outage with 3702i AP's going from a 5508 on 8.5.x to a 9800-40 on 17.3.8a.  

1. Disable AP Fallback on WLC the AP is currently on

2. Run WLAN Poller script with included commands in this order 

• "debug capwap console cli"
• "capwap ap primary-base <new-wlc-name> <new-ip-address>"
• "archive download-sw /force-reload ftp://<ftp-ip-address>/c3700-k9w8-tar.153-3.JPJ11.tar"

Disabling AP Fallback prevents the AP from automatically joining the new controller within 30ish seconds of entering that primary-base command.  Then the commands in the script assign it the new controller info, and tell it to download / install / force-reload.  This resulted in a sub 3 minute client downtime in my lab test.