Changing MTU on Xavier NX (resets to 1500)

I’m trying to change the MTU of the eth0 interface on my Nvidia Jetson Xavier NX. Running sudo netplan apply successfully sets the mtu for eth0 to 1280.

Unfortunately, within a minute, my SSH connection is dropped. I notice MTU is reset to 1500 when I eventually reconnect. I can see that with ifconfig eth0

This is not a problem for NVIDIA AGX Orin, though it also has an unrelated MTU mystery: AGX Orin - mtu 1466 - #3 by kayccc

I’ve added the following to my netplan YAML config directory (/etc/netplan/eth0.yaml):

  version: 2
  renderer: NetworkManager
      dhcp4: true
      # Set use-mtu to false is only needed on Ubuntu 18.04 (eg. Xavier NX's)
      # to update a network interface's MTU variable.
      # See
        use-mtu: false
      mtu: 1280

Model: NVIDIA Jetson Xavier NX Developer Kit - Jetpack 4.6 [L4T 32.6.1]


  • Does anyone know if Nvidia Jetson Xavier NX supports changing MTU?
  • Why does it reset to 1500 within a few minutes?
  • What do you suggest I do?

More information: why I want the MTU to be 1280.

Tailscale doesn’t support 1500 MTU, I’ve tried it on other devices and it doesn’t work. Their default is 1280. Their release notes state:

TS_DEBUG_MTU environment variable can be set to change the tailscale0 MTU size; has to be changed for both nodes wanting to use larger packets. Setting the MTU larger than 1468 is unlikely to work. For Linux platforms, it can be set in /etc/default/tailscaled source

My device runs microk8s with Flanneld, and the containers inside don’t know which interface they’ll use. Flanneld will use the host network interface to determine the MTU to use. I think they should resort to creating packets with max size of 1280 bytes, in case these bytes are destined to go via tailscale. Therefore, I need to set eth0’s mtu to 1280.

Please try the commands:
How to change MTU size in Linux

Hi @DaneLLL,

I have already tried most things on that article, and more:

  • set mtu using ifconfig eth0 mtu 1280 up
  • using netplan (as in my first post)
  • Disabling MTU in DHCP configuration /etc/dhcp/dhclient.conf
  • not on article: set mtu using sudo ip link set eth0 mtu 1280
    • Result: resets back to 1500.

Extra things I tried from article:

  • I found a couple of things I haven’t tried, but they also don’t work…see below.
  • Note: I did remember to undo the changes I tried in my first post.
  • Setting MTU in /etc/dhcp/dhclient.conf by using code snippet below:
    • I then ran sudo systemctl restart systemd-networkd and sudo service networking restart to load the new config.
    • Results: Doesn’t affect MTU.
# Suggested on nvidia forums to use
interface "eth0" {
default interface-mtu 1280;
supersede interface-mtu 1280;
  • Configuring /etc/network/interfaces
    • Results: Doesn’t even change the mtu, and instead an error:
    • Isn’t this only relevant if the interface are configured in there too. My file is quite empty:
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
post-up /sbin/ifconfig eth0 mtu 1280 up
  • This is a deprecated command (in newer Ubuntu), replaced by ip link set, which also doesn’t work.
  • Added post-up /sbin/ifconfig eth0 mtu 1280 up
  • Ran sudo service networking restart, with error:
$ sudo service networking restart
Job for networking.service failed because the control process exited with error code.
See "systemctl status networking.service" and "journalctl -xe" for details
$ systemctl status networking.service
● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2023-02-16 11:25:17 UTC; 41s ago
     Docs: man:interfaces(5)
  Process: 26467 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
  Process: 26441 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm settle (code=exited, status=1/
 Main PID: 26467 (code=exited, status=1/FAILURE)

Question: Could this be a hardware or driver bug?

Turns out the entire device reboots within minutes after the MTU is changed.

Watching the logs (sudo journalctl _SYSTEMD_UNIT=systemd-networkd.service _SYSTEMD_UNIT=systemd-networkd.socket _SYSTEMD_UNIT=ifup@eth0.service), I get the following:

Feb 16 15:46:56 device_name systemd-networkd[31004]: eth1: Configured
Feb 16 15:46:56 device_name systemd-networkd[31004]: eth0: DHCPv4 address via
Feb 16 15:46:56 device_name systemd-networkd[31004]: eth0: Configured
Feb 16 15:48:45 device_name systemd-networkd[31004]: eth0: Lost carrier
Feb 16 15:48:45 device_name systemd-networkd[31004]: eth0: DHCP lease lost
Feb 16 15:48:47 device_name systemd-networkd[31004]: eth0: Gained carrier
Feb 16 15:48:52 device_name systemd-networkd[31004]: eth0: DHCPv4 address via
Feb 16 15:48:52 device_name systemd-networkd[31004]: eth0: Configured
-- Reboot --

This happens when I change the MTU. For example, by using netplan, or just using sudo ip link set eth0 mtu 1280.