Redes: VLANs mal configuradas — El error que crea fallos fantasma

El único error: etiquetado inconsistente a lo largo de un trayecto

Este es el error que crea fallos fantasma: una VLAN está etiquetada en un lado de un enlace y tratada como no etiquetada en el otro.
O la VLAN nativa difiere entre los extremos del trunk. O la lista de “VLANs permitidas” no coincide a lo largo de la cadena de trunks.
Diferentes variantes, misma enfermedad: no tienes una verdad consistente sobre “¿en qué VLAN está esta trama?” de un extremo al otro.

En la práctica, se manifiesta así:

• Un servidor envía tramas etiquetadas en eth0.120, pero el puerto del switch está configurado como puerto de acceso en la VLAN 120 (espera sin etiqueta).
• Un trunk tiene VLAN nativa 1 en un lado y VLAN nativa 120 en el otro. Las tramas no etiquetadas se convierten en VLAN 1 en un extremo y VLAN 120 en el otro.
• Un cambio “útil” reduce las VLANs permitidas en un trunk de agregación, eliminando accidentalmente una VLAN todavía usada por un host legado.
• Un portgroup de vSwitch de hipervisor espera VLAN 120, pero la NIC física ascendente está configurada como “sin etiquetar” y depende del switch para etiquetarla.

La mala noticia: esto no siempre corta toda la conectividad. Los casos realmente peligrosos filtran la conectividad justo suficiente para mantener los sistemas medio vivos.
ARP y el aprendizaje de MAC pueden oscilar. Algunos flujos hacen hashing de una manera, otros de otra. Los reintentos enmascaran el problema hasta que llega el pico de tráfico y el sistema admite que está dañado.

La conclusión operacional es directa: las VLANs no son “configurar y olvidar”. Son un contrato extremo a extremo. Si no puedes describir el contrato a través de cada salto,
no tienes una VLAN: tienes un rumor.

Por qué eso crea fallos “fantasma” (y no fallos limpios)

1) Confusión del dominio de difusión: ARP y ND actúan como narradores poco fiables

Cuando el etiquetado es inconsistente, las solicitudes ARP pueden salir en una VLAN mientras las respuestas ARP vuelven en otra —o llegan por un puerto distinto debido al churn de la tabla de MAC.
El host cachea los mapeos “IP → MAC”. El switch cachea los mapeos “MAC → puerto”. Ahora tienes dos cachés independientes intentando modelar una realidad que acabas de romper.

Verás síntomas como:

• Entradas ARP que alternan entre dos MAC para la misma IP (o la misma MAC rebotando entre puertos).
• Rarezas en Neighbor Discovery en IPv6: reachable, stale, reachable, stale, sin razón aparente.
• Conectividad que funciona durante un minuto después de una actualización ARP y luego empeora hasta la siguiente actualización.

2) “Funciona casi” es peor que “caído”

Los fallos limpios te alertan, impulsan acción y terminan rápido. Los fallos fantasma se alargan días porque:

• Los reintentos de TCP ocultan la pérdida de paquetes hasta que la latencia tail se hace visible para el negocio.
• Los chequeos de salud prueban una ruta feliz mientras el tráfico real golpea la rota rota.
• Los balanceadores de carga mantienen una pierna viva y drenan silenciosamente la otra, así que solo lo notas bajo carga.
• La monitorización agrega el patrón: 0,5% de pérdida parece ruido hasta que es tu base de datos la afectada.

3) El etiquetado inconsistente crea caminos asimétricos

Un clásico fantasma: el tráfico saliente deja el servidor bien, pero el tráfico de retorno aterriza en la VLAN equivocada o en el puerto incorrecto porque la red aprendió la MAC en otro sitio.
O al revés. Puedes hacer ping en un sentido, fallar en el otro, y pasar horas culpando a los firewalls. Los registros del firewall parecerán inocentes porque los paquetes nunca llegaron.

4) MTU y la sobrecarga de la etiqueta VLAN pueden convertir “bien” en “inestable”

El etiquetado 802.1Q añade 4 bytes. Si trabajas con MTU ajustados (especialmente en overlays o redes de almacenamiento), una descoordinación puede hacer que algunos dispositivos descarten tramas “gigantes”
mientras otros fragmentan o recortan. El resultado es dolor selectivo: pings pequeños funcionan, transferencias grandes se atascan.

Broma #1: Las VLANs son como etiquetas con nombres en una conferencia—si la mitad de la sala las lleva y la otra mitad no, seguirás conociendo gente, solo que no las correctas.

