Networking en Proxmox VE 9: buenas prácticas, VLANs, jumbo frames y los errores que todos cometen

La red de un Proxmox parece trivial hasta el día que deja de serlo. Instalas el nodo, aceptas el vmbr0 que te propone el instalador, arrancas cuatro VMs y todo funciona. El problema llega después: cuando metes VLANs, cuando quieres agregar dos enlaces de 10 GbE, cuando activas jumbo frames «porque el NAS los soporta» y de repente las copias fallan a medias sin un solo error visible. La red de virtualización no da errores educados: da timeouts, cortes intermitentes y paquetes que se pierden en silencio. Y casi siempre la causa es una decisión de red tomada a la ligera el primer día.

Este artículo es la guía de networking que me habría ahorrado más de una guardia. Repasamos el modelo de red de Proxmox VE 9, cuándo usar un bridge VLAN-aware y cuándo no, cómo montar bonding sin pelearte con el switch, cómo activar MTU 9000 en toda la cadena para que no se rompa por detrás, qué pinta el SDN nuevo y las trampas concretas que se cobran su peaje en producción. Si acabas de instalar el nodo, quizá te interese repasar antes cómo instalar Proxmox VE en un mini PC y las buenas prácticas de almacenamiento, porque la red de almacenamiento y la de gestión se diseñan juntas o se sufren por separado.

El modelo de red de Proxmox: el Linux bridge manda

Proxmox VE no inventa nada raro en la capa de red: usa el Linux bridge del kernel, el mismo que lleva Debian desde hace lustros. Un bridge (vmbr0, vmbr1...) es un switch virtual en software. Le enchufas por un lado la NIC física del host y por otro las interfaces virtuales de las VMs y contenedores, y él conmuta tramas entre ellos como haría un switch de sobremesa. Ese es todo el secreto del modelo por defecto, y por eso es tan sólido: es tecnología del kernel probada durante veinte años.

Toda la configuración de red del host vive en un único fichero de texto plano, /etc/network/interfaces, gestionado por ifupdown2 (el paquete por defecto en instalaciones nuevas desde Proxmox VE 7.0, y por supuesto en la 9). Un nodo recién instalado con una sola tarjeta tiene una pinta parecida a esta:

# /etc/network/interfaces de un nodo Proxmox 9 recién instalado
auto lo
iface lo inet loopback

# La NIC física NO lleva IP: solo entra en el bridge
iface enp3s0 inet manual

# El bridge es quien tiene la IP de gestión del host
auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports enp3s0
    bridge-stp off
    bridge-fd 0

Fíjate en el detalle que descoloca a los recién llegados: la IP del host no está en la NIC física, está en el bridge. La interfaz enp3s0 está en modo manual, sin dirección, y solo actúa como puerto de subida (uplink) del switch virtual. Esto es deliberado y correcto: permite que el host y las VMs compartan el mismo enlace físico sin conflictos.

La gran ventaja de ifupdown2 frente al viejo ifupdown es que puedes aplicar cambios de red sin reiniciar. Editas el fichero (o tocas la GUI, que escribe por ti) y recargas en caliente:

# Aplicar la configuración de red sin reiniciar el nodo
ifreload -a

# Comprobar el estado detallado de una interfaz o del bridge
ip -d link show vmbr0
bridge link show

Un aviso que aprendí a la mala: cuando editas la red desde la GUI, los cambios se guardan primero en /etc/network/interfaces.new y no se aplican hasta que pulsas Apply Configuration. Si editas a mano el fichero definitivo pero antes habías dejado un .new pendiente desde la interfaz, la GUI te lo puede pisar. Decide si administras la red por CLI o por GUI, pero no bailes entre las dos a la vez.

Bridge tradicional vs bridge VLAN-aware

Aquí está la primera bifurcación de diseño importante, y la que más gente resuelve mal por desconocimiento. Hay dos formas de meter VLANs en Proxmox, y elegir la equivocada te condena a un fichero de red que crece como una bola de nieve.

