Redes en Proxmox vs ESXi: trunk VLAN, bridges/vSwitches, bonding/LACP explicado

noviembre 14, 2025 • febrero 3, 2026 • Lectura: 28 min • Views: 8

¿Te fue útil?

Si alguna vez migraste un clúster y viste cómo la “red simple” se convierte en una caída de cuatro horas, ya conoces la verdad:
la red del hipervisor es donde las suposiciones mueren. Las VLAN se comportan. Los trunks se comportan. Hasta el día en que no lo hacen, porque la caja
está haciendo exactamente lo que le dijiste, no lo que querías decir.

Este es el mapa práctico entre las redes de Proxmox y ESXi: cómo aterriza realmente el trunk VLAN en un bridge de Linux frente a un vSwitch,
cómo funciona el bonding/LACP (y cómo falla), y qué comprobar cuando los paquetes desaparecen en el vacío.

1) El modelo mental: bridges vs vSwitches

La red de ESXi es una pila de switch virtual diseñada para eso. Creas vSwitches (standard o distributed), defines port groups,
adjuntas vmnics (uplinks) y obtienes aplicación de políticas en un sistema guiado por UI con abstracciones consistentes.

La red en Proxmox es la red de Linux con una GUI. Bajo el capó usas bridges de Linux (a menudo llamados vmbr0),
subinterfaces VLAN y bonding de Linux. El “switch” es el kernel. La ventaja es que puedes depurarlo como cualquier otro host Linux,
con herramientas estándar. La desventaja es que también puedes pegarte un tiro en el pie como cualquier otro host Linux, con herramientas estándar.

Qué mapea a qué

ESXi vSwitch / vDS ≈ Linux bridge (Proxmox vmbrX)
ESXi uplinks (vmnicX) ≈ NICs de Linux (eno1, ens3f0, etc.) o bond (bond0)
ESXi Port Group ≈ VLAN en un puerto de bridge (bridge VLAN-aware + etiqueta en la VM) o un bridge/subinterface VLAN dedicado
ESXi VLAN ID 4095 (guest trunk) ≈ NIC de Proxmox sin etiqueta VLAN + el guest realiza el tagging

La gran diferencia conceptual: ESXi tiende a empujar la identidad VLAN hacia los port groups, mientras que Proxmox tiende a empujarla a la configuración
de la NIC de la VM cuando usas bridges VLAN-aware. Ambos pueden hacerlo de cualquier modo. Pero los humanos somos criaturas de hábito, y las migraciones fallan
en las brechas entre hábitos.

La cita de fiabilidad que deberías tatuar en tus runbooks

“La esperanza no es una estrategia.” — idea parafraseada citada a menudo en operaciones y fiabilidad.
Trata las configuraciones de VLAN y LACP como código: revisa, prueba y ten rollback.

2) Trunk VLAN: Proxmox vs ESXi en términos sencillos

Un trunk VLAN es simplemente “llevar múltiples VLANs sobre un enlace físico.” Las discusiones empiezan cuando preguntas: “¿Dónde ocurre el etiquetado?”

Trunk VLAN en ESXi

En ESXi, el trunking se expresa mayormente a través de port groups:

VLAN ID = N: ESXi etiqueta los tramas salientes de ese port group con VLAN N y acepta VLAN N entrante.
VLAN ID = 0: comportamiento de prioridad-tagging; se usa raramente en virtualización típica.
VLAN ID = 4095: caso especial que significa “trunk VLAN hacia el guest.” ESXi pasa las etiquetas VLAN y la VM gestiona el tagging.

Cuando adjuntas un vmnic uplink a un vSwitch o vDS, estás diciendo: “Este uplink está conectado a un puerto de switch que está
configurado correctamente para el comportamiento VLAN que estos port groups esperan.” ESXi no configurará tu switch físico, y tu
switch físico no leerá tu mente. Por eso existen tickets.

Trunk VLAN en Proxmox

En Proxmox, el patrón “moderno” más común es:

Hacer vmbr0 un bridge VLAN-aware.
Adjuntar tu uplink trunk (una NIC física o un bond) como puerto del bridge.
Para cada NIC de VM, configurar la etiqueta VLAN en la configuración hardware de la VM.

Eso es conceptualmente similar a los port groups de ESXi con IDs VLAN, excepto que Proxmox pone la etiqueta en la NIC de la VM en vez de en un objeto port group.
Operacionalmente está bien—hasta que tienes que auditar 200 VMs para “¿quién está en la VLAN 132?” y te pierdes una porque fue configurada de forma diferente en
ese caso especial de 2019.

Patrón alternativo en Proxmox: crear subinterfaces VLAN en el host (por ejemplo, bond0.100) y construir un bridge separado por VLAN (por ejemplo, vmbr100).
Es más verboso, pero también brutalmente claro. La claridad es una característica de rendimiento cuando corre el reloj de la caída.