Datos interesantes y contexto histórico

• IEEE 802.1Q (etiquetado VLAN) se convirtió en el estándar interoperable porque los proveedores tenían métodos de trunking incompatibles en los años 90.
• La etiqueta 802.1Q son 4 bytes: ID de VLAN de 12 bits (1–4094 usable), además de bits de prioridad y un indicador de elegibilidad para descarte.
• VLAN 0 está reservada para etiquetado de prioridad; está “etiquetada” pero no asignada a una VLAN en el sentido normal.
• VLAN 1 tiene una carga histórica especial: muchos dispositivos usanla por defecto para protocolos de gestión/plan de control, por eso “nativa VLAN 1 en todas partes” se volvió común (y riesgosa).
• La VLAN nativa existe principalmente por compatibilidad con Ethernet no etiquetado; también es una fuente recurrente de desajustes silenciosos.
• El doble etiquetado (ataques de VLAN hopping) explotó el comportamiento de la VLAN nativa; la práctica recomendada moderna es evitar usar VLAN 1 como nativa y evitar trunks no etiquetados.
• A principios, los centros de datos solían usar VLANs para crear “zonas de seguridad”, pero las VLANs son segmentación, no seguridad; tu enforcement sigue siendo ACLs/firewalls.
• Los entornos grandes pasaron de “VLAN por aplicación” a sobreposiciones EVPN/VXLAN porque el escalado L2 y la complejidad del spanning tree se volvieron operativamente costosos.
• La “lista de VLANs permitidas” en un trunk es tanto un mecanismo de seguridad como un arma de doble filo: limita el radio de impacto, pero puede dejar tráfico varado cuando ocurre deriva.

Firmas de fallo: cómo se ve en producción

Los fallos fantasma tienen una vibra. Una vez que te han quemado, los puedes oler en las gráficas.

Síntomas que puedes graficar

• Ráfagas cortas y repetidas de pérdida cada pocos minutos (a menudo alineadas con los timers de refresco ARP/ND o con el envejecimiento de MAC).
• Picos de latencia sin saturación de ancho de banda, especialmente en tráfico este-oeste.
• Una AZ/rack “se siente lenta” pero nada está completamente caído; mover cargas “lo arregla”.
• Inestabilidad en almacenamiento: timeouts iSCSI/NFS, flaps de OSD de Ceph, retraso en replicación. El almacenamiento no perdona y será tu sistema de aviso temprano.

Síntomas en los registros

• Flux ARP (tormentas de ARP gratuitas, churn en la caché de vecinos).
• Advertencias de flapping de MAC en switches (“MAC movida del puerto X al puerto Y”).
• Contadores de errores de interfaz que no coinciden con la historia (CRC bien, pero aumentan las caídas; o errores de entrada que suben en un uplink).
• Reintentos de aplicación y timeouts sin presión correlacionada de CPU/memoria.

Por qué tu primera hipótesis suele estar equivocada

Culparás al DNS. Luego al balanceador. Luego a Kubernetes. Luego “al equipo de firewall”. Mientras tanto, la red está silenciosamente etiquetando mal las tramas.
Los equipos más rápidos aprenden a probar el contrato VLAN antes de inventar nuevas teorías.

Guion de diagnóstico rápido

Este es el bucle de triaje que uso cuando alguien dice “es intermitente” y mi café aún no ha hecho efecto.
El objetivo es encontrar el cuello de botella rápido, no realizar un viaje espiritual por cada switch.

Primero: prueba si esto es rareza L2/VLAN o no

1. Elige un host afectado y un objetivo (la IP del gateway es perfecta). Ejecuta un ping continuo y un ping con MTU grande (donde esté permitido).
2. Observa ARP/ND mientras ocurre el problema. Si las entradas ARP cambian o quedan incompletas, sospecha de VLAN/etiquetado inmediatamente.
3. Comprueba la estabilidad de la dirección MAC en el switch: si la misma MAC se mueve entre puertos/VLANs, estás en terreno L2.

Segundo: valida el contrato de etiquetado extremo a extremo

1. En el host: confirma si la NIC está enviando tramas etiquetadas (subinterfaz VLAN) o no etiquetadas (interfaz simple).
2. En el puerto adyacente del switch: confirma modo access vs trunk, VLAN nativa y lista de VLANs permitidas.
3. Recorre los uplinks: en cada trunk del camino, verifica que la VLAN esté permitida y etiquetada de forma consistente (y que las VLANs nativas coincidan si se usan).

