ubuntu 18.10 to 19.04 host-only network enp0s3 times out

[DAE51D]

Windows 10 host running latest Virtualbox 6.0.10 and my development Ubuntu VM has been upgraded many times over the past 3 years. Most recently I was on 18.10 and since it's EOL I did a snapshot and "do-release-upgrade" to 19.04.

The upgrade went fine and everything seems to work, except my host-only network will time-out after several minutes (not sure exactly, feels like maybe between 15-30 as I'm unsure if it's based upon idle time or something) and terminates my ssh sessions. It's obviously disruptive and infuriating as I loose all my NFS mounts, SSH tabs, IDE editor locks up, etc...

I have my networking set as follows

Code: Select all

 $ ▶ ifconfig
br-977f7fd82c8b: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.18.0.1  netmask 255.255.0.0  broadcast 172.18.255.255
        ether 02:42:a4:fd:b2:af  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:a1:cd:80:ac  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.56.102  netmask 255.255.255.0  broadcast 192.168.56.255
        inet6 fe80::a00:27ff:fe35:aa1  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:35:0a:a1  txqueuelen 1000  (Ethernet)
        RX packets 860  bytes 126188 (126.1 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 822  bytes 237700 (237.7 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.3.15  netmask 255.255.255.0  broadcast 10.0.3.255
        inet6 fe80::a00:27ff:feae:11bd  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:ae:11:bd  txqueuelen 1000  (Ethernet)
        RX packets 10522  bytes 15001725 (15.0 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3657  bytes 213404 (213.4 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 219  bytes 17886 (17.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 219  bytes 17886 (17.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Code: Select all

 $ ▶ cat interfaces
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface host-only
allow-hotplug enp0s3
iface enp0s3 inet dhcp
#iface enp0s3 inet static
#address 192.168.56.102
#netmask 255.255.255.0
#gateway 192.168.56.1

# The secondary network interface NAT
allow-hotplug enp0s8
iface enp0s8 inet dhcp

virtualbox ubuntu vm networking.jpg (47.44 KiB) Viewed 3307 times

It only effects the HOST ONLY one. I can use the VirtualBox "GUI console" (for lack of a better word) and login, and I can still connect to the outside world via NAT as that IP address doesn't change (from 10.0.3.15 for example). I just have completely lost the IP for the enp0s3

virtualbox gui console.jpg (86.58 KiB) Viewed 3307 times

As root login, trying to

Code: Select all

/etc/init.d/networking restart

does NOT re-enable the port. Nor does

Code: Select all

sudo ifdown -a && sudo ifup -a

And these two commands straight up fail

Code: Select all

service network-manager restart
systemctl restart NetworkManager.service

with basically saying the service is not found?!

The only way to get the port back is to reboot the VM!

Curiously this shows the port is "UP" right?

ip link show.jpg (10.22 KiB) Viewed 3305 times

dmesg has this curious part, but it also mentions BOTH interfaces in separate cut blocks, so not sure if this is a red herring...

Code: Select all

[   10.703410] ------------[ cut here ]------------
[   10.703411] netdevice: enp0s3: failed to disable LRO!
[   10.703435] WARNING: CPU: 1 PID: 1169 at net/core/dev.c:1568 dev_disable_lro+0xab/0xe0
[   10.703436] Modules linked in: iptable_nat nf_nat_ipv4 xt_addrtype iptable_filter bpfilter xt_conntrack nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc aufs overlay dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_rapl_perf input_leds serio_raw vboxguest(OE) mac_hid tcp_bbr sch_fq ib_iser rdma_cm iw_cm ib_cm nfsd auth_rpcgss nfs_acl lockd grace ib_core sunrpc iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear aesni_intel aes_x86_64 crypto_simd vboxvideo(OE) cryptd ttm glue_helper drm_kms_helper syscopyarea sysfillrect psmouse virtio_net ahci net_failover failover libahci sysimgblt fb_sys_fops i2c_piix4 drm pata_acpi video
[   10.703494] CPU: 1 PID: 1169 Comm: dockerd Tainted: G           OE     5.0.0-27-generic #28-Ubuntu
[   10.703495] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[   10.703496] RIP: 0010:dev_disable_lro+0xab/0xe0
[   10.703512] Code: 52 b1 74 14 be 25 00 00 00 48 89 df e8 ae 80 15 00 48 85 c0 4c 0f 44 e3 4c 89 ea 4c 89 e6 48 c7 c7 58 5c 5a b1 e8 b7 9c 7d ff <0f> 0b e9 78 ff ff ff 80 3d 13 3e f4 00 00 49 c7 c5 22 5a 52 b1 75
[   10.703513] RSP: 0018:ffffb90bc3d77dd0 EFLAGS: 00010286
[   10.703514] RAX: 0000000000000000 RBX: ffff8f1cda9e2000 RCX: 0000000000000006
[   10.703515] RDX: 0000000000000007 RSI: 0000000000000082 RDI: ffff8f1cdbb16440
[   10.703515] RBP: ffffb90bc3d77de8 R08: 0000000000000001 R09: 000000000000020b
[   10.703516] R10: 0000000000000004 R11: 0000000000000000 R12: ffff8f1cda9e2000
[   10.703517] R13: ffffffffb151ce42 R14: ffffffffb19d5e10 R15: ffff8f1cda9e2000
[   10.703518] FS:  00007f74789a7700(0000) GS:ffff8f1cdbb00000(0000) knlGS:0000000000000000
[   10.703518] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   10.703519] CR2: 00007fc6890c78f0 CR3: 000000011800a004 CR4: 00000000000606e0
[   10.703535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   10.703536] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   10.703536] Call Trace:
[   10.703543]  devinet_sysctl_forward+0x1b7/0x1de
[   10.703564]  proc_sys_call_handler+0xac/0x100
[   10.703566]  proc_sys_write+0x14/0x20
[   10.703568]  __vfs_write+0x1b/0x40
[   10.703569]  vfs_write+0xab/0x1b0
[   10.703570]  ksys_write+0x5c/0xd0
[   10.703571]  __x64_sys_write+0x1a/0x20
[   10.703586]  do_syscall_64+0x5a/0x110
[   10.703588]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   10.703590] RIP: 0033:0x55707b4cf550
[   10.703591] Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7 c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30
[   10.703592] RSP: 002b:000000c000cb6910 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
[   10.703593] RAX: ffffffffffffffda RBX: 000000c00005c000 RCX: 000055707b4cf550
[   10.703593] RDX: 0000000000000002 RSI: 000000c000cb6afe RDI: 000000000000000b
[   10.703594] RBP: 000000c000cb6960 R08: 0000000000000000 R09: 0000000000000000
[   10.703594] R10: 0000000000000000 R11: 0000000000000202 R12: 000000000000000c
[   10.703595] R13: 0000000000000032 R14: 000055707d0f01e8 R15: 0000000000000000
[   10.703598] ---[ end trace 107528a7ea113615 ]---

[   10.703601] ------------[ cut here ]------------
[   10.703602] netdevice: enp0s8: failed to disable LRO!
[   10.703607] WARNING: CPU: 1 PID: 1169 at net/core/dev.c:1568 dev_disable_lro+0xab/0xe0
[   10.703608] Modules linked in: iptable_nat nf_nat_ipv4 xt_addrtype iptable_filter bpfilter xt_conntrack nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc aufs overlay dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_rapl_perf input_leds serio_raw vboxguest(OE) mac_hid tcp_bbr sch_fq ib_iser rdma_cm iw_cm ib_cm nfsd auth_rpcgss nfs_acl lockd grace ib_core sunrpc iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear aesni_intel aes_x86_64 crypto_simd vboxvideo(OE) cryptd ttm glue_helper drm_kms_helper syscopyarea sysfillrect psmouse virtio_net ahci net_failover failover libahci sysimgblt fb_sys_fops i2c_piix4 drm pata_acpi video
[   10.703627] CPU: 1 PID: 1169 Comm: dockerd Tainted: G        W  OE     5.0.0-27-generic #28-Ubuntu
[   10.703628] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[   10.703629] RIP: 0010:dev_disable_lro+0xab/0xe0
[   10.703630] Code: 52 b1 74 14 be 25 00 00 00 48 89 df e8 ae 80 15 00 48 85 c0 4c 0f 44 e3 4c 89 ea 4c 89 e6 48 c7 c7 58 5c 5a b1 e8 b7 9c 7d ff <0f> 0b e9 78 ff ff ff 80 3d 13 3e f4 00 00 49 c7 c5 22 5a 52 b1 75
[   10.703630] RSP: 0018:ffffb90bc3d77dd0 EFLAGS: 00010286
[   10.703631] RAX: 0000000000000000 RBX: ffff8f1ccccd0000 RCX: 0000000000000006
[   10.703632] RDX: 0000000000000007 RSI: 0000000000000082 RDI: ffff8f1cdbb16440
[   10.703632] RBP: ffffb90bc3d77de8 R08: 0000000000000001 R09: 0000000000000231
[   10.703633] R10: 0000000000000004 R11: 0000000000000000 R12: ffff8f1ccccd0000
[   10.703633] R13: ffffffffb151ce42 R14: ffffffffb19d5e10 R15: ffff8f1ccccd0000
[   10.703634] FS:  00007f74789a7700(0000) GS:ffff8f1cdbb00000(0000) knlGS:0000000000000000
[   10.703635] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   10.703648] CR2: 00007fc6890c78f0 CR3: 000000011800a004 CR4: 00000000000606e0
[   10.703651] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   10.703652] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   10.703652] Call Trace:
[   10.703654]  devinet_sysctl_forward+0x1b7/0x1de
[   10.703656]  proc_sys_call_handler+0xac/0x100
[   10.703658]  proc_sys_write+0x14/0x20
[   10.703659]  __vfs_write+0x1b/0x40
[   10.703660]  vfs_write+0xab/0x1b0
[   10.703661]  ksys_write+0x5c/0xd0
[   10.703663]  __x64_sys_write+0x1a/0x20
[   10.703664]  do_syscall_64+0x5a/0x110
[   10.703666]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   10.703666] RIP: 0033:0x55707b4cf550
[   10.703667] Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7 c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30
[   10.703668] RSP: 002b:000000c000cb6910 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
[   10.703669] RAX: ffffffffffffffda RBX: 000000c00005c000 RCX: 000055707b4cf550
[   10.703669] RDX: 0000000000000002 RSI: 000000c000cb6afe RDI: 000000000000000b
[   10.703670] RBP: 000000c000cb6960 R08: 0000000000000000 R09: 0000000000000000
[   10.703671] R10: 0000000000000000 R11: 0000000000000202 R12: 000000000000000c
[   10.703671] R13: 0000000000000032 R14: 000055707d0f01e8 R15: 0000000000000000
[   10.703673] ---[ end trace 107528a7ea113616 ]---
[   10.732328] Initializing XFRM netlink socket

