---
title: "Comment by Owen Scott on \"The Packets Are Too Big: MTU and Encapsulation Overhead in Multi-Cloud Networks\" | Hashnode"
description: "This matches what I keep seeing in the field: the demo path with tiny probes looks fine, then a 1400+ byte payload + GRE/VXLAN/WireGuard overhead silently fragm"
url: "https://hashnode.com/posts/the-packets-are-too-big-mtu-and-encapsulation-overhead-in-multi-cloud-networks/6af2243166494ef3ed618980/comment/6af23e33d33f19b0aeb80965"
---

[Discussion](https://hashnode.com/posts/the-packets-are-too-big-mtu-and-encapsulation-overhead-in-multi-cloud-networks/6af2243166494ef3ed618980)

Comment [The Packets Are Too Big: MTU and Encapsulation Overhead in Multi-Cloud Networks](https://hashnode.com/posts/the-packets-are-too-big-mtu-and-encapsulation-overhead-in-multi-cloud-networks/6af2243166494ef3ed618980)

[Owen Scott](https://hashnode.com/@owenscott)

[2d ago](https://hashnode.com/posts/the-packets-are-too-big-mtu-and-encapsulation-overhead-in-multi-cloud-networks/6af2243166494ef3ed618980/comment/6af23e33d33f19b0aeb80965)

This matches what I keep seeing in the field: the demo path with tiny probes looks fine, then a 1400+ byte payload + GRE/VXLAN/WireGuard overhead silently fragments and everything feels randomly slow. Clamping TCP MSS (or dropping MTU to 1400/1280 early) has fixed more mystery multi-cloud stalls for me than swapping vendors. Nice write-up.