ifdownup2 breaks network on nodes.

[Dragon19]

I have verified this issue on multiple nodes with fresh installs. All nodes were installed with debian buster for the LUKS encryption. Followed the guide exactly.

This was not happening two weeks ago on older installs (same hardware) so I'm at a loss here.

Images of the issue. Ignore the dirty monitor I rarely use it and it was in storage:

https://i.imgur.com/wbul3uE.jpg

https://i.imgur.com/D3zDcD3.jpg

https://i.imgur.com/5naRk4O.jpg

 

[Dragon19]

Also this was a functional node in the cluster before installing ifdownup2 and that network configuration worked.

 

[Mihai]

I had the same issue. Had to uninstall ipdownup2 and reboot the nodes.

 

[danielb]

Would you happen to have OVS bridges/bonds ? ifupdown2 does not support OVS (yet)

 

[Mihai]

No we don't use OpenvSwitch, just regular linux bonds/bridges.

 

[danielb]

can you share your /etc/network/interfaces ? I've switched to ifupdown2 on a 5 node cluster, with very little issues (and a lot of new possiblities)

 

[Mihai]

can you share your /etc/network/interfaces ? I've switched to ifupdown2 on a 5 node cluster, with very little issues (and a lot of new possiblities)

Sure, here's an example from one of our 3 node cluster.

They're all same.

auto lo
iface lo inet loopback

iface eno1 inet manual

iface eno2 inet manual

iface enp4s0 inet manual

auto enp4s0d1
iface enp4s0d1 inet static
        address  10.10.1.16
        netmask  255.255.255.0
#CEPH

iface enp3s0f0 inet manual

iface enp3s0f1 inet manual

auto bond0
iface bond0 inet static
        address  10.10.2.16
        netmask  255.255.255.0
        slaves eno1 eno2
        bond_miimon 100
        bond_mode broadcast
#Corosync Direct Host to Host

auto vmbr0
iface vmbr0 inet static
        address  10.10.0.16
        netmask  255.255.255.0
        gateway  10.10.0.1
        bridge_ports enp4s0
        bridge_stp off
        bridge_fd 0
#Proxmox

 

[danielb]

Mmm, nothing obvious which would prevent ifupdown2 to handle it. If you still have them arround, you should check the logs at the time the network wouldn't come up to see what went wrong

 

[Dragon19]

Mmm, nothing obvious which would prevent ifupdown2 to handle it. If you still have them arround, you should check the logs at the time the network wouldn't come up to see what went wrong

I worded my OP poorly. What I meant to say was that ifdownup2 was fully functional and worked fine a week ago. It's only on new installs this is happening (I haven't upgraded the cluster, though, so maybe it's bugged on the upgrades as well).

 

[102020]

Chiming in here as I was directed from another thread. Same issue here, using ifupdown2 and OVS. I very specifically did the upgrade, rebooted and every server booped up after that. My temporary fix was to add auto vmbr1 to my OVS bridge, which is not ideal.

Following.