Ubuntu 24.04: las VLAN no funcionan — la única bandera del bridge que la mayoría olvida

noviembre 9, 2025 • febrero 3, 2026 • Lectura: 26 min • Views: 7

¿Te fue útil?

Todo parece correcto. El puerto del switch es un troncal. La VM tiene una interfaz etiquetada. La VLAN existe. Incluso puedes ver paquetes en el cable. Y sin embargo: no hay tráfico. No “lento”. No “inestable”. Simplemente muerto, como tu ventana de cambios.

En Ubuntu 24.04, que las VLAN “no funcionen” en un bridge Linux suele deberse a un único elemento faltante: filtrado VLAN del bridge. Si vlan_filtering no está habilitado en el bridge, tu troncal cuidadosamente configurada se convierte en una sugerencia educada que el kernel ignora. La solución es sencilla; el diagnóstico es donde la gente quema horas.

La bandera olvidada: `vlan_filtering` y por qué importa

Los bridges Linux pueden hacer dos cosas muy distintas con las VLAN:

Bridge ajeno a VLAN: el bridge reenvía tramas según el aprendizaje de MAC y no mantiene membresía por puerto de VLAN. Las etiquetas pueden pasar en algunos casos, pero no estás configurando VLANs en el bridge en sí.
Bridge consciente de VLAN: el bridge actúa como un pequeño switch gestionado. Los puertos tienen membresía de VLAN, un PVID (ID de VLAN de puerto), comportamiento opcional sin etiqueta y filtrado. Este modo se controla con vlan_filtering.

En Ubuntu 24.04, especialmente con Netplan + systemd-networkd, la gente suele construir un bridge esperando “trunking tipo switch”. Definen VLANs, crean una interfaz VM, la etiquetan y asumen que el bridge reenviará tráfico etiquetado. Pero el bridge no se comportará como un switch consciente de VLAN a menos que actives el filtrado VLAN. Puedes tener definiciones de VLAN perfectamente válidas y aun así no filtrar nada—porque al kernel no se le pidió.

Aquí está el comportamiento clave para recordar:

Si vlan_filtering=0, la configuración de bridge vlan se ignora efectivamente para las decisiones de reenvío.
Si vlan_filtering=1, el bridge usa su tabla de VLAN para decidir qué VLANs están permitidas en qué puertos y cómo se clasifican las tramas sin etiqueta (PVID).

Un pequeño chiste, porque te lo has ganado: el filtrado VLAN es como el cinturón de seguridad—nadie lo nota hasta el momento en que sale volando por el parabrisas.

Cómo se ve realmente “las VLAN no funcionan”

Patrones comunes:

Las VMs en una VLAN etiquetada pueden hacer ARP pero no reciben respuestas.
VM a VM en el mismo host funciona, pero VM a gateway no.
El tráfico sin etiqueta funciona en el bridge, pero el etiquetado desaparece.
tcpdump muestra etiquetas VLAN en una interfaz VM, pero no en la NIC física (o viceversa).

Cómo manejan realmente las VLANs los bridges Linux (no como desearíamos)

Un bridge Linux es un datapath del kernel (no solo un concepto de espacio de usuario), con controles que determinan cómo se clasifican y reenvían las tramas. El bridging consciente de VLAN está implementado en la capa de bridge: el bridge mantiene la membresía de VLAN por puerto y por VLAN, además de banderas como “sin etiqueta” y “PVID”.

Las piezas móviles que debes mantener claras

Dispositivo bridge (p. ej., br0): donde se habilita el filtrado VLAN y donde vive la tabla de VLAN.
Puertos del bridge (p. ej., eno1, vnet12): cada puerto puede ser miembro trunk de muchas VLANs y puede tener un PVID.
PVID: la VLAN asignada a las tramas de entrada sin etiqueta en un puerto. Es tu concepto de “VLAN nativa” (pero no abuses de ese término frente a los ingenieros de red, a menos que te gusten los suspiros).
Bandera de salida sin etiqueta: si las tramas para esa VLAN salen por el puerto sin etiqueta.
Subinterfaces VLAN (p. ej., br0.20 o eno1.20): una forma separada de hacer VLANs, a menudo usada cuando quieres L3 en una VLAN. Esto puede coexistir con bridging consciente de VLAN, pero mezclar patrones sin cuidado es como crear problemas fantasmas.

Por qué Ubuntu 24.04 confunde a la gente