[socratis]

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500

I don't like the looks of this... Docker is a program that relies on VirtualBox, but modifies its configuration files in unknown ways to us, and with unknown consequences, especially the networking part. It is not supported on these VirtualBox forums/channels, they have their own Docker support channels. If you are having this problem with a standalone version of VirtualBox (after a complete uninstallation of Docker), then we can continue this discussion.

Another potential source of the problem might be this:

my development Ubuntu VM has been upgraded many times over the past 3 years

Do you have a problem like the one you're facing if you install a new 19.04 VM? Even sticking an Ubuntu 19.04 LiveDVD and booting from that would suffice...

Finally, from the screenshot of your guest's network configuration (please post is as text the next time), I see that you're not actually getting an IP for enp0s3. Was that screenshot taken after you lost connectivity?

[fth0]

The dmesg output shows that the dockerd tries to disable LRO (Large Receive Offset) on both network interfaces, so docker could be part of the problem. Use brctl show to look at the state of the bridge interface: If docker (or some other process) connects enp0s3 to br-977f7fd82c8b, then enp0s3 will naturally lose its IP address.

[DAE51D]

Docker is a program that relies on VirtualBox

With respect, I've been using this VM with all of this configuration for nearly 3 years at my job without any problems in several previous Ubuntu versions from probably 16.x through 18.10 without any incident. Only this new 19.04 is exhibiting an issue. I mean, it COULD be docker related with a later kernel or something, but I would think things would only get better, not worse -- especially given all the attention to docker/containers over the past few years...

