VLAN en Proxmox no funciona: puertos trunk, etiquetado de bridge Linux y soluciones “sin red”

El modelo mental que evita adivinanzas

Cuando las VLAN “no funcionan” en Proxmox rara vez es misterioso. Normalmente es uno de estos:

• Las tramas no están etiquetadas cuando crees que lo están. La VM envía sin tag, el bridge espera tag, o viceversa.
• Las tramas están etiquetadas, pero se descartan. La tabla VLAN del bridge, la lista permitida del switch o un ACL ascendente las descarta.
• Las tramas pasan, pero L2/L3 falla. ARP no es respondido, la puerta de enlace está en otra VLAN, o tienes enrutamiento asimétrico.
• Todo funciona… hasta que deja de funcionar. Un reinicio cambia el orden de interfaces, VLAN filtering se alterna, LACP re-negocia, o la plantilla del puerto del switch “amablemente” resetea la configuración.

Piénsalo por capas, no por sensaciones:

1. L1: enlace activo, velocidad/duplex, ópticas, estado del bonding.
2. L2: tags VLAN, tabla VLAN del bridge, aprendizaje de MAC, estado STP.
3. L3: direccionamiento IP, puerta de enlace, ARP/ND, enrutamiento, firewall.

Proxmox complica esto porque mezcla la red del host (gestión, almacenamiento) con el switching de invitados del hipervisor (NICs de VM). Los bridges de Linux son switches reales con tablas de reenvío reales. Trátalos como tal.

Una cita para tener en la pared: “La esperanza no es una estrategia.” — General Gordon R. Sullivan. La red no recompensa el optimismo.

Guion de diagnóstico rápido (primero/segundo/tercero)

Primero: demuestra si los tags existen en el cable

Tu primera tarea es dejar de teorizar y observar la realidad.

• En el host Proxmox, ejecuta tcpdump en la NIC física o bond y busca vlan en las tramas.
• Si faltan tags: es un problema de Proxmox/bridge/VM.
• Si los tags están presentes: es un problema de trunk/allowed VLANs/PVID en el switch, o una política upstream.

Segundo: confirma el VLAN filtering y la pertenencia en el bridge

Los bridges de Linux pueden ignorar las tablas VLAN (modo clásico) o aplicarlas (VLAN-aware). Mezclar expectativas causa el síntoma “sin red” con configuraciones que parecen correctas.

• Comprueba vlan_filtering en el bridge y la pertenencia VLAN por puerto.
• Verifica cuál puerto es el uplink, cuál es el tap de la VM y qué IDs VLAN están permitidos.

Tercero: valida lo básico de L3 y las cosas aburridas

Una vez que L2 está bien, las fallas que quedan suelen ser:

• Puerta de enlace equivocada o máscara de subred incorrecta en el invitado.
• Fallo de ARP por firewall, IP duplicada, o dispositivo upstream respondiendo ARP en la VLAN equivocada.
• Desajuste de MTU—especialmente con VLAN + bond + redes de almacenamiento.

Si sólo recuerdas una cosa: el camino más rápido es “¿está presente el tag?” → “¿está permitido?” → “¿se responde ARP?”

Hechos y contexto interesantes (sí, importan)

Esto no es trivia por trivia. Cada punto corresponde a un modo de fallo real que he visto en producción.

1. El etiquetado 802.1Q añade 4 bytes a una trama Ethernet. Ese pequeño header es por qué los problemas de MTU aparecen “solo en VLANs”.
2. El bridging en Linux tiene décadas y precede a muchas envolturas modernas tipo “SDN”. Bajo Proxmox sigue siendo el kernel de Linux quien hace el switching.
3. El modo bridge VLAN-aware es relativamente nuevo comparado con el bridging clásico y se comporta como un switch gestionado: si una VLAN no está en la tabla, puede ser descartada silenciosamente.
4. El concepto de “native VLAN” es convención del switch, no una característica de la VLAN. Native VLANs desalineadas hacen que tráfico sin tag caiga en el sitio equivocado sin errores.
5. Las primeras implementaciones de VLAN buscaban contener broadcast, no seguridad. Hoy la gente trata las VLAN como zonas de seguridad; eso sólo es cierto si aplicas políticas L3/L4.
6. LACP no “balancea” por paquete por defecto en muchos sistemas; hace hashing por flujos. Por eso “una VM va lenta, otra va bien” ocurre en trunks bondedeados.
7. STP y VLANs están entrelazados: según el modo del switch (PVST/RPVST/MST), una VLAN puede estar bloqueada mientras otras reenvían, creando “solo VLAN 30 está muerta”.
8. ARP es ruidoso y frágil. Muchos incidentes de “VLAN rota” son en realidad respuestas ARP filtradas por firewall, seguridad upstream o IPs duplicadas.
9. Proxmox históricamente se apoyó en ifupdown-style; sistemas más nuevos usan ifupdown2 y pueden aplicar cambios en vivo, pero no todos los cambios son igual de seguros sin una ventana de mantenimiento.

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

