VLAN en Proxmox no funciona: configurar correctamente un puente compatible con VLAN

Guía de diagnóstico rápido

Si las VLAN “no funcionan” puedes perder horas discutiendo con el equipo de switches, con el equipo de firewall y con la persona que “solo cambió una descripción”. No lo hagas. Haz esto en su lugar. Estás buscando el primer lugar donde la etiqueta es incorrecta, falta o se descarta.

Primero: prueba la etiqueta en el cable (lado del hipervisor)

1. Identifica dónde se conecta la VM (pincha el puerto del puente, no tu intuición).
2. Captura tráfico e inspecciona etiquetas VLAN. Si los tramas que salen del nodo están sin etiquetar cuando deberían ir etiquetadas, deja de culpar al switch.
3. Confirma que el puente tiene habilitado el filtrado VLAN. Un checkbox “VLAN aware” que no aplicaste realmente es un clásico.

Segundo: prueba que el puerto del switch es un trunk (y que la VLAN nativa no te sabotea)

1. Comprueba VLANs permitidas. “Trunk” no es suficiente; los trunks pueden estar restringidos.
2. Comprueba la VLAN nativa. Si tu entorno asume “sin tramas sin etiquetar” pero el puerto asigna tráfico sin etiqueta a la VLAN 1 (u otra), acabas de construir un agujero negro silencioso.

Tercero: valida las expectativas de etiquetado del invitado

1. O Proxmox etiqueta para el invitado (establece la etiqueta VLAN en la NIC de la VM), o el invitado se etiqueta a sí mismo (subinterfaz VLAN dentro de la VM). Hacer ambas cosas produce doble etiquetado y sufrimiento.
2. Confirma que el DHCP está en la VLAN correcta. Muchos “problemas VLAN” son en realidad “el relay DHCP no está configurado allí”.

Una cita para mantenerte honesto: La esperanza no es una estrategia. — General Gordon R. Sullivan (citada comúnmente en contextos de operaciones). Es directa, pero mejor que “creo que debería funcionar”.

Modelo mental: dónde ocurre realmente el etiquetado VLAN

El diagnóstico VLAN se vuelve más fácil cuando dejas de pensar en “VLANs en un bridge” como magia y empiezas a pensar en quién añade la etiqueta 802.1Q y quién se espera que la quite.

Sólo hay tres actores que importan

• El invitado (VM o contenedor). Puede enviar tramas etiquetadas (subinterfaces VLAN) o tramas sin etiqueta (NIC normal).
• El host Proxmox. Puede etiquetar/desetiquetar tramas según la configuración de la NIC de la VM y las reglas de filtrado del puente, o puede pasar las etiquetas tal cual.
• El puerto del switch. Puede tratar el puerto como access (sin etiqueta, una sola VLAN) o trunk (etiquetado, muchas VLANs, más una VLAN nativa/sin etiqueta).

Todo lo demás es decoración. Cuando ocurre “VLAN no funciona”, uno de estos actores está añadiendo una etiqueta cuando no debe, no añadiéndola cuando debe, o descartando tráfico porque ve una etiqueta inesperada.

Chequeo de realidad específico de Proxmox

Proxmox te da dos formas principales de puentear: Linux bridge (el predeterminado) y Open vSwitch. Ambos pueden funcionar. Linux bridge con filtrado VLAN es totalmente válido para la mayoría de despliegues y tiene menos piezas móviles. Prefiérel o salvo que tengas una razón sólida para no hacerlo.

Puente compatible con VLAN en Proxmox significa: el Linux bridge tiene habilitado el filtrado VLAN para que el puente pueda manejar membresías VLAN por puerto, y Proxmox pueda programar esas reglas de VLAN basadas en las etiquetas de la NIC de la VM.

Detalle clave: una “etiqueta VLAN” configurada en la NIC de una VM en Proxmox no es sólo un campo de la interfaz. Convierte esa NIC de VM en un puerto de acceso para esa VLAN, pero sobre un enlace troncal upstream. El host etiqueta el tráfico que sale por el uplink físico, y quita la etiqueta del tráfico entregado a la NIC del invitado.

La desalineación es la enfermedad. La alineación es la cura.

Broma #1: Las VLANs son como la política de oficina: todos juran que son simples hasta que preguntas quién es el dueño del trunk y cuál es la VLAN nativa.