El modelo tradicional crea una subinterfaz por cada VLAN (enp3s0.20, enp3s0.30...) y un bridge distinto colgado de cada una (vmbr0v20, vmbr0v30...). Funciona, pero cada nueva VLAN implica dos objetos nuevos en el fichero. Con cinco VLANs es incómodo; con treinta es un infierno de mantener.

El modelo VLAN-aware es la forma moderna y la que recomiendo por defecto en cuanto haya más de un par de VLANs. Un único bridge (vmbr0) se declara consciente de VLANs con bridge-vlan-aware yes, se le indica el rango de VLANs permitidas con bridge-vids, y a partir de ahí el tag de VLAN se asigna en la NIC de cada VM, no en la infraestructura del host. El bridge se comporta como un switch gestionable de verdad: un solo puerto trunk de subida y etiquetado por puerto de acceso.

# Bridge VLAN-aware: un solo bridge para todas las VLANs
auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports enp3s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

Con esto, cuando creas o editas una VM, en la NIC virtual escribes el número de VLAN (por ejemplo, 20) y el bridge se encarga del etiquetado. Nada de subinterfaces, nada de un bridge por VLAN. Para comprobar qué VLANs están realmente activas en cada puerto del bridge:

# Ver la tabla de VLANs por puerto del bridge (tu "show vlan" de toda la vida)
bridge vlan show

Dos escenarios claros

Escenario A, despliegue sin VLANs (homelab, oficina pequeña, red plana): no compliques nada. Un vmbr0 normal, sin bridge-vlan-aware, con la NIC física como puerto y la IP de gestión encima. Todas las VMs cuelgan de ese bridge en la misma red L2. Es lo que monta el instalador y es perfectamente correcto. Activar VLAN-awareness «por si acaso» cuando no vas a usar VLANs solo añade una superficie de fallo que no necesitas.

Escenario B, despliegue con uso intensivo de VLANs (producción, multi-tenant, segmentación seria): VLAN-aware sin dudarlo, un único vmbr0 con bridge-vids 2-4094 conectado a un puerto trunk del switch físico. Cada VM lleva su tag en la NIC, la segmentación vive en el hipervisor y el switch, y el fichero de red no crece aunque tengas cuarenta redes. Este es el patrón que quieres para cualquier despliegue que vaya a durar.

VLAN tagging: de la NIC de la VM al switch físico

Conviene tener claro dónde ocurre el etiquetado, porque es la fuente número uno de «no me llega la red a la VM». Hay tres puntos en la cadena:

• La NIC de la VM. En un bridge VLAN-aware, aquí escribes el VLAN tag (el campo VLAN Tag de la interfaz de red de la VM). La trama que salga de esa VM se etiquetará con ese ID al entrar en el bridge. Sin tag, la VM va a la VLAN nativa (untagged) del bridge.
• El puerto del switch físico. El uplink del nodo tiene que estar configurado como trunk (o tagged en jerga de HP/Aruba) permitiendo todas las VLANs que uses. Si el puerto del switch está en modo access de una sola VLAN, el etiquetado del hipervisor no sirve de nada: el switch descarta lo que no entiende.
• El offload de hardware. Las NIC modernas hacen VLAN tag offloading por hardware. Normalmente esto es transparente y beneficioso, pero con drivers viejos o combinaciones concretas puede provocar que el tag se coma o se duplique. Si ves comportamientos imposibles con VLANs, mirar ethtool -k y probar a desactivar rx-vlan-offload/tx-vlan-offload es un diagnóstico rápido.

# Añadir por CLI una NIC a la VM 100 en el bridge vmbr0 con la VLAN 20
qm set 100 --net0 virtio,bridge=vmbr0,tag=20

# Ver qué offloads de VLAN tiene activados la NIC física
ethtool -k enp3s0 | grep vlan

La regla mental: la VM pone el tag, el switch tiene que esperar ese tag en un trunk, y el hardware no debería estorbar. Cuando falla la conectividad de una VM con VLAN, recorre esos tres puntos en orden antes de tocar nada más.

Bonding: agregación de enlaces sin pelearte con el switch