Estas son las tareas que ejecuto, en este orden aproximado, cuando una VM dice “sin red” en una VLAN. Cada una incluye: comando, qué significa una salida típica y qué decisión tomar a continuación.

Tarea 1: Confirma que el host ve enlace y qué NIC es cuál

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp3s0           UP             3c:ec:ef:11:22:33 <BROADCAST,MULTICAST,UP,LOWER_UP>
enp4s0           DOWN           3c:ec:ef:11:22:34 <BROADCAST,MULTICAST>
bond0            UP             3c:ec:ef:aa:bb:cc <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP>
vmbr0            UP             3c:ec:ef:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP>

Significado: bond0 y vmbr0 están arriba; una NIC física está abajo. Si pensabas que tenías dos enlaces activos, no es así.

Decisión: Arregla la salud del enlace/bond antes de tocar la configuración VLAN. Depurar VLAN en un uplink que está flapping es autolesión.

Tarea 2: Revisa la salud del bonding (LACP vs active-backup y qué esclavo está activo)

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

Slave Interface: enp3s0
MII Status: up
Actor Churn State: churned
Partner Churn State: churned

Slave Interface: enp4s0
MII Status: down

Significado: LACP está configurado, pero un esclavo está abajo y los estados churn sugieren renegociación.

Decisión: Revisa la configuración LACP del switch y el cableado. Si el switch espera un trunk estático pero el host usa LACP, tendrás rarezas intermitentes en las VLANs.

Tarea 3: Inspecciona la configuración de red de Proxmox (fuente de la verdad)

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

auto bond0
iface bond0 inet manual
        bond-slaves enp3s0 enp4s0
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer3+4

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

Significado: Bridge con VLAN-aware habilitado; el uplink es bond0; la IP de gestión está sin tag en vmbr0 (por tanto está en la VLAN nativa/untagged que llegue por el trunk).

Decisión: Si tu red de gestión debe estar etiquetada, muévela a una subinterfaz (ej., vmbr0.10) o ajusta expectativas de PVID. Gestión sin tag en un trunk es la forma de llevarte sorpresas luego.

Tarea 4: Confirma que el VLAN filtering del bridge está realmente activo

cr0x@server:~$ ip -d link show vmbr0
7: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:aa:bb:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
    bridge forward_delay 0 hello_time 2 max_age 20 ageing_time 300 stp_state 0 priority 32768 vlan_filtering 1 vlan_protocol 802.1Q

Significado: vlan_filtering 1 significa que el bridge aplicará reglas de pertenencia VLAN.

Decisión: Debes verificar la tabla VLAN a continuación. En modo VLAN-aware, “está conectado a vmbr0” no es suficiente.

Tarea 5: Volcar la pertenencia VLAN por puerto del bridge

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

Significado: El uplink bond0 tiene las VLANs 10 y 20 tagged, y VLAN 1 sin tag (nativa). Los puertos tap de VM son miembros sin tag con PVID por VM.

Decisión: Si la VM debe etiquetar ella misma (guest VLAN tagging), su puerto tap normalmente debería portar VLANs etiquetadas, no PVID-untagged. Decide quién etiqueta: host o invitado. No hagas ambos.

Tarea 6: Identificar qué dispositivo tap corresponde a qué VM

cr0x@server:~$ qm list
      VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID
       100 app-01               running    4096              32.00 2101
       101 db-01                running    8192             128.00 2255