Definición de trunk: no confundas “VLAN permitidas” con “VLAN nativa”

Los trunks en switches físicos típicamente tienen:

Lista de VLAN permitidas: qué etiquetas VLAN están permitidas a través del trunk.
VLAN nativa (o VLAN sin tag): qué ocurre con tramas sin etiqueta (se mapean a una VLAN).

Si tu uplink del hipervisor envía tramas sin etiqueta (management, clúster, almacenamiento, lo que sea) y asumes “sin etiqueta significa VLAN 1”
mientras que el switch usa VLAN nativa 20, tendrás conectividad—pero en el lugar equivocado. Así las caídas se convierten en incidentes con
implicaciones de seguridad.

Broma #1: Las VLAN son como los planos de asientos de la oficina—todos coinciden en que son necesarias, y nadie coincide en quién se sienta dónde.

3) Port groups de ESXi vs bridges VLAN-aware de Proxmox

El port group de ESXi es un objeto de políticas: VLAN ID, ajustes de seguridad, shaping de tráfico, reglas de NIC teaming y, en vDS, incluso cosas
como NetFlow y políticas de mirrored ports. Es una abstracción limpia para entornos con muchos consumidores y control de cambios.

El modelo de bridge VLAN-aware de Proxmox está más cerca de “switching en el kernel”: el bridge ve las etiquetas y reenvía según MAC+VLAN.
La interfaz tap de la VM recibe una configuración de etiqueta VLAN, y Linux maneja el etiquetado/desetiquetado.

Qué preferir

Si tienes un entorno pequeño-mediano, los bridges VLAN-aware son el patrón más simple y menos frágil en Proxmox.
Un bridge, un uplink trunk, etiquetas en las NICs de las VM. Escala operativamente hasta que necesitas políticas por red y guardarraíles estrictos.

Si necesitas fuerte separación de funciones (netops define redes, el equipo de virtualización adjunta VMs), el enfoque de port groups de ESXi tiende a encajar
mejor con la realidad corporativa. En Proxmox todavía puedes hacer separación—solo acepta que la construirás con convenciones, automatización
y revisión, no con objetos mágicos.

Guest VLAN trunking (la VM hace el tagging)

ESXi lo hace explícito con VLAN 4095. Proxmox puede hacerlo no estableciendo una etiqueta VLAN en la NIC de la VM y asegurando que el bridge/uplink
pase tramas etiquetadas. Entonces el guest ejecuta subinterfaces 802.1Q dentro de la VM.

Esto es útil para routers virtuales, firewalls o appliances que esperan enlaces trunk. También es la forma más rápida de crear un agujero de conejo de diagnóstico
donde nadie sabe si el tagging está en el guest, en el hipervisor o en el switch físico. Elige un lugar y documenta.

4) Bonding y LACP: qué funciona y qué duele

Haces bonding de NICs para lograr redundancia y/o ancho de banda. Hay dos categorías amplias:

Modos estáticos/team (sin negociación con el switch): active-backup, balance-xor (según caso), etc.
LACP (802.3ad): agregación negociada con el switch, con políticas de hash que deciden qué flujo usa qué enlace.

Bonding en Proxmox

Proxmox suele usar bonding de Linux (bond0) con modos como:

active-backup: un enlace activo, otro en standby. Aburrido. Fiable. Mi predeterminado para redes de gestión.
802.3ad (LACP): todos los enlaces activos, mejor utilización, pero requiere configuración correcta del switch y hashing consistente.
balance-xor: estilo de agregación estática; puede funcionar pero es más fácil de desconfigurar entre switches.

NIC teaming y LACP en ESXi

El NIC teaming del vSwitch estándar de ESXi no es LACP. Es “teaming” con varias políticas de balanceo. Para LACP real usualmente necesitas
un vDS (distributed switch) dependiendo de versión/licencia, y entonces defines un LAG LACP y adjuntas uplinks.

Traducción: si estás acostumbrado a “simplemente habilitar LACP en el host,” ESXi puede forzarte al mundo vDS. Si estás acostumbrado a “simplemente agrupar NICs,”
Proxmox podría tentarte a modos estáticos que funcionan hasta que un reemplazo de switch cambia el comportamiento.

El hashing es donde los sueños mueren

LACP no da mágicamente el doble de ancho de banda a un flujo TCP único. Reparte flujos entre enlaces según un hash (combinaciones MAC/IP/puertos).
Si quieres “una VM obtiene 20 Gbps,” probablemente necesites otra cosa (múltiples flujos, SMB multichannel, NVMe/TCP con múltiples sesiones,
o simplemente un enlace mayor).

Además: el tráfico de almacenamiento (iSCSI, NFS) y vMotion/tráfico de migración puede volverse muy sensible a entregas fuera de orden y micro-bursts
si “optimizas” sin medir. LACP no es un almuerzo gratis. Es un acuerdo negociado para discutir con la física.

