Wireless Access

New 2019 deployments!

 

What is the best practice regarding jumbo? A couple months ago I had a customer core switch fragmenting packets from a controller for years and CPU utilization was over 70% this entire time. (Illustrated with monitoring software) After jumbo deployed to the controller the CPU dropped to..30-40%.

 

Fundamentals guide states.

To achieve maximum performance benefits with Tunnel Mode, end-to-end jumbo frame support
should be enabled on a wired switch due to the increased aggregation introduced with the IEEE
802.11ac standard.

 

Do you deploy jumbo to APs or just the controller side? I'd assume Jumbo support from AP to controller.

 

What about when doing PUTN or PPTN with switches? Same situation I'd guess...?

Aruba campus AP’s defect the maximum frame size end to end. You can also specifieke the mtu in the ap system profile. By default a mtu of 1500 end to end is fine. The AP en controller will care about the fragmentation and defregmentation.

There is a difference with PUTN and PPTN. Jumbo frames end to end are required because the switches are not able to perform fragmentation. The mtu need to be atleast 1524 bytes because of the gre tunnel.

So for cap’s jumbo frames are not required however for switch port tunneling it is.

So how do you handle PUTN over WAN/Internet/VPN? Can you lower PUTN GRE Tunnel MTU from the switch? 

The short answer this is not possible. Lowering the switch MTU will probably work, however all the systems behind the switch should detect the low MTU. I foresee some issues with this.

There is a lot of discussion about this topic. A switch a completely different from a (R)AP. The AP's will handle all the fragmentation, however the switch not. Another issue can be the delay between the switch and the controller.

With UBT (user based tunneling) the whole concept is based on a campus deployed. So, there is a reliable connection between the switch and controller.

I will advise you to contact your Aruba SE for this.