Significado: Los VMIDs 100/101 probablemente corresponden a tap100i0 y tap101i0.

Decisión: Si la VM equivocada está en la VLAN equivocada, verifica la configuración de hardware de la VM en Proxmox: tag en la NIC, selección de bridge, bandera de firewall.

Tarea 7: Confirma que la NIC de la VM está etiquetada como se espera en Proxmox

cr0x@server:~$ qm config 100 | sed -n '1,120p'
boot: order=scsi0;net0
memory: 4096
name: app-01
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,tag=10,firewall=0
scsi0: local-lvm:vm-100-disk-0,size=32G

Significado: Proxmox aplica el tag para la VM 100 (VLAN 10). El invitado debe configurarse con una NIC sin tag.

Decisión: Si el invitado también etiqueta VLAN 10 internamente, habrás doble-etiquetado. Arregla un lado.

Tarea 8: Captura tráfico en el uplink y verifica tags VLAN

cr0x@server:~$ sudo tcpdump -eni bond0 -c 8 '(arp or icmp) and (vlan 10)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:10.112233 DE:AD:BE:EF:10:00 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), vlan 10, ethertype ARP (0x0806), Request who-has 10.10.10.1 tell 10.10.10.50, length 46
12:01:10.113005 00:11:22:33:44:55 > DE:AD:BE:EF:10:00, ethertype 802.1Q (0x8100), vlan 10, ethertype ARP (0x0806), Reply 10.10.10.1 is-at 00:11:22:33:44:55, length 46

Significado: Los tags VLAN 10 están presentes en el cable. ARP es respondido. L2 probablemente está bien para esta VLAN.

Decisión: Si la VM aún no alcanza nada, mira la configuración IP del invitado, el firewall del host o el enrutamiento upstream. Si ves solicitudes ARP pero no respuestas, revisa la pertenencia VLAN del switch o la presencia de la puerta de enlace.

Tarea 9: Captura en el tap de la VM para ver qué “ve” el invitado

cr0x@server:~$ sudo tcpdump -eni tap100i0 -c 6 arp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tap100i0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:02:44.000111 DE:AD:BE:EF:10:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), Request who-has 10.10.10.1 tell 10.10.10.50, length 46
12:02:44.000890 00:11:22:33:44:55 > DE:AD:BE:EF:10:00, ethertype ARP (0x0806), Reply 10.10.10.1 is-at 00:11:22:33:44:55, length 46

Significado: El tap orientado al invitado está sin tag (esperado, ya que Proxmox etiqueta en egress hacia el uplink). ARP funciona.

Decisión: Si ARP funciona aquí pero no en bond0, las reglas de tagging/bridge VLAN están mal. Si ARP funciona en ambos, enfócate en L3.

Tarea 10: Verifica aprendizaje MAC y tabla de reenvío (FDB) por VLAN

cr0x@server:~$ bridge fdb show br vmbr0 | head -n 12
00:11:22:33:44:55 dev bond0 vlan 10 master vmbr0 permanent
de:ad:be:ef:10:00 dev tap100i0 master vmbr0
de:ad:be:ef:20:00 dev tap101i0 master vmbr0

Significado: La MAC de la puerta de enlace está aprendida/forzada en VLAN 10 vía bond0. La MAC de la VM está aprendida en el tap.

Decisión: Si falta la MAC de la puerta de enlace, el switch/puerta de enlace puede no ser alcanzable en esa VLAN. Si la MAC de la VM no aparece, la VM no está transmitiendo o está conectada al bridge equivocado.

Tarea 11: Revisa si hay firewall en el host o sorpresas de bridge netfilter

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 = 0

Significado: El tráfico bridged puede atravesar reglas de iptables. A veces eso es deseado, a veces es un triturador silencioso de paquetes.

Decisión: Si no filtras intencionalmente tráfico bridged, considera deshabilitar bridge-nf calls o auditar reglas. Si sí filtras, confirma que las reglas incluyen las interfaces VLAN/taps correctamente.

Tarea 12: Valida MTU de extremo a extremo (host, bridge, ruta VM)

