Good day all.
I am looking for some help and guidance with a small issue that I am having.
I have four nic’s bonded, as long as the cables are all connected I don’t have any issue.
And this would be the case 99% of the time.
The other 1% of the time is when I move the system to perform maintenance, etc, during this time I am only likly to connect one network cable.
And as such each time the system is rebooted it gets stuck at:
a start job is running for wait for network to be configured
And waits for 2 minutes before coming up with FAILED and continuing to boot.
Reading netplan.io it says that I can use the optional: true key added to them. This will prevent long delays in booting for interfaces that may not come up.
After adding optional: true I am still getting the 2 minute wait.
interfaces: [eno2, eno3, enp5s0f0, enp5s0f1]
addresses: [192.168.1.204/24, 192.168.1.205/24, 192.168.1.206/24, 192.168.1.207/24]
Thanks for your time.
All my netplan systems are simple 1 nix affairs so I don’t have experience using netplan for bonds but I want to share what I do know because the problems I’ve run into and solved are the complete opposite of obvious. Perhaps the wait is indicating a configuration problem on either side of the bond that could be working itself by setting a default at the end of the timeout?
I’ve worked a good bit with bonds using 802.3ad on RHEL based systems in a mostly Cisco shop. The context for this is KVM/Ovirt so there are a lot of VLANs in the mix. The following are the important bits:
- The nics do not have IPs, only the bond does.
- The bond is assigned an IPv4 address manually and the VLAN that IP belongs to must be set as default/native on the Cisco side. If it is not set as native or the incorrect network is set native the bond will never activate. This is the non-obvious thing and doesn’t apply in Windows setups according to my network guys.
I hope I’m not forgetting something, this is all from my often faulty memory. The thing that concerns me most about your config is the IPs on the bond members. If you are trying to create an 802.3ad bond then those members should not have an IP in my experience. Rather, your bond is a new interface providing more bandwidth and fault tolerance and the IPs are floating a layer above it using virtual interfaces either on the default network or on the other networks you’re trunking through the bond.
I’m not an expert but it looks to me like you’re mixing the concepts of 802.3ad trunking and linux-side link aggregation and I think those two things are mutually exclusive. If I’m totally off my rocker here I apologize but I hope it is helpful in some way. Once 802.3ad gets working it is pretty darned awesome and helpful so I wish you luck, just remember you need full cooperation on both sides of the link so don’t neglect your switch configuration as well.