Solved: CAPWAP, MTU and Jumbo Frames

Johannes Luther · ‎12-09-2009

Hi Community!

I have a question regarding CAPWAP Tunneling and the MTU. Couldn't find anything on CCO regarding this topic.

So what's it all about?

Facts:

A wireless client sends a packet with 1500 Bytes (IP Payload). The Lightweight AP receives that packet an put it inside the CAPWAP Tunnel towards the wireless controller. So, this packet runs over ethernet towards controller.

- IP Header (assuming 20 bytes)

- UDP Header (8 Bytes)

- CAPWAP Header (8 - 16 Bytes)

The CAPWAP payload contains the original wireless frame

- 802.11 Header (24 Bytes)

- Original IP packet (1500 Bytes)

So in total, a packet with 1568 Bytes is sent from the AP to the WLC. In most environments, the maximum MTU is set to 1500 Bytes, so fragmentation occurs (fragmentation is bad ). The packet is fragmented by the AP und assembled back by the WLC.

My point is clear - I want to avoid fragmentation.

Solutions:

Path MTU Discovery:

If I understood the CAPWAP standard (RFC5415) paper correctly (http://www.ietf.org/rfc/rfc5415.txt), then PMTUD is only possible for control traffic (see section 3.5 in the RFC). How should the AP inform a wireless client to decrease the MTU? An ICMP Message Too Big from the APs Management Interface? I don't think so! So I guess PMTUD is not a solution for my problem, right?

Jumbo Frame Support in Infrastructure

My idea is, to enable jumbo frames at the components between the AP and the WLC. My basic question is: Does the AP and the WLC support jumbo frames? If I enable jumbo frames at all my switches and routers, but the AP and the WLC doesn't care about that, it won't solve my problem.

How did you guys solve this? Or is the standard design to ignore the tunnel and let the AP and WLC fragment packets? This would be a little bit dissatisfying.

Thanks in advance

Johannes

Aaron · ‎12-09-2009

No jumbo frame support on the AP:

Deb1250(config)#int gig0
Deb1250(config-if)#mtu ?
<1500-4470> MTU size in bytes

Deb1250(config-if)#mtu 4470
% Interface GigabitEthernet0 does not support adjustable maximum datagram size

Nor is there any jumbo frame support on the WLC side (see CSCsh25990).

View solution in original post

Aaron · ‎12-09-2009

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

Johannes Luther · ‎12-09-2009

Aaron, thanks for your very helpful reply. I wasn't aware of the fact, that the MSS may be adjusted at the WLC!

This approach would satisfy my needs.

But to come back to the jumbo frames. Do you know whether the Lightweight APs or the WLC supports jumbo frames?

This would solve the issue for tcp, udp and IP protocols.

Again - thank you very much!

Aaron · ‎12-09-2009

No jumbo frame support on the AP:

Deb1250(config)#int gig0
Deb1250(config-if)#mtu ?
<1500-4470> MTU size in bytes

Deb1250(config-if)#mtu 4470
% Interface GigabitEthernet0 does not support adjustable maximum datagram size

Nor is there any jumbo frame support on the WLC side (see CSCsh25990).