Ubuntu 24.04 por defecto configura muchos servidores con Netplan y systemd-networkd. Eso es bueno. Es determinista. También es implacable: si no pides explícitamente comportamiento consciente de VLAN, no lo obtendrás. Los how-tos antiguos de la era “ifupdown” suelen asumir valores por defecto diferentes, y muchas pilas de virtualización “ocultan” la complejidad hasta que sales del camino feliz.

Además: Linux te da al menos tres maneras de construir la misma topología de red. Elige una y apégate a ella:

Bridge Linux consciente de VLAN (recomendado para bridging KVM y hosting de VMs multi-VLAN).
Interfaces VLAN separadas + bridges por VLAN (aburrido y efectivo; escala mal pero depura fácilmente).
OVS (Open vSwitch) (potente; más piezas móviles; vale la pena si necesitas funciones de OVS).

Plan de diagnóstico rápido (verifica 1, 2, 3)

Si las VLANs “no funcionan”, quieres encontrar el cuello de botella rápido. No te lances al YAML de Netplan de inmediato. Primero, demuestra qué cree el kernel que es verdad.

1) ¿El bridge es consciente de VLAN?

Revisa vlan_filtering y la tabla de VLAN. Si el filtrado está desactivado, para y arregla eso primero.

2) ¿Permite el bridge la VLAN en los puertos correctos?

La VLAN debe estar presente en ambos:

el puerto uplink físico (el troncal hacia tu switch), y
el puerto vnet de la VM (o veth de contenedor), o un bond/bridge aguas abajo.

3) ¿El comportamiento sin etiqueta vs etiquetado es correcto?

La mayoría de las interrupciones aquí son “desajuste de PVID” o “suposición de VLAN nativa”. Confirma:

¿En qué VLAN se convierte la entrada sin etiqueta?
¿Estás quitando etiquetas involuntariamente en la salida?

4) Luego revisa el switch externo

Sólo después de haber demostrado que Linux está configurado correctamente deberías discutir con el equipo de red (o contigo mismo del pasado). Valida los VLANs permitidos en el troncal y la expectativa de VLAN nativa.

Tareas prácticas: comandos, salida esperada, y decisiones

Estas son las tareas que realmente ejecuto en producción cuando alguien dice “las VLANs no funcionan”. Cada tarea incluye un comando, salida de ejemplo, lo que significa y la decisión que tomas.

Task 1: Identificar el bridge y sus puertos

cr0x@server:~$ bridge link
2: eno1 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master br0
5: vnet12 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master br0
6: vnet13 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master br0

Qué significa: Los puertos eno1, vnet12, vnet13 están esclavizados a br0.

Decisión: Si la NIC física que esperas no aparece listada, tu bridge no está conectado al mundo exterior. Arregla eso antes de perseguir VLANs.

Task 2: Comprobar si el filtrado VLAN está habilitado (el punto clave)

cr0x@server:~$ ip -d link show br0
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:ab:cd:ef brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
    bridge forward_delay 1500 hello_time 200 max_age 2000 stp_state 0 priority 32768 vlan_filtering 0 vlan_protocol 802.1Q

Qué significa: vlan_filtering 0 significa que el bridge no es consciente de VLAN. La tabla bridge vlan no será aplicada.

Decisión: Si estás intentando troncar VLANs a través de br0, casi con seguridad quieres vlan_filtering 1. Actívalo (temporalmente con ip, permanentemente vía Netplan/systemd-networkd).

Task 3: Mostrar la tabla de membresía VLAN actual

cr0x@server:~$ bridge vlan show
port              vlan-id  
eno1              1 PVID Egress Untagged
vnet12            1 PVID Egress Untagged
vnet13            1 PVID Egress Untagged

Qué significa: Solo la VLAN 1 existe en todas partes, y es el PVID, y sale sin etiqueta. No hay VLAN 20/30 presente.

Decisión: Añade VLANs a los puertos relevantes, o vuelve a comprobar que tu configuración se aplicó. Si el filtrado VLAN está desactivado, arregla eso primero—esta tabla puede ser irrelevante para el comportamiento de reenvío.

Task 4: Confirmar que la interfaz de la VM ve etiquetas VLAN

cr0x@server:~$ tcpdump -eni vnet12 -c 5 vlan
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vnet12, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:00:01.100000 52:54:00:11:22:33 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), vlan 20, p 0, ethertype ARP (0x0806), Request who-has 10.20.0.1 tell 10.20.0.50, length 46
12:00:01.200000 52:54:00:11:22:33 > 33:33:00:00:00:02, ethertype 802.1Q (0x8100), vlan 20, p 0, ethertype IPv6 (0x86dd), length 86