If you are having this problem with a standalone version of VirtualBox (after a complete uninstallation of Docker), then we can continue this discussion.

I can certainly give it a go for debugging purposes... however I will also say that the above happens just starting the VM/Ubuntu and sitting there. No docker containers running or anything.

Do you have a problem like the one you're facing if you install a new 19.04 VM? Even sticking an Ubuntu 19.04 LiveDVD and booting from that would suffice...

Another great suggestion that I can try... certainly was going to be on my list of things to do, but was hoping there was a "simple" or "known" issue and resolution before spending too much time potentially re-inventing the wheel...

I see that you're not actually getting an IP for enp0s3. Was that screenshot taken after you lost connectivity?

Yes. That is literally the problem I'm writing you all about. The IP goes away. It starts out great when I boot and after 15-30 mins ONLY that HOST-ONLY interface goes away (and I can't ssh from my host to the guest). The NAT one is fine and I can use the VM GUI to login and do internet stuff external (to my host).

Finally, from the screenshot of your guest's network configuration (please post is as text the next time)

I can't SSH into the VM to get text or I would have as I did the others -- trust me, screen grabbing, saving, resizing to < 128k, uploading and inlining is vastly more annoying than just copy/paste in a code block tag .
That is from the VirtualBox console (and I wasn't about to re-type all that stuff by hand) -- hence screenshot.

[DAE51D]

The dmesg output shows that the dockerd tries to disable LRO (Large Receive Offset) on both network interfaces, so docker could be part of the problem. Use brctl show to look at the state of the bridge interface: If docker (or some other process) connects enp0s3 to br-977f7fd82c8b, then enp0s3 will naturally loose its IP address.

I am currently running my 18.10 snapshot (again) and not the 19.04 one (to get my actual job tasks done after the fiasco earlier). But while I can switch back and test your statement, I would like to point out that here in my WORKING 18.10, this is that output you requested, and it shows what you suggest would be a problem, but it is in fact not the problem as my VM and docker work perfectly and I never lose my HOST-ONLY IP...

Code: Select all

$ ▶ brctl show
bridge name         bridge id               STP enabled     interfaces
br-977f7fd82c8b     8000.02428eae6435       no              veth99f1975
docker0             8000.0242a300104b       no              vethfce30ee

[socratis]

With respect, I've been using this VM with all of this configuration for nearly 3 years

With respect, something was fragile in your setup and something broke. What? How? I don't know. It would require a major investigation to find out exactly what went wrong there. The fact that it's a VM doesn't make it necessarily a VirtualBox problem, could be a misconfiguration in your guest OS, it happens all the time...

in fact not the problem as my VM and docker work perfectly

If you want something working, stick with the old setup, don't try to fix what's not broken.

If on the other hand something stops working, we need to take a look at what might be broken. And since your specific setup has two potential major culprits (compared to everyone else's and their cousins' that it works), we need to start eliminating these, no?

So, please, I don't know what changed/didn't change in your setup, I don't know what the upgrade did/didn't do to potentially expose an underlying condition and trigger it, I don't know how Docker interacts/doesn't interact with your NICs. All I know from the little time that I've devoted looking into Docker, is that is messes the HostOnly networks, seriously messes them up. And you're actually having a HostOnly problem... Hmm...

[fth0]

I am currently running my 18.10 snapshot (again) and not the 19.04 one (to get my actual job tasks done after the fiasco earlier). But while I can switch back and test your statement, I would like to point out that here in my WORKING 18.10, this is that output you requested, and it shows what you suggest would be a problem, but it is in fact not the problem as my VM and docker work perfectly and I never lose my HOST-ONLY IP...

I think it's clear that your problem only exists after upgrading your Ubuntu VM to 19.04., and IMHO docker is only one of many candidates for causing it (albeit a promising one ). What I've been suggesting is a first step in identifying the cause of your problem. Reading your statement, I'm not sure if you understood what I've been trying to say, so I'll clarify a bit:

In general, if you have a Linux bridge interface configured with an IPv4 address (statically or with DHCP), and if you have an Ethernet interface configured with an IPv4 address (statically or with DHCP), and if you then attach the Ethernet interface to the bridge, the Ethernet interface will no longer have its previous IPv4 address, because all network interfaces attached to a bridge share the IPv4 address of the bridge. If you then detach the Ethernet interface from the bridge again, it will have its own IPv4 address again (maybe another one in the DHCP case). This is Linux standard behavior and you can test this yourself using ifconfig, brctl addif and brctl delif. Knowing this, your missing IPv4 address for enp0s3 naturally leads to using brctl show to find out, if enp0s3 is attached to one of your two bridges when having the problem.

[DAE51D]

Just adding more data to the thread here as I try to figure out WTF is broken....

Last night I went home and created two FRESH installs of both Ubuntu 19.04 and 18.10, installing the default Docker package and a few other random ones (AWS CLI, Postgres, etc.) as part of the initial installation options. I left them both running and they worked fine. Then it dawned on me that I remembered updating Docker to the rebranded Docker-CE since the existing packages were never getting any love. I thought MAYBE that was a factor. It was not. They both continued to work perfect...

ubuntu 19.04 and 18.10 new docker installed.png (126.19 KiB) Viewed 3277 times

I'm currently in the process now of updating the 18.10 to 19.04 via the

Code: Select all

do-release-upgrade

script to see if maybe something with the upgrade is hosing it up.
UPDATE: doesn't seem to be THAT either. FML. This is getting annoying. This 'updated' one is seemingly solid too... Onto next idea...

Another option I thought is to use my aforementioned Development VM and UNINSTALL docker-ce all together for a hot minute and see if the network goes wonky again. Then from there decide next steps...

On a related note, *IF* it turns out I need to take the new fresh install 19.04 and rebuild my 3 years of configs and tools, anyone know a good way to get a list of all packages that I've installed on it that are NOT part of an Ubuntu normal distribution (or upgrades)? And then is there a command to "apt install" this list en masse (I know I can just concat them all together as a big blob on the CLI, but maybe there's a cleaner way)?

