Cómo implementar multihoming y failover con Proxmox, OVS y SDN

Problema

En entornos con varios servidores Proxmox es frecuente disponer de enlaces de distinta velocidad (1 GbE y 10 GbE) y de diferentes topologías (VLAN de gestión, enlaces agregados, enlaces dedicados a almacenamiento). El objetivo es:

1. Mantener conectividad de gestión independiente del tráfico de datos.
2. Usar enlaces LACP para agregación de ancho de banda y redundancia.
3. Permitir que los nodos sin 10 GbE sigan operando sin forzar todo el tráfico por los puertos de 10 GbE.
4. Implementar failover automático cuando un enlace o un nodo falla, sin perder conectividad de clúster ni de máquinas virtuales.
5. Aprovechar la capa de SDN de Proxmox para segmentar subredes sin crear una red física compleja.

Cuando se combina Open vSwitch (OVS) con la pila SDN de Proxmox, aparecen limitaciones: OVS no admite “bond stacking” (un bond dentro de otro bond) y algunos drivers (p. ej. i40e) no soportan RSTP. La solución debe funcionar con cualquier NIC que tenga soporte de Linux y permitir que los enlaces de 1 GbE y 10 GbE se utilicen de forma independiente según la carga.

Causa

1. Bonding limitado en OVS – OVS permite crear un bond (LACP, active‑backup, balance‑slb) pero no admite un bond que contenga otro bond. Cuando se intenta combinar varios grupos LACP en una única entidad de failover, OVS descarta la configuración o la deja en modo “fallback”, lo que rompe la redundancia esperada.

2. Falta de STP/RSTP en algunos drivers – Los controladores i40e, ixgbe y otros pueden no exponer los hooks de STP a OVS, impidiendo que OVS participe en la topología de árbol de expansión. Sin STP, los bucles de capa 2 pueden generar tormentas y bloquear puertos.

3. Diseño de red monolítica – Usar un único puente Linux o OVS para todos los tipos de tráfico obliga a que todo pase por los enlaces más rápidos, incluso cuando la carga es mínima. Los nodos sin 10 GbE terminan enviando tráfico de gestión y VM por los enlaces de 1 GbE que están agregados a un bond de 10 GbE, saturando la uplink.

4. SDN sin segmentación adecuada – La capa SDN de Proxmox necesita una red subyacente que ya esté preparada para VLAN o VXLAN. Si la red física no está segmentada, los flujos SDN compiten con el tráfico de gestión y pueden provocar colisiones.

Solución

1. Separar dominios de tráfico con puentes independientes

Crear tres puentes OVS:

Los puentes no se anidan; cada uno se conecta a su propio bond o NIC física. De esta forma, el tráfico de gestión nunca compite con el de datos.

2. Usar bond activo‑backup para failover entre grupos LACP

OVS permite un modo de bonding llamado active‑backup donde cada “member” es a su vez un bond LACP. La configuración queda:

# Bond LACP de 1 GbE (3 NICs)
ovs-vsctl add-bond br-data bond1g eth0 eth1 eth2 \
    other_config:lacp=active other_config:bond_mode=balance-tcp

# Bond LACP de 10 GbE (2 NICs)
ovs-vsctl add-bond br-data bond10g eth3 eth4 \
    other_config:lacp=active other_config:bond_mode=balance-tcp

# Bond activo‑backup que alterna entre los dos grupos
ovs-vsctl add-bond br-data bond-failover bond1g bond10g \
    other_config:bond_mode=active-backup other_config:fail_over_mac=1

bond-failover actúa como punto de unión para las VM. Si todo el grupo bond10g desaparece (corte de la uplink 10 GbE), OVS cambia automáticamente a bond1g. El tráfico no se “carga” en los 10 GbE cuando no hay necesidad, porque la política de balance‑tcp distribuye los flujos según la tabla de hash; los flujos de bajo ancho de banda permanecen en los enlaces de 1 GbE.

3. Habilitar RSTP con Linux bridge como fallback (solo si el driver no lo soporta)

Cuando el driver no expone RSTP a OVS, se puede colocar un Linux bridge delante del OVS y usar STP allí. El bridge solo actúa como “guardia” contra bucles y no interfiere con el bonding OVS.

