<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Troubleshooting - Tag - Fryguy's Blog</title><link>https://fryguy.net/tags/troubleshooting/</link><description>Troubleshooting - Tag - Fryguy's Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Thu, 13 Aug 2026 12:00:00 +0000</lastBuildDate><atom:link href="https://fryguy.net/tags/troubleshooting/" rel="self" type="application/rss+xml"/><item><title>MTU Path Test — Find Where a Path Silently Fragments, Hop by Hop</title><link>https://fryguy.net/2026/08/13/mtu-path-test-find-where-a-path-silently-fragments-hop-by-hop/</link><pubDate>Thu, 13 Aug 2026 12:00:00 +0000</pubDate><author>Fryguy</author><guid>https://fryguy.net/2026/08/13/mtu-path-test-find-where-a-path-silently-fragments-hop-by-hop/</guid><description><![CDATA[<p>MTU problems are some of the most annoying things to troubleshoot in networking, because they&rsquo;re usually <em>silent</em>. Small packets sail through fine, everything looks healthy, and then someone complains that a specific app is slow or hanging — and it turns out one link in the path, three hops in, has an MTU 8 bytes smaller than everyone assumed. GRE, IPsec, PPPoE, a VPN overlay, a jumbo-frame config that only got applied to half the path, a VLAN tag quietly adding 4 bytes nobody accounted for, or just two vendors defining and displaying &ldquo;MTU&rdquo; differently (L2 vs. L3, tagged vs. untagged) — any of these can quietly clip your effective MTU, and standard <code>ping</code>/<code>traceroute</code> won&rsquo;t tell you where.</p>]]></description></item></channel></rss>