Tercero: comprueba “no son VLANs, es MTU”

1. Confirma MTU en host, puerto del switch y en cualquier frontera overlay/underlay.
2. Busca descarte de tramas enormes, contadores de fragmentación o desajustes de TCP MSS clamping.
3. No olvides hipervisores y bonds—la deriva de MTU adora la virtualización.

Cuarto: confirma que no construiste un bucle o un hairpin

1. Revisa cambios de spanning-tree, puertos bloqueados o estado de reenvío inesperado.
2. Revisa mis-bundles de LACP donde un lado piensa que es un port-channel y el otro piensa que son dos enlaces independientes.
3. Busca IPs duplicadas o confusión VRRP/HSRP que puedan imitar problemas de VLAN.

Si haces esos cuatro pasos, o encontrarás el desajuste VLAN o lo descartarás rápidamente y podrás avanzar sin perder un día.

Tareas prácticas: comandos, salidas y decisiones

El trabajo práctico supera la teoría. Abajo hay tareas reales que puedes ejecutar en hosts Linux y entornos de switching comunes. Cada una incluye:
el comando, qué significa la salida y qué decisión tomar a partir de ella.

Task 1: Check whether the host is using VLAN subinterfaces

cr0x@server:~$ ip -d link show
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
3: eth0.120@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    vlan protocol 802.1Q id 120 <REORDER_HDR>

Meaning: eth0.120 exists and will transmit tagged VLAN 120 frames. The parent eth0 is just the carrier.

Decision: The switchport facing this host must be a trunk (or a hybrid port configured to accept tagged VLAN 120). If it’s access VLAN 120, you’ve got a mismatch.

Task 2: Confirm IP addressing is bound to the VLAN interface you think

cr0x@server:~$ ip addr show dev eth0.120
3: eth0.120@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.20.120.17/24 brd 10.20.120.255 scope global eth0.120
       valid_lft forever preferred_lft forever

Meaning: The host’s IP is on the tagged interface, not on eth0.

Decision: If the switchport is access (untagged), the host will be shouting into a tagged void. Fix the port mode or move the IP to the correct interface.

Task 3: Verify default route uses the expected interface

cr0x@server:~$ ip route show default
default via 10.20.120.1 dev eth0.120 proto static

Meaning: Default route exits via VLAN 120 subinterface.

Decision: If the gateway is intermittently reachable, focus on L2 (VLAN/ARP) before chasing upstream routing.

Task 4: Watch ARP behavior during the problem window

cr0x@server:~$ ip -s neigh show dev eth0.120
10.20.120.1 lladdr 00:25:90:aa:bb:cc REACHABLE used 42/0/38 probes 0
10.20.120.50 lladdr 00:25:90:11:22:33 STALE used 9/9/0 probes 0

Meaning: If entries toggle between REACHABLE, STALE, and INCOMPLETE during outages, something is disrupting L2 reachability or replies are arriving on a different segment.

Decision: ARP/ND instability is a loud hint: check tagging consistency and MAC moves on switches.

Task 5: Capture VLAN tags on the wire (prove the host is tagging)

cr0x@server:~$ sudo tcpdump -eni eth0 -c 5 vlan 120
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:10:01.123456 52:54:00:12:34:56 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 120, p 0, ethertype ARP, Request who-has 10.20.120.1 tell 10.20.120.17, length 46
12:10:02.123457 52:54:00:12:34:56 > 00:25:90:aa:bb:cc, ethertype 802.1Q (0x8100), length 74: vlan 120, p 0, ethertype IPv4, 10.20.120.17 > 10.20.120.1: ICMP echo request, id 123, seq 1, length 32

Meaning: The frames leaving eth0 are VLAN-tagged (ethertype 0x8100, VLAN 120).

Decision: If the switchport is access/untagged, it will not accept these frames (or it may drop them). Configure the port as trunk or remove host tagging.

Task 6: Check MTU and look for a “works for ping, fails for transfers” trap

cr0x@server:~$ ip link show dev eth0.120
3: eth0.120@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

Meaning: MTU is 1500 on the VLAN interface. If your network expects jumbo frames (9000) or you’re running overlays, you may be accidentally fragmenting or dropping.

Decision: If you see selective failure for large payloads, run a path MTU test and align MTU end-to-end.

Task 7: Test path MTU without fragmentation