Hechos interesantes y contexto histórico

• El etiquetado 802.1Q añade 4 bytes a una trama Ethernet; por eso las VLANs y el MTU pueden chocar de forma sorprendente cuando estás cerca de 1500.
• La VLAN 1 es históricamente la predeterminada en muchos switches; la “VLAN nativa” suele apuntar allí, y así el tráfico sin etiqueta acaba silenciosamente donde no querías.
• El filtrado VLAN en Linux bridge se generalizó a mediados de los 2010; antes, muchas configuraciones Linux dependían de subinterfaces VLAN separadas (como eth0.100) en lugar de reglas VLAN por puerto.
• Proxmox movió a muchos usuarios de la “networking manual en Debian” a un modelo opinado donde la UI escribe /etc/network/interfaces. Esto mejoró la consistencia—y creó nuevas formas de estar convencidamente equivocado.
• Offloads de hardware (especialmente VLAN offload) pueden hacer que las capturas de paquetes mientan si capturas en la interfaz equivocada; a veces el kernel ve etiquetas que tcpdump no ve, o viceversa.
• Q-in-Q (802.1ad) existe para “doble etiquetado”, pero la mayoría de despliegues SMB/enterprise de virtualización no hacen provider bridging. Un doble etiquetado accidental parece Q-in-Q, pero no suele ser intencional y normalmente se descarta.
• Puentes y bonds han tenido una larga y a veces complicada relación en el networking Linux; algunos “problemas VLAN” son en realidad problemas de modo de bond / LACP que se manifiestan como pérdida selectiva de paquetes.
• Spanning Tree fue diseñado para prevenir bucles en redes bridged; un STP mal configurado puede parecer una caída de VLAN porque el tráfico está bloqueado, no perdido.

Patrones de configuración correctos (y cuándo usarlos)

Patrón A: “Trunk al host, Proxmox etiqueta por NIC de VM” (recomendado)

Este es el patrón de producción limpio para la mayoría de clústeres Proxmox. El puerto del switch hacia el nodo es un trunk. El Linux bridge es compatible con VLAN. Cada NIC de VM obtiene una etiqueta VLAN en Proxmox. Los invitados creen que están en una red Ethernet normal. La vida es buena.

Usar cuando: quieres configuraciones de invitado simples, control centralizado de VLANs y menos misterios tipo “¿por qué esta VM usa la VLAN 200?”.

Evitar cuando: necesitas que el invitado vea múltiples VLANs en una sola vNIC (por ejemplo, VM router, VM firewall). Para eso, quieres pasar etiquetas.

Ejemplo /etc/network/interfaces

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 10.10.10.11/24
        gateway 10.10.10.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

El elemento bridge-vlan-aware yes es la clave. bridge-vids 2-4094 le dice al puente qué IDs VLAN están permitidos en este puente. Si lo omites, Proxmox aún funciona en muchos casos porque programa la membresía VLAN dinámicamente, pero en producción prefiero ser explícito. Es una menos sorpresa del tipo “¿por qué la VLAN 3000 no pasa?”.

Patrón B: “Trunk al host, el invitado se etiqueta” (passthrough de etiquetas)

Aquí quieres que la VM reciba tramas etiquetadas y cree subinterfaces VLAN dentro del invitado. Así construyes una VM router, una VM firewall, nodos Kubernetes con trucos de CNI o appliances que esperan un trunk.

Configuración en Proxmox: deja la etiqueta de la NIC de VM en “sin etiqueta” (vacío / 0 según la interfaz). El puente aún debe ser compatible con VLAN si quieres filtrado y evitar fugas accidentales; pero configúralo para permitir las VLANs en ese puerto.

Modo fallo: si pones una etiqueta en Proxmox y etiquetas dentro del invitado, creaste doble etiquetado. La mayoría de puertos de switch no lo pasarán. Tu captura de paquetes parecerá arte moderno.

Patrón C: “Puerto de acceso al host, sólo una VLAN” (no recomendado, pero existe)

Esto es lo que hace la gente cuando no controla el switch o están “solo probando”. El puerto del switch es un access en una VLAN. El puente de Proxmox no es compatible con VLAN (o puede serlo, pero es irrelevante aquí). Cada VM conectada a ese puente cae en la misma VLAN salvo que empieces a crear subinterfaces VLAN en el host.

