Wrong MTU assigned to the docker containers

[r3pek]

Describe the issue you are experiencing

I recently had to change the MTU on the host adapter (VM) because the interface is running over a VXLAN. That beeing said, no addon has internet connection since the veth interfaces still get configured as 1500 MTU and by the looks of it, there's no way to edit the docker configuration file (/etc/docker/daemon.json) to account for the different MTU.

What type of installation are you running?

Home Assistant OS

Which operating system are you running on?

Home Assistant Operating System

Steps to reproduce the issue

1. Change the Host adapter to an MTU lower than 1500 (1450 in my case)
2. No docker container can talk to the internet

...

Anything in the Supervisor logs that might be useful for us?

Just a bunch of error messages complaining about git can't access anything (checking for addon updates)

System Health information

System Information

version	core-2024.7.3
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
user	root
virtualenv	false
python_version	3.12.4
os_name	Linux
os_version	6.6.33-haos
arch	x86_64
timezone	Europe/Lisbon
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
GitHub API Calls Remaining	5000
Installed Version	1.34.0
Stage	running
Available Repositories	1459
Downloaded Repositories	13
HACS Data	ok

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 12.4
update_channel	stable
supervisor_version	supervisor-2024.06.2
agent_version	1.6.0
docker_version	26.1.4
disk_total	30.8 GB
disk_used	22.1 GB
healthy	true
supported	true
host_connectivity	true
supervisor_connectivity	true
ntp_synchronized	true
virtualization	kvm
board	ova
supervisor_api	ok
version_api	ok
installed_addons	Advanced SSH & Web Terminal (18.0.0), Studio Code Server (5.15.0), Nextcloud Backup (0.17.7), Node-RED (18.0.4), Matter Server (6.2.1), ESPHome (2024.6.6), Mosquitto broker (6.4.1)

Instituto Português do Mar e Atmosfera (IPMA)

api_endpoint_reachable	ok

Dashboards

dashboards	2
resources	5
views	10
mode	storage

Recorder

oldest_recorder_run	July 23, 2023 at 21:36
current_recorder_run	July 20, 2024 at 15:43
estimated_db_size	1667.86 MiB
database_engine	mysql
database_version	10.5.22

Spotify

api_endpoint_reachable	ok

Xiaomi Miot Auto

component_version	0.7.19
can_reach_server	ok
can_reach_spec	ok
logged_accounts	1
total_devices	2

Supervisor diagnostics

config_entry-hassio-9be3d9d992b1c6c5034faedb044b986d.json

Additional information

I've also reported the same issue here (https://github.com/home-assistant/operating-system/issues/3480), but I'm reporting it here too since I'm not really sure where's the correct place to do it.

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[r3pek]

Still happens on latest version (2024.8.2)

[agners]

Hm, should Docker maybe handle that more gracefully? If so we should report it upstream to Docker so it automatically sets the MTU correctly. :thinking:

Alternatively, we could probably teach Supervisor to set an MTU.

Currently, the HA ecosystem doesn't really deal with MTUs. How did you set the MTU on HAOS in first place? :thinking:

[r3pek]

@agners

I think the "easy" way would be to just populate the docker config (/etc/docker/daemon.json) with whatever MTU is configured on the interface on bootup. What is not "easy" is figuring out which interface one should monitor (but that can't be done with maybe some simple greps on the route -4n command).

The way I dot it is a 2-step process.

1. Change the MTU of all veth* interfaces
2. get a shell inside the supervisor container and change the MTU of the first interface.

I have to do that after every reboot...

EDIT: If you ment how did I change the MTU of the "host" itself, the virtio driver reads that from qemu so the driver already sets the correct MTU on the interface after a bootup (it's running on proxmox)

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[r3pek]

No bot, it still happens :)

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[r3pek]

No, the issue still isn't solved :)

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[r3pek]

no bot, the issue is still there ;)

[LightJack05]

Hey, having the same issue. It's quite a big problem, I'm running a hyperconverged Proxmox cluster with VXLANs for SDN. My MTU is limited to 1400. Everything that is bigger than a simple command to a device gets either fragmented to hell and back, or dropped outright.

I can't really get updates (without going through a shell and doing docker exec to set the MTU manually in the container), I cant use add-ons, etc.

Can someone please finally take care of this? At least a workaround would solve the core issue. Maybe add a config option and just mirror it to the docker daemon config?

[jsk73]

Same issue on my setup, nothing I can do to change the MTU since my local deployment only allow 1442 max This been open since 2024 so I guess wont be cover this, then I'll forget home assistant from now.

[agners]

Hm, from Bridge driver options documentation it seems that we can set the MTU when we create the hassio network. It should be fairly straight forward to add support for MTU similar to how @davidrapan added IPv6 support in #5879 recently. It would be ha docker options --mtu or something along these lines.

In a quick test, setting "options": {"com.docker.network.bridge.name": DOCKER_NETWORK, "com.docker.network.driver.mtu": "1400"}, in DOCKER_NETWORK_PARAMS created the bridge with a lower MTU.

@jsk73 what is your host network interface's MTU? What type of installation and network card do you have? Is it a virtual machine just like OP?

[jsk73]

My host network MTU is 1442, running in openstack so network need to be set to 1442 I attached the network in the HA VM:

About docker options, --help showing that there're only --enable-ipv6 is supported:

The root system is mounted within readonly so seem I can't change docker config from the shell

[agners]

The root system is mounted within readonly so seem I can't change docker config from the shell

Yeah that is by design, Home Assistant OS is a largely stateless read-only OS.

[agners]

About docker options, --help showing that there're only --enable-ipv6 is supported:

Yeah I am aware. Creating --mtu is a suggestion how to implement this feature.

[r3pek]

Ahhhhh I waas hopping today's update would finally bring this. Guess not since the CLI PR is still opened :( https://github.com/home-assistant/cli/pull/589

[agners]

Besides the CLI also the actual feature in Supervisor is not yet released either (#6079 will be in 2025.08.2).

Supervisor as well as the CLI plug-in updates are not dependent on Home Assistant OS release cycle. So it will be available as soon as those two compontens have been released and promoted to stable (in https://github.com/home-assistant/version).