cr0x@server:~$ ip -br link show bond0 vmbr0
bond0            UP             3c:ec:ef:aa:bb:cc <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500
vmbr0            UP             3c:ec:ef:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

Significado: MTU es 1500. Si tu upstream es 9000 (jumbo) o tu VM espera 1500 pero algo intermedio está a 1496 por configuraciones extrañas, tendrás fragmentación/PMTUD problemática.

Decisión: Elige un MTU por dominio. Para trunks VLAN que llevan tráfico jumbo de almacenamiento, ajusta MTU consistentemente en NICs físicas, bonds, bridges y puertos del switch. Si no, quédate con 1500 y duerme tranquilo.

Tarea 13: Revisa enrutamiento y tabla de vecinos en el host (para IPs etiquetadas en host)

Si el host Proxmox tiene una subinterfaz VLAN (común para gestión), verifica la resolución de vecinos.

cr0x@server:~$ ip neigh show dev vmbr0
10.10.10.1 lladdr 00:11:22:33:44:55 REACHABLE
10.10.10.50 lladdr de:ad:be:ef:10:00 STALE

Significado: ARP funciona en vmbr0. Si ves entradas FAILED, L2 está roto o filtrado.

Decisión: Si los vecinos fallan sólo en una VLAN, revisa la tabla VLAN del bridge y las VLANs permitidas en el switch. Si fallan en general, revisa enlace/bond y estado del puerto del switch.

Tarea 14: Verifica que el camino del invitado no esté bloqueado por flags de firewall en Proxmox

cr0x@server:~$ pvesh get /nodes/server/qemu/100/config | sed -n '1,40p'
boot: order=scsi0;net0
memory: 4096
name: app-01
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,firewall=0,tag=10

Significado: El firewall está desactivado para la NIC de la VM. Si está activado, las reglas pueden estar bloqueando DHCP/ARP/ICMP.

Decisión: Si habilitas firewall, permite explícitamente DHCP (67/68), ARP (L2) y protocolos necesarios, o depurarás “problemas VLAN” que en realidad son políticas.

Patrones de configuración en Proxmox que realmente funcionan

Hay dos formas sensatas de hacer VLANs para VMs en Proxmox. Elige una. Mezclarlas es la forma de crear un santuario al packet loss.

Patrón A: Proxmox etiqueta por NIC de VM (recomendado para la mayoría)

Este es el campo “VLAN tag” en la config de la NIC de la VM. El invitado ve una NIC sin tag. Proxmox la coloca en una VLAN etiquetando las tramas en el uplink del bridge.

Por qué funciona: Centralizas la asignación de VLAN en el hipervisor. Los invitados se mantienen simples. La migración entre hosts es predecible.

Requisitos del bridge:

• bridge-vlan-aware yes en el bridge
• bridge-vids incluye los IDs VLAN que necesitas (o configurado vía la tabla vlan del bridge)
• El puerto del switch es un trunk que lleva esas VLANs

Patrón B: El invitado etiqueta VLANs (solo cuando hay razón)

A veces una VM es un router, firewall o appliance que necesita múltiples VLANs en una NIC. Entonces el invitado etiqueta VLANs por su cuenta (ej., eth0.10, eth0.20).

Configuración del host: La NIC de la VM no debe tener un tag. El puerto tap debe permitir tramas etiquetadas, y gestionas las VLANs permitidas en la tabla del bridge y en el trunk del switch.

Regla general: Si no estás construyendo una VM router/firewall, no hagas guest VLAN tagging. Añade complejidad innecesaria y hace que los incidentes “sin red” sean más creativos de lo necesario.

IP de gestión del host en una VLAN: hazlo limpio

Si tu red de gestión Proxmox está etiquetada (común en entornos corporativos), no confíes en “trunk sin tag = la VLAN correcta”. Hazlo explícito con una interfaz VLAN sobre el bridge. Ejemplo:

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

auto bond0
iface bond0 inet manual
        bond-slaves enp3s0 enp4s0
        bond-miimon 100
        bond-mode 802.3ad

auto vmbr0
iface vmbr0 inet manual
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 10 20 30

auto vmbr0.10
iface vmbr0.10 inet static
        address 10.10.10.11/24
        gateway 10.10.10.1

