Problema

En entornos de virtualización con Proxmox, los administradores suelen disponer de servidores con múltiples interfaces de red: algunas de 1 Gb para gestión y otras de 10 Gb para tráfico de máquinas virtuales (VMs) o para la comunicación del clúster. El reto consiste en conectar de forma eficiente todas esas NICs a un switch de 10 Gb, garantizando que:

  • El tráfico de gestión no compita con el de las VMs.
  • El clúster de Proxmox pueda usar la red de alta velocidad para replicación y HA.
  • Los dispositivos de almacenamiento (por ejemplo, un Synology) puedan seguir operando sin crear cuellos de botella.

El problema se vuelve crítico cuando se añaden nodos con diferentes generaciones de hardware (Dell R640, HP DL360 Gen9/Gen10) y cuando se planea escalar a varios nodos y VMs de bajo consumo, pero con requisitos de ancho de banda razonables.

Causa

  1. Falta de segmentación de tráfico – Usar la misma interfaz para gestión, VM y clúster genera congestión y dificulta la identificación de fallos.
  2. Incompatibilidad de transceptores – Los servidores pueden tener SFP+ mientras el switch solo ofrece RJ45 10 Gb o viceversa, obligando a usar adaptadores que no siempre son compatibles.
  3. Configuración de bonding o VLAN incompleta – Sin LACP o sin VLANs bien definidas, el tráfico no se distribuye de forma balanceada y la redundancia se pierde.
  4. Alimentación insuficiente del switch – Un switch de 10 Gb con pocos puertos SFP+ puede requerir módulos de fibra o DAC que no se han provisionado.
  5. Ignorar la separación de tráfico de almacenamiento – Con un Synology de 1 Gb, el backup puede saturar la red de gestión si no se aísla.

Solución

1. Arquitectura de red recomendada

Segmento NIC recomendada Tipo de conexión Comentario
Gestión 1 Gb Ethernet RJ45 Conecta a cualquier puerto del switch de 1 Gb o a un puerto dedicado del switch 10 Gb (modo 1 Gb).
Tráfico de VMs 10 Gb SFP+ / RJ45 SFP+ (DAC o fibra) o RJ45 10 Gb Usa un bridge en Proxmox (vmbr0) sin VLANs para exponer la red a las VMs.
Clustering / Replicación 10 Gb (puede ser la misma que VMs) SFP+ Configura una VLAN separada (ej. VLAN 100) para el tráfico del clúster.
Backups (Veeam → Synology) 1 Gb Ethernet RJ45 Mantén este tráfico en la red de gestión o crea una VLAN dedicada (ej. VLAN 200).

2. Selección de hardware

  • NICs – En los HP DL360, instala tarjetas Intel X710 o Broadcom 5719 de 10 Gb SFP+. Son compatibles con SR‑IOV y ofrecen buen rendimiento en Proxmox.
  • Transceptores – Si el switch Unifi tiene puertos SFP+, usa cables DAC de 10 Gb (Direct Attach Copper) para distancias <7 m. Para mayores distancias, emplea módulos SFP+ LR y fibra multimodo.
  • Switch – Unifi Switch 10 Gb con al menos 2 puertos SFP+ y 2 puertos RJ45 10 Gb permite mezclar ambos tipos de conexión y reservar puertos 1 Gb para gestión.

3. Configuración de Proxmox

  1. Crear bridges

    • vmbr0 (10 Gb, sin VLAN) para VMs.
    • vmbr1 (10 Gb, VLAN 100) para clúster.
    • vmbr2 (1 Gb) para gestión.

  2. Activar VLANs en el switch para los IDs 100 (clúster) y 200 (backups). Asigna puertos de uplink a los servidores y marca los puertos del Synology como miembros de VLAN 200.

  3. Bonding opcional – Si cada nodo tiene dos NICs de 10 Gb, configura LACP (mode 4) para crear un bond0 y úsalo como base del bridge. Esto duplica ancho de banda y aporta redundancia.

4. Implementación paso a paso

a) Configuración del switch

  • En la interfaz web del Unifi, crea las VLAN 100 y 200.
  • Asigna los puertos SFP+ a “Trunk” y permite ambas VLANs.
  • Marca los puertos RJ45 1 Gb como “Access” en VLAN 200 para el Synology.

b) Configuración de NICs en los nodos HP

