Comment 7 for bug 1807273
Revision history for this message
| jd (jeff-dyke) wrote Re: [Bug 1807273] Re: netplan not respecting mtu | #7 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
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/
>>
>> 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/
>> file.
>>
>> It's somewhat unlikely that folks want to drop MTU when the underlying
>> device
>> can support larger ones.
>>
>> 1. https:/
>>
>>
>> > Thanks for the tips.
>>
>>
>> > ** Attachment added: "Files from previous post"
>> >
>> >
>> https:/
>> >
>> > --
>> > You received this bug notification because you are subscribed to
>> > netplan.
>> > Matching subscriptions: netplan
>> > https:/
>> >
>> > Title:
>> > netplan not respecting mtu
>> >
>> > To manage notifications about this bug go to:
>> > https:/
>> >
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https:/
>>
>> Title:
>> netplan not respecting mtu
>>
>> Status in netplan:
>> New
>>
>> Bug description:
>> This is very similar to https:/
>> 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/
>> [Match]
>> MACAddress=
>>
>> [Link]
>> WakeOnLan=off
>> MTUBytes=1500
>>
>> $> cat /var/run/
>> [Match]
>> MACAddress=
>>
>> [Network]
>> DHCP=ipv4
>> Domains=
>>
>> [DHCP]
>> UseMTU=true
>> RouteMetric=100
>>
>> $> ip link show eth0
>> 2: eth0: <BROADCAST,
>> 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,
>> 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,
>> 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
>>
>> To manage notifications about this bug go to:
>> https:/
>>
>