Un solo cable es un punto único de fallo y un techo de ancho de banda. El bonding (o link aggregation) agrupa dos o más NICs físicas en una interfaz lógica (bond0) que da redundancia, ancho de banda, o ambas cosas. En Proxmox el bond se declara en /etc/network/interfaces y luego el bridge cuelga del bond en vez de colgar de la NIC directamente.

Lo que más quebraderos de cabeza da no es el bond en sí, sino que el modo del bond y la configuración del switch tienen que estar de acuerdo. Un bond LACP contra un puerto de switch sin LACP configurado es la receta clásica del «funciona a ratos y luego se cae». Aquí están los modos que de verdad se usan:

Mi criterio de producción es corto: si el switch es gestionable y soporta LACP, usa 802.3ad. Es el estándar, negocia el estado del enlace de forma bidireccional (802.3ad detecta un cable medio muerto que un etherchannel estático no vería) y te da redundancia y balanceo. Si el switch no habla LACP, o quieres repartir las dos NICs entre dos switches distintos para sobrevivir a la muerte de uno entero (y no tienes stack MLAG), entonces active-backup: pierdes el balanceo pero ganas una tolerancia a fallos que LACP contra un solo switch no te da.

Una configuración típica de bond LACP con bridge VLAN-aware encima, que es el patrón de oro para un nodo de producción, queda así:

# Dos NICs físicas, sin IP, listas para el bond
iface enp3s0f0 inet manual
iface enp3s0f1 inet manual

# Bond LACP (802.3ad) con las dos NICs
auto bond0
iface bond0 inet manual
    bond-slaves enp3s0f0 enp3s0f1
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit-hash-policy layer3+4

# El bridge VLAN-aware cuelga del bond, no de las NICs
auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

Dos detalles que marcan la diferencia. El bond-xmit-hash-policy layer3+4 reparte el tráfico teniendo en cuenta IP y puerto, no solo la MAC; sin él, todo el tráfico entre dos mismas máquinas viaja siempre por el mismo enlace y el balanceo es ficticio. Y en el switch, el port-channel tiene que estar en LACP activo con el mismo hashing y, muy importante, con LACP fast rate o al menos coherente entre las dos puntas. Para verificar que el bond ha negociado de verdad y no está cojeando de una pata:

# Estado real del bond: mira que las dos NICs estén "up" y agregadas
cat /proc/net/bonding/bond0

# En un LACP sano verás "MII Status: up" en el bond y en cada slave,
# y "Aggregator ID" igual para ambos slaves

Jumbo frames (MTU 9000): la trampa silenciosa

Los jumbo frames (MTU de 9000 en lugar de los 1500 por defecto) reducen la sobrecarga por trama y suben el rendimiento en redes de almacenamiento y migración. La idea es buena. El problema es que un MTU inconsistente no da un error claro: rompe en silencio. Los paquetes pequeños pasan, el ping básico funciona, la conexión TCP se establece... y luego las transferencias grandes se cuelgan a medias porque una trama grande, con el bit «no fragmentar», llega a un salto que no la puede tragar y se descarta sin avisar a nadie. Has visto ese síntoma: el ping va, el SSH va, pero scp de un fichero grande se queda congelado. Casi siempre es MTU.

La regla de oro es tozuda: el MTU tiene que ser idéntico en TODA la cadena. Y la cadena en Proxmox es más larga de lo que parece: la NIC física, el bond (si lo hay), el bridge, la subinterfaz de VLAN si la usas, la NIC virtio de la VM y, fuera del host, cada puerto del switch por el que pasa el tráfico. Un solo eslabón a 1500 y toda la cadena está rota para tramas grandes.

# MTU 9000 en TODA la cadena del host. Cada iface lleva su mtu 9000.
iface enp3s0f0 inet manual
    mtu 9000

iface enp3s0f1 inet manual
    mtu 9000

auto bond0
iface bond0 inet manual
    bond-slaves enp3s0f0 enp3s0f1
    bond-miimon 100
    bond-mode 802.3ad
    mtu 9000

auto vmbr0
iface vmbr0 inet static
    address 10.10.10.10/24
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
    mtu 9000