Usar cuando: laboratorios, nodos de propósito único o un entorno de proveedor donde la VLAN de acceso es el producto.

Evitar cuando: te importa escalar, segmentación multi-tenant o la cordura de tu yo futuro.

Patrón D: “Bond (LACP) + trunk + puente compatible con VLAN” (común en clústeres)

La mayoría de clústeres hacen bond de dos NICs para redundancia y rendimiento, luego ponen un puente compatible con VLAN encima. Esto está bien. Pero introduce modos de fallo adicionales: LACP no negociado, hashing que causa problemas asimétricos, o un puerto del switch configurado como independiente mientras el host espera LACP.

La buena práctica: mantenlo sencillo. Haz bond en 802.3ad si tu equipo de switches lo soporta y lo configurará correctamente; de lo contrario usa active-backup y duerme tranquilo.

Broma #2: LACP es genial hasta que deja de serlo; entonces es un sistema distribuido con dos nodos y tres opiniones.

Tareas prácticas: comandos, significado de salidas y decisiones

No se depura VLAN por sensaciones. Se depura con observaciones. A continuación hay comprobaciones probadas en campo que responden “¿qué es verdadero ahora mismo?” y qué hacer después.

Tarea 1: Confirma que Proxmox cree que el puente es compatible con VLAN

cr0x@server:~$ grep -A10 -n "iface vmbr0" /etc/network/interfaces
12:iface vmbr0 inet static
13-        address 10.10.10.11/24
14-        gateway 10.10.10.1
15-        bridge-ports eno1
16-        bridge-stp off
17-        bridge-fd 0
18-        bridge-vlan-aware yes
19-        bridge-vids 2-4094

Qué significa: Si bridge-vlan-aware yes falta, Proxmox no podrá aplicar filtrado VLAN por puerto como esperas.

Decisión: Si falta, añádelo (y preferiblemente bridge-vids), luego recarga la red en una ventana de mantenimiento.

Tarea 2: Verifica que el filtrado VLAN esté realmente activado en el bridge del kernel

cr0x@server:~$ bridge link show
2: eno1 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0
3: tap100i0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0
4: fwpr100p0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0

cr0x@server:~$ bridge vlan show
port              vlan-id
eno1              1 PVID Egress Untagged
eno1              100
tap100i0          100 PVID Egress Untagged
fwpr100p0         100 PVID Egress Untagged

Qué significa: Buscas la membresía VLAN por puerto. Si bridge vlan show está vacío o muestra solo VLAN 1 en todas partes, el puente no filtra como crees.

Decisión: Si la VM debería estar en VLAN 100 y su puerto tap no es PVID 100, corrige la etiqueta de la NIC de la VM o la configuración VLAN del puente.

Tarea 3: Comprueba la configuración de la NIC de VM en Proxmox (modo de etiquetado)

cr0x@server:~$ qm config 100 | egrep "net0|bridge|tag|trunks"
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,tag=100,firewall=1

Qué significa: Esta NIC de VM es un puerto de acceso para la VLAN 100. El invitado no debería crear subinterfaces VLAN para esta NIC.

Decisión: Si el invitado está etiquetando también, elimina la configuración VLAN del invitado o quita la etiqueta en Proxmox y configura el trunk apropiadamente.

Tarea 4: Valida que el uplink físico esté activo, a la velocidad correcta y sin flapping

cr0x@server:~$ ip -br link show eno1
eno1             UP             5c:ba:ef:00:11:22 <BROADCAST,MULTICAST,UP,LOWER_UP>

cr0x@server:~$ ethtool eno1 | egrep "Speed|Duplex|Link detected"
Speed: 10000Mb/s
Duplex: Full
Link detected: yes

Qué significa: El enlace está arriba. Si ves caídas de velocidad o flapping, puedes perseguir fantasmas VLAN mientras la capa física se quema.

Decisión: Si el enlace es inestable, detente aquí y arregla cableado/SFPs/errores del puerto del switch.

Tarea 5: Revisa errores y descartes hacia el switch en el host

cr0x@server:~$ ip -s link show dev eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 5c:ba:ef:00:11:22 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    987654321  1234567      0     124       0  45678
    TX:  bytes packets errors dropped carrier collsns
    876543210  1122334      0       0       0       0