Qué significa: La VM está enviando tramas etiquetadas (VLAN 20) al host.

Decisión: Si hay etiquetas en el vnet, la VM probablemente está configurada correctamente. Ahora asegura que el bridge reenvíe VLAN 20 y que el uplink la permita.

Task 5: Confirmar que el uplink físico ve las mismas etiquetas VLAN

cr0x@server:~$ tcpdump -eni eno1 -c 5 vlan 20
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:00:01.300000 52:54:00:ab:cd:ef > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), vlan 20, p 0, ethertype ARP (0x0806), Request who-has 10.20.0.1 tell 10.20.0.50, length 46

Qué significa: Las etiquetas llegan a la NIC. Eso apunta lejos de Linux y hacia el switch, filtrado aguas arriba o problemas en la ruta de retorno.

Decisión: Si ves etiquetas en vnet pero no en eno1, Linux está descartando/quitando etiquetas (tabla de filtrado VLAN/PVID/banderas de salida sin etiqueta). Arregla la configuración del bridge Linux primero.

Task 6: Habilitar temporalmente el filtrado VLAN para probar la hipótesis

cr0x@server:~$ sudo ip link set dev br0 type bridge vlan_filtering 1
cr0x@server:~$ ip -d link show br0 | sed -n '1,3p'
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:ab:cd:ef brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
    bridge forward_delay 1500 hello_time 200 max_age 2000 stp_state 0 priority 32768 vlan_filtering 1 vlan_protocol 802.1Q

Qué significa: El bridge ahora es consciente de VLAN.

Decisión: Si las VLANs de repente empiezan a funcionar, has encontrado la bandera faltante. Ahora hazla persistente en Netplan/systemd-networkd. No la dejes como un arreglo temporal único.

Task 7: Añadir VLAN 20 al uplink y al puerto VM (en tiempo de ejecución)

cr0x@server:~$ sudo bridge vlan add dev eno1 vid 20
cr0x@server:~$ sudo bridge vlan add dev vnet12 vid 20
cr0x@server:~$ bridge vlan show | egrep 'eno1|vnet12'
eno1              1 PVID Egress Untagged
eno1              20
vnet12            1 PVID Egress Untagged
vnet12            20

Qué significa: VLAN 20 ahora está permitida en ambos puertos.

Decisión: Si el tráfico funciona ahora, traduce estas configuraciones a tu configuración declarativa. Los comandos en tiempo de ejecución son para diagnóstico, no para dormir tranquilo.

Task 8: Verificar PVID y comportamiento sin etiqueta en el uplink

cr0x@server:~$ bridge vlan show dev eno1
port              vlan-id  
eno1              1 PVID Egress Untagged
eno1              20

Qué significa: Las tramas sin etiqueta que entran por eno1 serán tratadas como VLAN 1, y la VLAN 1 saldrá sin etiqueta. La VLAN 20 saldrá etiquetada.

Decisión: Si tu puerto de switch espera una VLAN nativa diferente, ajusta el PVID (y posiblemente elimina la VLAN 1). Los PVID desalineados crean misterios de “funciona para algunos hosts”.

Task 9: Buscar subinterfaces VLAN inesperadas que compliquen el bridging

cr0x@server:~$ ip -o link show | grep -E '\.([0-9]+):'
10: eno1.20@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
11: br0.30@br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000

Qué significa: Tienes subinterfaces VLAN encima de la NIC y/o del bridge. Esto no está mal, pero es una señal de que podrías estar mezclando patrones de diseño.

Decisión: Decide si estás haciendo bridging consciente de VLAN (preferido para trunks VM) o subinterfaces VLAN + bridges por VLAN. Mezclar sin un diagrama es cómo la depuración se convierte en folklore.

Task 10: Confirmar qué renderer y backend están en uso

cr0x@server:~$ networkctl status -a | sed -n '1,14p'
● State: routable
  Online state: online
  Address state: routable
  IPv4 address state: routable
  IPv6 address state: degraded
  Carrier bound to: config
  DNS: 10.0.0.53
  Network:
       Link 2 (eno1)
       Link 7 (br0)

Qué significa: systemd-networkd está gestionando los enlaces (común en servidores Ubuntu). Si esperabas NetworkManager, estás depurando la pila equivocada.

Decisión: Mantente con un único plano de control. Si Netplan renderiza hacia networkd, usa Netplan (o archivos nativos de networkd) de forma consistente.