cr0x@server:~$ ping -M do -s 1472 -c 3 10.20.120.1
PING 10.20.120.1 (10.20.120.1) 1472(1500) bytes of data.
1472 bytes from 10.20.120.1: icmp_seq=1 ttl=64 time=0.402 ms
1472 bytes from 10.20.120.1: icmp_seq=2 ttl=64 time=0.398 ms
1472 bytes from 10.20.120.1: icmp_seq=3 ttl=64 time=0.401 ms

--- 10.20.120.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2040ms

Meaning: 1500-byte MTU path works to the gateway. If this fails, you have an MTU issue or filtering.

Decision: If 1472 fails but small ping works, don’t call it “random loss.” Fix MTU or MSS clamping; VLAN tagging overhead can be part of the mismatch story.

Task 8: Check Linux VLAN filtering and bridge membership (common on hypervisors)

cr0x@server:~$ bridge vlan show
port              vlan-id  
eth0              1 PVID Egress Untagged
br0               1 PVID Egress Untagged
vnet0             120

Meaning: This host/bridge setup is not symmetrical: eth0 is effectively untagged VLAN 1, while a VM NIC (vnet0) expects VLAN 120.

Decision: This is how you get “VM works sometimes” depending on which interface gets the traffic. Fix bridge VLAN filtering: tag VLAN 120 on uplink or move the VM to the correct portgroup.

Task 9: Confirm bond/LACP state (L2 issues often hide in “half a bond”)

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
Active Aggregator Info:
        Aggregator ID: 2
        Number of ports: 2
Slave Interface: eth1
MII Status: up
Actor Churn State: churned
Partner Churn State: churned
Slave Interface: eth2
MII Status: up
Actor Churn State: stable
Partner Churn State: stable

Meaning: One slave shows churn. That can correlate with intermittent packet reordering or drops, especially if switch-side LACP is misconfigured or VLANs differ per member link.

Decision: Verify the switch port-channel is correctly formed and consistent VLAN config is applied to the bundle, not individual member ports.

Task 10: Look for MAC address flapping evidence on the host (as a hint)

cr0x@server:~$ sudo journalctl -k --since "1 hour ago" | tail -n 8
Feb 04 09:12:11 server kernel: IPv6: eth0.120: neighbor 10.20.120.1 is using my MAC address 52:54:00:12:34:56
Feb 04 09:12:12 server kernel: arp: 10.20.120.1 moved from 00:25:90:aa:bb:cc to 00:25:90:dd:ee:ff on eth0.120
Feb 04 09:12:40 server kernel: arp: 10.20.120.1 moved from 00:25:90:dd:ee:ff to 00:25:90:aa:bb:cc on eth0.120

Meaning: The gateway’s MAC appears to change. That can happen with HA gateways, but the pattern plus outages often points to VLAN leakage or a loop.

Decision: Confirm whether the gateway is actually redundant (VRRP/HSRP) and whether those devices share a VLAN consistently. If not, suspect tagging mismatch or L2 loop.

Task 11: On a Linux router/firewall, verify VLAN interfaces are present and correctly named

cr0x@server:~$ ip -d link show | grep -E "vlan|eth1\."
5: eth1.120@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    vlan protocol 802.1Q id 120 <REORDER_HDR>
6: eth1.220@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    vlan protocol 802.1Q id 220 <REORDER_HDR>

Meaning: The router expects tagged VLANs 120 and 220 on eth1.

Decision: The adjacent switchport must be trunking those VLANs to the router. If someone “simplified” it to access VLAN 120, VLAN 220 will go dark in strange, partial ways.

Task 12: Verify firewall rules aren’t lying to you (because the packets never arrive)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,40p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iifname "eth1.120" ip saddr 10.20.120.0/24 tcp dport { 22, 443 } accept
    iifname "eth1.220" ip saddr 10.20.220.0/24 tcp dport 443 accept
  }
}

Meaning: Rules are interface-specific. If VLAN 120 packets accidentally arrive untagged on eth1, they will miss these rules and get dropped by default policy.

Decision: If drops spike while the rule counters stay flat, it’s probably not the rule; it’s the interface/VLAN classification. Fix tagging before “fixing” the firewall.

Task 13: Validate switch-side VLAN membership from a host using LLDP hints (when available)

cr0x@server:~$ sudo lldpctl | sed -n '1,40p'
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface:    eth0, via: LLDP, RID: 1, Time: 0 day, 00:00:22
  Chassis:
    ChassisID:    mac 00:1c:73:aa:bb:cc
    SysName:      tor-sw-07
  Port:
    PortID:       ifname Ethernet1/7
    PortDescr:    server-rack12-u14
  VLAN:           120

