netplan not respecting mtu

Bug #1807273 reported by jd
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Netplan
Fix Released
Undecided
Unassigned
netplan.io (Ubuntu)
Fix Released
Medium
Unassigned
Bionic
Fix Released
Undecided
Unassigned
Cosmic
Fix Released
Undecided
Unassigned

Bug Description

[Impact]
DHCP configurations where custom settings (MTU) need to be applied. This is a subset of the changes presented in bug 1759014.

[Test case]
1) Configure netplan for the particulars of the network by configuring an appropriate dhcp{4,6}-override stanza:

network:
  version: 2
  ethernets:
    engreen:
      dhcp4: true
      dhcp4-overrides:
        use-mtu: false

Additionally, if so required, add a custom MTU to the configuration. e.g.

      mtu: 1700

(See https://netplan.io/reference#dhcp-overrides for the available options)

2) Run 'netplan apply' or reboot to have the configuration applied.
3) Validate that the routes / DNS are properly ignored and/or replaced by the defined values.

[Regression potential]
Minimal; this adds new values to the configuration generated for networkd or NetworkManager. Existing configurations will remain unchanged, but new configurations using the dhcp{4,6}-overrides fields will benefit from additional flexibility.

---

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

Revision history for this message
jd (jeff-dyke) wrote :
Revision history for this message
Ryan Harper (raharper) wrote : Re: [Bug 1807273] [NEW] netplan not respecting mtu

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.

Revision history for this message
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.

Revision history for this message
Ryan Harper (raharper) wrote : Re: [Bug 1807273] Re: netplan not respecting mtu

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
>

Revision history for this message
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...

Revision history for this message
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...

Revision history for this message
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)
Changed in netplan:
status: New → Fix Committed
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Closing as Fix Released for upstream and for disco (netplan.io 0.95 contained the fix):