Task 11: Validar el renderizado de netplan y capturar errores de YAML

cr0x@server:~$ sudo netplan generate
cr0x@server:~$ sudo netplan try
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 120 seconds

Qué significa: generate tuvo éxito (sin errores de sintaxis). try aplica temporalmente y te da una salida segura.

Decisión: Usa netplan try en sesiones remotas. Si errores de VLAN matan tu conectividad, recuperas el servidor sin peregrinaje a consola y linterna.

Task 12: Inspeccionar el estado del bridge en el kernel y la base de reenvío

cr0x@server:~$ bridge fdb show br br0 | head
52:54:00:11:22:33 dev vnet12 master br0 permanent
0a:1b:2c:3d:4e:5f dev eno1 master br0
33:33:00:00:00:16 dev vnet12 master br0 permanent

Qué significa: El bridge está aprendiendo MACs y tiene algunas entradas permanentes. Esto demuestra que el reenvío L2 está vivo al menos a un nivel básico.

Decisión: Si la FDB está vacía mientras las interfaces están arriba y existe tráfico, podrías estar lidiando con peculiaridades de offload, unión equivocada (VM no en ese bridge), o tráfico que nunca llega al bridge.

Task 13: Buscar descartes relacionados con VLAN en contadores

cr0x@server:~$ ip -s link show eno1 | sed -n '1,12p'
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast           
     987654321  1234567      0     120       0    45678
    TX:  bytes packets errors dropped carrier collsns         
     876543210  1122334      0       0       0       0

Qué significa: Un dropped no nulo en RX puede ser por colas, driver, offload o políticas. Es una pista, no un veredicto.

Decisión: Si los descartes aumentan durante tus pruebas de VLAN, considera ajustes de offload o desajuste de MTU (especialmente con VLAN + overlay). Mide antes de “optimizar”.

Task 14: Verificar MTU de extremo a extremo (VLAN añade overhead, tu overlay añade arrepentimiento)

cr0x@server:~$ ip link show br0 | head -n 2
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:ab:cd:ef brd ff:ff:ff:ff:ff:ff

Qué significa: MTU del bridge es 1500. Si tu red física es 1500 y además ejecutas VXLAN/Geneve encima, fragmentarás o descartarás.

Decisión: Si usas overlays, aumenta la MTU en el underlay apropiadamente (y hazla consistente), o acepta una MTU de overlay menor y configúrala intencionalmente.

Task 15: Confirmar expectativas del switch comprobando sin etiqueta vs etiquetado

cr0x@server:~$ sudo arping -I br0 -c 3 10.0.0.1
ARPING 10.0.0.1 from 10.0.0.10 br0
Unicast reply from 10.0.0.1 [00:11:22:33:44:55]  1.233ms
Unicast reply from 10.0.0.1 [00:11:22:33:44:55]  1.104ms
Unicast reply from 10.0.0.1 [00:11:22:33:44:55]  1.098ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)

Qué significa: La conectividad sin etiqueta/nativa funciona en br0.

Decisión: Si lo sin etiqueta funciona pero VLAN 20 no, céntrate en membresía VLAN/PVID/etiquetado a través de los puertos del bridge y en la lista de VLANs permitidas del switch.

Netplan en Ubuntu 24.04: el patrón de bridge con conciencia de VLAN que funciona

Hay dos patrones sensatos para hosts VM multi-VLAN. Elige según tus prioridades operativas.

Patrón A (recomendado): bridge consciente de VLAN como troncal a VMs

Creas un bridge (br0) con el uplink físico como puerto. Habilitas el filtrado VLAN. Defines qué VLANs están permitidas en qué puertos. Las VMs se conectan y pueden estar etiquetadas dentro de la VM, o puedes configurar el comportamiento VLAN por VM en las herramientas del hipervisor (libvirt/virt-manager/etc.).

Un ejemplo representativo de Netplan (conceptual; tus claves exactas pueden variar según tu entorno):

cr0x@server:~$ sudo cat /etc/netplan/01-br0.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: false
  bridges:
    br0:
      interfaces: [eno1]
      dhcp4: false
      addresses: [10.0.0.10/24]
      routes:
        - to: default
          via: 10.0.0.1
      nameservers:
        addresses: [10.0.0.53]
      parameters:
        stp: false
      # The critical part: VLAN-aware bridge behavior is not magic.
      # Netplan renders this into the appropriate backend config.
      # If your environment doesn't apply it, validate with `ip -d link show br0`.

