LACP Bond on Switches With No Port-Channel, Plus an Untagged VLAN
A three-node AHV cluster was built by a network team that wanted maximum throughput. Each host has two 10 GbE interfaces, one cabled to ToR-A and one to ToR-B; the two switches are standalone with no MLAG or stacking. The bond was configured as balance-tcp (LACP 802.3ad). After the hosts were rebooted during patching, all three CVMs became unreachable and every VM lost network connectivity. The team also reports that VMs placed on VLAN 220 cannot reach their gateway, even on the one node that came back partially.
1. Explain why the cluster lost connectivity after the reboot and which bond mode you would move to.
Read the worked answer
balance-tcp relies on LACP negotiation with a port-channel on the switch side. With ToR-A and ToR-B standalone and no LAG configured, the switches never form the LACP bundle, so the OVS bond has no usable active path and br0 - the bridge that carries CVM and VM traffic - goes down. The reboot is only the trigger; the misconfiguration was latent.
Given one uplink per switch and no MLAG, the correct choices are active-backup or balance-slb:
- active-backup: one link carries all traffic, the other is standby. Simple, works with any switch config, survives a switch failure.
- balance-slb: both links active, hashing per source MAC/VLAN flow, no switch-side LAG needed. Better utilization with the same cabling, but a single VM flow still uses one uplink.
Either is valid; balance-slb is the usual pick when the customer paid for two 10 GbE links. Change the bond mode from Prism with the hosts placed in maintenance mode first, and verify the CVMs are reachable on all three nodes before returning to service.
2. VLAN 220 still fails. Walk through the checks in the order you would perform them.
Read the worked answer
Verify the VLAN exists and is assigned on the VM NIC in Prism Element (VM > NIC > VLAN 220), not left as untagged. A VM NIC with no VLAN sends untagged frames, which the upstream gateway drops if it expects a tagged subinterface.
Check whether the guest is also tagging. If the VM NIC is set to trunked and the guest OS sends 802.1Q frames for VLAN 220, you get double tagging. Choose exactly one tagging model.
Confirm both switch ports carry VLAN 220 as a trunk (with balance-slb/active-backup, every uplink must trunk all VM VLANs, because any flow can egress either port). A port left as an access port for a single native VLAN will pass that VLAN and drop the rest.
On the host, inspect the bridge and bond with ovs-vsctl show to confirm br0 carries the bond and the VLAN is permitted, and check for a misconfigured uplink that is administratively down.
Only after 1-3 are clean does it make sense to look at guest-side routing or the physical switch ARP table. Most incidents like this end at step 1 or 3.
3. What would you tell the customer about resilience with this cabling, so they do not repeat the mistake at the next cluster?
Read the worked answer
With one link to each of two standalone switches, the cluster can lose a link, a NIC, or an entire switch and stay up - provided the bond mode does not require switch-side negotiation. That is the correct design for this cabling. What is not available is link aggregation beyond 10 GbE per host and per flow, and there is no way to get it without MLAG or stacked switches.
If they want more than 10 GbE per host, the conversation is about switch architecture first (MLAG/VPC/stacking) and LACP second. Recommend documenting the bond mode and the VLAN trunk list alongside the cluster build sheet, and adding it to the change template so patching does not silently rewrite the bond. For a future cluster, also push back on mixing balance-tcp with standalone ToRs, since that combination looks like redundancy on paper and is a single point of failure in practice.