Broma #2: LACP es una relación—si un lado piensa que eres “active-backup” y el otro piensa que eres “a todo gas”, alguien va a desaparecer paquetes.

5) MTU, offloads y el impuesto de los “jumbo frames”

Las discrepancias de MTU son aburridas y catastróficas. ESXi tiende a propagar ajustes de MTU a través de vSwitches/vDS e interfaces VMkernel.
Proxmox los propaga a través de interfaces Linux, bonds, subinterfaces VLAN y bridges. Puedes hacerlo bien—o “casi bien,” que es como terminas con una red de almacenamiento
que funciona hasta que activas la replicación.

Si ejecutas jumbo frames (MTU 9000), ejecútalos end-to-end: puertos del switch físico, uplinks, bond, bridge, interfaces VLAN y NICs de guest donde corresponda.
Si no puedes garantizar extremo a extremo, no lo hagas a medias. Usa 1500 y dedica tiempo al CPU pinning o al diseño de almacenamiento en su lugar.

6) Controles de seguridad del vSwitch vs valores por defecto de Linux

Los port groups de ESXi tienen toggles clásicos de seguridad: Promiscuous Mode, MAC Address Changes, Forged Transmits. Están ahí porque el switching virtual
es un medio compartido y algunas cargas (IDS, appliances) necesitan comportamiento especial. Muchas de las peores “caídas misteriosas” en entornos ESXi
son por tener estos ajustes demasiado estrictos para una VM concreta.

El bridging de Proxmox/Linux no presenta exactamente esos mismos controles de la misma manera, pero existen restricciones similares: reglas ebtables/nftables,
filtrado en el bridge y comportamiento del guest. Si ejecutas firewalls virtuales, necesitas validar que el hipervisor pasará los tramas que esperas,
incluidas etiquetas VLAN y comportamiento MAC.

7) Datos interesantes y contexto histórico (8 apuntes rápidos)

802.1Q VLAN tagging se estandarizó en 1998, y todavía discutimos sobre VLANs nativas como si fuera nuevo.
El bridging en Linux es de calidad productiva desde hace décadas; antecede a muchas UIs modernas de virtualización empresarial.
LACP (802.3ad / 802.1AX) fue diseñado para estandarizar link aggregation entre proveedores; también estandarizó las discusiones al respecto.
El vSwitch standard de ESXi históricamente no hacía LACP del mismo modo que un vDS puede hacerlo; la gente usó políticas de teaming “suficientemente buenas”.
VLAN 4095 en ESXi no es “una VLAN”, es una señal de passthrough de trunk para que el port group lleve todas las VLANs al guest.
VXLAN/overlay networks se hicieron mainstream en parte porque la escala de VLAN (4094 VLANs útiles) era un techo real en grandes entornos.
Los offloads de NIC (TSO/GSO/GRO/LRO) pueden cambiar el comportamiento de los paquetes lo suficiente para confundir captures y algunos appliances de seguridad.
STP y bridges siguen importando: los bucles accidentales pueden fundir redes rápido, ya sea el switch físico o virtual.

8) Tareas prácticas: comandos, salidas, decisiones (12+)

Estas son las comprobaciones que realmente corro cuando algo huele mal. Cada tarea incluye: comando, salida de ejemplo, qué significa y la
decisión que tomas.

Tarea 1: Identificar NIC físicas y estado de enlace (Proxmox)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             3c:fd:fe:aa:bb:01
eno2             DOWN           3c:fd:fe:aa:bb:02
ens3f0           UP             0c:42:a1:11:22:33
ens3f1           UP             0c:42:a1:11:22:34
bond0            UP             0c:42:a1:11:22:33
vmbr0            UP             0c:42:a1:11:22:33

Significado: Ves de inmediato qué está up/down y si existen bonds/bridges.
Decisión: Si una NIC miembro está down inesperadamente, deja de culpar a las VLANs y ve primero a mirar cableado/errores en el switch.

Tarea 2: Verificar modo de bond y estado LACP (Proxmox)

cr0x@server:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: fast
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
        Aggregator ID: 2
        Number of ports: 2
        Actor Key: 17
        Partner Key: 42
        Partner Mac Address: 00:11:22:33:44:55

Slave Interface: ens3f0
MII Status: up
Actor Churn State: none
Partner Churn State: none

Slave Interface: ens3f1
MII Status: up
Actor Churn State: none
Partner Churn State: none

Significado: Confirma 802.3ad, política de hash y que ambos esclavos están realmente agregados con una MAC partner.
Decisión: Si ves “Number of ports: 1” o churns, sospecha desajuste de LACP en el switch o enlaces flapping.

Tarea 3: Confirmar awareness VLAN del bridge y membresía de puertos (Proxmox)