Chequeo de realidad: La abstracción de Netplan es útil hasta que deja de serlo. La única verdad es lo que reporta el kernel (ip -d link, bridge vlan show).

Si no puedes lograr que Netplan establezca de forma fiable el filtrado VLAN en tu entorno, es aceptable bajar a la configuración nativa de systemd-networkd. Los sistemas de producción premian la corrección aburrida.

Patrón B: subinterfaces por VLAN y bridges por VLAN

Esto se ve así:

eno1.20 adjunto a br20
eno1.30 adjunto a br30

Es verboso, pero fácil de depurar: si VLAN 20 está rota, miras eno1.20 y br20 y te quedas ahí. Esto es lo que haces cuando quieres el modelo mental más simple y no te importa la proliferación de configuración.

Ajustes de systemd-networkd que realmente necesitas

La red de servidores Ubuntu 24.04 frecuentemente acaba gestionada por systemd-networkd. Bajo eso, el bridging consciente de VLAN típicamente se reduce a:

Bridge creado y puertos adjuntos
VLANFiltering=yes (o equivalente) aplicado al bridge
Membresía VLAN configurada por puerto (a veces vía entradas de bridge VLAN)

En lugar de adivinar, valida lo que se aplicó:

cr0x@server:~$ networkctl status br0 | sed -n '1,40p'
● 7: br0
             Link File: /run/systemd/network/10-netplan-br0.network
          Network File: /run/systemd/network/10-netplan-br0.network
                  Type: bridge
                 State: routable (configured)
          Online state: online

Qué significa: Netplan generó unidades runtime para networkd. Ahora sabes dónde mirar si necesitas inspeccionar la configuración renderizada.

cr0x@server:~$ sudo sed -n '1,120p' /run/systemd/network/10-netplan-br0.netdev
[NetDev]
Name=br0
Kind=bridge

[Bridge]
STP=false

Qué significa: Este archivo renderizado puede no incluir el filtrado VLAN, dependiendo de cómo Netplan lo expresó (o no lo expresó).

Decisión: Si la configuración en runtime no establece filtrado VLAN, puedes arreglar tu YAML de Netplan o cambiar a archivos nativos de networkd donde lo controles explícitamente.

Segundo chiste pequeño (y el último): Un bridge sin filtrado VLAN es como una solicitud de cambio sin plan de reversión—técnicamente permitido, emocionalmente irresponsable.

Errores comunes: síntoma → causa raíz → arreglo

Esta es la sección que querrás a las 02:00 cuando estés entrecerrando los ojos frente a tcpdump.

1) El tráfico VLAN etiquetado nunca sale del host

Síntoma: Aparecen etiquetas VLAN en vnetX, pero no en eno1.

Causa raíz: Filtrado VLAN del bridge habilitado pero VLAN no permitida en el puerto uplink; o filtrado VLAN deshabilitado de modo que tu configuración VLAN no se aplica como crees; o egress untagged configurado incorrectamente.

Arreglo: Habilita el filtrado VLAN en el bridge y añade membresía VLAN en ambos puertos:

cr0x@server:~$ sudo ip link set dev br0 type bridge vlan_filtering 1
cr0x@server:~$ sudo bridge vlan add dev eno1 vid 20
cr0x@server:~$ sudo bridge vlan add dev vnet12 vid 20

2) El tráfico sin etiqueta funciona, las VLAN etiquetadas fallan

Síntoma: La gestión del host en la VLAN nativa funciona. La VM en VLAN 20 no llega al gateway.

Causa raíz: Troncal del switch sin la VLAN en la lista de permitidas; o bridge Linux no permite VLAN 20 en el uplink; o el hipervisor está quitando las etiquetas que espera la VM.

Arreglo: Valida la membresía VLAN en los puertos Linux primero con bridge vlan show, luego valida el troncal del switch.

3) Algunas VMs pueden hablar en VLAN 20, otras no

Síntoma: VM-A funciona en VLAN 20, VM-B no, mismo host.

Causa raíz: El puerto vnet de la VM defectuosa carece de membresía VLAN; o tiene modo de etiquetado distinto (etiquetado dentro del invitado vs sin etiqueta en el invitado y etiquetado por herramientas del hipervisor).

Arreglo: Compara bridge vlan show dev vnetX para ambas y estandariza un enfoque.

4) ARP funciona pero el tráfico IP no

Síntoma: Ves respuestas ARP pero los pings fallan.

Causa raíz: Problemas de MTU/fragmentación (especialmente con overlays), política de seguridad aguas arriba o enrutamiento asimétrico. La configuración VLAN puede estar bien.

