[07:45] we're using netplan on our router / server box, its configuration is https://paste.debian.net/1197100/ during maintenance schedules, it seems our ISPs router (123.123.123.1) does a power cycle, leading to a "enp4s0f3 NIC Link is down" / "enp4s0f3 NIC Link is up" cycle. whenever this happens, the default route is dropped and not added back automatically. I can't figure out why this is, what to do [07:45] (installing ifplugd doesn't seem like the right approach here, I'd just like the route to remain, and I don't know how it interacts with netplan anyhow). Any hints? [08:05] fiesh: with "default route" you mean the gateway4/6 settings? Is there any other networking daemon running in the background (besides netplan/systemd-networkd), like NetworkManager or dhclient? Or maybe the ISPs router sends IPv6 RAs, to reconfigure the default routes... you could try: "accept-ra: false" [08:06] mcint: it should apply on reboot. Try "netplan --debug apply" do see what's going on. [08:08] Sat0: macvtap is currently not supported, see: https://bugs.launchpad.net/netplan/+bug/1664847 [08:12] oh I see you're using "accept-ra: false" already.. [09:10] slyon: yes, the two gateways are dropped. There's no NetworkManager or dhclient. However, since the system hosts many lxc instances, lxd is running. It seems that lxd spawns an instance of dnsmasq -- could that be related? [09:10] doing a `netplan apply` re-adds the gateways correctly after they've been dropped [09:14] fiesh: yeah.. sounds like something is changing the default gateway in the background somehow. Is the default gateway removed all together or changed to a different value? Is the static route still there after this change? [09:15] Would it be an option to define your default gateway as a static route as well? [09:33] slyon: the default route is just gone [09:34] slyon: that's a good suggestion... I'll give it a shot [09:37] slyon: ok so it work after the `netplan apply`... I'll have to try a link down later when there's less traffic I'll potentially break [09:38] slyon: I am very hopeful... thank you! :) [09:38] :) let me know if that works! [09:39] (I'm optimistic since no other routes go missing after the link cycle, so it would seem that adding the default route this way should behave alike) [09:54] ack [12:29] slyon: thanks, nothing. in lxd *lxc containers, just the 50-cloud-init.yaml file. ok. it says it applied, but doesn't include the new ip address nor nameserver i configured [12:29] renderer: networkd [12:30] mcint: would you mind sharing your YAML config? [12:31] e.g. via paste.ubuntu.com [12:31] yeah... will sanitize values [12:31] seems likely that it's a container issue [12:32] ** (generate:10751): DEBUG: 12:31:03.940: openvswitch: definition eno1 is not for us (backend 1) [12:32] ** (generate:10751): DEBUG: 12:31:03.940: NetworkManager: definition eno1 is not for us (backend 1) [12:33] that looks ok, as you said you're using networkd as a backend renderer [12:34] https://paste.ubuntu.com/p/K6RBFr277y/ [12:35] I had not included one before. also --debug, helped ...remind me i wasn't doing it as root [12:35] also seeing: DEBUG:eno1 not found in {} [12:36] ...and the device is called eth0@if130. some kind of lxc autogenerated vdev/if [12:36] device that exists. I'm clearly missing some fundamental understanding, and I don't think it's even in netplan [12:37] mcint: yeah "eno1 not found in {}" is not good. I think you're missing the netmask in your IP address, try "addresses: [172.1.2.3/24]" (or what every your netmask is [12:38] but that should throw parsing errors IMO.. [12:39] it shows this for me: "test.yaml:5:7: Error in network definition: address '172.1.2.3' is missing /prefixlength" [12:39] try fixing this up, maybe it can then correctly generate your configs [14:06] oh, sorry - bad hand-redaction. I do have netmasks on every address for the interface [14:14] https://pasteboard.co/K1pi6rs.png [14:16] mcint: ok. Is this definition for eno1 or eth0? I think you should not add the @if130 suffix to eth0 [14:16] also, indentation might be off due to the #eno1 comment, not sure how picky YAML is in this case