cr0x@server:~$ bridge link
2: bond0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0
5: tap100i0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0
6: tap101i0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0

Significado: Muestra qué está adjunto al bridge: uplink y dispositivos tap de VM.
Decisión: Si el uplink no está en el bridge, tu “trunk” es un concepto filosófico, no una red.

Tarea 4: Inspeccionar el filtrado VLAN en un bridge Linux (Proxmox)

cr0x@server:~$ bridge vlan show
port              vlan-id  
bond0             1 PVID Egress Untagged
bond0             20
bond0             30
tap100i0          20
tap101i0          30

Significado: El bridge está filtrando VLANs; bond0 permite VLANs 20 y 30 y tiene PVID 1 sin etiqueta.
Decisión: Si la VLAN que necesitas no aparece, o bien permítela (si el filtrado está activado) o corrige la configuración de etiqueta de la NIC de la VM.

Tarea 5: Comprobar direccionamiento IP del host y qué interfaz lo posee (Proxmox)

cr0x@server:~$ ip -br addr
eno1             UP             192.0.2.10/24
bond0            UP
vmbr0            UP             198.51.100.10/24
vmbr0.20         UP             10.20.0.10/24

Significado: Muestra si la IP de gestión está en un bridge, subinterface VLAN o NIC física.
Decisión: Si la IP del host está en una NIC física que además está en un bridge, espera comportamientos extraños. Pon IPs en el bridge (o en interfaces VLAN sobre el bridge), no en puertos esclavizados.

Tarea 6: Validar consistencia de MTU en uplink, bond, bridge (Proxmox)

cr0x@server:~$ ip -d link show bond0
3: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 0c:42:a1:11:22:33 brd ff:ff:ff:ff:ff:ff promiscuity 0
    bond mode 802.3ad miimon 100 updelay 0 downdelay 0 lacp_rate 1 xmit_hash_policy 1

Significado: MTU es 9000 en el bond; todavía necesitas verificar las NIC esclavas, el bridge y los puertos del switch.
Decisión: Si la MTU difiere en algún salto, o corrígela extremo a extremo o vuelve a 1500 y deja de pagar el impuesto de jumbo frames.

Tarea 7: Prueba rápida de alcance VLAN con ping + bit DF (Proxmox)

cr0x@server:~$ ping -c 2 -M do -s 8972 10.20.0.1
PING 10.20.0.1 (10.20.0.1) 8972(9000) bytes of data.
8972 bytes from 10.20.0.1: icmp_seq=1 ttl=64 time=0.421 ms
8972 bytes from 10.20.0.1: icmp_seq=2 ttl=64 time=0.398 ms

--- 10.20.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Significado: Confirma que jumbo MTU funciona hasta la puerta de enlace en esa VLAN (al menos para ICMP).
Decisión: Si esto falla pero un ping normal funciona, tienes fragmentación/blackhole de MTU. Arregla la MTU o el comportamiento de path MTU discovery.

Tarea 8: Ver aprendizaje de MACs en el bridge (Proxmox)

cr0x@server:~$ bridge fdb show br vmbr0 | head
0c:42:a1:11:22:33 dev bond0 master vmbr0 permanent
52:54:00:aa:bb:01 dev tap100i0 master vmbr0 vlan 20
52:54:00:aa:bb:02 dev tap101i0 master vmbr0 vlan 30

Significado: Confirma que el bridge está aprendiendo MACs de VM por VLAN y dónde viven.
Decisión: Si una MAC de VM no aparece mientras la VM está arriba y genera tráfico, sospecha la conexión de la NIC de la VM, reglas de firewall o que el guest está en la VLAN equivocada.

Tarea 9: Capturar tráfico etiquetado en el uplink (Proxmox)

cr0x@server:~$ sudo tcpdump -eni bond0 -c 5 vlan
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:11.123456 0c:42:a1:11:22:33 > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 86: vlan 20, p 0, ethertype IPv4, 10.20.0.10.5353 > 224.0.0.251.5353: UDP, length 44
12:01:11.223456 52:54:00:aa:bb:01 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 10.20.0.1 tell 10.20.0.50, length 28

Significado: Puedes ver etiquetas VLAN en la red y confirmar el ID VLAN.
Decisión: Si faltan etiquetas en un trunk que debería llevarlas, tu etiquetado está ocurriendo en otra parte—or no está ocurriendo.

Tarea 10: ESXi—confirmar enlace vmnic e info del driver (en shell ESXi)

cr0x@server:~$ esxcli network nic list
Name    PCI Device    Driver  Link  Speed  Duplex  MAC Address         MTU  Description
vmnic0  0000:3b:00.0  ixgbe   Up    10000  Full    3c:fd:fe:aa:bb:01  9000 Intel Corporation 82599ES
vmnic1  0000:3b:00.1  ixgbe   Up    10000  Full    3c:fd:fe:aa:bb:02  9000 Intel Corporation 82599ES