Arreglo: Comprueba la consistencia de MTU, luego revisa enrutamiento y firewall. Las VLANs no son lo único que puede arruinar tu noche.

5) El tráfico funciona hasta que reinicias

Síntoma: bridge vlan add en runtime lo arregló, pero al reiniciar falla.

Causa raíz: No hiciste persistente el filtrado VLAN y la tabla VLAN; falta líneas críticas en la configuración de Netplan/networkd.

Arreglo: Codifica los ajustes en Netplan o archivos nativos de networkd. Confirma después del reinicio con ip -d link show br0 y bridge vlan show.

6) “Pero el bridge está arriba” (distracción clásica)

Síntoma: Todos los enlaces muestran UP, pero no ocurre el reenvío VLAN.

Causa raíz: Filtrado VLAN desactivado o membresía VLAN faltante. El estado del enlace no es el estado de la política.

Arreglo: Deja de confiar en “UP.” Empieza a confiar en la tabla VLAN y en las capturas.

Tres mini-historias corporativas desde las trincheras

Incidente causado por una suposición errónea: “Un bridge Linux es un switch, ¿verdad?”

Una empresa mediana ejecutaba un clúster de virtualización en Ubuntu. Migraron desde una imagen de host más antigua donde la red se configuraba con scripts hechos a mano. La nueva imagen estandarizó en Ubuntu 24.04 y Netplan. El plan era sensato: un bridge por host, trunk de múltiples VLANs y mantener la red de VM flexible.

La primera ventana de mantenimiento fue bien—hasta que nuevas VMs en una “VLAN de aplicaciones” etiquetada no llegaban a su gateway. El equipo hizo la danza habitual: revisaron el trunk del switch, recargaron el puerto ToR, reanudaron las NIC de las VMs y probaron distintos modelos virtio. Alguien incluso tocó STP porque “sentía” que había que hacer algo.

La suposición equivocada fue simple: creyeron que definir membresía de VLAN en alguna parte de su cadena de herramientas automáticamente haría que el bridge Linux se comportara como un switch consciente de VLAN. No lo hizo. El bridge reenviaba tramas sin etiqueta bien, así que todos miraron fuera del host y hacia la red. Mientras tanto, el host estaba ignorando sus intenciones VLAN porque vlan_filtering estaba desactivado.

La solución tomó minutos: habilitar el filtrado VLAN y añadir la membresía VLAN para el uplink y los puertos VM. El trabajo real fue social: actualizar la documentación de la imagen y las pruebas de aceptación para que esto no volviera a ocurrir.

Después escribieron una verificación previa que se ejecutaba en cada host: volcar ip -d link show br0, fallar el build si vlan_filtering 0 y requerir una lista conocida de VLANs en bridge vlan show. A nadie le gustan las guardrails hasta que evitan un incidente.

Optimización que salió mal: “Habilitemos todos los offloads”

Otra organización quería mejor rendimiento en la red de VMs. Tenían múltiples VLANs bridgadas a una NIC de 25G y veían pérdidas ocasionales en ráfagas. La solución, pensaron, era habilitar todas las características de offload disponibles y afinar colas agresivamente.

Al principio mejoró: la CPU bajó, el rendimiento subió en pruebas sintéticas y los gráficos se veían mejor. Luego empezaron los problemas: pérdida intermitente de paquetes solo en una VLAN y solo para ciertos patrones de tráfico. ARP parecía bien. TCP se atascaba y se recuperaba. Monitoreo basado en UDP fallaba intervalos. Era el peor tipo de bug: intermitente y plausiblemente “aguas arriba”.

El contragolpe vino de la combinación de comportamiento del driver y cómo se interpretaban las capturas. Con algunos offloads activados, la visibilidad de paquetes cambió: tcpdump no siempre decía la verdad completa sobre qué estaba etiquetado y dónde, y el equipo persiguió problemas VLAN fantasma por días. También descubrieron que las ráfagas eran causadas por un patrón de despliegue de aplicaciones, no por la red, así que ajustaron lo incorrecto primero.

La resolución eventual no fue “desactivar todos los offloads para siempre”. Fue más aburrida: crear una prueba de tráfico reproducible, ajustar una configuración a la vez, validar con contadores hardware y mantener el diagnóstico VLAN separado del tuning de rendimiento. Cuando reintrodujeron offloads selectivamente y verificaron MTU y etiquetado de extremo a extremo, la estabilidad volvió.