[DAE51D]

Well, I concede defeat. I tried again yesterday to do the fresh upgrade to 19.04 and from there to 19.10 hoping that whatever they broke was fixed in that year. I also updated VirtualBox to 6.2 thinking that might be the culprit somehow.

Finally in the end, I just did a fresh install of 19.10 from an ISO, mounted my old VDI to the new VM as /mnt/oldvm and copied over the useful bits of my code, home directory, root (user) directory, /usr/local/bin and a few /etc configs for good measure.

I've been running the new VM all day with my docker and code and NFS mount and everything so far seems pretty good.

It was a little annoying to figure out the new netplan to get my NAT and Host-Only working properly again (with a static IP)...

Ubuntu, as always, switched the way network interfaces are configured somewhere around 18 but definitely in 19.x...

edit /etc/netplan/50-cloud-init.yaml

Code: Select all

network:
    version: 2
    renderer: networkd
    ethernets:
      enp0s3:
        dhcp4: false
        addresses: [192.168.56.102/24]
        #gateway4: 192.168.56.1
        nameservers:
          addresses: [192.168.56.1, 8.8.8.8, 8.8.4.4]
      enp0s8:
        dhcp4: true

Note that the gateway is commented out. Without this change, you won't be able to ping!
That bit there is subtle but significant and kind of stupid that it's not mentioned more.

Also don't forget to disable the cloud init that will overwrite this file...

Code: Select all

echo "network: {config: disabled}" > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

https://unix.stackexchange.com/question ... 240#457240
https://askubuntu.com/questions/984445/ ... 42#1051542
https://unix.stackexchange.com/question ... ing-vmware


Oh and here's a "duh moment"... there you go. all your installed packages

Code: Select all

apt --installed list

[javierj]

I found a bug in ubuntu's launchpad, it was closed, upstream bug in kernel, might be an old bug that is persisting. I bet you are using virtio network adapters.

on ubuntu 20 im seeing the same issue playing with netplan and creating bond's and bridges.