# Instalar drivers (si no están incluidos)
apt-get update && apt-get install -y firmware-misc-nonfree

# Verificar que la NIC aparece como 10Gb
ip -brief link show | grep -i eth

# Crear bonding (opcional)
cat > /etc/network/interfaces.d/bond0.cfg <<EOF
auto bond0
iface bond0 inet manual
    bond-slaves eth0 eth1
    bond-mode 802.3ad
    bond-miimon 100
    bond-xmit_hash_policy layer3+4
EOF

# Bridge para VMs
cat > /etc/network/interfaces.d/vmbr0.cfg <<EOF
auto vmbr0
iface vmbr0 inet static
    address 10.0.10.1/24
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
EOF

# Bridge para clúster (VLAN 100)
cat > /etc/network/interfaces.d/vmbr1.cfg <<EOF
auto vmbr1
iface vmbr1 inet static
    address 10.0.100.1/24
    bridge-ports bond0
    bridge-vlan-aware yes
    bridge-vids 100
    bridge-stp off
    bridge-fd 0
EOF

# Bridge de gestión (1Gb)
cat > /etc/network/interfaces.d/vmbr2.cfg <<EOF
auto vmbr2
iface vmbr2 inet static
    address 192.168.1.10/24
    bridge-ports eth2
    bridge-stp off
    bridge-fd 0
EOF

systemctl restart networking

c) Configurar Proxmox Cluster

pvecm create mycluster
pvecm add 10.0.100.2   # IP del segundo nodo en la VLAN 100
pvecm add 10.0.100.3   # IP del tercer nodo

d) Asignar red a VMs

En la UI de Proxmox, selecciona vmbr0 como puente de red para cada VM. Si una VM necesita acceso al clúster interno, habilita la VLAN 100 dentro de la VM (por ejemplo, usando una interfaz eth0.100).

5. Buenas prácticas

  • Separar tráfico de backup – Usa VLAN 200 y limita el ancho de banda con QoS en el switch para que los backups no saturen la red de gestión.
  • Monitorizar uso de ancho de banda – Herramientas como iftop o el propio panel de Unifi permiten detectar cuellos de botella rápidamente.
  • Mantener firmware actualizado – NICs de 10 Gb y switches a menudo reciben mejoras de estabilidad que evitan pérdidas de paquetes bajo carga.

Cuándo aplicar esta solución

  • Entornos con 2‑3 nodos Proxmox que requieren alta velocidad entre VMs y clúster.
  • Presencia de al menos un switch 10 Gb con puertos SFP+ o RJ45 10 Gb.
  • Necesidad de separar tráfico de gestión, VM y backup para evitar interferencias.
  • Escenarios donde el número de VMs es bajo (≤10) pero el rendimiento de red es crítico (bases de datos, replicación, backups frecuentes).

No aplicar si:

  • Solo se dispone de conexiones 1 Gb y el presupuesto no permite NICs o transceptores de 10 Gb.
  • El tráfico de VMs es extremadamente bajo y la complejidad de VLANs no justifica el beneficio.

Código

# Verificar que la NIC de 10Gb está operativa
ethtool -i eth0 | grep driver

# Probar rendimiento con iperf3 entre dos nodos
iperf3 -s -B 10.0.10.2 &
iperf3 -c 10.0.10.1 -P 4 -t 30

Verificación

  1. Conectividad – ping -c 3 10.0.10.X desde cada nodo a los demás usando la IP del bridge vmbr0.
  2. Latencia y throughput – Ejecuta iperf3 como se muestra arriba; valores cercanos a 9 Gbps indican que la ruta está libre de cuellos.
  3. Estado del clúster – pvecm status debe listar todos los nodos con “Online”.
  4. VLANs – En el switch, verifica que los puertos muestran tráfico etiquetado 100 y 200 según corresponda (show vlan).
  5. Backups – Inicia un job de Veeam y observa que el tráfico aparece en la VLAN 200 (puedes usar tcpdump -i vmbr2 vlan 200).

Notas adicionales

  • SR‑IOV puede mejorar aún más el rendimiento de VMs con carga de red intensiva; sin embargo, requiere que la BIOS del servidor lo habilite y que el hipervisor lo exponga.
  • Si el switch no soporta LACP, el bonding debe configurarse en modo balance‑rr; el rendimiento será menor pero sigue proporcionando redundancia.
  • En entornos con varios racks