Rocky 10: tested bond failover and VLAN tagging

Test scope

In a Rocky Linux 10.2 VM (kernel 6.12.0-211.16.1.el10_2): three virtio NICs (ens18 management, ens19/ens20 on two isolated bridges), an active-backup bond built with ip link, the active slave read from /proc/net/bonding, a link brought down to prove failover, and an 802.1Q VLAN on the bond. Log: plans/content-expansion/evidence/logs/rocky-bonding-vlan.log.

No real switch: LACP (802.3ad) and switch trunk configuration were not tested and are labelled as such.

Why a VM can prove failover

Container “NICs” are dummy devices or shared host networking: ip link builds a bond but link state is fake. virtio NICs in a VM have real carrier, so bringing one down makes the kernel bonding driver genuinely detect link loss and switch.

The difference from bare metal is the switch side: a VM has no peer switch, so LACP cannot negotiate. active-backup does not need the switch, which is why it can be fully tested.

Build the bond from real NICs

sudo nmcli device set ens19 managed no
sudo nmcli device set ens20 managed no
sudo ip link add bond0 type bond mode active-backup miimon 100
sudo ip link set ens19 down && sudo ip link set ens20 down
sudo ip link set ens19 master bond0
sudo ip link set ens20 master bond0
sudo ip link set ens19 up && sudo ip link set ens20 up
sudo ip link set bond0 up
cat /proc/net/bonding/bond0 | head -6

Ethernet Channel Bonding Driver: v6.12.0-211.16.1.el10_2.0.1.x86_64
Bonding Mode: fault-tolerance (active-backup)
Currently Active Slave: ens19
MII Status: up
MII Polling Interval (ms): 100

Slaves are brought down before master to keep NetworkManager from claiming them mid-transition; nmcli device set ... managed no removes both NICs from NM control.

Failover: read what the kernel says

sudo ip link set ens19 down
sleep 3
grep -E "Currently Active Slave|MII Status" /proc/net/bonding/bond0

bond0: (slave ens19): link status definitely down, disabling slave
bond0: (slave ens20): making interface the new active one
Currently Active Slave: ens20
MII Status: up

Those two kernel lines are the proof. Bringing ens19 back up does not fail back — active-backup keeps the current slave unless primary= is set or you switch manually.

Tag 802.1Q on the bond

sudo ip link add link bond0 name bond0.100 type vlan id 100
ip -d link show bond0.100 | head -2

bond0.100@bond0: <BROADCAST,MULTICAST> ... state DOWN ...
    vlan protocol 802.1Q id 100 <REORDER_HDR>

A new VLAN interface starts DOWN; ip link set bond0.100 up is required before it carries traffic.

A real incident: two bond ports on one bridge form a loop

During testing both vNICs were attached to the same vmbr2 before bonding — the VM immediately became unreachable. Two ports in the same L2 domain create a loop: the bond’s broadcasts leave one port and return through the other, producing a broadcast storm.

Correct design: bond ports must reach different bridges/switches (or an LACP port group on one switch). That is why ens19/ens20 sit on two isolated bridges here.

Equivalent nmcli configuration (not run step by step)

sudo nmcli con add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=100"
sudo nmcli con add type ethernet con-name bond0-p1 ifname ens19 master bond0
sudo nmcli con add type ethernet con-name bond0-p2 ifname ens20 master bond0
sudo nmcli con up bond0

This page uses ip link to isolate kernel behaviour; production should persist the configuration with nmcli or configuration management.

Switch-side requirements

Mode	Switch
active-backup	Nothing; both ports in the same VLAN
802.3ad (LACP)	LACP port group, matching rate/period on both ends
balance-alb	Usually nothing, relies on ARP

VLAN side: the switch port must be a trunk allowing the VLAN ID.

Playable failover recording

The recording below comes from the Rocky Linux 10.2 VM and shows the full order of events — build the bond, read the active slave, take a link down, switch, bring it back (the .cast is 857 bytes and never autoplays):

bond active-backup failover (Rocky Linux 10.2) ▶ 播放终端演示 / Play

文字版（命令与输出） / Text transcript

# 1. create active-backup bond over two vNICs
nmcli device set ens19 managed no; nmcli device set ens20 managed no
ip link add bond0 type bond mode active-backup miimon 100
ip link set ens19 master bond0; ip link set ens20 master bond0
ip link set bond0 up

# 2. active slave and MII status
Bonding Mode: fault-tolerance (active-backup)
Currently Active Slave: ens19
MII Status: up

# 3. failover: take the active link down
ip link set ens19 down
Currently Active Slave: ens20
MII Status: up

# 4. bring it back (no automatic failback)
ip link set ens19 up
Currently Active Slave: ens20

Commands and output are real; the player loads on demand, so asciinema-player is not fetched until you click play.

Common traps

• Both ports on the same bridge/switch: loop, broadcast storm, host unreachable;
• Mixing NM and ip link: NM reclaims slaves; run nmcli device set ... managed no first;
• VLAN created but not up: the interface exists but carries nothing;
• LACP only on the host: the link never comes up.

Practice: bond, fail over, tag a VLAN

sudo ip link add bond0 type bond mode active-backup miimon 100
sudo ip link set ens19 master bond0 && sudo ip link set ens20 master bond0
sudo ip link set bond0 up
grep "Active Slave" /proc/net/bonding/bond0
sudo ip link set ens19 down && sleep 3
grep -E "Active Slave|MII Status" /proc/net/bonding/bond0
sudo ip link add link bond0 name bond0.100 type vlan id 100
ip -d link show bond0.100 | grep 802.1Q

Checks:

1. Active slave is ens19 before the down and ens20 after
2. MII Status stays up
3. dmesg contains making interface the new active one
4. The VLAN interface shows 802.1Q id 100

FAQ

常见问题

Does active-backup fail back automatically?

No, by default the current slave stays active after the original link returns; configure primary= or switch manually during a maintenance window.

Can both bond ports connect to the same switch?

active-backup can, but never attach both to the same bridge (a loop); 802.3ad needs an LACP port group with matching parameters on both ends.

Why use ip link instead of nmcli in the test?

ip link verifies kernel bonding behaviour without NM interference; production should persist the setup with nmcli or configuration management so it survives reboots.

Next steps

• Network triage: Triage network problems by symptom
• Static IP: nmcli static IP
• Firewall: firewalld rich rules