Significado: Los uplinks físicos están up, a la velocidad/MTU esperada. Esto elimina una gran clase de excusas de “es la red”.
Decisión: Si la velocidad es 1000 cuando esperabas 10000, para. Arregla la óptica/cableado/configuración del puerto en el switch primero.

Tarea 11: ESXi—inspeccionar vSwitches y port groups

cr0x@server:~$ esxcli network vswitch standard list
vSwitch0
   Name: vSwitch0
   Class: etherswitch
   Num Ports: 128
   Used Ports: 12
   Configured Ports: 128
   MTU: 9000
   Uplinks: vmnic0, vmnic1
   Portgroups: Management Network, VM Network, Storage-20

Significado: Muestra MTU, uplinks y qué port groups existen en el vSwitch standard.
Decisión: Si el port group relevante no está en el vSwitch que crees, has encontrado tu mal cableado—lógico, no físico.

Tarea 12: ESXi—verificar VLAN IDs configurados en port groups

cr0x@server:~$ esxcli network vswitch standard portgroup list
Name               Virtual Switch  VLAN ID
Management Network vSwitch0        10
VM Network         vSwitch0        0
Storage-20         vSwitch0        20
Trunk-to-FW        vSwitch0        4095

Significado: Te dice si ESXi etiqueta tramas (VLAN 10/20) o las pasa al guest (4095).
Decisión: Si una VM que espera tráfico sin etiqueta está en VLAN 20, estará “up” pero aislada. Arregla el VLAN ID del port group, no la VM.

Tarea 13: Proxmox—validar que el archivo de configuración es lo que crees

cr0x@server:~$ sed -n '1,200p' /etc/network/interfaces
auto lo
iface lo inet loopback

auto bond0
iface bond0 inet manual
        bond-slaves ens3f0 ens3f1
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer3+4
        bond-lacp-rate 1

auto vmbr0
iface vmbr0 inet static
        address 198.51.100.10/24
        gateway 198.51.100.1
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

Significado: Confirma modo de bond, ajuste bridge VLAN-aware y rango de VLANs permitidas.
Decisión: Si bridge-vlan-aware está off pero dependes de etiquetas en NICs de VM, las etiquetas no se comportarán como esperas. Enciéndelo o cambia el diseño.

Tarea 14: Proxmox—comprobar reglas de firewall que interfieran con L2/L3

cr0x@server:~$ sudo pve-firewall status
Status: enabled/running

Significado: El firewall está activado; ahora debes tener en cuenta las reglas de firewall del host y de las VMs en tu modelo mental.
Decisión: Si estás depurando “ARP funciona pero TCP no,” aislar temporalmente la influencia del firewall (en una ventana controlada) suele ser más rápido que adivinar.

9) Guion rápido de diagnóstico

Cuando la red falla en hipervisores, el camino más rápido es encontrar la capa donde la realidad diverge de tu diagrama. Comprueba en este orden.

Primero: verdad física (enlace, velocidad, errores)

¿Está el enlace de la NIC up? ¿Es la velocidad esperada?
En Proxmox: ip -br link, ethtool eno1 (si está disponible), contadores del switchport.
En ESXi: esxcli network nic list.

Indicador de cuello de botella: desajuste de velocidad (1G en vez de 10G), aumento de errores/drops, enlaces flapping.

Segundo: topología L2 (bonding/LACP, adjunto bridge/vSwitch)

¿El uplink está realmente adjunto al bridge/vSwitch que crees?
¿LACP está negociado y estable?
Proxmox: cat /proc/net/bonding/bond0, bridge link.
ESXi: uplinks del vSwitch, y si es vDS, confirma membresía en el LAG.

Indicador de cuello de botella: solo un esclavo activo en un bond, churn o uplink ausente donde debería estar.

Tercero: corrección de VLAN (lugar del etiquetado, VLANs permitidas, VLAN nativa)

¿La etiqueta VLAN se aplica en el objeto correcto (NIC de VM vs port group vs SO del guest)?
¿El trunk físico permite la VLAN?
Proxmox: bridge vlan show, tcpdump -eni bond0 vlan.
ESXi: esxcli network vswitch standard portgroup list.

Indicador de cuello de botella: solicitudes ARP visibles pero sin respuestas en la VLAN esperada, o respuestas llegando en una VLAN distinta.

Cuarto: MTU y agujeros de fragmentación

Prueba con ping DF al MTU esperado.
Verifica MTU en cada salto: switch físico, NIC uplink, bond, bridge/vSwitch, VMkernel (ESXi), NIC del guest.

Indicador de cuello de botella: pings pequeños funcionan, pings grandes fallan; almacenamiento se queda; migraciones se congelan intermitentemente.

Quinto: políticas y filtrado (firewalls, ajustes de seguridad, comportamiento MAC)

