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 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
>>>
>>> To manage notifications about this bug go to:
>>> https://bugs.launchpad.net/netplan/+bug/1807273/+subscriptions
>>>
>>