Meaning: The switch advertises VLAN 120 on that port. LLDP can be wrong or incomplete, but it’s a useful clue.

Decision: If LLDP shows VLAN 120 but the host is tagging and the port is actually access VLAN 120, you still have a mismatch. Use this as direction, not truth.

Task 14: Verify actual packet path classification with conntrack (for intermittent flows)

cr0x@server:~$ sudo conntrack -L | head
tcp      6 431999 ESTABLISHED src=10.20.120.17 dst=10.20.120.80 sport=52344 dport=5432 src=10.20.120.80 dst=10.20.120.17 sport=5432 dport=52344 [ASSURED] mark=0 use=1
tcp      6 431998 ESTABLISHED src=10.20.120.17 dst=10.20.120.90 sport=49712 dport=443 src=10.20.120.90 dst=10.20.120.17 sport=443 dport=49712 [ASSURED] mark=0 use=1

Meaning: Flows exist and are established; if the application still complains, you’re probably seeing sporadic drops, reordering, or asymmetric return paths rather than a clean block.

Decision: Move down the stack: interface counters, ARP stability, MAC table stability, and VLAN trunk consistency.

That’s more than a dozen tasks. Use them like a funnel: start broad, then narrow to the one link that’s mintiendo sobre las etiquetas.

Tres micro-historias corporativas (anonimizadas, plausibles, dolorosas)

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

Una empresa SaaS mediana tenía una red “simple”: dos switches top-of-rack por fila, uplinks a un par de spines y un puñado de VLANs.
La red de almacenamiento era VLAN 220, la red general de servidores VLAN 120 y una VLAN de gestión de la que nadie quería hablar.

Un rack nuevo entró en servicio. El equipo de servidores apro visionó hosts con subinterfaces VLAN en Linux porque “así funcionaba el rack anterior”.
Etiquetaron eth0.120 y eth0.220, pusieron IPs allí y siguieron adelante.

El equipo de red, mientras tanto, había estandarizado los puertos hacia servidores como puertos de acceso en VLAN 120 y mantenía almacenamiento en una NIC separada.
Supusieron que los nuevos servidores estaban sin etiquetar. Nadie habló porque “son solo VLANs”.

El resultado no fue un fallo limpio. Parte del tráfico funcionó porque un host hipervisor aguas arriba tenía una configuración antigua que trunkaba los puertos,
y algunos servidores se conectaron accidentalmente a esos puertos. Otros servidores se conectaron a puertos de acceso estrictos y básicamente gritaban tramas etiquetadas al vacío.

Lo que lo convirtió en un fallo fantasma: el host de monitorización estaba por casualidad en un puerto “funcionando”. Los errores hacia clientes estaban en los puertos “roto”.
El incidente duró lo suficiente para que todos se molestaran pero no tanto como para que alguien quisiera hacer un postmortem. Hasta que volvió a ocurrir.

La solución fue humillantemente básica: alinear el contrato. O convertir los puertos de servidor en trunks con solo las VLANs necesarias permitidas, o dejar de etiquetar en los hosts.
Eligieron trunks con listas explícitas de VLAN permitidas, documentadas por rack. La siguiente puesta en servicio no requirió telepatía.

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

Una gran empresa tenía la costumbre de “limpiar la proliferación de VLANs”. Objetivo razonable. Las VLANs tienden a acumularse como buckets S3 olvidados.
Un ingeniero senior decidió apretar las listas de VLAN permitidas en trunks para reducir el ruido broadcast y limitar el impacto de fallos.

Actualizó las VLANs permitidas en varios trunks spine-to-leaf, eliminando un puñado de VLANs que “no estaban en uso”.
La comprobación de uso se basó en una exportación del CMDB y una mirada rápida a las configuraciones de switch. Fue ordenado, rápido y equivocado.

Una de las VLANs eliminadas era usada por un clúster de procesamiento por lotes legado que solo corría trabajos pesados los fines de semana.
Entre semana parecía inactivo. El sábado por la mañana, el clúster por lotes cobró vida, no pudo alcanzar su base de datos y empezó a reintentar.
Los reintentos se convirtieron en manadas atronadoras. La base de datos vio tormentas de conexión. La CPU subió. La latencia aumentó. Todos culparon a la base de datos.

Cuando descubrieron que la VLAN no estaba permitida en un único trunk, el incidente ya había mutado: el clúster por lotes también había activado
lógica de failover en otros lugares, creando una pila de alertas secundarias que enmascararon la causa raíz.