Beneficio operativo: Cuando alguien cambia la “native VLAN” del switch, tu host no se teletransporta a otra red. Permanece en VLAN 10 porque etiqueta.

Broma corta #1: Una native VLAN es como “reglas de firewall temporales”—nadie recuerda que existe hasta que arruina tu día.

No te compliques: un bridge por uplink suele ser suficiente

La gente crea múltiples bridges (vmbr0, vmbr1, vmbr2) para cada VLAN porque parece ordenado. También multiplica puntos de fallo, hace los trunks más difíciles de razonar y complica migraciones.

Usa un solo bridge VLAN-aware para un uplink y etiqueta en la NIC de la VM. Añade más bridges solo cuando realmente tengas dominios físicos separados o necesites MTUs o propiedades de seguridad distintas.

Comprobaciones de sanity del trunk en el switch

Seamos claros: la mitad de los tickets de VLAN en Proxmox son en realidad tickets del switch con piel de Linux. Puedes hacer todo bien en el host y fallar porque el trunk no está realmente trunking.

Qué necesitas del puerto del switch

• Modo trunk (o equivalente): el puerto debe aceptar tramas etiquetadas.
• Lista de VLANs permitidas: incluye las VLANs que necesitan tus VMs. “Todas las VLANs” es fácil pero a veces prohibido por política.
• Alineación de native VLAN: si usas tráfico sin tag, define a qué VLAN se mapea. Mejor: evita sin tag excepto por razones explícitas.
• Consistencia LACP: si haces bond, ambos lados deben acordar LACP vs agregación estática.
• Comportamiento STP: los puertos trunk pueden bloquearse si STP detecta loops. Vigila modos de bloqueo por VLAN en algunas familias de switch.

Los dos desajustes de trunk que más tiempo consumen

Desajuste 1: Las VLANs permitidas no incluyen tu VLAN. Tu host etiqueta VLAN 20; el switch descarta VLAN 20. En el host verás tags saliendo pero no respuestas. Clásico.

Desajuste 2: Native VLAN desalineada. Tu host envía tráfico sin tag esperando VLAN 10; el switch lo mapea a VLAN 1. Tu host mantiene enlace, pero está en otro planeta.

Broma corta #2: Los desajustes de VLAN son el único sitio donde “funciona en mi máquina” se traduce a “está roto en el switch”.

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

1) Síntoma: La VM no obtiene lease DHCP en la VLAN, pero con IP estática tampoco hace ping a la puerta de enlace

Causa raíz: VLAN no permitida en el trunk del switch o falta la pertenencia VLAN en la tabla del bridge.

Solución: Añade la VLAN a la lista permitida del switch y asegúrate de bridge-vlan-aware yes además de que la VLAN aparezca en bridge vlan show. Valida con tcpdump -eni bond0 vlan X.

2) Síntoma: La VM puede hacer ping a la puerta de enlace pero no a otras subredes

Causa raíz: Puerta de enlace equivocada en el invitado, ruta faltante upstream, o enrutamiento asimétrico causado por puertas de enlace/firewalls multi-homed.

Solución: Verifica la ruta por defecto del invitado, luego traza desde el lado de la puerta de enlace. Si tienes múltiples interfaces VLAN en un firewall, revisa políticas y tablas de enrutamiento por VLAN.

3) Síntoma: Solo un nodo Proxmox tiene VLANs funcionales; los demás no

Causa raíz: Los puertos del switch difieren (VLANs permitidas, native VLAN, modo LACP), o las configuraciones del host se han desviado (vlan filtering activado en uno pero no en el otro).

Solución: Compara /etc/network/interfaces, ip -d link y bridge vlan show entre nodos. Los puertos del switch deben usar el mismo perfil.

4) Síntoma: La VLAN funciona hasta que la VM se migra en caliente, luego muere

Causa raíz: La tabla VLAN del bridge del nodo destino carece de la VLAN, o el trunk del uplink difiere.

Solución: Trata la pertenencia VLAN como intención a nivel de cluster: estandariza la config del bridge y la del switch por nodo. Prueba migraciones con una VM canaria por VLAN.

5) Síntoma: El acceso de gestión al host desaparece tras activar bridge VLAN-aware