Los ajustes de seguridad de port group en ESXi bloquean forged transmits o cambios de MAC para appliances.
El firewall/nftables de Proxmox bloquea tráfico que asumías “solo L2.”

Indicador de cuello de botella: un tipo de VM falla (p. ej., VM firewall) mientras servidores normales funcionan.

10) Tres micro-historias del mundo corporativo

Incidente por una suposición equivocada: “Sin etiqueta significa VLAN 1”

Una empresa mediana movió cargas de ESXi a Proxmox durante una renovación de hardware. El equipo de virtualización mantuvo los mismos
switches top-of-rack físicos y reutilizó los puertos trunk existentes. En ESXi, la mayoría de los port groups de VM estaban etiquetados, pero la gestión
estaba sin etiqueta en los uplinks porque “siempre fue así.”

En Proxmox, construyeron un vmbr0 VLAN-aware y pusieron la IP de gestión directamente en vmbr0 sin etiqueta VLAN.
El host arrancó, pero la red de gestión se comportó de forma inconsistente: algunos hosts eran accesibles, otros no, y las tablas ARP parecían
haber sido removidas con palillo.

La suposición equivocada: el equipo creyó que la VLAN nativa del switch en esos trunks era VLAN 1. No lo era. Una estandarización previa de la red
había movido la VLAN nativa a una VLAN “infra” dedicada, y VLAN 1 estaba explícitamente podada en lugares. Las tramas sin etiqueta aterrizaban en la
VLAN infra, no en la VLAN de gestión. Así que los hosts hablaban—solo que al vecindario equivocado.

La solución no fue heroica. Etiquetaron la gestión correctamente (subinterface VLAN o etiqueta en la NIC de la VM) y hicieron el trunk explícito:
lista de VLAN permitidas, VLAN nativa definida y documentada. El informe de incidente fue corto y ligeramente embarazoso, que es exactamente como debe ser.
Cuanto más largo el informe, más estás admitiendo que el sistema era insondable.

Optimización que salió mal: “Hagamos LACP en todas partes y subamos MTU a 9000”

Otra organización ejecutaba ESXi con redes separadas: management, storage, vMotion. Migraron a Proxmox y decidieron “simplificar” convergiendo todo en
un solo bond LACP y un trunk VLAN. El pitch era limpio: menos cables, menos puertos, mejor utilización del ancho de banda.

También activaron jumbo frames extremo a extremo—o eso creían. MTU del host en 9000, puertos del switch configurados y el bond parecía sano.
En laboratorio funcionó. En producción, durante ventanas de backup, la latencia de almacenamiento subió y las migraciones de VMs fallaron intermitentemente.
Las fallas no fueron outages totales. Fueron peores: parciales, impredecibles y fáciles de descartar como “la red siendo la red.”

El culpable fue doble. Primero, un switch en la ruta tenía un ajuste MTU aplicado al perfil de puerto equivocado, dejando un solo salto en 1500.
Parte del tráfico se fragmentó, otra parte quedó en blackhole, dependiendo del protocolo y DF. Segundo, la política de hashing del bond en Linux estaba en
layer3+4, mientras que el lado switch distribuía flujos de forma diferente para ciertas clases de tráfico. Bajo microburst, un enlace se saturó y el otro parecía ocioso.

El rollback fue pragmático: mantener LACP para VLANs de VM/datos, pero poner almacenamiento en un par de NICs separado usando active-backup y una VLAN dedicada,
con MTU validada salto a salto. El rendimiento se estabilizó. La “simplificación” había sido real, pero también eliminó aislamiento y dificultó el troubleshooting.
La convergencia es una herramienta, no una personalidad.

Práctica aburrida pero correcta que salvó el día: “Un bridge, un propósito, configuraciones probadas”

Una firma de servicios financieros gestionaba un parque mixto: algunos clústeres ESXi, otros Proxmox para cargas específicas. Su equipo de red insistió
en una regla que sonaba a burocracia: cada host hipervisor debe tener un diseño pequeño “solo mgmt” que se pueda probar independientemente de las redes VM.

En Proxmox, eso significó un bridge de gestión dedicado mapeado a una VLAN dedicada con bonding active-backup, sin inventos. Las VLANs VM/datos vivían
en un trunk bridge separado, a menudo en un bond distinto. Sí, consumía más puertos. Sí, hacía los diagramas de cableado más largos. También significó que
podías reiniciar, parchear y recuperar hosts sin depender de un trunk LACP convergente que podría comportarse mal.

Durante una actualización de firmware del switch, el comportamiento LACP de un rack se degradó de una forma que no llegó a dejar caer enlaces pero sí causó churn y rebalanceos.
Las redes VM vieron pérdida de paquetes. La gestión se mantuvo limpia. El equipo de operaciones aún pudo alcanzar cada host, evacuar VMs y mantener control del radio de impacto.

