Configure Reliable Ethernet Failover with SLES 15 Bonding

If a SUSE Linux Enterprise Server 15 host has two Ethernet adapters but loses network access when one cable fails, configure a bond0 interface in YaST, add both adapters, and select active-backup with miimon=100. Put the server's IP configuration on the bond rather than on either physical port. This provides link redundancy without requiring an LACP-enabled switch.

The steps below use the Wicked networking service normally used for SLES server workloads. Changing the interface that carries an SSH session can disconnect you, so perform the change from a local console, remote management console, or an approved maintenance window with a recovery path.

Check the adapters and choose the correct bonding mode

Two available network cards do not automatically form a failover pair. Without bonding, each interface is managed separately, and an application using one route may lose connectivity when its link goes down. A Linux bond presents several physical ports as one logical interface.

Before making changes, identify the real interface names, record the host's current IPv4/IPv6 addresses, gateway, VLAN, and DNS settings, and confirm that both switch ports reach the intended network:

ip -br link
ip -br addr
ip route
systemctl status network

In the example screens, the two physical interfaces are enp1s0 and enp2s0. These names are illustrative; your server may have different names. The sample address 192.0.2.20/24 is a documentation-only address, not a value to deploy on your network.

Use active-backup (mode 1) when the goal is to preserve service during a port or cable failure. One port transmits while the other remains available for failover. Choose 802.3ad (LACP, mode 4) only when the network switch is explicitly configured for a matching LACP aggregation group, with compatible speed and duplex settings. LACP can distribute different traffic flows across links, but does not promise double the speed of one connection. SUSE cautions against spanning ordinary bonds across multiple switches unless the switch vendor supports the arrangement. See the SUSE network bonding procedures and restrictions.

Configure bond0 in YaST

  1. 1. Open Network Settings and identify the available ports

    Run sudo yast2 or open YaST locally, then go to System > Network Settings. In the Overview tab, identify both Ethernet interfaces you intend to combine. If one interface currently holds the server's management address, arrange console access before changing its configuration. Do not choose a wireless interface or an interface already dedicated to an unrelated bridge without planning that topology first.

    YaST Network Settings overview showing two Ethernet adapters enp1s0 and enp2s0 and the Add button
    The Network Settings overview identifies enp1s0 and enp2s0 before creating a bonded device.
  2. 2. Create a bonding interface

    Click Add, change Device Type to Bonding, and click Next. YaST opens the network card setup for the new logical bond. Do not try to make both physical adapters independently own the same static address.

    YaST Add New Network Card window with Bonding selected in the Device Type menu
    The Add New Network Card view shows Bonding selected as the new device type.
  3. 3. Assign the bond's IP settings

    On the Address tab, choose Dynamic Address if your infrastructure supplies an appropriate DHCP lease, or Statically Assigned IP Address for a server with a fixed address. In a static deployment, move the previous management address and subnet to the bond and ensure the old physical interface does not retain a duplicate IP. Confirm the default gateway on the Routing tab and DNS under Hostname/DNS as appropriate; do not assume static addressing populates them automatically.

    YaST Network Card Setup Address tab showing static address 192.0.2.20 and subnet mask 255.255.255.0
    The Address tab shows an example static IP and subnet mask assigned to the bond, not its members.
  4. 4. Select both ports, keep link monitoring, and apply

    Open Bond Ports and check the two intended adapters. In Bond Driver Options, select active-backup for simple redundancy and keep miimon=100. This checks member-link state at a 100-millisecond interval; it is not a guarantee that all upstream failures will be detected. Select Next, accept any prompt to adapt the old individual-interface configuration by choosing Continue, and click OK to commit the new bond. You may briefly lose access while the IP moves to bond0.

    YaST Network Card Setup Bond Ports tab with both adapters selected and active-backup link monitoring at 100 milliseconds
    Both Ethernet ports are selected, with active-backup bonding and a 100-millisecond MII monitoring interval.

These screen views focus on the controls described in SUSE's SLES 15 SP7 YaST bonding instructions; the exact layout or wording can vary with the installed YaST version and graphical or text interface.

Use ifcfg files if YaST is unavailable

Manual configuration is a fallback for administrators who cannot use YaST. SUSE documents the /etc/sysconfig/network/ifcfg-* format for Wicked-managed hosts. Back up the original network files outside the live /etc/sysconfig/network directory and retain console access before proceeding:

sudo mkdir -p /root/network-bond-backup
sudo cp -a /etc/sysconfig/network/ifcfg-enp1s0 /root/network-bond-backup/
sudo cp -a /etc/sysconfig/network/ifcfg-enp2s0 /root/network-bond-backup/

If a named source file is absent, inspect the directory and back up the actual file instead of assuming the name. For this illustrative static-IP configuration, create /etc/sysconfig/network/ifcfg-bond0 with the following contents, replacing the interface names and address with your real values:

STARTMODE='auto'
BOOTPROTO='static'
IPADDR='192.0.2.20/24'
BONDING_MASTER='yes'
BONDING_SLAVE0='enp1s0'
BONDING_SLAVE1='enp2s0'
BONDING_MODULE_OPTS='mode=active-backup miimon=100'