Causa raíz: La IP de gestión del host estaba sin tag en el bridge y dependía de una native VLAN; al habilitar filtering cambió el manejo, o el PVID/untagged no era lo que pensabas.

Solución: Mueve la gestión a una subinterfaz etiquetada (vmbr0.10) y asegúrate de que el trunk del switch permita VLAN 10. Programa ventana de mantenimiento y usa acceso fuera de banda.

6) Síntoma: Parte del tráfico funciona (pings pequeños), pero transferencias grandes se estancan

Causa raíz: Desajuste de MTU con overhead VLAN, o PMTUD bloqueado por firewall.

Solución: Estandariza MTU; permite mensajes ICMP fragmentation-needed si hay enrutamiento. Prueba con ping -M do -s desde el invitado.

7) Síntoma: VLAN 1 funciona, VLAN 10/20 no

Causa raíz: El trunk del switch es en realidad un puerto access, o la lista de VLANs permitidas está equivocada.

Solución: Reconfigura el switch a trunk y permite las VLANs. Verifica tags en el cable con tcpdump; si nunca ves tags saliendo, el tagging en host/bridge está mal.

8) Síntoma: Salen solicitudes ARP, pero nunca vuelven respuestas ARP

Causa raíz: VLAN bloqueada en el trunk, puerta de enlace no en esa VLAN, o característica de seguridad upstream (dynamic ARP inspection, port security) que descarta las respuestas.

Solución: Confirma la VLAN de la interfaz de la puerta de enlace; revisa características de seguridad del switch; valida aprendizaje de MAC. En el host, usa tcpdump para ver si las respuestas llegan a bond0.

Listas de verificación / plan paso a paso

Paso a paso: consigue una VLAN funcionando de extremo a extremo (método repetible)

1. Elige una VLAN de prueba (p. ej., VLAN 20) y una VM de prueba con IP/puerta de enlace de confianza.
2. Verifica el trunk del switch: modo trunk, VLAN 20 permitida, native VLAN correcta (o sin dependencia de sin-tag).
3. Verifica uplink del host: enlace arriba, bond correcto, sin flapping.
4. Verifica modo del bridge: VLAN-aware habilitado si confías en tags del host.
5. Verifica config NIC de la VM: tag=20 si el host etiqueta; si no, sin tag si el invitado etiqueta.
6. Verifica la tabla VLAN del bridge incluyendo VLAN 20 en uplink y comportamiento correcto del tap de VM.
7. Observa ARP en tres puntos: tap, bridge/uplink y (si es posible) lado del switch/puerta de enlace.
8. Prueba L3 con ping a la puerta de enlace; luego prueba más allá de la puerta de enlace.
9. Testea MTU si hay rendimiento o paquetes grandes en juego.
10. Solo después de que funcione, escala a más VLANs y automatización.

Checklist pre-cambio (antes de tocar VLANs en producción)

• Acceso consola fuera de banda funciona (IPMI/iDRAC/iLO) y credenciales actualizadas.
• La configuración del puerto del switch está respaldada o capturada (incluso un snippet pegado sirve).
• Existe ventana de mantenimiento o plan de rollback: revertir /etc/network/interfaces y reiniciar networking puede dejarte aislado.
• Sabe si usas etiquetado por Proxmox o por invitado. Escríbelo.
• Confirma si el firewall de Proxmox está activado a nivel datacenter/nodo/VM y si bridge netfilter está habilitado.

Checklist post-cambio (prueba que realmente está arreglado)

• La VM obtiene DHCP (si aplica) y puede renovar lease.
• La VM puede hacer ping a la puerta de enlace y al menos a una IP más allá de la puerta de enlace.
• Prueba de migración: live-migra la VM a otro nodo y vuelve a probar conectividad.
• Prueba de reinicio (si está permitido): confirma que la VLAN sobrevive al reinicio del nodo.
• Captura evidencia: un snippet de tcpdump mostrando tag VLAN presente y respuestas ARP recibidas.

Tres mini-historias corporativas desde el terreno

Mini-historia 1: El incidente causado por una suposición equivocada