Lección: el trabajo de rendimiento cambia la observabilidad. Si no puedes medirlo, no puedes confiar en ello. Especialmente alrededor del etiquetado VLAN y bridging.

Práctica aburrida pero correcta que salvó el día: “Haz del estado del kernel tu prueba de aceptación”

Una empresa del sector financiero tenía control de cambios estricto y su red era famosa por ser conservadora. Sus hosts VM eran basados en Ubuntu y se movían despacio por buenas razones. También tenían un hábito que desearía que más equipos copiara: validaban el estado vivo del kernel después de aplicar la configuración de red, cada vez, con una lista de control.

Durante una renovación, una nueva plantilla introdujo un cambio sutil en Netplan. El YAML parecía “equivalente” al anterior, pero ya no configuraba el bridge como consciente de VLAN. El primer host que arrancó falló inmediatamente las comprobaciones de aceptación post-configuración.

Porque habían escrito qué aspecto tenía “correcto”—vlan_filtering 1, IDs de VLAN esperadas presentes en los puertos esperados y una prueba rápida de ping etiquetado—lo detectaron antes de que cualquier carga de producción se moviera. No hubo incidentes. No hubo llamadas a medianoche. Solo un paso de despliegue fallido y un ticket para arreglar la plantilla.

No ganaron puntos por creatividad. Ganaron por ser aburridos y correctos.

Hechos y contexto (por qué esto confunde en 2025)

Algunos hechos cortos y concretos e historia que explican por qué la gente sigue pisando este rastrillo:

802.1Q VLAN tagging añade un encabezado de 4 bytes a las tramas Ethernet, insertando un ID de VLAN y bits de prioridad.
El bridging en Linux lleva décadas en kernel y está más cerca del datapath de un switch de lo que la gente cree—hasta que la política de VLAN entra en escena.
El soporte de bridges conscientes de VLAN maduró con el tiempo; las configuraciones antiguas a menudo usaban subinterfaces VLAN porque era más fácil de razonar.
El concepto de “VLAN nativa” es principalmente un comportamiento de puerto de switch; en bridges Linux, el mecanismo análogo es el PVID y las banderas de salida sin etiqueta.
Netplan es un renderer, no una pila de red. Genera configuración para systemd-networkd o NetworkManager, lo que significa que “cambié YAML” no es lo mismo que “el kernel cambió comportamiento”.
systemd-networkd es estricto y determinista, lo cual es bueno para servidores. También significa que un booleano faltante puede deshabilitar silenciosamente un conjunto entero de funciones.
La visibilidad de tcpdump puede distorsionarse por offloads (TSO/GSO/GRO y offloads VLAN), así que las capturas deben corroborarse con el estado del bridge y los contadores.
Las tablas de VLAN del bridge son por puerto; no basta con “activar VLAN 20 en el bridge.” El uplink y el puerto VM deben permitirla.
Los bridges por VLAN son un patrón antiguo que sigue ganando en simplicidad operativa; es verboso, pero difícil de malinterpretar durante un incidente.

Listas de verificación / plan paso a paso

Paso a paso: arreglar un trunk VLAN roto en un bridge en Ubuntu 24.04

Confirma la topología: identifica el nombre del bridge (br0) y el uplink físico (eno1).
Revisa el filtrado VLAN: ip -d link show br0; si vlan_filtering 0, ese es tu primer arreglo.
Actívalo (temporalmente): ip link set dev br0 type bridge vlan_filtering 1.
Inspecciona la tabla VLAN: bridge vlan show. Confirma que las VLANs esperadas existen.
Permite VLANs en uplink y puertos VM: bridge vlan add dev eno1 vid 20 y bridge vlan add dev vnet12 vid 20.
Verifica PVID y ajustes sin etiqueta: asegúrate de que tu comportamiento “nativo” coincida con la configuración del switch.
Prueba con captura de paquetes: las etiquetas deben aparecer tanto en vnet como en la NIC física donde corresponda.
Hazlo persistente: codifica en Netplan o networkd nativo; evita arreglos solo en runtime.
Prueba de reinicio: valida de nuevo tras reiniciar; no confíes en una configuración hasta que sobreviva a uno.
Documenta el estado esperado: guarda las salidas de ip -d link show br0 y bridge vlan show como “conocido bueno”.

Lista operativa: cómo se ve “bien”

ip -d link show br0 muestra vlan_filtering 1.
bridge vlan show lista los IDs VLAN esperados en eno1 y en cada puerto VM relevante.
El PVID es intencional, no por defecto accidental.
La salida sin etiqueta está configurada sólo donde la quieres.
tcpdump confirma que las etiquetas atraviesan el host correctamente.
Un reinicio no cambia el comportamiento.

