CAPWAP channels Path MTU Discovery principles, AP Capwap Path max MTU change

Question

Cisco LWAP in FlexConnect mode uses two Capwap channels:
• CAPWAP control traffic—Identified by UDP port 5246
• CAPWAP 802.11 traffic—Identified by UDP port 5247
For some reason I would need to route user data ( UDP port 5247 ) through other WAN path with lower IP MTU, say 1326B,  different from the WAN path used for Capwap control traffic ( UDP port 5246 ) that has say 1500B MTU.
Seems the process is that the AP finds the IP MTU through the control Capwap channel, sets Capwap Path MTU to 1485B and uses it as a maximum also for the packets routed via UDP port 5247. Because some IP packets sent via UDP port 5247 might be larger, means over 1326B, the AP gets fragmentation needed and DF set unreachable ICMP from the router and sets its Capwap Path MTU to 1325B. After a while the AP sends 1485B IP packet through UDP port 5246 and resets its Capwap Path MTU to 1485B and this repeats.
Correct me if I am wrong and the process works different way. This is what I am reading from Wireshark sniff.
I would like to avoid this and also other potential troubles while having the two separate WAN paths with different MTUs.
Does anyone know how I could
either
Change the initial AP 1485B test packet to something lower, like 1325B. Means the AP would not try IP packets larger than 1325B. I tried to change MTU on BVI interface on the AP, this works, but unfortunately is re-written to default after AP reload.
or
Persuade the AP to use UDP port 5247 for the path MTU discovery process rather than UDP port 5246.
Unfortunately there is no way for me to do this on some other network device between the AP and WAN , like on a switch. It would be optimal, but no way.
Thanks,
Vlad

Answer 1

Johannes, the best approach in most cases where your transport network, due to tunneling constraints, must deliver a small (<1500B) inner IP MTU to its clients, is to use the TCP MSS Adjust feature.
With TCP MSS Adjust, the network hacks the MSS values reported by the TCP endpoints at connection establishment time.  E.g. let's say that the TCP endpoints have an IP MTU of 1500B, and therefore want to use an MSS of 1460 (assuming IP/TCP headers of 40B.)  So each end reports an MSS of 1460 in their TCP SYNs.  But the network changes the MSS fields in these SYNs to, let's say, 1260 instead.  This causes the TCP peers to use an MSS of 1260 (MTU of 1300) for the rest of that connection.
MSS Adjust is in IOS, so a good place to configure it is on the default router for the wireless clients' subnet.  In 6.0, CUWN also supports MSS Adjust - you can configure it on the WLC, and it will push the MSS adjust config out to the APs. 
http://www.cisco.com/en/US/docs/wireless/controller/6.0/configuration/guide/c60lwap.html#wp1111701
Now, TCP MSS Adjust only affects TCP connections, not non-TCP protocols such as UDP.  Those protocols would need to rely upon either IP PMTUD (RFC-1191 etc.), or some protocol-specific discovery mechanism, to avoid IP fragmentation.  Now, CUWN is not going to send a "DF Set but needed to frag" ICMP error to a wireless endpoint, since it's not a router.  You could configure your routers in the vicinity of the wireless clients' network with small MTUs, so that they would generate the needful ICMP errors, so that PMTUD could happen.  But in practice, UDP endpoints rarely need (or take advantage of) PMTUD ... so you should be able to get away with just using TCP MSS Adjust.
Hth,
Aaron