La lección no fue “nunca podar VLANs”. Fue: no podes podar basándote en papeleo. Podás podar basándote en tráfico observado y desmantelamiento deliberado.
Haz el cambio reversible, hazlo por etapas y mide. La optimización es un impuesto que pagas después si no prestas atención ahora.

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

Una fintech gestionaba múltiples centros de datos con control de cambios estricto. No control lento. Control estricto: cada VLAN tenía un responsable, un propósito
y un camino definido a través del tejido. Mantenían un “contrato VLAN” vivo que describía, para cada VLAN, dónde estaba etiquetada,
dónde estaba sin etiquetar (idealmente en ningún sitio), y qué trunks la transportaban.

Durante una renovación de hardware, se introdujo un nuevo modelo de top-of-rack. Uno de los templates por defecto en la nueva línea de switches usaba una VLAN nativa
diferente al template antiguo. Mismo proveedor, defaults distintos. Un clásico.

El ingeniero de despliegue siguió la checklist de todos modos: después de aplicar el template, ejecutó un script de validación que comparaba la VLAN nativa del trunk
y las listas de VLAN permitidas contra el contrato. Falló de inmediato. No en producción, sino en staging.

La solución tomó diez minutos: actualizar el template para desactivar el uso de VLAN nativa en trunks (etiquetar todo), establecer explícitamente las mismas VLANs permitidas
y volver a ejecutar la validación. Sin impacto al cliente. Sin espectros.

Esa es la cuestión con las prácticas aburridas: no hacen grandes historias de guerra, pero te evitan protagonizar una.

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

1) “Algunos hosts en el rack no alcanzan el gateway, otros sí”

Causa raíz: Configs mixtas de access y trunk en puertos hacia servidores; hosts etiquetando de forma inconsistente.

Solución: Estandarizar: o los hosts están sin etiquetar (puertos de acceso) o los hosts etiquetan (puertos trunk). Elegir uno por entorno y aplicarlo con plantillas.

2) “Fallos ARP intermitentes, entradas de vecino quedan INCOMPLETE”

Causa raíz: Desajuste de VLAN causando que solicitudes/respuestas ARP aterricen en VLANs distintas, o inestabilidad de tabla MAC por fuga/bucle.

Solución: Validar el contrato de etiquetado salto a salto; revisar flaps de MAC en switches; eliminar trunks no etiquetados o VLANs nativas descoordinadas.

3) “Solo fallan transferencias grandes; pings pequeños funcionan”

Causa raíz: Desajuste de MTU amplificado por la sobrecarga de la etiqueta VLAN o encapsulación de overlay; PMTUD bloqueado; jumbos inconsistentes.

Solución: Alinear MTU en host, puertos de switch, port-channels y cualquier overlay. Permitir ICMP “fragmentation needed” donde sea apropiado o aplicar MSS clamping.

4) “Advertencias de flapping de dirección MAC en el switch”

Causa raíz: Bucle L2, enlaces redundantes mal cableados sin LACP correcto, o fuga de VLAN donde la misma MAC aparece en múltiples lugares.

Solución: Revisar estado de spanning tree, bundles LACP y asegurar que las VLANs no están accidentalmente puenteadas entre segmentos. Arreglar cableado y configuración de port-channel.

5) “El firewall no ve nada; las apps hacen timeout igualmente”

Causa raíz: Los paquetes nunca alcanzan la interfaz/VLAN del firewall que crees; llegan sin etiquetar o en otra VLAN y se descartan en otro sitio.

Solución: Capturar tráfico en las interfaces del firewall con conciencia VLAN; verificar el etiquetado del switch hacia el firewall; evitar confiar en la VLAN nativa para zonas críticas.

6) “Después de un cambio, una VLAN está muerta pero solo en una dirección”

Causa raíz: Desajuste en la lista de VLANs permitidas en un trunk en un camino multi-salto; VLANs permitidas asimétricas o poda inconsistente.

Solución: Comparar listas de VLANs permitidas en ambos extremos de cada trunk; usar automatización para detectar deriva; ejecutar la poda por etapas con comprobaciones de tráfico observadas.

7) “Las VMs en el mismo host se ven, pero no fuera del host”

Causa raíz: El vSwitch/bridge del hipervisor etiqueta internamente, pero el uplink físico está configurado como access (o el trunk tiene la VLAN equivocada).