FAQ

1) ¿Cuál es la “una bandera del bridge que la mayoría olvida”?

vlan_filtering en el dispositivo bridge. Sin ella, las reglas de reenvío conscientes de VLAN no se aplican como la gente espera cuando construye troncos a través de un bridge Linux.

2) ¿Cómo compruebo si el filtrado VLAN está habilitado?

Ejecuta:

cr0x@server:~$ ip -d link show br0 | grep -o 'vlan_filtering [01]'
vlan_filtering 0

Si imprime vlan_filtering 0, tu bridge no es consciente de VLAN.

3) Si el filtrado VLAN está apagado, ¿las etiquetas VLAN siempre se descartan?

No siempre; por eso esto confunde. Las etiquetas a veces parecen pasar, dependiendo de la topología y las expectativas. Pero si confías en membresía por puerto y política tipo trunk, quieres el modo consciente de VLAN. De lo contrario estarás depurando un comportamiento que no es controlado por políticas.

4) ¿Necesito configurar VLANs tanto en el uplink como en el puerto VM?

Sí, para bridging consciente de VLAN. La VLAN debe estar permitida en los puertos de entrada/salida que la transportan. El trunk físico y el puerto vnet de la VM necesitan ambos membresía para esa VLAN.

5) ¿Cuál es la diferencia entre PVID y “untagged”?

El PVID clasifica las tramas entrantes sin etiqueta en una VLAN. “Egress untagged” decide si las tramas para esa VLAN salen por el puerto sin la etiqueta 802.1Q. Puedes tener una VLAN presente sin que sea el PVID.

6) ¿Debo trunkear VLANs dentro de la VM, o etiquetar en el host?

Elige uno por entorno y estandariza:

Etiquetar dentro de la VM si la VM es un router/firewall o necesita múltiples VLANs.
Etiquetar en el host/hipervisor si la VM debe ser “una sola VLAN, NIC simple”.

Mezclar ambos enfoques al azar es una excelente forma de crear outages de “depende”.

7) ¿Por qué mi tcpdump no muestra etiquetas VLAN que estoy seguro existen?

Los offloads pueden cambiar lo que ves en las capturas. El manejo de etiquetas VLAN puede estar offloadeado en hardware, y GRO/GSO puede coalescer paquetes. Usa el estado del bridge (bridge vlan show) y corrobóralo con múltiples puntos de captura.

8) ¿Open vSwitch es una mejor respuesta?

A veces. Si necesitas funciones como políticas más avanzadas, integración con tunneling o mejor observabilidad en el virtual switch, OVS puede merecerlo. Si tu requisito es “trunk VLANs a VMs de forma fiable”, el bridge en kernel de Linux con filtrado VLAN suele ser más simple y más rápido de depurar.

9) ¿Puedo arreglar esto con un reinicio o reiniciando servicios de red?

Los reinicios no arreglan configuraciones faltantes; sólo tiran los dados sobre lo que olvidaste. Usa reinicios para verificar persistencia, no como herramienta de reparación.

10) ¿Cuál es una buena prueba de aceptación después de cambios?

Como mínimo:

ip -d link show br0 y verificar vlan_filtering 1
bridge vlan show y verificar presencia VLAN en puertos relevantes
Captura de paquetes o prueba de conectividad etiquetada desde una VM
Reiniciar y repetir las comprobaciones

Conclusión: pasos prácticos siguientes

Cuando las VLANs “no funcionan” en bridges de Ubuntu 24.04, el camino más rápido es dejar de hipotetizar e interrogar al kernel. Revisa vlan_filtering. Revisa la tabla VLAN del bridge. Confirma que la VLAN existe tanto en el uplink como en el puerto VM. Solo entonces empieza a debatir la configuración del switch.

Aquí tienes tu plan amigable para la ventana de cambios:

Ejecuta ip -d link show br0 y arregla vlan_filtering primero.
Ejecuta bridge vlan show y asegúrate de que la membresía VLAN sea correcta por puerto.
Demuestra el reenvío con un tcpdump de dos puntos (vnet + NIC física).
Hazlo persistente en tu plano de control elegido (Netplan o networkd nativo) y valida después de reiniciar.

Una idea parafraseada de Werner Vogels (ingeniería enfocada en confiabilidad): todo falla eventualmente; diseña para que las fallas sean esperadas y recuperables (idea parafraseada).