Each member's ifcfg file must no longer have its own IP configuration. For example, place only these lines in both ifcfg-enp1s0 and ifcfg-enp2s0:

BOOTPROTO='none'
STARTMODE='hotplug'

Keep any necessary system-wide route and resolver configuration consistent with the new bond. Inspect the configuration and bring up the logical interface with Wicked:

sudo wicked show-config
sudo wicked ifup all bond0

Use sudo wicked ifreload bond0 after later edits to the running bond. Do not use systemctl to start or stop an individual bonded device; SUSE specifies wicked for that task. For supported file parameters, consult the SUSE manual bond configuration reference and the locally installed man 5 ifcfg-bonding page.

Troubleshoot a bond that does not come online

The bond exists but has no IP address: Check that the address was assigned to bond0, not to a member, and confirm the DHCP server or static address settings. A missing gateway or incorrect VLAN can make the server unreachable even when both ports report carrier. Inspect ip route and your actual switch-port configuration before repeatedly restarting the network.

The bond reports a down member: Check cable, switch-port status, interface selection, and driver messages. Ensure the member names in BONDING_SLAVE0 and BONDING_SLAVE1 match ip -br link. Link monitoring detects relevant interface/carrier changes, but not every possible failure beyond the directly connected switch.

Traffic fails after switching to 802.3ad: Confirm the switch's LACP group and port settings first. A bond set to LACP while its switch ports remain ordinary independent ports is a configuration mismatch. If the purpose is simply failover, return to active-backup rather than introducing switch aggregation unnecessarily.

Verify the configuration and test failover

Check the live bond, its member interfaces, and routing:

sudo wicked ifstatus --verbose bond0
ip -br addr show bond0
ip route
cat /proc/net/bonding/bond0

The bond should have the intended IP address, its link should be up, and the kernel status file should list both member interfaces. In active-backup mode, check the Currently Active Slave field and each member's MII Status. The exact output depends on your driver and configuration; the Linux kernel bonding documentation describes this status interface.

Finally, confirm connectivity to the real default gateway and the service clients that must reach the host. During an approved maintenance window, briefly disconnect or disable only the currently active link while watching the bond status and a continuous connectivity test; the standby member should take over and connectivity should recover. Restore the link afterward and confirm both members show a healthy state. If the network remains unreachable, use your console access to restore the backed-up member configurations rather than making additional blind changes over SSH.

Leave a Comment

Configure Reliable Ethernet Failover with SLES 15 Bonding

Configure Reliable Ethernet Failover with SLES 15 Bonding

Create a redundant Ethernet connection on SLES 15 with YaST and Wicked, configure active-backup bonding, and verify both ports and failover.

Build a Reusable AutoYaST Profile for SLES 15 Installs

Build a Reusable AutoYaST Profile for SLES 15 Installs

Turn an existing SLES 15 system into a reviewed AutoYaST profile, validate it, and use it to deploy a test server with fewer manual steps.

SLES 15 KVM Setup: Make Selected VMs Start at Boot

SLES 15 KVM Setup: Make Selected VMs Start at Boot

Install the SLES 15 KVM and libvirt tools, enable the right host service, and configure selected virtual machines to start after a reboot.

Diagnose a SUSE Server That Hangs at the systemd Shutdown Screen

Diagnose a SUSE Server That Hangs at the systemd Shutdown Screen

Use systemd jobs and the previous boot journal to locate a slow service, mount, or storage dependency, then correct it without masking the cause.

Open Only the Web Traffic Your SLES 15 Server Needs

Open Only the Web Traffic Your SLES 15 Server Needs

Use firewall-cmd to inspect the active zone, allow HTTP safely, preserve SSH access, and verify that the rule survives a reload on SLES 15.

Diagnose SLES PAM Login Failures Without Locking Yourself Out

Diagnose SLES PAM Login Failures Without Locking Yourself Out

Trace a PAM failure to its service, account policy, or identity provider, then repair the right SLES configuration while preserving a working admin session.

SLES Boot Module Load Failure: Find the Driver and Fix It

SLES Boot Module Load Failure: Find the Driver and Fix It

Trace a failed kernel module at SLES startup, correct an obsolete boot entry or repair the required driver, and verify the next boot.

Set Up DM-Multipath on SLES 15 for Reliable SAN Paths

Set Up DM-Multipath on SLES 15 for Reliable SAN Paths

Prepare SCSI SAN paths, enable multipathd, inspect SUSE’s hardware defaults, and verify stable device maps without guessing array settings.

Clear a Zypper Lock Safely on SUSE Linux Enterprise

Clear a Zypper Lock Safely on SUSE Linux Enterprise

Find the process holding Zypper’s package lock, distinguish process conflicts from package locks, and retry updates without deleting lock files blindly.

Build a Supported SLES 15 HA Cluster with Fencing First

Build a Supported SLES 15 HA Cluster with Fencing First

Register SLE HA, bootstrap SLES 15 nodes, then add fencing, quorum, and tested service resources before relying on failover.