Dentro de la VM, la NIC virtio también tiene que ir a 9000 (se ajusta desde el sistema operativo invitado o desde la configuración de la VM). Y el switch tiene que tener jumbo frames habilitados en los puertos implicados. En algunos switches el jumbo se activa por switch entero, en otros por puerto; revísalo, porque es el eslabón que más se olvida.

La forma de verificar que los jumbo frames funcionan de verdad de extremo a extremo es un ping con el bit de no fragmentar y el tamaño justo. El truco del tamaño: a un MTU de 9000 hay que restarle 28 bytes (20 de cabecera IP + 8 de cabecera ICMP), así que el payload máximo es 8972. Si ese ping pasa, la cadena está sana; si falla pero con 1472 (el equivalente para MTU 1500) pasa, tienes un eslabón capado a 1500 en algún punto.

# -M do = no fragmentar (Don't Fragment). -s 8972 = payload para MTU 9000.
ping -M do -s 8972 10.10.10.20

# Si esto FALLA pero el de abajo PASA, hay un MTU 1500 escondido en la ruta
ping -M do -s 1472 10.10.10.20

Mi recomendación práctica: activa jumbo frames solo en las redes que se benefician de verdad (almacenamiento Ceph, red de migración, iSCSI/NFS a la cabina) y déjalo en 1500 en la red de gestión y de VMs de propósito general. No ganas nada con MTU 9000 en la gestión y sí te expones a que un cliente con MTU 1500 tenga problemas raros. Segrega el jumbo a su dominio y verifícalo con ping -M do el día que lo montes, no el día que falle una copia.

SDN en Proxmox 9: zonas, VNets y fabric

Proxmox VE 9 trae un stack de Software-Defined Networking (SDN) bastante más maduro, y conviene entender qué resuelve para no montarlo donde no hace falta. El SDN abstrae la red en tres piezas: las zonas (el tipo de red y su dominio: VLAN, VXLAN, EVPN...), las VNets (redes virtuales concretas dentro de una zona, que aparecen como bridges utilizables por las VMs) y los subnets asociados. La gracia es que la configuración de red se define a nivel de datacenter y se replica a todos los nodos del clúster, en vez de editar el /etc/network/interfaces de cada uno a mano.

La novedad grande de la 9 es el fabric: Proxmox automatiza el enrutamiento entre nodos del clúster usando protocolos de enrutamiento dinámico sobre la implementación de FRR (necesitas los paquetes frr y frr-pythontools). En la 9.0 el fabric soporta OpenFabric y OSPF: configuras un router-ID único por nodo, un prefijo de loopback y las interfaces que hablan entre nodos, y el fabric levanta una red mallada autoconfigurada que se adapta a cambios de topología. En Proxmox VE 9.2 el fabric suma BGP y WireGuard como protocolos, más route maps y prefix lists para filtrado fino de rutas BGP/EVPN, y mejores informes de estado del SDN en la GUI (por ejemplo, ver las MAC/IP aprendidas en zonas EVPN). Ese filtrado por prefijos no es cosmético: sin un filtro explícito, el fabric instala en la tabla de rutas del kernel un filtro por defecto derivado de los propios prefijos IPv4/IPv6 del fabric.

# El fabric SDN se apoya en FRR. Instálalo antes de configurar el fabric.
apt install frr frr-pythontools

# La config de SDN vive versionada bajo /etc/pve (se replica al clúster)
ls /etc/pve/sdn/

# Estado del enrutamiento dinámico que levanta el fabric (OSPF/OpenFabric/BGP)
vtysh -c "show ip route"
vtysh -c "show openfabric topology"

¿Cuándo merece la pena el SDN frente a los bridges clásicos? Mi criterio: si tienes un nodo o un clúster pequeño con una red L2 plana y unas cuantas VLANs, quédate con los bridges VLAN-aware. Son más simples, más fáciles de depurar y no dependen de FRR. El SDN empieza a pagar cuando necesitas redes L2 que se extienden entre nodos sobre una red L3 (VXLAN/EVPN), cuando montas una red mallada de Ceph con enrutamiento dinámico en vez de cables cruzados, o cuando la escala de redes y la necesidad de que la configuración sea idéntica en todo el clúster hace inviable editar cada nodo a mano. Para un homelab con tres VLANs, montar EVPN es matar moscas a cañonazos. Para un clúster multi-nodo con segmentación compleja, el SDN es justo la herramienta.