Solución: Hacer que el uplink físico sea un trunk que transporte las VLANs de las VMs; verificar el filtrado VLAN en bridges Linux o los IDs VLAN de portgroup en el hipervisor.

8) “La redundancia lo empeora”

Causa raíz: Los miembros de un bundle LACP no comparten ajustes VLAN idénticos; o un lado es LACP y el otro son puertos individuales estáticos.

Solución: Configurar VLANs en el port-channel, no en los miembros individuales; verificar estado LACP; asegurar que ambos lados coinciden en modo y expectativas de hashing.

Broma #2: La VLAN nativa es como un cajón de “miscelánea”—bien hasta que necesitas encontrar algo, entonces se vuelve una escena del crimen.

Listas de verificación / plan paso a paso

Paso a paso: arreglar el incidente actual de forma segura

1. Elige un único flujo fallando (host origen, host/destino/gateway, protocolo/puerto). Escríbelo.
2. Prueba el etiquetado en la fuente usando ip -d link y tcpdump vlan.
3. Revisa el modo del puerto adyacente (access vs trunk) y los parámetros de VLAN (nativa, VLANs permitidas).
4. Recorre el camino: en cada salto de trunk, verifica que la VLAN esté permitida y etiquetada de forma consistente.
5. Comprueba la estabilidad MAC: busca flapping; si está presente, detente y busca bucles/misbundles antes de cambiar más VLANs.
6. Corrige el contrato en un límite: elige “host etiqueta” o “red etiqueta”, no ambos. Implementa el cambio más pequeño que restaure la coherencia.
7. Valida con captura: verifica tramas etiquetadas donde las esperas y sin etiquetar solo donde lo quieras explícitamente.
8. Bloquea el cambio: actualiza plantillas y gestión de configuraciones para que la deriva no reaparezca la próxima semana.
9. Verificación post-incidente: ejecuta pruebas MTU y observa la estabilidad ARP/ND durante al menos un intervalo de envejecimiento de MAC.

Checklist: diseñar VLANs para que no te persigan

• Etiqueta todo en los trunks. Si debes usar una VLAN nativa, hazla no usada para tráfico de usuario y consistente en todas partes.
• Minimiza L2 donde puedas. Haz routing en el ToR si tu diseño lo soporta; mantén VLANs pequeñas e intencionales.
• Listas explícitas de VLAN permitidas en trunks—combinadas con automatización para detectar deriva. La poda manual es donde las buenas intenciones mueren.
• Una única fuente de verdad para la propiedad y propósito de VLAN. Si nadie posee la VLAN 317, al final te poseerá a ti.
• Estandariza la conectividad de servidores. Decide etiquetado en host vs puertos de acceso; documenta excepciones como delitos que requieren papeleo.
• Monitorea señales L2: flaps de MAC, cambios STP, anomalías en la tasa ARP. Son la alarma de humo para problemas de VLAN.

Checklist: validación previa al cambio (antes de tocar producción)

• Confirma que ambos extremos de cada trunk coinciden en: modo de trunking, VLAN nativa (si la hay), lista de VLANs permitidas.
• Confirma consistencia LACP: mismo modo, mismos puertos miembros, mismos ajustes VLAN en el bundle.
• Confirma MTU: NICs de host, puertos de switch, port-channels y fronteras overlay.
• Ejecuta una prueba rápida: ARP al gateway, ping con DF y una pequeña transacción de aplicación si es posible.
• Tener un plan de rollback que restaure rápidamente la lista de VLAN permitidas o el modo de puerto previo.

Principio operacional que deberías robar

Aquí hay una idea parafraseada atribuida a Richard Cook (ingeniería de resiliencia): los sistemas complejos tienen éxito porque las personas se adaptan continuamente para mantenerlos funcionando.
La deriva de VLAN prospera cuando tu sistema depende de la adaptación de héroes en vez de contratos explícitos.

Preguntas frecuentes

1) ¿Qué es exactamente un “fallo fantasma” en términos de VLAN?

Un fallo en el que la conectividad falla de forma intermitente o parcial porque las tramas a veces se clasifican en la VLAN equivocada a lo largo del trayecto.
No es un corte limpio; es un dolor probabilístico.

2) ¿La VLAN nativa es inherentemente mala?

La VLAN nativa es una característica de compatibilidad. No es mala, es fácil de usar mal. Si la usas, mantenla consistente en ambos extremos y evita llevar tráfico de usuario sin etiqueta.
Muchos equipos de producción optan por “etiquetar todo” en trunks y tratar lo no etiquetado como una mala configuración.

