Guillaume Nault <gna...@redhat.com> writes: > On Mon, Jul 14, 2025 at 09:57:52PM +0200, Salvatore Bonaccorso wrote: >> Hi, >> >> Charles Bordet reported the following issue (full context in >> https://bugs.debian.org/1108860) >> >> > Dear Maintainer, >> > >> > What led up to the situation? >> > We run a production environment using Debian 12 VMs, with a network >> > topology involving VXLAN tunnels encapsulated inside Wireguard >> > interfaces. This setup has worked reliably for over a year, with MTU set >> > to 1500 on all interfaces except the Wireguard interface (set to 1420). >> > Wireguard kernel fragmentation allowed this configuration to function >> > without issues, even though the effective path MTU is lower than 1500. >> > >> > What exactly did you do (or not do) that was effective (or ineffective)? >> > We performed a routine system upgrade, updating all packages include the >> > kernel. After the upgrade, we observed severe network issues (timeouts, >> > very slow HTTP/HTTPS, and apt update failures) on all VMs behind the >> > router. SSH and small-packet traffic continued to work. >> > >> > To diagnose, we: >> > >> > * Restored a backup (with the previous kernel): the problem disappeared. >> > * Repeated the upgrade, confirming the issue reappeared. >> > * Systematically tested each kernel version from 6.1.124-1 up to >> > 6.1.140-1. The problem first appears with kernel 6.1.135-1; all earlier >> > versions work as expected. >> > * Kernel version from the backports (6.12.32-1) did not resolve the >> > problem. >> > >> > What was the outcome of this action? >> > >> > * With kernel 6.1.135-1 or later, network timeouts occur for >> > large-packet protocols (HTTP, apt, etc.), while SSH and small-packet >> > protocols work. >> > * With kernel 6.1.133-1 or earlier, everything works as expected. >> > >> > What outcome did you expect instead? >> > We expected the network to function as before, with Wireguard handling >> > fragmentation transparently and no application-level timeouts, >> > regardless of the kernel version. >> >> While triaging the issue we found that the commit 8930424777e4 >> ("tunnels: Accept PACKET_HOST in skb_tunnel_check_pmtu()." introduces >> the issue and Charles confirmed that the issue was present as well in >> 6.12.35 and 6.15.4 (other version up could potentially still be >> affected, but we wanted to check it is not a 6.1.y specific >> regression). >> >> Reverthing the commit fixes Charles' issue. >> >> Does that ring a bell? > > It doesn't ring a bell. Do you have more details on the setup that has > the problem? Or, ideally, a self-contained reproducer?
+1 - I tested this patch with an OVS setup using vxlan and geneve tunnels. A reproducer or more details would help. >> Regards, >> Salvatore >>