Qué significa: Paquetes RX descartados pueden ser congestión, límites de ring buffer o policing upstream. No es prueba de problemas VLAN, pero es una señal de alarma.

Decisión: Si los descartes suben durante las pruebas, investiga congestión del puerto del switch, driver de la NIC y desajustes de MTU.

Tarea 6: Confirma el MTU del puente y considera la sobrecarga VLAN

cr0x@server:~$ ip -d link show vmbr0 | egrep "mtu|vlan|bridge"
2: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    bridge vlan_filtering 1 vlan_default_pvid 1

Qué significa: El filtrado VLAN está activado (vlan_filtering 1). MTU 1500 está bien para la mayoría de redes VLAN pero puede morder si tu entorno espera tramas jumbo de extremo a extremo.

Decisión: Si ejecutas MTU 9000 en redes de almacenamiento/vMotion, aplica MTU consistente en NIC, puente y trunk del switch.

Tarea 7: tcpdump en el uplink para ver etiquetas VLAN (o su ausencia)

cr0x@server:~$ tcpdump -eni eno1 -c 10 vlan
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:01:11.123456 5c:ba:ef:00:11:22 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 100, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: DHCP, Request
10:01:11.223456 00:11:22:33:44:55 > 5c:ba:ef:00:11:22, ethertype 802.1Q (0x8100), length 370: vlan 100, p 0, ethertype IPv4, 10.10.100.1.67 > 10.10.100.50.68: DHCP, Reply

Qué significa: Puedes ver literalmente VLAN 100 en el cable. Esto responde inmediatamente “¿está el host etiquetando y recibiendo correctamente?”.

Decisión: Si no ves etiquetas VLAN saliendo del host, céntrate en la configuración del puente/ NIC de VM en Proxmox. Si ves etiquetas saliendo pero nada vuelve, céntrate en el trunk del switch y en el L2/L3 upstream.

Tarea 8: tcpdump en la interfaz tap de la VM para confirmar entrega sin etiqueta al invitado

cr0x@server:~$ tcpdump -eni tap100i0 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tap100i0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:02:01.100001 de:ad:be:ef:10:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 328: 0.0.0.0.68 > 255.255.255.255.67: DHCP, Request
10:02:01.200002 00:11:22:33:44:55 > de:ad:be:ef:10:00, ethertype IPv4 (0x0800), length 352: 10.10.100.1.67 > 10.10.100.50.68: DHCP, Reply

Qué significa: No hay 802.1Q aquí. Eso es esperado cuando Proxmox hace el etiquetado y el invitado es un “puerto de acceso”.

Decisión: Si ves 802.1Q en el tap cuando no lo esperas, configuraste passthrough de etiquetas o el invitado está etiquetando inesperadamente.

Tarea 9: Comprueba que el firewall de Proxmox no está descartando lo que crees que es “tráfico VLAN”

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

cr0x@server:~$ pve-firewall compile
root@pam: OK

Qué significa: El firewall está activo y compila. La VLAN en sí no suele ser “bloqueada por firewall”, pero DHCP, ARP o ICMP podrían serlo.

Decisión: Desactiva temporalmente el firewall en la NIC de la VM (no globalmente) para aislar. Si lo arregla, revisa las reglas: no era un problema de VLAN.

Tarea 10: Valida la resolución ARP en el namespace del host (una comprobación rápida de L2)

cr0x@server:~$ ip neigh show dev vmbr0 | head
10.10.10.1 lladdr 00:aa:bb:cc:dd:ee REACHABLE
10.10.10.50 lladdr de:ad:be:ef:10:00 STALE

Qué significa: El host ve vecinos en vmbr0 (probablemente la VLAN de gestión). Esto no prueba que VLAN 100 funcione, pero demuestra que el puente está vivo y hace L2.

Decisión: Si la tabla de vecinos está vacía y no puedes hacer ARP ni siquiera en gestión, arregla la conectividad base antes de trabajar con VLANs.

Tarea 11: Para modo trunk-to-guest, confirma que el invitado ve VLANs etiquetadas (lado host)

cr0x@server:~$ qm config 200 | egrep "net0|tag"
net0: virtio=DE:AD:BE:EF:20:00,bridge=vmbr0,firewall=0