Separar el tráfico: gestión, VMs, clúster y almacenamiento

Este es el apartado que separa un Proxmox de juguete de uno de producción, y el que más se descuida. Meter todo el tráfico por una sola NIC funciona hasta que no funciona, y cuando no funciona te enteras de la peor manera: un backup saturando el enlace tumba el corosync, el clúster pierde quórum y las VMs con HA se reinician solas. He visto esa cascada más de una vez. La solución es diseñar la separación de tráfico desde el principio, idealmente en interfaces (o al menos VLANs) distintas:

• Red de gestión (management). El acceso a la GUI, SSH y API del host. Poco ancho de banda, pero tiene que estar siempre disponible. Va en su propia red, a ser posible aislada del tráfico de las VMs.
• Red de VMs. El tráfico de producción de las máquinas virtuales, normalmente con sus VLANs sobre el bridge VLAN-aware. Es la que más varía en carga.
• Red de clúster / corosync. La más sensible de todas, y la que más gente subestima. Corosync no necesita ancho de banda, necesita latencia baja y estable. Un pico de latencia por saturación y el nodo pierde quórum. Debe ir en su propia red física dedicada, y Proxmox permite además configurar un anillo redundante (Corosync soporta varios links) para que la caída de una red no tumbe el clúster.
• Red de almacenamiento y migración (Ceph, réplicas, live migration). La que mueve terabytes. Va a 10/25 GbE, dedicada, y es la candidata natural a los jumbo frames. Nunca la compartas con corosync: el día que Ceph reconstruye un OSD, se come el enlace entero y tu clúster se cae si el corosync viajaba por ahí.

La regla que no me canso de repetir: corosync va solo, y el almacenamiento va aparte y rápido. Si solo puedes permitirte separar una cosa, separa la red de clúster. La estabilidad de todo el HA depende de que las tramas de corosync lleguen a tiempo, y no llegan a tiempo si comparten cable con una migración en vivo de 200 GB.

Caveats y trampas que se pagan en producción

Estos son los tropiezos concretos que veo una y otra vez. Ninguno es exótico; todos se cobran su peaje.

• MTU inconsistente. Ya insistido, pero es el rey. Un eslabón a 1500 en una cadena de 9000 y las transferencias grandes se cuelgan sin error. Verifica con ping -M do -s 8972 el día del montaje.
• Bridge con STP mal entendido. Proxmox pone bridge-stp off por defecto y para un nodo con un solo uplink es lo correcto. El peligro aparece si conectas dos uplinks del mismo bridge a la misma red L2 sin bonding: creas un bucle de capa 2 que tumba la red entera. Si necesitas dos enlaces, es bonding, no dos bridge-ports sueltos. STP en el bridge no es tu mecanismo de redundancia aquí.
• El VLAN-aware olvidado. Pones el tag en la NIC de la VM, el puerto del switch es un trunk correcto, y aun así la VM no tiene red. Miras el bridge y bridge-vlan-aware yes no está. Sin esa línea, el bridge ignora los tags y todo va a la VLAN nativa. Es de los primeros sitios donde mirar.
• Orden de arranque de las interfaces. Con bonds, bridges apilados y VLANs, el orden importa: el bond tiene que existir antes que el bridge que cuelga de él. ifupdown2 resuelve dependencias razonablemente bien, pero un fichero editado a mano con las stanzas desordenadas o un auto que falta puede dejar una interfaz sin levantar tras un reinicio. Prueba siempre un ifreload -a y, mejor aún, un reinicio real controlado antes de dar por buena una topología nueva.
• El firewall de Proxmox interfiriendo. El pve-firewall actúa a nivel de bridge y de interfaz de la VM. Si lo activas a nivel de datacenter o de VM con las reglas por defecto y sin pensar, puedes cortarte tráfico legítimo (o a ti mismo el acceso de gestión). Cuando algo «deja de pasar» justo después de tocar el firewall, revisa /etc/pve/firewall/ y el estado con pve-firewall status antes de volverte loco con la red.
• El renombrado de interfaces (nombres predecibles en Debian 13). Debian 13 usa los nombres de interfaz predecibles de systemd (enp3s0, eno1, ens18). Suena estable, pero si mueves una NIC de slot PCIe, añades otra tarjeta o hay un cambio de enumeración tras un update, el nombre puede cambiar y tu vmbr0 se queda sin uplink: el nodo arranca sin red y te toca ir con teclado y monitor. Para blindarte, ancla el nombre por MAC con un fichero .link de systemd:

# Anclar el nombre de una NIC a su MAC para que no cambie nunca
# /etc/systemd/network/10-uplink.link
[Match]
MACAddress=aa:bb:cc:dd:ee:ff

[Link]
Name=uplink0

# Aplicar tras crear el fichero
update-initramfs -u
# Y usar "uplink0" como bridge-ports en /etc/network/interfaces

• Bond mal negociado con el switch. El bond marca up en el host pero el switch no tiene el port-channel bien configurado, o una punta habla LACP y la otra tiene un etherchannel estático. Resultado: intermitencias, MACs que aparecen y desaparecen, rendimiento por debajo de un solo enlace. Comprueba siempre cat /proc/net/bonding/bond0 y que en el switch el port-channel reporte el LACP negociado. Un bond LACP que no lista los dos slaves con el mismo Aggregator ID no está agregando nada.

Los pain points reales de gestionar red en Proxmox

Más allá de los errores puntuales, hay dolores estructurales que quien administra Proxmox en serio conoce bien. El primero es que la red se diseña antes de tener carga y se cambia con carga encima: rehacer el bonding o pasar de bridge tradicional a VLAN-aware con VMs en producción implica cortes, y planificarlo bien el primer día ahorra ventanas nocturnas. El segundo es la coordinación con el equipo de red: el 80% de los «problemas de Proxmox» con VLANs y LACP son en realidad el puerto del switch mal configurado, y depurarlo exige mirar las dos puntas a la vez, que en organizaciones con silos entre sistemas y comunicaciones acaba en un ping-pong de tickets.

El tercero es la falta de visibilidad hasta que aprendes las herramientas: acostumbrado al show de un switch, al principio no sabes dónde mirar en Linux. bridge vlan show, ip -d link, cat /proc/net/bonding/bond0 y tcpdump en la interfaz correcta son tu nuevo cuadro de mandos. Y el cuarto, el más traicionero, es que Proxmox no valida la coherencia de tu diseño: te deja MTU distintos en cada eslabón, un bond LACP contra un switch que no lo espera, corosync compartiendo cable con el almacenamiento. Todo «funciona» en la GUI. La factura llega en producción, y por eso estas buenas prácticas no son estética: son las que evitan la llamada a las tres de la mañana.

Si vas a montar un clúster serio, remata el diseño de red junto con el resto de la plataforma y no olvides el hardening del nodo: una red bien segmentada es también la primera capa de tu seguridad.

El diseño de red es la decisión que no puedes improvisar

La red de Proxmox es sencilla de arrancar y traicionera de escalar. El instalador te da un vmbr0 que funciona, y esa facilidad es una trampa: invita a no pensar el diseño hasta que ya tienes carga y cambiarlo duele. Las decisiones que importan se toman el primer día: bridge VLAN-aware si vas a segmentar, bonding LACP contra un switch bien configurado, jumbo frames solo donde aportan y verificados de extremo a extremo, y una separación real entre gestión, VMs, corosync y almacenamiento.

Ninguna de estas prácticas es difícil de aplicar. Lo difícil es aplicarlas después, con VMs en producción y una ventana de dos horas para rehacer el bonding. Diseña la red como si fuera a durar años, porque va a durar años, y verifica cada eslabón antes de dar nada por bueno. El Proxmox que no te da guerra de madrugada es, casi siempre, el que tenía la red bien pensada desde el principio.