El postmortem no fue glamoroso. Fue mayormente un recordatorio de que la segmentación es una estrategia de fiabilidad. Cuando las cosas se rompen, quieres un dominio de fallo estrecho.
Los diseños aburridos producen uptime emocionante.

11) Errores comunes: síntoma → causa raíz → solución

1) Las VMs no alcanzan la puerta de enlace en una VLAN, pero otras VLANs funcionan

Síntoma: Solo VLAN 30 está muerta; VLAN 20 funciona bien.
Causa raíz: VLAN no permitida en el trunk físico, o el filtrado VLAN del bridge no la incluye.
Solución: Asegura que la VLAN esté en la lista de trunk permitidas del switch; en Proxmox, confirma bridge-vlan-aware yes y que bridge vlan show incluya la VLAN; en ESXi confirma el VLAN ID del port group.

2) La conectividad de gestión muere cuando agregas un puerto al bridge

Síntoma: Agregas una NIC al bridge; el host desaparece de la red.
Causa raíz: IP del host configurada en la NIC física esclavizada en lugar del bridge; movimientos ARP/MAC causan confusión.
Solución: Pon la IP en vmbrX (o en la interfaz VLAN vmbrX.Y), no en la NIC/bond subyacente.

3) El bond LACP aparece, pero solo un enlace lleva tráfico

Síntoma: Ambos enlaces “up”, pero la utilización concentra en uno.
Causa raíz: Política de hashing inadecuada para el patrón de tráfico (flujo único dominante) o desajuste de hashing con el switch.
Solución: Alinea políticas de hashing; acepta que un flujo TCP único no se stripeará; considera múltiples sesiones o redes separadas para los heavy hitters.

4) El almacenamiento funciona hasta carga, luego timeouts

Síntoma: NFS/iSCSI OK en reposo, falla bajo backup/replicación.
Causa raíz: Desajuste de MTU o microbursts en enlaces convergentes; QoS ausente; offloads interactuando mal.
Solución: Valida MTU con pings DF end-to-end; separa el tráfico de almacenamiento o implementa buffering/QoS apropiado; prueba cambios de offload con cuidado.

5) Firewall/router virtual ve tráfico solo en un sentido

Síntoma: Paquetes entrantes visibles, salientes faltantes (o al revés).
Causa raíz: Ajustes de seguridad del port group en ESXi bloquean forged transmits/cambios de MAC; o trunking del guest mal configurado.
Solución: En ESXi, ajusta la seguridad del port group para ese appliance; en Proxmox, asegúrate de que las etiquetas VLAN se pasen/traten en la capa correcta y que reglas de firewall no estén descartando.

6) Advertencias aleatorias de IP duplicada o ARP flapping

Síntoma: Logs muestran IP duplicada; conectividad oscila.
Causa raíz: Mismatch de VLAN nativa causando que tráfico sin etiqueta caiga en la VLAN equivocada; o bucle L2 accidental.
Solución: Haz explícita y consistente la VLAN nativa; habilita STP donde corresponda; valida puertos de bridge y configuraciones de switchport.

12) Listas de verificación / plan paso a paso

Checklist A: Diseñar trunk VLAN en Proxmox (haz esto, no vibras)

Decide dónde vive el etiquetado VLAN: etiquetas en NICs de VM (bridge VLAN-aware) o subinterfaces en host (bridge por VLAN). Escoge un predeterminado.
Haz uplink un bond si necesitas redundancia. Escoge active-backup para gestión por defecto; usa LACP solo cuando puedas validar configuración del switch y hashing.
Activa bridge-vlan-aware yes en bridges trunk y define VLANs permitidas (bridge-vids) intencionalmente.
Define comportamiento nativo/sin etiqueta: idealmente, no confíes en sin etiqueta para nada importante. Etiqueta también la gestión a menos que tengas una razón sólida para no hacerlo.
Valida MTU extremo a extremo con pings DF por VLAN.
Captura tráfico en el uplink con tcpdump -eni para confirmar que las etiquetas VLAN están presentes.
Documenta: qué bridge lleva qué VLANs y si alguna VM es “guest trunk”.

Checklist B: Migrar de port groups ESXi a etiquetas VLAN en Proxmox

Exporta o lista port groups y VLAN IDs de ESXi (incluye trunks 4095).
Crea bridge(s) trunk en Proxmox y confirma awareness VLAN.
Para cada VM, mapea: VLAN ID del port group ESXi → etiqueta VLAN de la NIC en Proxmox.
Para VMs con VLAN 4095: asegura que la NIC de Proxmox no tenga etiqueta y que el guest esté configurado para 802.1Q; valida con captura de paquetes.
Antes del corte, prueba una VM por VLAN: ARP, ping, ping jumbo (si se usa) y verificación a nivel de aplicación.
Mantén la ruta de gestión lo bastante aislada para que puedas revertir sin ir al datacenter.