cr0x@server:~$ tcpdump -eni tap200i0 -c 5 vlan
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tap200i0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:03:11.010101 de:ad:be:ef:20:00 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 200, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: DHCP, Request

Qué significa: El tap ve etiquetas VLAN, lo cual es esperado cuando el invitado está trunking/etiquetando.

Decisión: Si esperas modo trunk pero no ves etiquetas VLAN, el invitado no está etiquetando o Proxmox está quitando etiquetas por una configuración no intencionada.

Tarea 12: Revisa el estado del bond si usas uno (saneamiento LACP/active-backup)

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
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: 1
        Number of ports: 2
        Actor Key: 17
        Partner Key: 42
        Partner Mac Address: 00:25:90:12:34:56

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

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

Qué significa: LACP se negoció y ambos esclavos están arriba. Si falta Partner Key/MAC o sólo un esclavo está activo, la configuración del port-channel upstream puede ser incorrecta.

Decisión: Arregla la alineación LACP/port-channel antes de perseguir la configuración VLAN. Un bond roto puede tirar algunas VLANs “aleatoriamente” según el hashing y el comportamiento upstream.

Tarea 13: Confirma que Proxmox aplicó la configuración (sin estado runtime obsoleto)

cr0x@server:~$ ifreload -a
warning: vmbr0: interface is already configured
warning: eno1: interface is already configured

Qué significa: Se recargó; las advertencias pueden ser normales. Lo que quieres es: sin errores críticos y el estado runtime coincide con el archivo.

Decisión: Si la recarga falla o tienes miedo, planifica una ventana de mantenimiento y reinicia la red con cuidado. No improvises remotamente salvo que disfrutes sesiones sorpresa en consola.

Tarea 14: Revisa sysctl o nftables relacionados con VLAN (raro, pero real)

cr0x@server:~$ sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.bridge.bridge-nf-call-arptables
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-arptables = 1

Qué significa: El tráfico bridged se pasa por los hooks de iptables/nftables. Esto puede ser deseado (filtrado) o desastroso (descartes/latencia inesperada).

Decisión: Si no filtras tráfico bridged intencionalmente, considera desactivar estas opciones o auditar reglas del firewall cuidadosamente. “VLAN rota” a veces significa “netfilter del bridge se comió el DHCP”.

Tres microhistorias corporativas desde las trincheras VLAN

Microhistoria 1: El incidente causado por una suposición incorrecta

Una empresa mediana estaba consolidando racks. El equipo de virtualización movió un nodo Proxmox de un viejo stack de switches a una nueva leaf. El equipo de switches dijo: “El puerto está trunked, está bien.” El nodo Proxmox arrancó, la gestión funcionó, pero todas las VLANs de tenant en ese nodo estaban muertas.

El equipo de virtualización asumió que “trunked” significaba “todas las VLANs permitidas”. En la plantilla del nuevo switch, los trunks estaban restringidos a una pequeña lista de permitidos por defecto. La VLAN de gestión estaba incluida (porque todo necesita gestión), pero las VLANs de tenant no. El host etiquetó las tramas; el switch las descartó. Ambos se comportaron correctamente.

La situación empeoró porque el síntoma era selectivo: algunas VMs en el nodo podían hablar con “servicios compartidos” que accidentalmente estaban en la VLAN de gestión, así que los propietarios de apps reportaron problemas “intermitentes”. Alguien incluso sugirió “Proxmox es buggy con VLANs”. No lo era.

La solución fue aburrida: alinear la lista de VLANs permitidas con el rango de VLANs previsto por el hipervisor y documentarlo. La acción del postmortem que importó no fue “mejorar el monitoreo”. Fue “dejar de usar la palabra trunk sin especificar VLANs permitidas y comportamiento de VLAN nativa”.

Microhistoria 2: La optimización que se volvió en contra

Otra organización quiso reducir la “complejidad de red”. Decidieron que cada nodo Proxmox tendría un solo bond y cada puente ejecutaría una lista de VLAN recortada: sólo las VLANs en uso actualmente. La idea era reducir el blast radius si una VM se etiquetaba mal.

