<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>MTU on Support Tools</title><link>https://support.tools/tags/mtu/</link><description>Recent content in MTU on Support Tools</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Sun, 25 Oct 2026 09:00:00 -0500</lastBuildDate><atom:link href="https://support.tools/tags/mtu/index.xml" rel="self" type="application/rss+xml"/><item><title>Cilium MTU Black Hole: How a Linux Bridge and KubeVirt VMs Silently Broke VXLAN and Kept Longhorn Degraded</title><link>https://support.tools/cilium-mtu-linux-bridge-kubevirt-vxlan-blackhole-longhorn-degraded/</link><pubDate>Sun, 25 Oct 2026 09:00:00 -0500</pubDate><guid>https://support.tools/cilium-mtu-linux-bridge-kubevirt-vxlan-blackhole-longhorn-degraded/</guid><description>&lt;p&gt;For about ten hours, roughly 45 Longhorn volumes on one of our production RKE2 clusters sat in a degraded state. Replicas flapped to &lt;code&gt;ERR&lt;/code&gt;, rebuilds started and failed, and the Longhorn event stream logged more than 1,400 replica errors, nearly 800 of them in a single hour on one node. Small API calls worked. DNS worked. Health checks were green. Only bulk traffic between certain pairs of nodes was disappearing, and which pairs changed over the course of the day.&lt;/p&gt;&#10;&lt;p&gt;The cause turned out to be three ordinary behaviors stacked on top of each other. A Linux bridge takes the MTU of its smallest port. KubeVirt VMs attach 1500-byte veths to that bridge. And Cilium, with no MTU configured, does not just read the device MTU at startup: it follows it while running. Pods keep the MTU they were created with. So every time a VM moved onto or off a node, that node&amp;rsquo;s tunnel MTU changed underneath pods that still believed the old value, and their large VXLAN packets went into a black hole with no error anywhere.&lt;/p&gt;&#10;&lt;p&gt;This post walks through the mechanism, a reproducible demonstration of the bridge behavior, the commands that prove it on a live cluster, the fix (pin the MTU, flatten the underlay), and the planned full-cluster outage it took to apply that fix safely.&lt;/p&gt;</description></item><item><title>Find the Correct MTU With ping on Linux (ping -M do -s)</title><link>https://support.tools/ping-mtu-linux/</link><pubDate>Tue, 22 Oct 2024 08:45:00 -0500</pubDate><guid>https://support.tools/ping-mtu-linux/</guid><description>&lt;h2 id="using-the-ping-command-to-help-determine-the-correct-mtu-setting-for-your-network"&gt;Using the &lt;code&gt;ping&lt;/code&gt; Command to Help Determine the Correct MTU Setting for Your Network&lt;/h2&gt;&#10;&lt;p&gt;In network environments, ensuring that all devices, including nodes and switches, have matching &lt;strong&gt;MTU (Maximum Transmission Unit)&lt;/strong&gt; settings is critical for optimal performance. Mismatched MTU settings can lead to packet fragmentation, which reduces efficiency and can impact application performance. This guide will show how to use the &lt;code&gt;ping&lt;/code&gt; command on Linux to verify that the correct MTU is set for your network.&lt;/p&gt;</description></item></channel></rss>