Checklist C: Despliegue de LACP sin dolor autoinfligido

Confirma que tus switches soportan LACP tal como lo configurarás (multi-chassis LAG/MLAG si abarca dos switches).
Define la tasa LACP (fast/slow) intencionalmente y haz que coincida en ambos lados.
Alinea la política de hashing. Si no sabes qué usa tu switch, descúbrelo. No adivines.
Prueba modos de fallo: desenchufa un enlace; reinicia un switch; confirma que el tráfico sobrevive y se rebalancea sin flapping.
Monitorea drops y errores bajo carga. Si no puedes medir, no puedes declarar éxito.

13) FAQ

Q1: ¿Un bridge Linux de Proxmox es básicamente lo mismo que un vSwitch de ESXi?

Funcionalmente, sí: ambos reenvían tramas entre interfaces de VM y uplinks. Operacionalmente, no: ESXi es una abstracción-appliance;
Proxmox es la red de Linux con todo el poder y los bordes afilados que eso implica.

Q2: ¿Debo usar un gran bridge trunk para todo en Proxmox?

Para muchos entornos, un bridge trunk para VLANs de VM/datos está bien. Pero mantén la gestión aburrida y recuperable.
Si puedes permitirlo, separa la gestión del trunk convergente.

Q3: ¿Qué es ESXi VLAN 4095 y cuál es el equivalente en Proxmox?

ESXi VLAN 4095 significa “pasar etiquetas VLAN al guest” (guest trunk). En Proxmox, normalmente haces esto no estableciendo una etiqueta VLAN en la NIC de la VM
y permitiendo que el guest cree subinterfaces VLAN—asegurando que el bridge/uplink pase tramas etiquetadas.

Q4: ¿LACP duplica el ancho de banda para una VM única?

No para un flujo TCP único. LACP reparte flujos entre enlaces según hashing. Un flujo grande suele quedarse en un enlace. Múltiples flujos pueden usar varios enlaces.

Q5: ¿Active-backup está “desperdiciando” ancho de banda?

Sí “desperdicia” el throughput agregado potencial. También te compra modos de fallo más simples. Para gestión, ese intercambio suele ser correcto.
Para tráfico intenso east-west, considera LACP si puedes soportarlo operativamente.

Q6: ¿Por qué problemas de VLAN a veces parecen fallos de DNS o de la aplicación?

Porque la conectividad parcial es la peor clase. ARP puede funcionar, paquetes pequeños pueden funcionar, pero MTU o filtrado pueden romper protocolos específicos.
Tu app falla de formas creativas que hacen que todos se culpen entre sí.

Q7: ¿Debería usar jumbo frames para redes de almacenamiento?

Solo si puedes demostrar consistencia de MTU extremo a extremo y has medido un beneficio. Si no puedes garantizarlo, usa 1500 y optimiza en otro lugar.

Q8: ¿Cómo pruebo rápido si el etiquetado ocurre en el lugar correcto?

Captura en el uplink: en Proxmox usa tcpdump -eni bond0 vlan; en ESXi puedes usar herramientas de captura apropiadas u observar la configuración del port group.
Si ves tags 802.1Q con la VLAN esperada, el etiquetado es real. Si no, tu configuración es deseo.

Q9: ¿Cuál es el diseño de VLAN más amigable para migraciones en Proxmox?

Bridge VLAN-aware con etiquetas en las NICs de VM, más una red de gestión claramente etiquetada. Mapea limpiamente a port groups de ESXi y evita proliferación de bridges.

Q10: ¿Cuándo prefieres bridge por VLAN en Proxmox?

Cuando quieres claridad extrema, separación más estricta, o integras con procesos legacy donde “esta red tiene su propia interfaz”
es cómo la gente piensa y audita.

14) Pasos prácticos siguientes

Si ejecutas ESXi, trata los port groups como tu fuente de la verdad: VLAN IDs, ajustes de seguridad y reglas de teaming. Audítalos, expórtalos
y deja de permitir que los trunks 4095 “temporales” se conviertan en arquitectura permanente.

Si ejecutas Proxmox, acepta la realidad Linux: usa bridges VLAN-aware intencionalmente, mantén IPs en las interfaces correctas y haz del bonding
una elección deliberada (active-backup para redes aburridas, LACP donde puedas validar comportamiento del switch y hashing).

Pasos siguientes que regresan valor inmediatamente:

Elige y documenta una estrategia VLAN por defecto por plataforma (etiquetar en port group vs etiquetar en NIC de VM) y una estrategia de excepción (guest trunk) con reglas estrictas.
Ejecuta el guion rápido de diagnóstico en un host sano y guarda las salidas. Las líneas base hacen que las caídas sean más cortas.
Para cualquier plan de LACP o jumbo-frames: prueba modos de fallo y MTU extremo a extremo antes de declarar victoria.