Funcionó—hasta que dejó de hacerlo. Un nuevo proyecto creó una VM en VLAN 240 y el equipo de VM etiquetó la NIC correctamente en Proxmox. Pero bridge-vids en vmbr0 sólo permitía 2-239. El Linux bridge filtró la VLAN antes de que siquiera llegara al switch. Desde la perspectiva del switch, no pasaba nada. Desde la perspectiva de Proxmox, nada “estaba mal”. Desde la perspectiva de la VM, el universo estaba en silencio.

El ticket rebotó entre equipos porque todos revisaron su propia capa: la configuración de la VM tenía tag=240, el trunk del switch permitía VLAN 240, el firewall tenía reglas, DHCP estaba listo. La pieza faltante fue que el bridge del host había sido “optimizado” para excluir VLANs futuras.

Mantuvieron el filtrado VLAN (bien), pero cambiaron la política: permitir un rango amplio de VLANs en los uplinks de nodo y controlar el acceso a VLANs de VM vía permisos de Proxmox y revisiones. Seguridad por listas de permiso desactualizadas no es seguridad. Es una bomba de tiempo.

Microhistoria 3: La práctica aburrida que salvó el día

Un equipo de servicios financieros ejecutaba Proxmox con control de cambios estricto. Cada nodo tenía una configuración de red estándar: bond0 (active-backup), vmbr0 para gestión, vmbr1 compatible con VLAN como trunk para invitados, y una pequeña “VM de validación de red” presente en cada nodo. Esa VM podía hacer solicitudes DHCP, hacer ping a gateways y emitir tramas etiquetadas a demanda.

Una mañana, todo un rack perdió conectividad sólo para la VLAN 310. No la gestión, no otras VLANs. Los logs del switch eran ruidosos pero inconclusos. La gente empezó a sospechar un cambio de ACL en el core.

El SRE de guardia usó la VM de validación en dos nodos: uno en el rack afectado y otro en un rack sano. Misma etiqueta VLAN, misma prueba DHCP, mismo objetivo de ping. Las capturas en los uplinks físicos mostraron que el rack afectado nunca recibía respuestas—no hubo DHCP Offer, no hubo respuesta ARP—mientras que el rack sano sí.

Esa prueba acotó el radio del fallo a “en algún punto entre ToR y upstream” en minutos. El equipo de switches encontró un miembro del port-channel con una configuración obsoleta que no permitía VLAN 310. Como el bond era active-backup, hacer failover al enlace activo movió el tráfico al miembro correctamente configurado y restauró el servicio rápidamente.

La práctica aburrida fue: configuraciones estandarizadas, una VM pequeña de validación y el hábito de capturar paquetes en el borde. No fue glamoroso. Fue efectivo, que es mejor.

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

1) No hay DHCP en una VM etiquetada, pero el enlace está arriba

Síntoma: La NIC de la VM aparece “conectada”, pero DHCP caduca. Los pings fallan.

Causa raíz: El puerto del switch es access VLAN (o el trunk no incluye la VLAN) mientras Proxmox está etiquetando, por lo que las tramas etiquetadas se descartan.

Solución: Configura el puerto del switch como trunk y permite la VLAN. Confirma con tcpdump -eni eno1 vlan que llegan las respuestas.

2) La VM habla en la red equivocada (conectividad sorpresa)

Síntoma: Una VM destinada a VLAN 200 obtiene una IP de la VLAN 1 o de la VLAN de gestión.

Causa raíz: Mismatch de VLAN nativa / PVID: el tráfico sin etiqueta se está mapeando a una VLAN no intencionada en algún punto (host o switch).

Solución: Decide qué significa sin etiqueta. Prefiere “sin tramas sin etiqueta” en trunks de producción. Asegúrate de que el uplink vmbr no use VLAN 1 como PVID a menos que sea intencional.

3) Solo una VLAN funciona; otras están muertas

Síntoma: VLAN 100 funciona, VLAN 200 no, en el mismo host/uplink.

Causa raíz: La lista de VLANs permitidas en el trunk está restringida, o bridge-vids excluye la VLAN.

Solución: Revisa bridge vlan show y la lista de permitidos del trunk en el switch. Amplía el conjunto permitido y vuelve a probar.

4) “Problemas VLAN intermitentes” en uplinks bondadosos

Síntoma: Pérdida aleatoria de paquetes, algunos flujos funcionan, otros no; peor bajo carga.