3) ¿Un desajuste de VLAN puede causar conectividad unilateral?

Sí. Si las tramas salientes están etiquetadas correctamente pero las de retorno se aprenden/reenvían en una VLAN distinta (o llegan sin etiquetar y se asignan a otra VLAN),
obtienes alcanzabilidad asimétrica: el SYN sale, el SYN-ACK nunca vuelve.

4) ¿Por qué los problemas ARP aparecen primero?

ARP (y ND en IPv6) es broadcast/multicast y depende de estar en el dominio L2 correcto. Si la clasificación de VLAN es errónea, la resolución de direcciones falla de maneras que TCP no puede ocultar por mucho tiempo.
Verás entradas de vecino quedar incompletas, o MACs del gateway “cambiar”.

5) ¿El etiquetado VLAN afecta al MTU?

La etiqueta VLAN añade 4 bytes. En equipos correctamente configurados, la MTU física lo acomoda. En la vida real, los dispositivos discrepan.
Si tu diseño es ajustado (jumbos, overlays), esos 4 bytes pueden empujarte a descartes o fragmentación a menos que alinees la MTU extremo a extremo.

6) ¿Cómo elijo entre etiquetado en host y puertos de acceso en el switch?

Si ejecutas hipervisores o necesitas múltiples VLANs en una NIC, el etiquetado en host (o en el hipervisor) suele ser práctico—combinado con puertos trunk.
Si buscas simplicidad y menos piezas móviles, puertos de acceso por NIC por VLAN pueden ser más seguros. La elección equivocada es mezclar ambos sin documentación.

7) ¿Cuál es la forma más rápida de demostrar que una VLAN está permitida a través del tejido?

Desde el host: captura tramas etiquetadas saliendo de la NIC, luego captura en el switch adyacente (SPAN/mirror) para ver si esas tramas etiquetadas llegan sin cambios.
Si desaparecen o quedan sin etiqueta, has encontrado un límite que rompe el contrato.

8) ¿La poda de VLAN permitidas puede causar problemas incluso si “nadie usa esa VLAN”?

Sí, porque “nadie la usa” a menudo significa “nadie la usa ahora mismo”. Jobs programados, pruebas de DR, appliances antiguos o failovers HA pueden activar usos latentes de VLAN.
Podá solo después de una desmantelación verificada y observada, no solo por documentación.

9) ¿Cómo se relaciona esto con fallos de almacenamiento?

Los protocolos de almacenamiento son sensibles a pérdida y latencia. Una pequeña cantidad de pérdida intermitente relacionada con VLAN puede disparar timeouts, failovers o replicación degradada.
El almacenamiento se convierte en tu sistema de aviso temprano de que “la red está mintiendo”.

10) Si uso VXLAN/EVPN, ¿siguen importando los errores de VLAN?

En algunos lugares menos, en otros más. Las sobreposiciones reducen la proliferación L2, pero aún tienes VLANs en el borde (puertos de servidor, uplinks VTEP, segmentos de handoff).
El mal etiquetado en el borde aún puede crear fallos fantasma—ahora con encapsulación que hace los síntomas más difíciles de leer.

Conclusión: pasos prácticos siguientes

Los fallos fantasma no son sobrenaturales. Son lo que obtienes cuando tu red no puede responder consistentemente a una pregunta básica: “¿En qué VLAN está esta trama?”
El etiquetado inconsistente, las VLANs nativas descoordinadas y las listas de VLAN permitidas que derivan convierten Ethernet en un libro de elige-tu-propia-aventura,
excepto que el final siempre es un canal de incidentes lleno de capturas de pantalla.

Pasos siguientes que realmente mueven la aguja:

1. Elige una política: etiqueta todo en trunks y trata lo no etiquetado como una excepción deliberada.
2. Escribe el contrato VLAN: para cada VLAN, define dónde existe, dónde está etiquetada y quién la posee.
3. Automatiza la detección de deriva: mismatches de VLAN nativa y VLANs permitidas deberían detectarse antes que los usuarios lo noten.
4. Añade señales L2 a la monitorización: flaps de MAC, eventos STP, anomalías ARP/ND y caídas de interfaz.
5. Practica el guion: ejecuta los pasos de diagnóstico rápido en periodos tranquilos para poder hacerlo bajo presión.

Haz eso y la próxima vez que alguien diga “es intermitente”, tendrás una lista corta de pruebas —no una larga lista de conjeturas.