Manage Segment MTU!
- Authoritatively declare an IP MTU for every subnet that you operate
- Do not permit hosts to exceed the declared MTU in their interface MTU configuration
- Only permit hosts to configure interface MTU that is lower than the subnet’s declared MTU:
- If they can successfully demonstrate that their IP M_R_U remains at least as large as the subnet’s declared MPU
- Very begrudgingly
- Include MTU option whenever DHCP is used
Overlay Precautions
- Always prefer the minimum required number of stacked overlays
- Don’t deploy an overlay if you don’t have authoritative knowledge of the underlay’s MTU
- When declaring the IP MTU for an overlay subnet, use a value less-than or equal to:
- Underlay-MTU minus the overlay’s encapsulation overhead
Enable PLPMTUD
- Enable PLMTUD in the TCP implementation of any hosts in your networks that support it.
- This solves PMTUD blackholes for TCP traffic; why are we not doing this already?
Bi-modal MTU
- Prefer operational models that implement a bi-modal approach to MTU.
- 1500-byte MTU for the vast majority of IP-on-Ethernet subnets
- A “large-MTU” (“of best fit”) for your organization for everything using jumbo-frames and large IP packets
BGP Policy
- Consider tagging routes when they are introduced to BGP, coding for segment MTU
- And applying BGP policy to prefer paths that maximize higher end-to-end-MTU.
- This is, admittedly, much simpler if you have a bi-modal MTU approach in your organization