I'm troubleshooting an issue where when AP-105s failover from their local site-LMS to master LMS, they report the wrong MTU, and also get stuck in Dirty, unable to receive initial configurations.
Master controller is at HQ, and is defined in AP system profiles as backup LMS IP. Each branch office has it's own controller which is defined as the LMS IP for that AP group/profile.
Mostly 3600 series controllers, running 6.4.2.4.
CPsec is not enabled, not being used.
I've tested the MTU across the WAN link, and it doesn't support 1500 byte packets, max value varies from site to site, but many are somewhere between 1300-1400 bytes.
I've changed the SAP MTU in the AP system profile for a test group, and confirmed that on the local LMS, 'show ap bss' displays the correct SAP MTU (i.e., 1300).
When I reboot, or disconnect the local LMS, the APs successfully initiate failover to the master at HQ, however, they never fully come up.
Initially, within the first 30 or so seconds, show ap bss shows the MTU of the moved APs at 1300. However, as soon as the uptime field starts counting, the MTU seems to get reset, or displayed in the table as 1500.
The ap debug details show the AP is waiting on configuration ('Configuring') and the log also shows switch to AP message of CONFIG with a length somewhere around 3600 bytes. 'show ap database' shows the APs in the group as dirty, but Up.
From this point forward, config counters increment on the AP, with no acks, and the APs never come up.
If I bring the local LMS back online, after the hold down time, since pre-emption is on, the APs migrate back and everything works again.
It feels like an MTU issue, however, I can't seem to get the MTU to stick when the APs migrate and failover.
Would enabling cpsec help here with path MTU discovery if native GRE can't properly negotiate a working MTU for whatever reason?
Thanks for any assistance!