Causa raíz: Mismatch de LACP o miembros del port-channel mal configurados con VLANs/MTU/VLAN nativa inconsistentes.

Solución: Valida el estado del bond en /proc/net/bonding/* y asegura que los miembros del port-channel del switch sean idénticos. No aceptes “casi idénticos”.

5) Las capturas muestran sin etiquetas VLAN aunque pusiste tag=100

Síntoma: tcpdump en eno1 no muestra 802.1Q.

Causa raíz: Confusión por offload VLAN/punto de captura, o el tráfico nunca sale porque el filtrado del puente lo bloquea.

Solución: Captura tanto en el tap como en el uplink físico; verifica bridge vlan show. Si hace falta, desactiva temporalmente VLAN offload (durante el diagnóstico) y vuelve a probar.

6) Invitados en la misma VLAN no se comunican entre sí

Síntoma: Dos VMs en VLAN 300 pueden alcanzar el gateway a veces, pero no entre ellas de forma fiable.

Causa raíz: Reglas del firewall de Proxmox, ebtables/nft filtering o STP/protección contra bucles bloqueando switching intra-host.

Solución: Desactiva temporalmente el firewall de la VM, confirma que L2 funciona y luego reintroduce reglas con cuidado. Revisa los sysctls de bridge netfilter.

7) Contenedores (LXC) se comportan distinto que VMs

Síntoma: VM etiquetada funciona; contenedor etiquetado no (o viceversa).

Causa raíz: El contenedor usa comportamiento de interfaz virtual distinto y puedes estar etiquetando en la capa equivocada (config del contenedor vs puerto del bridge).

Solución: Estandariza: etiqueta en la veth del host (lado host) o dentro del contenedor, no en ambas, y confirma con bridge vlan show.

8) Migración a otro nodo rompe la red de la VM

Síntoma: La VM funciona en el nodo A, falla en el nodo B.

Causa raíz: Configuración de red inconsistente entre nodos: puente no compatible con VLAN, bond/trunk diferente, VLANs faltantes en la lista permitida.

Solución: Trata la red de Proxmox como configuración a nivel de clúster. Mismos nombres de vmbr, mismas opciones VLAN-aware y mismo comportamiento de trunk físico en todas partes.

Listas de verificación / plan paso a paso

Paso a paso: Construir un puente compatible con VLAN en un uplink único

1. Decide el modelo: el host etiqueta por NIC de VM (recomendado) o el invitado se etiqueta (trunk-to-guest). Escríbelo. Esto evita el doble etiquetado.
2. Configura el puerto del switch: trunk, permite las VLANs que vas a usar, establece la VLAN nativa intencionalmente (o efectivamente desactiva sin etiqueta). Mantén el MTU consistente.
3. Configura el puente en Proxmox: Linux bridge con bridge-vlan-aware yes. Opcionalmente fija bridge-vids a un rango sensato.
4. Conecta NICs de VM: para estilo access, establece tag=VLANID en cada NIC de VM. Para trunk-to-guest, deja la etiqueta vacía.
5. Valida con capturas: confirma etiquetas en el uplink físico y tramas sin etiqueta en el tap para VMs en modo access.
6. Fija la consistencia: replica en todos los nodos. La inconsistencia es cómo las migraciones se vuelven outages.

Checklist: Antes de culpar a las VLANs

• ¿El enlace físico es estable? (ethtool, ip -s link)
• ¿El puente está realmente filtrando VLAN? (bridge vlan show)
• ¿La NIC de la VM está etiquetada en exactamente un lugar? (Proxmox o invitado)
• ¿El trunk del switch permite la VLAN? (no basta con “está trunked”)
• ¿Ves DHCP Offer/ARP replies en la captura del uplink?
• ¿El MTU es consistente extremo a extremo para la VLAN?
• ¿El filtrado del firewall está afectando el tráfico bridged inesperadamente?

Checklist: Procedimiento de cambio seguro para nodos de producción

• Programa una ventana si vas a tocar bridge-ports, bonds o recargar la red.
• Tén acceso por consola fuera de banda listo. Hacer cambios de red solo remotamente es una opción de vida.
• Cambia una variable a la vez: lista permitida del switch, luego puente en el host, luego etiquetas de VM.
• Captura antes/después en el uplink físico. Es tu suero de la verdad.
• Tras los cambios, prueba: DHCP, ping al gateway, ping entre VMs y una pequeña sesión TCP.

Preguntas frecuentes

1) ¿Necesito Open vSwitch para que las VLANs funcionen en Proxmox?

No. Linux bridge con VLAN-aware habilitado es suficiente para la mayoría de despliegues. OVS es útil si necesitas sus funciones o su modelo operativo, no como un parche para VLANs.

2) ¿Qué cambia realmente “VLAN aware”?

Activa el filtrado VLAN en el Linux bridge, permitiendo membresía VLAN por puerto y dejando que Proxmox programe el comportamiento access/trunk por NIC de VM.

3) ¿Debería poner bridge-vids 2-4094?

En producción, sí—a menos que tengas una razón para restringirlo. Evita problemas tipo “VLAN no pasa porque está fuera del rango permitido” cuando alguien añada una VLAN nueva más tarde.

4) ¿Por qué mi VM pierde conectividad después de una migración en caliente?

El nodo destino probablemente tiene ajustes de bridge VLAN distintos, una lista permitida del trunk upstream diferente o un mapeo vmbr distinto. Haz la red de los nodos idéntica para cualquier workload migrable.

5) ¿Dónde debe ocurrir el etiquetado VLAN: en Proxmox o dentro del invitado?

Elige uno. Para VMs normales, etiqueta en Proxmox (más simple, control central). Para VMs router/firewall/appliance que necesitan múltiples VLANs, etiqueta dentro del invitado y pasa el trunk.

6) ¿Por qué tcpdump a veces no muestra etiquetas VLAN cuando las espero?

El offload VLAN puede hacer que las etiquetas las gestione el hardware, volviendo confusas las capturas según la interfaz y el driver. Captura en múltiples puntos (tap y físico) y correlaciona con bridge vlan show.

7) ¿El firewall de Proxmox puede romper DHCP en una VLAN?

Sí. DHCP es muy dependiente de broadcasts y sensible al filtrado. Si el tráfico bridged pasa por hooks netfilter, una regla puede tirar DHCP o ARP y parecer que “la VLAN está rota”.

8) ¿Las VLANs requieren MTU mayor?

No necesariamente. MTU estándar 1500 funciona con etiquetado VLAN en la mayoría de entornos. Los problemas aparecen cuando intentas usar jumbo frames y algún enlace en la ruta no está configurado igual.

9) Mi switch dice que el puerto está trunking, pero la VLAN sigue fallando. ¿Qué debo pedir?

Pide: lista de VLANs permitidas, VLAN nativa y confirmación de que todos los miembros del port-channel tienen VLAN/MTU idénticos. “Está trunked” no es una respuesta.

10) ¿Es seguro pasar tráfico de gestión por el mismo puente compatible con VLAN que usan los invitados?

PUEDE serlo, pero no es mi favorito. Separa la gestión (vmbr0) de los trunks de invitados (vmbr1) cuando puedas. Reduce el blast radius y facilita el diagnóstico.

Conclusión: próximos pasos para evitar reincidencias

Arreglar un problema VLAN en Proxmox rara vez se trata de “la configuración mágica correcta”. Se trata de dejar explícito el contrato de etiquetado: quién etiqueta, dónde está permitido y qué significa sin etiqueta. Una vez que puedes señalar una captura de paquetes y decir “esto es VLAN 100 saliendo del host”, las discusiones terminan y la ingeniería continúa.

Haz lo siguiente:

1. Estandariza la red de los nodos en todo el clúster (mismos nombres vmbr, ajustes VLAN-aware y comportamiento de bond).
2. Documenta expectativas de trunks en switches en lenguaje operativo: VLANs permitidas, VLAN nativa, MTU, política LACP.
3. Añade una rutina de validación repetible: una VM conocida o un script que pueda DHCP/ping en una VLAN especificada, más una receta de captura.
4. Haz difícil el doble etiquetado por política: o Proxmox etiqueta VLANs de acceso, o el invitado hace trunk—nunca ambos.

Si no haces otra cosa, recuerda esto: el debugging de VLAN es simplemente comprobar si la etiqueta en la que crees es la etiqueta que realmente está en el cable.