Estaban migrando unas “bajas en riesgo” VMs a un nuevo cluster Proxmox. El equipo de red había provisto dos puertos de switch por host, agrupados en LACP, y dijo las palabras mágicas: “Es un trunk.” El equipo de virtualización asintió, habilitó bridges VLAN-aware, asignó tags por VM y siguió con su trabajo.

Dos horas después empezó la primera oleada de migraciones. La mitad de las VMs arrancaron bien. Las demás mostraban “sin red” dentro del invitado. El equipo hizo lo que los equipos hacen bajo presión: cambiaron tres cosas a la vez—rebootearon VMs, recargaron servicios de red, togglearon flags de firewall—y empeoraron la evidencia.

La suposición equivocada fue sutil: “trunk” significaba “todas las VLANs” para el equipo de virtualización, pero el switch sólo permitía un subconjunto. Las VMs que funcionaron vivían en VLANs permitidas; las rotas no. Nada en el host parecía “caído”. Enlace arriba, bonds arriba, bridges arriba. Fue la falla más limpia que puede ofrecer una red: descartado silencioso de tags VLAN no autorizados.

La solución fue aburrida e inmediata: alinear las listas de VLAN permitidas en cada port-channel de host, y estandarizar una checklist: cuando se introduce una VLAN nueva, actualizar tanto la permisividad del bridge en Proxmox como la lista permitida del trunk en el switch como un único cambio.

También añadieron una VM canaria por VLAN que comprobaba continuamente ARP y alcance a la puerta de enlace. No es glamoroso, pero hace que la próxima suposición equivocada sea ruidosa en vez de cara.

Mini-historia 2: La optimización que salió mal

Un ingeniero orientado al rendimiento decidió “simplificar y acelerar” creando bridges Linux separados por VLAN, cada uno enlazado al mismo bond uplink, y luego conectando las VMs al bridge específico. La lógica sonaba ordenada: menos reglas VLAN, menos complejidad, diagramas más limpios. También hizo el sistema más difícil de operar.

El primer problema apareció durante mantenimiento. Un cambio en el switch alteró temporalmente la native VLAN en el trunk. Uno de esos bridges llevaba gestión sin tag—porque “la gestión no necesita tags, está en la native VLAN.” La IP de gestión del host acabó en otra VLAN, y el nodo desapareció del monitoring. No caído. Solo… reubicado.

El segundo problema llegó con las migraciones. Algunos nodos tenían definiciones de bridge ligeramente distintas, y una VM migrando de nodo A a nodo B acabó conectada a un bridge existente pero no plumbed igual. La conectividad se volvió un rasgo de personalidad por nodo.

En la limpieza post-incidente, volvieron a un solo bridge VLAN-aware por uplink y usaron tags por VM en Proxmox. Movieron la gestión del host a una subinterfaz etiquetada explícita. El rendimiento no empeoró. La claridad operativa mejoró dramáticamente.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Otra organización tenía la costumbre casi anticuada de: cada nodo Proxmox tenía un bloque de red idéntico, almacenado en gestión de configuración, y los puertos del switch se aprovisionaban vía plantilla estándar. Seguían teniendo incidentes—todos los tienen—pero el radio de impacto era más pequeño.

Una tarde, introdujeron una VLAN nueva para una app de negocio. La VLAN se añadió al firewall y al switching core, pero no a los puertos de acceso que alimentaban dos de los cuatro hypervisors. Las VMs en esos dos nodos no alcanzaban su puerta de enlace; las VMs en los otros nodos sí.

Aquí la práctica aburrida rindió frutos: el on-call siguió el guion rápido, comparó las VLANs permitidas entre los puertos y encontró la descoincidencia en minutos. No hubo debate prolongado sobre si Proxmox “soporta esa VLAN” o si el driver del invitado “se comporta raro”. La evidencia fue clara porque la línea base era consistente.

La solución fue una única actualización de plantilla del switch y re-aplicar. Luego añadieron a su checklist de cambios: “Agregar VLAN a trunks de hypervisor” como ítem explícito. No es ingenioso, pero es el tipo de aburrimiento que mantiene tus horarios de sueño intactos.

Preguntas frecuentes (FAQ)

1) ¿Debo usar bridges VLAN-aware en Proxmox?