brctl addbr br-stp
brctl addif br-stp eth5   # puerto conectado al switch principal
brctl stp br-stp on
brctl setbridgeprio br-stp 32768

Conecta br-stp al puerto del switch que lleva la VLAN de gestión y a br-mgmt mediante una interfaz veth:

ip link add veth0 type veth peer name veth1
brctl addif br-stp veth0
ovs-vsctl add-port br-mgmt veth1

Esta capa mínima de STP protege contra bucles sin sacrificar la capacidad de OVS para el tráfico de datos.

4. Configurar SDN de Proxmox sobre una red VLAN existente

Proxmox SDN no obliga a que el nodo administre IPs. Basta con crear un SDN zone que apunte a la VLAN ya configurada en el switch. En la UI de Proxmox:

1. Datacenter → SDN → Zones → Add → Tipo VLAN.
2. Asigna el ID de VLAN (p. ej. 200) y selecciona br-sdn como interfaz.
3. Crea un Subnet dentro de la zona con el rango que necesites (p. ej. 10.10.200.0/24).
4. Asocia la zona a los contenedores/VM que requieran esa red.

El router externo sigue gestionando la puerta de enlace; Proxmox solo entrega la VLAN a los invitados.

5. Automatizar con pveproxy y qm/pct

Para que cada VM use la red adecuada, define la interfaz en la configuración de la VM:

qm set 101 -net0 virtio,bridge=br-data
qm set 102 -net0 virtio,bridge=br-sdn

Los contenedores (pct) siguen la misma lógica con -net0.

Cuándo aplicar esta solución

• Entornos híbridos con nodos que poseen tanto 1 GbE como 10 GbE y donde la disponibilidad es crítica.
• Clusters Proxmox que requieren balanceo de carga entre enlaces y failover sin sacrificar ancho de banda.
• Infraestructuras que usan OVS pero tienen drivers que no soportan RSTP; la combinación bridge + OVS brinda seguridad contra bucles.
• Implementaciones SDN donde la segmentación física ya existe (VLAN, VXLAN) y solo se necesita una capa lógica para los contenedores/VM.

No es recomendable cuando:

• Todos los nodos disponen exclusivamente de enlaces de la misma velocidad y no hay necesidad de segmentación SDN.
• El hardware de red es antiguo y no soporta LACP; en ese caso, usar solo active‑backup sin LACP.

Código

# 1. Crear bridges OVS
ovs-vsctl add-br br-mgmt
ovs-vsctl add-br br-data
ovs-vsctl add-br br-sdn

# 2. Bond LACP 1 GbE
ovs-vsctl add-bond br-data bond1g eth0 eth1 eth2 \
    other_config:lacp=active other_config:bond_mode=balance-tcp

# 3. Bond LACP 10 GbE
ovs-vsctl add-bond br-data bond10g eth3 eth4 \
    other_config:lacp=active other_config:bond_mode=balance-tcp

# 4. Bond activo‑backup para failover
ovs-vsctl add-bond br-data bond-failover bond1g bond10g \
    other_config:bond_mode=active-backup other_config:fail_over_mac=1

# 5. Bridge para STP (solo si necesario)
brctl addbr br-stp
brctl addif br-stp eth5
brctl stp br-stp on
ip link set dev br-stp up

# 6. Veth para conectar bridge y OVS (gestión)
ip link add veth0 type veth peer name veth1
brctl addif br-stp veth0
ovs-vsctl add-port br-mgmt veth1
ip link set dev veth0 up
ip link set dev veth1 up

Verificación

1. Estado de los bonds

   ovs-appctl bond/show bond-failover
   

   Debe mostrar bond1g como active y bond10g como backup (o viceversa según la disponibilidad).

2. Comprobación de LACP

   cat /proc/net/bonding/bond1g
   cat /proc/net/bonding/bond10g
   

   Verifica que todos los miembros estén en estado UP y que Aggregator ID coincida con el switch.

3. Prueba de failover
   Desconecta físicamente uno de los puertos 10 GbE y observa que el tráfico sigue fluyendo sin interrupciones (ovs-vsctl list Interface bond-failover mostrará el nuevo active).

4. SDN connectivity
   Desde una VM en br-sdn, haz ping a la puerta de enlace de la VLAN configurada. Si responde, la zona