[18:35] <decon> exit
[18:46] <decon> Hey all, I've just done a minor "apt upgrade" with 22.04 LTS on two servers. One of them worked perfectly, and on the other, I have this strange situation where if I type "netplan apply", I lose internet connectivity on one of the NICs, and then after about 2.5 minutes, connectivity is restored
[18:47] <decon> the second NIC still works perfectly throughout, and I can access the server via the internal network on that NIC
[18:47] <decon> both servers are pretty much identically configured, and this doesn't happen on the other server
[18:47] <decon> can anyone think of a reason that "netplan apply" would suddenly break things, but only for 2.5 minutes please?
[18:48] <decon> it's a pretty simply dhcp setup on the NIC that loses connectivity
[18:50] <decon> I did a diff between the two netplan configs, and the only significant difference is the MAC addresses
[18:53] <rfm> decon, no idea what causes the difference, but setting critical: true on the interface in netplan might paper over the problem
[18:54] <decon> rfm thanks, will try
[18:54] <decon> it's a production server, so every time i try something, i get painful downtime
[18:55] <decon> the netplan docs say "special care will be taken by to not release the assigned IP"
[18:56] <decon> i guess that's a DHCP reference
[18:56] <decon> maybe I should just hard-code the ip/gateway instead of using dhcp
[19:02] <rfm> using static would at least tell if the problem is dhcp.  (I'd also look in syslog curing the apply)
[19:12] <decon> rfm ouch, downtime again when i changed to static IP and then did a "netplan try". /var/log/syslog doesn't contain anything relevant as far as I can see
[19:13] <decon> this is so weird. both the servers were ordered at the same time, and I configured them both identically
[19:17] <decon> and critical: true doesn't help with
[19:17] <decon> either*
[19:18] <decon> although I noticed downtime was closer to 1.5 mins instead of 2.5 mins when critial: true specified
[19:29] <decon> i wonder if it's due to me having disabled ipv6
[19:29] <frickler> decon: you might want to use this to enable debug logging for systemd-networkd (assuming you didn't override the default backend) https://paste.opendev.org/show/byR0wW4fwpKqsbEvf0kF/
[19:31] <decon> frickler ooh, thanks, will try
[19:38] <decon> frickler lol this is so strange. i followed the instructions here https://superuser.com/a/1234599 to enable debugging as you mentioned, and now "netplan apply" gives no downtime. this is so confusing.
[21:21] <kenyon> decon: don't disable IPv6
[22:08] <znf> needrestart is probably the most obnoxious package that 22.04 shipped with 
[22:26] <decon> kenyon do you think that is what tripped it up?
[22:27] <decon> i think i will re-enable it, i just have to make sure i set up persistent ip6tables first
[22:28] <decon> it just occurred to me that one of the main differences between the server that had problems and the server that didn't, is that the server with the problems had more than one public IP address assigned to the NIC
[22:29] <decon> but everything was working fine until I did a regular "apt upgrade" and then reboot
[22:55] <kenyon> decon: could be, because that's a config that likely doesn't get much testing, since it's bad practice
[22:56] <kenyon> decon: if there were multiple addresses, also make sure there weren't multiple default routes, assuming only one would be valid. that's a common misconfiguration that I see
[23:16] <decon> kenyon why might it be bad practice? The server has its own primary IP address for admin access only, but then also has secondary IPs for web sites hosted. This allows fail-over if the server goes down, because the switch can direct the traffic to a backup web server NIC instead
[23:19] <patdk-lap> I dunno why it would be bad, it's common usage to have many ips on the same nic
[23:21] <patdk-lap> if multible ips per nic is bad practice, then keepalived/pacemaker/ipvs are horrid creations
[23:22] <patdk-lap> have ips from the same subnet bound to many nics attached to the same subnet will cause a lot of pain though unless managed carefully
[23:25] <decon> patdk-lap thanks, yeah i won't span them over multiple NICs.