netplan.io (0.95) disco; urgency=medium
 .
   * New upstream release:
     - Added support for WPA Enterprise / 802.1x authentication (LP: #1739578)
     - Added support for setting up IP tunnels; supporting the types: ipip,
       gretap, VTI, ISATAP (NetworkManager only), sit, gre, ipip6 and ip6ip6.
       + Fixes sit (ipv6) tunnels using Hurricane Electric (LP: #1799487)
     - Add support to override networkd UseMTU setting (LP: #1807273)
     - Generate output files in dependency order
     - Refactored unit and integration tests, along with various cleanups.
     - Add DHCP overrides to control route usage and default metric for DHCP
       routes. (LP: #1776228)
     - Mitigate against bad matching on devices behind bonds then they share
       the same MAC from a physical interface. (LP: #1804861)
     - Added snapcraft.yaml.

description: updated
Changed in netplan:
status: Fix Committed → Fix Released
Changed in netplan.io (Ubuntu):
importance: Undecided → Medium
status: New → In Progress
status: In Progress → Fix Released
Revision history for this message
jd (jeff-dyke) wrote :

Just wanted to say thank you!

Revision history for this message
Timo Aaltonen (tjaalton) wrote : Please test proposed package

Hello jd, or anyone else affected,

Accepted netplan.io into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in netplan.io (Ubuntu Cosmic):
status: New → Fix Committed
tags: added: verification-needed verification-needed-cosmic
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Hello jd, or anyone else affected,

Accepted netplan.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in netplan.io (Ubuntu Bionic):
status: New → Fix Committed
tags: added: verification-needed-bionic
Revision history for this message
Steve Langasek (vorlon) wrote :

Hello jd, or anyone else affected,

Accepted netplan.io into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.10.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Revision history for this message
Steve Langasek (vorlon) wrote :

Hello jd, or anyone else affected,

Accepted netplan.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.04.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Verification-done on bionic with netplan.io 0.96-0ubuntu0.18.04.2:

I set up a new AWS instance (t2.micro in this case); and applied a similar setup (attempting to just set mtu: 1500, that doesn't work, then using the new dhcp4-overrides feature). Forcing UseMTU=false makes the MTU apply to the interface.

ubuntu@ip-172-30-0-14:~$ dpkg -l netplan.io | grep ii
ii netplan.io 0.96-0ubuntu0.18.04.2 amd64 YAML network configuration abstraction for various backends
ubuntu@ip-172-30-0-14:~$ sudo netplan --debug apply
** (generate:2138): DEBUG: 16:30:02.609: Processing input file /etc/netplan/50-cloud-init.yaml..
** (generate:2138): DEBUG: 16:30:02.609: starting new processing pass
** (generate:2138): DEBUG: 16:30:02.609: Generating output files..
** (generate:2138): DEBUG: 16:30:02.609: NetworkManager: definition eth0 is not for us (backend 1)
DEBUG:netplan generated networkd configuration changed, restarting networkd
DEBUG:no netplan generated NM configuration exists
DEBUG:eth0 not found in {}
DEBUG:Merged config:
network:
  bonds: {}
  bridges: {}
  ethernets:
    eth0:
      dhcp4: true
      dhcp4-overrides:
        use-mtu: false
      match:
        macaddress: 06:84:40:e0:fd:7c
      mtu: 1500
      set-name: eth0
  vlans: {}
  wifis: {}

DEBUG:Skipping non-physical interface: lo
DEBUG:device eth0 operstate is up, not changing
DEBUG:{}
DEBUG:netplan triggering .link rules for lo
DEBUG:netplan triggering .link rules for eth0
ubuntu@ip-172-30-0-14:~$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 06:84:40:e0:fd:7c brd ff:ff:ff:ff:ff:ff

tags: added: verification-done-bionic
removed: verification-needed-bionic
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Verification-done for cosmic, using netplan.io 0.96-0ubuntu0.18.10.2:

As for the above test, I set up a new AWS instance (t2.micro); and applied the configuration (first trying to just set mtu: 1500; then using dhcp4-overrides: { use-mtu: false }).

ubuntu@ip-172-30-0-81:~$ dpkg -l netplan.io | grep ii
ii netplan.io 0.96-0ubuntu0.18.10.2 amd64 YAML network configuration abstraction for various backends
ubuntu@ip-172-30-0-81:~$ sudo netplan --debug apply
** (generate:2737): DEBUG: 16:39:55.688: Processing input file /etc/netplan/50-cloud-init.yaml..
** (generate:2737): DEBUG: 16:39:55.689: starting new processing pass
** (generate:2737): DEBUG: 16:39:55.689: Generating output files..
** (generate:2737): DEBUG: 16:39:55.689: NetworkManager: definition eth0 is not for us (backend 1)
(generate:2737): GLib-DEBUG: 16:39:55.689: posix_spawn avoided (fd close requested)
DEBUG:netplan generated networkd configuration changed, restarting networkd
DEBUG:no netplan generated NM configuration exists
DEBUG:eth0 not found in {}
DEBUG:Merged config:
network:
  bonds: {}
  bridges: {}
  ethernets:
    eth0:
      dhcp4: true
      dhcp4-overrides:
        use-mtu: false
      match:
        macaddress: 06:9d:85:76:e2:b2
      mtu: 1500
      set-name: eth0
  vlans: {}
  wifis: {}

DEBUG:Skipping non-physical interface: lo
DEBUG:device eth0 operstate is up, not changing
DEBUG:{}
DEBUG:netplan triggering .link rules for lo
DEBUG:netplan triggering .link rules for eth0
ubuntu@ip-172-30-0-81:~$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 06:9d:85:76:e2:b2 brd ff:ff:ff:ff:ff:ff

tags: added: verification-done-cosmic
removed: verification-needed verification-needed-cosmic
Revision history for this message
Steve Langasek (vorlon) wrote :

Hello jd, or anyone else affected,

Accepted netplan.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.04.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

tags: added: verification-needed verification-needed-bionic
removed: verification-done-bionic
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

This is still verification-done for bionic; re-upload was to skip some failing tunnel tests due to a difference in kernel behavior.

tags: added: verification-done-bionic
removed: verification-needed verification-needed-bionic
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (3.4 KiB)

This bug was fixed in the package netplan.io - 0.96-0ubuntu0.18.10.2

---------------
netplan.io (0.96-0ubuntu0.18.10.2) cosmic; urgency=medium

  * d/p/0001-Partially-revert-the-change-for-enabling-systemd-net.patch:
    Partially revert changes to networkd jobs ordering: leave systemd-networkd
    enabled in multi-user.target instead of network-online.target, as in some
    minimal setups there might be no job requiring network-online.target,
    whereas the natural target to reach for booting is multi-user.target.
    (LP: #1821867)

netplan.io (0.96-0ubuntu0.18.10.1) cosmic; urgency=medium

  * Backport netplan.io 0.96 to 18.10.
  * debian/patches/glib_changes.patch: Patch tests to work again on older GLib.
  * debian/control: adjust Depends for cosmic / re-add nplan package.

netplan.io (0.96-0ubuntu1) disco; urgency=medium

  * New upstream release 0.96.
    - Moved netplan-wpa@ services to earlier at boot (LP: #1819014)
    - Restart services when unconfiguring (LP: #1811868)
    - Use the .nmconnection extension for NM keyfiles (LP: #1817655)
    - Fixed integration tests runner to correctly report failures
    - Enforce integrity for use-routes in networkd backend.
    - Ensure terminal state at end of test (LP: #1817660)
    - Various small test fixes.
    - Fix typos in documentation.
  * debian/control: Update Maintainer for ubuntu upload.

netplan.io (0.95-2) unstable; urgency=medium

  * Set Priority to optional (Closes: #920327).

netplan.io (0.95-1) unstable; urgency=medium

  * New upstream release.
  * Update autopkgtests from the upstream.
  * Add debian/watch following GitHub releases.
  * Add Homepage (Closes: #917233).

netplan.io (0.95) disco; urgency=medium

  * New upstream release:
    - Added support for WPA Enterprise / 802.1x authentication (LP: #1739578)
    - Added support for setting up IP tunnels; supporting the types: ipip,
      gretap, VTI, ISATAP (NetworkManager only), sit, gre, ipip6 and ip6ip6.
      + Fixes sit (ipv6) tunnels using Hurricane Electric (LP: #1799487)
    - Add support to override networkd UseMTU setting (LP: #1807273)
    - Generate output files in dependency order
    - Refactored unit and integration tests, along with various cleanups.
    - Add DHCP overrides to control route usage and default metric for DHCP
      routes. (LP: #1776228)
    - Mitigate against bad matching on devices behind bonds then they share
      the same MAC from a physical interface. (LP: #1804861)
    - Added snapcraft.yaml.

netplan.io (0.90.1) disco; urgency=medium

  * Do not assume /etc/network exists in postinst, as netbase 5.5 no longer
    creates it.
  * netplan/cli/commands/ip.py: fix a flake.

netplan.io (0.90) disco; urgency=medium

  * New upstream release:
    - build: fixes for building on RPM-based distros
    - build: code prettiness changes (make indentation consistent)
    - Fix device name-changes detection (LP: #1770082)
    - Add support for IPv6 Privacy Extensions (LP: #1750392)
    - Add dhcp{4,6}-overrides to control DNS, NTP, hostname updates via DHCP
      (LP: #1759014)
    - Clarify MAC and MTU setting requirements (LP: #1800668)
    - Various documentation fixes (LP: #1800669)
    -...

Read more...

Changed in netplan.io (Ubuntu Cosmic):
status: Fix Committed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Update Released

The verification of the Stable Release Update for netplan.io has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Steve Langasek (vorlon) wrote :

A possible SRU regression has been reported against netplan.io 0.96-0ubuntu0.18.10.2 in LP: #1825206. This version has been rolled back to -proposed while the investigation is ongoing.

Changed in netplan.io (Ubuntu Cosmic):
status: Fix Released → Fix Committed
Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello jd, or anyone else affected,

Accepted netplan.io into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.10.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

tags: added: verification-needed verification-needed-cosmic
removed: verification-done-cosmic
Revision history for this message
Brian Murray (brian-murray) wrote :

Hello jd, or anyone else affected,

Accepted netplan.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.04.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

tags: added: verification-needed-bionic
removed: verification-done-bionic
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Verification-done for cosmic:

ubuntu@ip-172-30-0-50:~$ lsb_release -cs
cosmic
ubuntu@ip-172-30-0-50:~$ apt policy netplan.io
netplan.io:
  Installed: 0.96-0ubuntu0.18.10.3
  Candidate: 0.96-0ubuntu0.18.10.3
  Version table:
 *** 0.96-0ubuntu0.18.10.3 500
        500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu cosmic-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     0.40.2.2 500
        500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu cosmic-updates/main amd64 Packages
     0.40.2 500
        500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu cosmic/main amd64 Packages
ubuntu@ip-172-30-0-50:~$ cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    version: 2
    ethernets:
        eth0:
            dhcp4: true
            dhcp4-overrides:
                use-mtu: false
            mtu: 1700
            match:
                macaddress: 06:24:03:7d:3e:ec
            set-name: eth0
ubuntu@ip-172-30-0-50:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1700 qdisc fq_codel state UP group default qlen 1000
    link/ether 06:24:03:7d:3e:ec brd ff:ff:ff:ff:ff:ff
    inet 172.30.0.50/24 brd 172.30.0.255 scope global dynamic eth0
       valid_lft 3593sec preferred_lft 3593sec
    inet6 fe80::424:3ff:fe7d:3eec/64 scope link
       valid_lft forever preferred_lft forever

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Verification-done for bionic:

ubuntu@ip-172-30-0-32:~$ lsb_release -cs
bionic
ubuntu@ip-172-30-0-32:~$ apt policy netplan.io
netplan.io:
  Installed: 0.96-0ubuntu0.18.04.4
  Candidate: 0.96-0ubuntu0.18.04.4
  Version table:
 *** 0.96-0ubuntu0.18.04.4 500
        500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     0.40.1~18.04.4 500
        500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
     0.36.1 500
        500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
ubuntu@ip-172-30-0-32:~$ cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    version: 2
    ethernets:
        eth0:
            dhcp4: true
            dhcp4-overrides:
                use-mtu: false
            mtu: 1789
            match:
                macaddress: 06:12:92:f8:f9:c8
            set-name: eth0
ubuntu@ip-172-30-0-32:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1789 qdisc fq_codel state UP group default qlen 1000
    link/ether 06:12:92:f8:f9:c8 brd ff:ff:ff:ff:ff:ff
    inet 172.30.0.32/24 brd 172.30.0.255 scope global dynamic eth0
       valid_lft 3595sec preferred_lft 3595sec
    inet6 fe80::412:92ff:fef8:f9c8/64 scope link
       valid_lft forever preferred_lft forever

tags: added: verification-done-bionic verification-done-cosmic
removed: verification-needed verification-needed-bionic verification-needed-cosmic
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (4.5 KiB)

This bug was fixed in the package netplan.io - 0.96-0ubuntu0.18.04.4

---------------
netplan.io (0.96-0ubuntu0.18.04.4) bionic; urgency=medium

  * debian/patches/git_revert_explicit_renderer_def_ebc212a.patch: revert
    commit ebc212a: make renderer values explicit at the end of each parsing
    pass; it breaks "default" renderer behavior when multiple files may set
    a global renderer and expect the last to take effect globally.
    (LP: #1825206)
  * debian/patches/git_reorg_netdef_validation_181b583.patch: correct the
    fallout from the above change: validate netdefs in a single pass at the
    very end of parsing, once we know which is the applicable renderer. This
    makes sure tunnels get validated correctly.

netplan.io (0.96-0ubuntu0.18.04.3) bionic; urgency=medium

  * debian/patches/disable-networkd-tunnels-ipip-gre.patch: disable IPIP and
    GRE tunnel tests; those appear to be broken because neither the kernel nor
    networkd bring up the device automatically as in other releases.

netplan.io (0.96-0ubuntu0.18.04.2) bionic; urgency=medium

  * d/p/0001-Partially-revert-the-change-for-enabling-systemd-net.patch:
    Partially revert changes to networkd jobs ordering: leave systemd-networkd
    enabled in multi-user.target instead of network-online.target, as in some
    minimal setups there might be no job requiring network-online.target,
    whereas the natural target to reach for booting is multi-user.target.
    (LP: #1821867)

netplan.io (0.96-0ubuntu0.18.04.1) bionic; urgency=medium

  * Backport netplan.io 0.96 to 18.04.
  * debian/patches/glib_changes.patch: Patch tests to work again on older GLib.
  * debian/control: adjust Depends for bionic / re-add nplan package.

netplan.io (0.96-0ubuntu1) disco; urgency=medium

  * New upstream release 0.96.
    - Moved netplan-wpa@ services to earlier at boot (LP: #1819014)
    - Restart services when unconfiguring (LP: #1811868)
    - Use the .nmconnection extension for NM keyfiles (LP: #1817655)
    - Fixed integration tests runner to correctly report failures
    - Enforce integrity for use-routes in networkd backend.
    - Ensure terminal state at end of test (LP: #1817660)
    - Various small test fixes.
    - Fix typos in documentation.
  * debian/control: Update Maintainer for ubuntu upload.

netplan.io (0.95-2) unstable; urgency=medium

  * Set Priority to optional (Closes: #920327).

netplan.io (0.95-1) unstable; urgency=medium

  * New upstream release.
  * Update autopkgtests from the upstream.
  * Add debian/watch following GitHub releases.
  * Add Homepage (Closes: #917233).

netplan.io (0.95) disco; urgency=medium

  * New upstream release:
    - Added support for WPA Enterprise / 802.1x authentication (LP: #1739578)
    - Added support for setting up IP tunnels; supporting the types: ipip,
      gretap, VTI, ISATAP (NetworkManager only), sit, gre, ipip6 and ip6ip6.
      + Fixes sit (ipv6) tunnels using Hurricane Electric (LP: #1799487)
    - Add support to override networkd UseMTU setting (LP: #1807273)
    - Generate output files in dependency order
    - Refactored unit and integration tests, along with various cleanups.
    - Add DHCP overrides to control ...

Read more...

Changed in netplan.io (Ubuntu Bionic):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (4.0 KiB)

This bug was fixed in the package netplan.io - 0.96-0ubuntu0.18.10.3

---------------
netplan.io (0.96-0ubuntu0.18.10.3) cosmic; urgency=medium

  * debian/patches/git_revert_explicit_renderer_def_ebc212a.patch: revert
    commit ebc212a: make renderer values explicit at the end of each parsing
    pass; it breaks "default" renderer behavior when multiple files may set
    a global renderer and expect the last to take effect globally.
    (LP: #1825206)
  * debian/patches/git_reorg_netdef_validation_181b583.patch: correct the
    fallout from the above change: validate netdefs in a single pass at the
    very end of parsing, once we know which is the applicable renderer. This
    makes sure tunnels get validated correctly.

netplan.io (0.96-0ubuntu0.18.10.2) cosmic; urgency=medium

  * d/p/0001-Partially-revert-the-change-for-enabling-systemd-net.patch:
    Partially revert changes to networkd jobs ordering: leave systemd-networkd
    enabled in multi-user.target instead of network-online.target, as in some
    minimal setups there might be no job requiring network-online.target,
    whereas the natural target to reach for booting is multi-user.target.
    (LP: #1821867)

netplan.io (0.96-0ubuntu0.18.10.1) cosmic; urgency=medium

  * Backport netplan.io 0.96 to 18.10.
  * debian/patches/glib_changes.patch: Patch tests to work again on older GLib.
  * debian/control: adjust Depends for cosmic / re-add nplan package.

netplan.io (0.96-0ubuntu1) disco; urgency=medium

  * New upstream release 0.96.
    - Moved netplan-wpa@ services to earlier at boot (LP: #1819014)
    - Restart services when unconfiguring (LP: #1811868)
    - Use the .nmconnection extension for NM keyfiles (LP: #1817655)
    - Fixed integration tests runner to correctly report failures
    - Enforce integrity for use-routes in networkd backend.
    - Ensure terminal state at end of test (LP: #1817660)
    - Various small test fixes.
    - Fix typos in documentation.
  * debian/control: Update Maintainer for ubuntu upload.

netplan.io (0.95-2) unstable; urgency=medium

  * Set Priority to optional (Closes: #920327).

netplan.io (0.95-1) unstable; urgency=medium

  * New upstream release.
  * Update autopkgtests from the upstream.
  * Add debian/watch following GitHub releases.
  * Add Homepage (Closes: #917233).

netplan.io (0.95) disco; urgency=medium

  * New upstream release:
    - Added support for WPA Enterprise / 802.1x authentication (LP: #1739578)
    - Added support for setting up IP tunnels; supporting the types: ipip,
      gretap, VTI, ISATAP (NetworkManager only), sit, gre, ipip6 and ip6ip6.
      + Fixes sit (ipv6) tunnels using Hurricane Electric (LP: #1799487)
    - Add support to override networkd UseMTU setting (LP: #1807273)
    - Generate output files in dependency order
    - Refactored unit and integration tests, along with various cleanups.
    - Add DHCP overrides to control route usage and default metric for DHCP
      routes. (LP: #1776228)
    - Mitigate against bad matching on devices behind bonds then they share
      the same MAC from a physical interface. (LP: #1804861)
    - Added snapcraft.yaml.

netplan.io (0.90.1) disco; urgency=medium

  * Do ...

Read more...

Changed in netplan.io (Ubuntu Cosmic):
status: Fix Committed → Fix Released
Revision history for this message
Erwin Hager (errieman) wrote :

This bug is still present in 0.98-0ubuntu1~18.04.1. Can provide more info if needed. I have not tested the specific package Brian has posted. If I need to still do that, please let me know.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.