Sí, si estás usando Proxmox para etiquetar tráfico de VM (caso común). Los bridges VLAN-aware hacen que el bridge Linux se comporte como un switch real con pertenencia VLAN, lo que evita filtraciones accidentales y hace el etiquetado determinista.

2) Mi VM está etiquetada en Proxmox. ¿Debe el NIC del invitado crear subinterfaces VLAN?

No. Si Proxmox aplica tag=10 en la NIC de la VM, el invitado debe tratar esa NIC como sin tag. Las subinterfaces VLAN en el invitado son para casos en que la VM necesita portar múltiples VLANs o actuar como router/firewall.

3) ¿Por qué activar VLAN filtering rompió la red de gestión del host?

Porque tu IP de gestión probablemente dependía del comportamiento de native/untagged. Al habilitar filtering, el bridge puede aplicar la pertenencia VLAN de forma diferente, o el manejo de PVID/untagged cambia. Arréglalo poniendo la gestión en una interfaz etiquetada explícita como vmbr0.10.

4) ¿Cómo sé si el switch está descartando mi VLAN?

Ejecuta tcpdump -eni bond0 vlan X. Si ves solicitudes ARP etiquetadas saliendo pero no respuestas entrando, la VLAN probablemente no esté permitida en el trunk o la puerta de enlace no está presente en esa VLAN.

5) ¿Necesito configurar manualmente las tablas VLAN del bridge?

A menudo Proxmox gestiona gran parte cuando pones tags en las NICs de VM y habilitas VLAN-aware. Pero aún debes validar con bridge vlan show, especialmente al mezclar trunks etiquetados por el invitado, bonds o diseños de uplink inusuales.

6) ¿Cuál es la diferencia entre “bridge-vids” y “VLANs permitidas” en el switch?

bridge-vids define qué IDs VLAN considera válidos/permitidos el bridge Linux (dependiendo de la configuración). Las “VLANs permitidas” en el switch definen qué VLANs se reenviarán en ese trunk. Ambas deben incluir la VLAN o el tráfico muere.

7) Mi VLAN funciona en un nodo pero no tras migración. ¿Qué debo estandarizar?

Estandariza: configuración de trunk del switch por nodo, modo de bonding, setting bridge VLAN-aware y permiso de VLANs. Luego prueba migraciones como parte de la aceptación. Los fallos tras migración son casi siempre desviaciones de configuración.

8) ¿Las funciones SDN de Proxmox pueden causar confusión de VLAN?

Pueden, principalmente porque abstraen el comportamiento subyacente del bridge Linux. Si algo falla, vuelve a lo fundamental: inspecciona bridge vlan show, ip -d link y confirma tags con tcpdump. El kernel sigue haciendo el forwarding.

9) ¿Por qué ARP funciona pero TCP falla?

Porque ARP comprueba sólo descubrimiento L2. TCP puede fallar por MTU/PMTUD, reglas de firewall, enrutamiento asimétrico o ACLs upstream. Tras ARP exitoso, prueba MTU y traza rutas/políticas.

10) ¿Está bien trunkear “todas las VLANs” a Proxmox?

Técnicamente sí. Operativamente depende de tu modelo de seguridad. En muchos entornos limitar VLANs reduce el radio de impacto. Si las limitas, trátalo como un contrato: nueva VLAN requiere actualizaciones en switch + Proxmox juntas.

Conclusión: pasos siguientes para evitar repeticiones

Si tu VLAN en Proxmox no funciona, no sigas clickeando en la UI esperando que el universo te perdone. Haz pasos medibles:

1. Demuestra el etiquetado con tcpdump en el uplink.
2. Demuestra permiso con bridge vlan show y las VLANs permitidas en el switch.
3. Demuestra L3 con vecinos/ARP y alcance a la puerta de enlace.
4. Estandariza las configuraciones entre nodos para que la migración no sea una ruleta.
5. Haz la gestión explícita (subinterfaz etiquetada), y deja de depender de native VLANs salvo que realmente lo quieras.

Luego escribe tu modelo elegido (etiquetado por host vs por invitado), plantilla puertos del switch y mantén una VM canaria por VLAN. No es elegante. Funciona. Y en producción, “funciona” es la característica.