netplan not respecting mtu

Bug #1807273 reported by jd on 2018-12-06
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
netplan
Undecided
Unassigned

Bug Description

This is very similar to https://bugs.launchpad.net/bugs/1724895, but I decided to open this as i have tried what has succeeded for others. Thanks for any assistance.

I'm trying to set the MTU to 1500 and using a match on mac address, but after a netplan apply or reboot, it does not change or stick. This is on a EC2 T2.Medium instance. Actual configuration from a dev server:

network:
  version: 2
  ethernets:
    eth0:
      match:
        macaddress: 12:0f:ae:49:5d:06
      mtu: 1500
      dhcp4: true
      nameservers:
        search: [ devbuilds.vpc, ec2.internal ]

$> cat /var/run/systemd/network/10-netplan-eth0.link
[Match]
MACAddress=12:0f:ae:49:5d:06

[Link]
WakeOnLan=off
MTUBytes=1500

$> cat /var/run/systemd/network/10-netplan-eth0.network
[Match]
MACAddress=12:0f:ae:49:5d:06

[Network]
DHCP=ipv4
Domains=devbuilds.vpc ec2.internal

[DHCP]
UseMTU=true
RouteMetric=100

$> ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 12:0f:ae:49:5d:06 brd ff:ff:ff:ff:ff:ff
# manually set MTU
$> sudo ip link set dev eth0 mtu 1500
$> ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 12:0f:ae:49:5d:06 brd ff:ff:ff:ff:ff:ff
$> sudo netplan generate
$> sudo netplan apply
$> ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 12:0f:ae:49:5d:06 brd ff:ff:ff:ff:ff:ff

The last netplan commands could be replaced with a reboot with the same result. This configuration seemed to help others, so hopefully i'm simply missing something or perhaps this is related to EC2?

Attaching output of cloud-init

jd (jeff-dyke) wrote :

On Thu, Dec 6, 2018 at 3:40 PM jd <email address hidden> wrote:

> Public bug reported:
>
> This is very similar to https://bugs.launchpad.net/bugs/1724895, but I
> decided to open this as i have tried what has succeeded for others.
> Thanks for any assistance.
>
> I'm trying to set the MTU to 1500 and using a match on mac address, but
> after a netplan apply or reboot, it does not change or stick. This is on
> a EC2 T2.Medium instance. Actual configuration from a dev server:
>
> network:
> version: 2
> ethernets:
> eth0:
> match:
> macaddress: 12:0f:ae:49:5d:06
> mtu: 1500
> dhcp4: true
> nameservers:
> search: [ devbuilds.vpc, ec2.internal ]
>
> $> cat /var/run/systemd/network/10-netplan-eth0.link
> [Match]
> MACAddress=12:0f:ae:49:5d:06
>
> [Link]
> WakeOnLan=off
> MTUBytes=1500
>
> $> cat /var/run/systemd/network/10-netplan-eth0.network
> [Match]
> MACAddress=12:0f:ae:49:5d:06
>
> [Network]
> DHCP=ipv4
> Domains=devbuilds.vpc ec2.internal
>
> [DHCP]
> UseMTU=true
> RouteMetric=100
>
>
I have a hunch that the ec2 DHCP response includes an MTU of 9001. You can
do two things:

Attach the contents of
1) /run/systemd/netif/*

Under /run/systemd/netif/leases/<number> , networkd stores the DHCP response

2) in /run/systemd/networkd/10-netplan-eth0.network

   a) Modify UseMTU=true, to UseMTU=False
   b) ip link set dev eth0 mtu 1500
   c) sudo systemctl restart systemd-networkd

Note, I don't think this will drop your connection, but it's possible.

jd (jeff-dyke) wrote :

That was my thinking as well and your correct. Attached are the data you asked for. And tested a couple different things, what i found is that this does not survive a reboot, but i'm guessing that netplay apply may get called?

I remove the mtu value from the yaml file as well, but it would seem that some sort of netplan apply gets called on reboot.

Thanks for the tips.

On Thu, Dec 6, 2018 at 5:00 PM jd <email address hidden> wrote:

> That was my thinking as well and your correct. Attached are the data
> you asked for. And tested a couple different things, what i found is
> that this does not survive a reboot, but i'm guessing that netplay apply
> may get called?
>
> I remove the mtu value from the yaml file as well, but it would seem
> that some sort of netplan apply gets called on reboot.
>

Yes, it will get re-applied from the source netplan yaml
(etc/netplan/50-cloud-init.yaml).

There is upstream work to allow this to be toggled[1]. And the solution
there will
likely be storing that use-mtu: False snippet in an
/etc/systemd/network/*.network
file.

It's somewhat unlikely that folks want to drop MTU when the underlying
device
can support larger ones.

1. https://github.com/CanonicalLtd/netplan/pull/61

> Thanks for the tips.

> ** Attachment added: "Files from previous post"
>
> https://bugs.launchpad.net/netplan/+bug/1807273/+attachment/5219826/+files/launch_pad_netplan.txt
>
> --
> You received this bug notification because you are subscribed to
> netplan.
> Matching subscriptions: netplan
> https://bugs.launchpad.net/bugs/1807273
>
> Title:
> netplan not respecting mtu
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/netplan/+bug/1807273/+subscriptions
>

jd (jeff-dyke) wrote :
Download full text (4.2 KiB)

I completely understand people not wanting to drop the larger MTU, but i
have a similar issue with my galera cluster that is documented with
Redshift Clusters, Since these don't reboot much i'm just going to change
them manually and see nodes dropping from the cluster stops.

It looks like a good change, but i'm a bit biased b/c of my cluster issue.

Appreciate it, i'll write back if this does indeed fix the problem.

On Thu, Dec 6, 2018 at 6:20 PM Ryan Harper <email address hidden>
wrote:

> On Thu, Dec 6, 2018 at 5:00 PM jd <email address hidden> wrote:
>
> > That was my thinking as well and your correct. Attached are the data
> > you asked for. And tested a couple different things, what i found is
> > that this does not survive a reboot, but i'm guessing that netplay apply
> > may get called?
> >
> > I remove the mtu value from the yaml file as well, but it would seem
> > that some sort of netplan apply gets called on reboot.
> >
>
> Yes, it will get re-applied from the source netplan yaml
> (etc/netplan/50-cloud-init.yaml).
>
> There is upstream work to allow this to be toggled[1]. And the solution
> there will
> likely be storing that use-mtu: False snippet in an
> /etc/systemd/network/*.network
> file.
>
> It's somewhat unlikely that folks want to drop MTU when the underlying
> device
> can support larger ones.
>
> 1. https://github.com/CanonicalLtd/netplan/pull/61
>
>
> > Thanks for the tips.
>
>
> > ** Attachment added: "Files from previous post"
> >
> >
> https://bugs.launchpad.net/netplan/+bug/1807273/+attachment/5219826/+files/launch_pad_netplan.txt
> >
> > --
> > You received this bug notification because you are subscribed to
> > netplan.
> > Matching subscriptions: netplan
> > https://bugs.launchpad.net/bugs/1807273
> >
> > Title:
> > netplan not respecting mtu
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/netplan/+bug/1807273/+subscriptions
> >
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1807273
>
> Title:
> netplan not respecting mtu
>
> Status in netplan:
> New
>
> Bug description:
> This is very similar to https://bugs.launchpad.net/bugs/1724895, but I
> decided to open this as i have tried what has succeeded for others.
> Thanks for any assistance.
>
> I'm trying to set the MTU to 1500 and using a match on mac address,
> but after a netplan apply or reboot, it does not change or stick. This
> is on a EC2 T2.Medium instance. Actual configuration from a dev
> server:
>
> network:
> version: 2
> ethernets:
> eth0:
> match:
> macaddress: 12:0f:ae:49:5d:06
> mtu: 1500
> dhcp4: true
> nameservers:
> search: [ devbuilds.vpc, ec2.internal ]
>
> $> cat /var/run/systemd/network/10-netplan-eth0.link
> [Match]
> MACAddress=12:0f:ae:49:5d:06
>
> [Link]
> WakeOnLan=off
> MTUBytes=1500
>
> $> cat /var/run/systemd/network/10-netplan-eth0.network
> [Match]
> MACAddress=12:0f:ae:49:5d:06
>
> [Network]
> DHCP=ipv4
> Domains=devbuilds.vpc ec2.internal
>
> [DHCP]
> UseMTU=true
> RouteMetric=1...

Read more...

jd (jeff-dyke) wrote :
Download full text (4.5 KiB)

Looks like the PR was merged a couple hours ago, hopefully it will be
released soon. Thanks.

On Fri, Dec 7, 2018 at 11:19 AM Jeff Dyke <email address hidden> wrote:

> I completely understand people not wanting to drop the larger MTU, but i
> have a similar issue with my galera cluster that is documented with
> Redshift Clusters, Since these don't reboot much i'm just going to change
> them manually and see nodes dropping from the cluster stops.
>
> It looks like a good change, but i'm a bit biased b/c of my cluster issue.
>
> Appreciate it, i'll write back if this does indeed fix the problem.
>
>
>
> On Thu, Dec 6, 2018 at 6:20 PM Ryan Harper <email address hidden>
> wrote:
>
>> On Thu, Dec 6, 2018 at 5:00 PM jd <email address hidden> wrote:
>>
>> > That was my thinking as well and your correct. Attached are the data
>> > you asked for. And tested a couple different things, what i found is
>> > that this does not survive a reboot, but i'm guessing that netplay apply
>> > may get called?
>> >
>> > I remove the mtu value from the yaml file as well, but it would seem
>> > that some sort of netplan apply gets called on reboot.
>> >
>>
>> Yes, it will get re-applied from the source netplan yaml
>> (etc/netplan/50-cloud-init.yaml).
>>
>> There is upstream work to allow this to be toggled[1]. And the solution
>> there will
>> likely be storing that use-mtu: False snippet in an
>> /etc/systemd/network/*.network
>> file.
>>
>> It's somewhat unlikely that folks want to drop MTU when the underlying
>> device
>> can support larger ones.
>>
>> 1. https://github.com/CanonicalLtd/netplan/pull/61
>>
>>
>> > Thanks for the tips.
>>
>>
>> > ** Attachment added: "Files from previous post"
>> >
>> >
>> https://bugs.launchpad.net/netplan/+bug/1807273/+attachment/5219826/+files/launch_pad_netplan.txt
>> >
>> > --
>> > You received this bug notification because you are subscribed to
>> > netplan.
>> > Matching subscriptions: netplan
>> > https://bugs.launchpad.net/bugs/1807273
>> >
>> > Title:
>> > netplan not respecting mtu
>> >
>> > To manage notifications about this bug go to:
>> > https://bugs.launchpad.net/netplan/+bug/1807273/+subscriptions
>> >
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1807273
>>
>> Title:
>> netplan not respecting mtu
>>
>> Status in netplan:
>> New
>>
>> Bug description:
>> This is very similar to https://bugs.launchpad.net/bugs/1724895, but I
>> decided to open this as i have tried what has succeeded for others.
>> Thanks for any assistance.
>>
>> I'm trying to set the MTU to 1500 and using a match on mac address,
>> but after a netplan apply or reboot, it does not change or stick. This
>> is on a EC2 T2.Medium instance. Actual configuration from a dev
>> server:
>>
>> network:
>> version: 2
>> ethernets:
>> eth0:
>> match:
>> macaddress: 12:0f:ae:49:5d:06
>> mtu: 1500
>> dhcp4: true
>> nameservers:
>> search: [ devbuilds.vpc, ec2.internal ]
>>
>> $> cat /var/run/systemd/network/10-netplan-eth0.link
>> [Match]
>> MACAddress=12:0f:ae:49:5d:06...

Read more...

jd (jeff-dyke) wrote :
Download full text (5.0 KiB)

Just wanted to respond that after about 2 days, i've only had one drop,
which is better than what i was seeing. I know its not reboot proof, bu i
have the change in a salt state, so anytime its required to change back, i
can do so. I look forward to the release of that patch.

Thanks, please close at will.

On Fri, Dec 7, 2018 at 2:35 PM Jeff Dyke <email address hidden> wrote:

> Looks like the PR was merged a couple hours ago, hopefully it will be
> released soon. Thanks.
>
> On Fri, Dec 7, 2018 at 11:19 AM Jeff Dyke <email address hidden> wrote:
>
>> I completely understand people not wanting to drop the larger MTU, but i
>> have a similar issue with my galera cluster that is documented with
>> Redshift Clusters, Since these don't reboot much i'm just going to change
>> them manually and see nodes dropping from the cluster stops.
>>
>> It looks like a good change, but i'm a bit biased b/c of my cluster
>> issue.
>>
>> Appreciate it, i'll write back if this does indeed fix the problem.
>>
>>
>>
>> On Thu, Dec 6, 2018 at 6:20 PM Ryan Harper <email address hidden>
>> wrote:
>>
>>> On Thu, Dec 6, 2018 at 5:00 PM jd <email address hidden> wrote:
>>>
>>> > That was my thinking as well and your correct. Attached are the data
>>> > you asked for. And tested a couple different things, what i found is
>>> > that this does not survive a reboot, but i'm guessing that netplay
>>> apply
>>> > may get called?
>>> >
>>> > I remove the mtu value from the yaml file as well, but it would seem
>>> > that some sort of netplan apply gets called on reboot.
>>> >
>>>
>>> Yes, it will get re-applied from the source netplan yaml
>>> (etc/netplan/50-cloud-init.yaml).
>>>
>>> There is upstream work to allow this to be toggled[1]. And the solution
>>> there will
>>> likely be storing that use-mtu: False snippet in an
>>> /etc/systemd/network/*.network
>>> file.
>>>
>>> It's somewhat unlikely that folks want to drop MTU when the underlying
>>> device
>>> can support larger ones.
>>>
>>> 1. https://github.com/CanonicalLtd/netplan/pull/61
>>>
>>>
>>> > Thanks for the tips.
>>>
>>>
>>> > ** Attachment added: "Files from previous post"
>>> >
>>> >
>>> https://bugs.launchpad.net/netplan/+bug/1807273/+attachment/5219826/+files/launch_pad_netplan.txt
>>> >
>>> > --
>>> > You received this bug notification because you are subscribed to
>>> > netplan.
>>> > Matching subscriptions: netplan
>>> > https://bugs.launchpad.net/bugs/1807273
>>> >
>>> > Title:
>>> > netplan not respecting mtu
>>> >
>>> > To manage notifications about this bug go to:
>>> > https://bugs.launchpad.net/netplan/+bug/1807273/+subscriptions
>>> >
>>>
>>> --
>>> You received this bug notification because you are subscribed to the bug
>>> report.
>>> https://bugs.launchpad.net/bugs/1807273
>>>
>>> Title:
>>> netplan not respecting mtu
>>>
>>> Status in netplan:
>>> New
>>>
>>> Bug description:
>>> This is very similar to https://bugs.launchpad.net/bugs/1724895, but I
>>> decided to open this as i have tried what has succeeded for others.
>>> Thanks for any assistance.
>>>
>>> I'm trying to set the MTU to 1500 and using a match on mac address,
>>> but after a netplan apply or rebo...

Read more...

Ryan Harper (raharper) on 2018-12-10
Changed in netplan:
status: New → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers