Skip to content

fix(network): pin bridge MTU to 1500 and respawn aardvark-dns on network recreate#242

Merged
geodro merged 1 commit intomainfrom
fix/network-mtu-aardvark-respawn
Apr 23, 2026
Merged

fix(network): pin bridge MTU to 1500 and respawn aardvark-dns on network recreate#242
geodro merged 1 commit intomainfrom
fix/network-mtu-aardvark-respawn

Conversation

@geodro
Copy link
Copy Markdown
Owner

@geodro geodro commented Apr 22, 2026

Diagnosed on a Fedora 40 VM after lerd update --beta migrated the lerd podman network to dual-stack. Symptom: every phpmyadmin page took 5–10 seconds. Two separate rootless podman/netavark quirks combined:

1. Container eth0 MTU was 65520 (jumbo). Fedora's rootless podman defaults the netns interface MTU to pasta's huge value. glibc's resolver uses IP_MTU_DISCOVER=DO on its UDP socket and some kernel paths returned EMSGSIZE ("Message too large") on the write() of a trivially-sized DNS query. Containers fell back to TCP DNS, which worked but cost 5+ seconds per page. cachyos (my other VM) defaults to a saner MTU so the bug was invisible there.

2. RemoveNetwork unlinked aardvark-dns's config file but didn't kill the running aardvark-dns process. The daemon kept its file descriptor on the old inode. When containers joined the recreated network, netavark wrote a new config at the same path, but aardvark kept reading the stale inode. Half the migrated containers ended up missing from DNS — lerd-mysql returned NXDOMAIN even though the container was clearly running, making phpmyadmin time out on its connection attempt.

Changes

  • New LerdNetworkMTU = "1500" constant in internal/podman/network.go. Both EnsureNetwork and MigrateNetworkToIPv6 now pass --opt mtu=1500 to podman network create. 1500 is the universal bridge MTU; hosts that already worked (cachyos) are unaffected.
  • RemoveNetwork now runs pkill -f aardvark-dns after unlinking the aardvark config file. Podman/netavark auto-respawns the daemon on the next container join, against the freshly-written config.

Verified

On the Fedora 40 VM after applying the manual equivalent of these changes: curl to phpmyadmin dropped from 10 seconds to 220 ms, and aardvark-dns's registry contained all 10 lerd containers after the migration (before the kill, only 3 were registered).

…ork recreate

Diagnosed on a Fedora VM after lerd update --beta migrated the network
to dual-stack. Symptom: every phpmyadmin page took 5–10 seconds; DNS
lookups from inside containers returned EMSGSIZE "Message too large"
on UDP; TCP DNS worked fine; containers that joined the recreated
network weren't registered in aardvark-dns (NXDOMAIN for lerd-mysql
and friends even though the container was clearly running).

Two separate podman/netavark quirks on Fedora's rootless stack:

1. Container eth0 MTU was 65520 (jumbo). glibc's resolver uses
   IP_MTU_DISCOVER=DO on its UDP socket and kernel returns EMSGSIZE on
   write() under that MTU on some paths. TCP DNS fallback eventually
   resolved but cost 5+ seconds per page. cachyos defaults to a
   sane MTU so the bug was invisible there.

2. RemoveNetwork only unlinked aardvark-dns's config file but the
   running aardvark-dns process kept its old inode. When containers
   joined the recreated network netavark wrote a new config file at
   the same path, but aardvark-dns was reading from the stale inode
   and never saw the new container entries — half of them ended up
   with NXDOMAIN.

Changes:

- New LerdNetworkMTU = "1500" constant. EnsureNetwork and
  MigrateNetworkToIPv6 both pass --opt mtu=1500 to
  `podman network create`. 1500 is the universal bridge MTU;
  hosts that worked before (cachyos) are unaffected.
- RemoveNetwork now also runs `pkill -f aardvark-dns` after unlinking
  the config file. Podman/netavark auto-respawns aardvark-dns on the
  next container join, against the fresh config.

Verified on Fedora 40 rootless podman 5.x: after the manual equivalent
of these changes, curl to phpmyadmin dropped from 10 seconds to 220ms.
@geodro geodro merged commit 5207ddb into main Apr 23, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant