VLAN Nativa: Guía Completa de Teoría y Configuración CCNA

Hoy voy a desglosar uno de los conceptos que más dudas genera cuando preparamos el CCNA y que es fundamental para tu éxito: la VLAN nativa.

Puede parecer algo secundario, pero te aseguro que entenderla a fondo no solo es vital para el examen, sino que te salvará de muchos dolores de cabeza en entornos de red reales.

Mi objetivo es que al final de esta guía, domines qué es, por qué existe, cómo se configura correctamente y, lo más importante, cómo diagnosticar y solucionar los problemas más comunes asociados a ella, incluyendo los riesgos de seguridad que muchos ignoran.

Voy a cubrir desde la teoría fundamental hasta un laboratorio práctico paso a paso y anécdotas de entornos de producción.

Fundamentos Clave: ¿Qué es la VLAN Nativa y Para Qué Sirve?

La VLAN nativa es una VLAN específica en un enlace troncal 802.1Q cuyas tramas se transmiten sin la etiqueta (tag) de VLAN.

Por defecto, es la VLAN 1 en los switches Cisco. Su propósito principal es mantener la compatibilidad con dispositivos que no entienden el etiquetado de VLAN, como hubs o switches más antiguos.

En los enlaces troncales IEEE 802.1Q, se utiliza el concepto de VLAN nativa. La VLAN nativa es una VLAN a la que, de forma excepcional, no se le agrega una etiqueta VLAN al reenviar tramas Ethernet a través de un enlace troncal. Es posible especificar una única VLAN nativa por cada puerto troncal.

El término “nativo” (Native) hace referencia a algo que se mantiene “en su estado original”. Las tramas Ethernet pertenecientes a la VLAN nativa son reenviadas a través del enlace troncal sin modificación alguna.

Saber para qué sirve la VLAN nativa es clave: permite que el tráfico no etiquetado, como el de ciertos protocolos de control o dispositivos antiguos, pueda cruzar un enlace troncal.

Reconocimiento de VLAN en la VLAN Nativa

Para implementar el mecanismo fundamental de las VLAN —”reenviar tramas Ethernet únicamente entre puertos de la misma VLAN”—, es imperativo que se pueda identificar correctamente la VLAN de destino de cada trama.

Las tramas de la VLAN nativa no pueden ser identificadas mediante una etiqueta. En su lugar, el reconocimiento de la VLAN correcta se logra al asegurar que la configuración de la VLAN nativa coincida en ambos switches del enlace troncal.

Por ejemplo, en el siguiente diagrama, los puertos troncales que interconectan SW1 y SW2 tienen configurada la misma VLAN nativa: VLAN 1. Por consiguiente, cuando SW1 reenvía una trama de broadcast proveniente del host B (ubicado en la VLAN 1, que es la nativa) a través del puerto troncal, no le agrega ninguna etiqueta.

Al recibir la trama de broadcast sin etiquetar, SW2 la identifica como una trama de la VLAN nativa (VLAN 1) y realiza un flooding de dicha trama a todos los puertos que pertenecen a la VLAN 1 (en este caso, solo al puerto del PC D).

¿Qué ocurre si las VLAN Nativas no coinciden?

Es posible especificar una VLAN nativa para cada puerto troncal. El número de la VLAN designada como nativa debe ser el mismo en ambos puertos del enlace troncal.

Si las VLAN nativas no coinciden, las tramas Ethernet de las VLAN implicadas pueden ser interpretadas de forma incorrecta entre los switches, provocando pérdida de conectividad o comportamiento inesperado.

Considera el mismo esquema de red, pero esta vez con una configuración no coincidente: el puerto troncal de SW1 tiene la VLAN 2 como nativa, mientras que el puerto troncal de SW2 mantiene la VLAN 1 como nativa.

Cuando el host D en la VLAN 1 envía una trama de broadcast, SW2 la reenvía por el puerto troncal sin agregar una etiqueta, ya que su VLAN nativa es la 1. SW1, al recibir la trama sin etiqueta, la asocia a su propia VLAN nativa (VLAN 2) y la reenvía hacia el puerto del host C.

Aunque la trama de broadcast del host D (VLAN 1) llegue al host C (VLAN 2), esta será descartada, ya que no se realizará el procesamiento a nivel de IP.

Una discrepancia de VLAN nativa impide la comunicación a través del enlace troncal para las VLAN afectadas (en este caso, VLAN 1 y VLAN 2).

La Trama 802.1Q: Un Vistazo a la Etiqueta (Tag)

Para comprender cómo se realiza este etiquetado, es necesario analizar la estructura de la trama.

Para añadir la etiqueta, el tamaño de la trama tuvo que aumentarse en 4 bytes. El tamaño de una trama no etiquetada va de 64 a 1518 bytes, y una etiquetada, de 68 a 1522 bytes.

Estos 4 bytes se dividen en los siguientes campos:

Cómo Configurar y Verificar la VLAN Nativa en Cisco

Por defecto, la VLAN nativa por defecto es la VLAN 1. Un switch Cisco recién salido de fábrica contiene por defecto una única VLAN activa: la VLAN 1. Inicialmente, todos los puertos pertenecen a esta VLAN1.

Si deseas modificarla, existen varios comandos de Cisco IOS que permiten cambiar la VLAN nativa en un enlace troncal. Ejecuta el siguiente comando desde el modo de configuración de interfaz:

(config)#interface <interface-name>
(config-if)#switchport trunk native vlan <vlan-id>

• <interface-name>: Nombre de la interfaz.
• <vlan-id>: Número de la VLAN que se designará como nativa.

Por ejemplo, si se configuran VLANs adicionales y puertos troncales en el switch, todos los puertos troncales tendrán por defecto la NV=VLAN1:

Switch(config)#vlan 10
Switch(config-vlan)#vlan 11
Switch(config-vlan)#vlan 12
Switch(config)#interface gigabitEthernet 0/0
Switch(config-if)#switchport trunk encapsulation dot1q
Switch(config-if)#switchport mode trunk
Switch(config-if)#end
Switch#show interfaces trunk

Port   Mode Encapsulation  Status     Native vlan
Gi0/0  on   802.1q         trunking   1

Verificación de la configuración

Para verificar la VLAN nativa, el comando show interfaces trunk es el más claro y recomendable, como se detalla en la guía de configuración de VLAN trunks de Cisco.

Switch#show interfaces trunk

Port        Mode         Encapsulation  Status        Native vlan
Fa0/3       on           802.1q         trunking      1

Port      Vlans allowed on trunk
Fa0/3       1-4094

Port        Vlans allowed and active in management domain
Fa0/3       1-2

Port        Vlans in spanning tree forwarding state and not pruned
Fa0/3       1-2

Otro comando muy útil es show interfaces [interfaz] switchport.

La salida de este comando te proporciona un informe detallado del estado del puerto. Para encontrar la VLAN nativa, debes buscar una de las siguientes líneas, dependiendo de la versión de IOS de tu equipo:

• En la mayoría de las versiones y en simuladores como Packet Tracer, la línea clave es:
  Trunking Native Mode VLAN: [ID de la VLAN]
• En versiones de IOS más modernas, la información puede aparecer como:
  Operational Native VLAN tagging: enabled, VLAN: [ID de la VLAN]

Laboratorio Práctico: Desmontando el Error “Native VLAN Mismatch”

Ahora que conocemos la teoría y los comandos, vamos a ver qué sucede en un entorno real cuando las cosas salen mal. Este es el error más común relacionado con la VLAN Nativa y una pregunta clásica del examen CCNA, conocido como la discrepancia de VLAN nativa o “el error de native VLAN mismatch”.

En un puerto troncal IEEE 802.1Q, es imperativo que la configuración de la VLAN nativa coincida con la del puerto opuesto. Si la configuración de la VLAN nativa no coincide, la comunicación en las VLANs con dicha configuración discrepante será interrumpida.

Sin embargo, la comunicación en las VLANs no afectadas por la configuración de la VLAN nativa no presentará problemas. A continuación, se analizará un laboratorio de VLAN nativa con Packet Tracer para ver un ejemplo práctico de una discrepancia de VLAN nativa.

Puedes descargar el archivo de Cisco Packet Tracer utilizado para verificar el contenido explicado en esta página desde el siguiente botón.

Packet Tracer es una herramienta de simulación de redes Cisco indispensable para tu preparación.

Configuración de Red del Laboratorio

Se configuran las VLANs 10, 20 y 30 extendiéndose entre SW1 y SW2.

La asignación de direcciones IP y VLANs para cada PC es la siguiente:

Adicionalmente, los puertos Fa0/24 de SW1 y SW2 se configuran como puertos troncales 802.1Q, estableciendo la VLAN 10 como la VLAN nativa.

Escenario 1: En una Configuración Correcta

La configuración correcta para SW1 y SW2 se muestra a continuación. Los comandos de configuración de VLAN son idénticos para ambos switches.

SW1/SW2

vlan 10,20,30
!
interface FastEthernet0/1
 switchport mode access
 switchport access vlan 10
!
interface FastEthernet0/2
 switchport mode access
 switchport access vlan 20
!
interface FastEthernet0/3
 switchport mode access
 switchport access vlan 30
!
interface FastEthernet0/24
 switchport mode trunk
 switchport trunk native vlan 10

Nota: Packet Tracer no siempre permite la creación múltiple de VLAN en una sola línea, por lo que en algunos casos tendrás que crearlas individualmente.

En SW1, la salida será similar a la siguiente:

SW1

Sw1#show vlan brief 

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Fa0/4, Fa0/5, Fa0/6, Fa0/7
                                                Fa0/8, Fa0/9, Fa0/10, Fa0/11
                                                Fa0/12, Fa0/13, Fa0/14, Fa0/15
                                                Fa0/16, Fa0/17, Fa0/18, Fa0/19
                                                Fa0/20, Fa0/21, Fa0/22, Fa0/23
                                                Gig0/1, Gig0/2
10   VLAN0010                         active    Fa0/1
20   VLAN0020                         active    Fa0/2
30   VLAN0030                         active    Fa0/3
Sw1#show interfaces trunk 
Port        Mode         Encapsulation  Status        Native vlan
Fa0/24      on           802.1q         trunking      10

Cuando la VLAN nativa coincide en SW1 y SW2, la comunicación es posible a través de ambos switches dentro de las VLANs 10, 20 y 30. Al ejecutar un comando ping entre los PCs de cada VLAN, se obtendrá una respuesta correcta.

PC11

C:\>ping 192.168.10.12
 
Pinging 192.168.10.12 with 32 bytes of data:
 
Reply from 192.168.10.12: bytes=32 time=5ms TTL=128
Reply from 192.168.10.12: bytes=32 time=1ms TTL=128
Reply from 192.168.10.12: bytes=32 time<1ms TTL=128
Reply from 192.168.10.12: bytes=32 time<1ms TTL=128
 
Ping statistics for 192.168.10.12:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 5ms, Average = 1ms

PC21

C:\>ping 192.168.20.22
 
Pinging 192.168.20.22 with 32 bytes of data:
 
Reply from 192.168.20.22: bytes=32 time<1ms TTL=128
Reply from 192.168.20.22: bytes=32 time=1ms TTL=128
Reply from 192.168.20.22: bytes=32 time<1ms TTL=128
Reply from 192.168.20.22: bytes=32 time<1ms TTL=128
 
Ping statistics for 192.168.20.22:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms

PC31

C:\>ping 192.168.30.32
 
Pinging 192.168.30.32 with 32 bytes of data:
 
Reply from 192.168.30.32: bytes=32 time<1ms TTL=128
Reply from 192.168.30.32: bytes=32 time<1ms TTL=128
Reply from 192.168.30.32: bytes=32 time<1ms TTL=128
Reply from 192.168.30.32: bytes=32 time<1ms TTL=128
 
Ping statistics for 192.168.30.32:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

Escenario 2: En Caso de Discrepancia de VLAN Nativa (Mismatch)

Ahora, generaremos una discrepancia de VLAN nativa entre SW1 Fa0/24 y SW2 Fa0/24. Para ello, modificaremos la VLAN nativa a VLAN 20 en el puerto Fa0/24 de SW2.

SW2

interface FastEthernet0/24
 switchport trunk native vlan 20

Al ejecutar el comando show interfaces trunk en SW1 y SW2, se puede observar que las configuraciones de la VLAN nativa ya no coinciden.

SW1

Sw1#show interfaces trunk 
Port        Mode         Encapsulation  Status        Native vlan
Fa0/24      on           802.1q         trunking      10
 
Port        Vlans allowed on trunk
Fa0/24      1-1005
 
Port        Vlans allowed and active in management domain
Fa0/24      1,10,20,30
 
Port        Vlans in spanning tree forwarding state and not pruned
Fa0/24      1,10,20,30

SW2

SW2#show interfaces trunk 
Port        Mode         Encapsulation  Status        Native vlan
Fa0/24      on           802.1q         trunking      20
 
Port        Vlans allowed on trunk
Fa0/24      1-1005
 
Port        Vlans allowed and active in management domain
Fa0/24      1,10,20,30
 
Port        Vlans in spanning tree forwarding state and not pruned
Fa0/24      1,30

La discrepancia de VLAN nativa puede ser detectada por CDP (Cisco Discovery Protocol), por lo que se mostrará un mensaje de error de CDP en la consola.

SW1

%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/24 (10), with SW2 FastEthernet0/24 (20).

SW2

%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/24 (20), with Sw1 FastEthernet0/24 (10).

Cuando ocurre una discrepancia de este tipo, la comunicación entre switches para las VLANs afectadas (en este caso, VLAN 10 y 20) se interrumpe o presenta un funcionamiento incorrecto, dependiendo del comportamiento de STP y de la plataforma utilizada.

Una prueba de ping desde PC11 (VLAN 10) a PC12 no recibirá respuesta.

PC11

C:\>ping 192.168.10.12
 
Pinging 192.168.10.12 with 32 bytes of data:
 
Request timed out.
Request timed out.
Request timed out.
Request timed out.
 
Ping statistics for 192.168.10.12:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

La solicitud de ping (ICMP echo request) desde PC11 a PC12 no recibe una etiqueta de VLAN al ser reenviada desde el puerto Fa0/24 de SW1. Esto se debe a que la VLAN nativa en SW1 Fa0/24 es la VLAN 10.

Posteriormente, la solicitud de ping sin etiquetar es recibida por SW2 Fa0/24. Las tramas Ethernet sin etiquetar son asociadas a la VLAN nativa configurada, que en este caso es la VLAN 20. La solicitud de ping de PC11 no será reenviada a PC12 en el puerto Fa0/1, ya que dicho puerto no pertenece a la VLAN 20. Como resultado, el ping falla.

Si no existe una entrada de caché ARP para PC12 en PC11, el proceso de resolución de direcciones ARP también fallará.

La comunicación en la VLAN 20 se ve afectada de manera similar. El ping de PC21 a PC22 también fallará.

PC21

C:\>ping 192.168.20.22
 
Pinging 192.168.20.22 with 32 bytes of data:
 
Request timed out.
Request timed out.
Request timed out.
Request timed out.
 
Ping statistics for 192.168.20.22:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Sin embargo, la comunicación dentro de la VLAN 30, que no está involucrada en la configuración de la VLAN nativa, funciona correctamente. Un ping de PC31 a PC32 recibirá una respuesta normal.

PC31

C:\>ping 192.168.30.32
 
Pinging 192.168.30.32 with 32 bytes of data:
 
Reply from 192.168.30.32: bytes=32 time<1ms TTL=128
Reply from 192.168.30.32: bytes=32 time<1ms TTL=128
Reply from 192.168.30.32: bytes=32 time<1ms TTL=128
Reply from 192.168.30.32: bytes=32 time<1ms TTL=128
 
Ping statistics for 192.168.30.32:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

Análisis Avanzado: Teoría vs. Realidad en Switches y Routers

Discrepancia de NV: Teoría vs. Realidad

¿Qué dice Cisco al respecto?

Remember that the native VLAN must match on both sides of the trunk link for 802.1Q; otherwise the link will not work. If there is a native VLAN mismatch, Spanning Tree Protocol (STP) places the port in a port VLAN ID (PVID) inconsistent state and will not forward on the link.

En la documentación oficial de Cisco esto se presenta como un escenario en el que el enlace puede dejar de reenviar tráfico debido a un estado PVID inconsistent. Sin embargo, en la práctica el comportamiento depende de la plataforma, la versión de IOS y el modo de STP utilizado. No siempre se observa una caída total del troncal, sino un funcionamiento incorrecto o parcial.

Verifiquemos esta situación. He montado un laboratorio en EVE-NG:

Asigné a los tres VPCs direccionamiento en la red 192.168.1.0/24. Teóricamente, si el troncal es funcional, VPC1 debería poder hacer ping a VPC3, ya que ambos están en la misma VLAN10. Y VPC1 debería poder hacer ping a VPC2 a través de la NV.

• Verificación: VPC1 hace ping a VPC2.
• Segunda verificación: VPC1 no hace ping a VPC3.

Tras un breve análisis, se entiende que al hacer ping a VPC3, VPC1 enviará paquetes ARP y las tramas que los contienen se transmitirán sin etiqueta por el troncal. En S2, las tramas sin etiqueta se redirigen a la NV, es decir, a la VLAN20. Por lo tanto, VPC2 verá estos ARP, pero VPC3 no.

En cuanto a STP, probé los tres modos (MST, PVST+, Rapid PVST+) y en cada caso, los puertos Gi0/0 estaban en estado de reenvío (FWD) para todas las VLANs.

Conclusión: Con una discrepancia de NV, el troncal funciona, aunque de manera incorrecta. Esta es una divergencia con la teoría. Sin embargo, hay que considerar que las pruebas se realizaron en un emulador y no en hardware real, y el comportamiento podría depender de la versión de IOS.

NV en un enrutador (Router-on-a-Stick)

¿Puede existir una NV en un enrutador? Sí. Se utiliza en el diseño no óptimo conocido como Router-on-a-Stick.

En este esquema, el enrutador se conecta al conmutador mediante un enlace troncal. En el enrutador se crean subinterfaces, una para cada VLAN.

La configuración para especificar la NV en una subinterfaz es la siguiente:

Router(config-if)#interface GigabitEthernet 0/0.12
Router(config-subif)#encapsulation dot1Q 12 native

Para verificar la configuración en un entorno de laboratorio o en determinadas plataformas, pueden utilizarse comandos de verificación que muestren las subinterfaces y su encapsulación 802.1Q, por ejemplo:

Router#show running-config interface GigabitEthernet0/0.12
Router#show ip interface brief

En algunos sistemas es posible visualizar directamente qué subinterfaz está configurada como native dentro del bloque de configuración. Ten en cuenta que la disponibilidad de comandos como show vlans depende de la plataforma y versión de IOS.

¿Qué hacer si el router no es Cisco?

Si un dispositivo no es CISCO y carece de la opción para configurar explícitamente la NV en una subinterfaz, la NV debe asignarse a la interfaz principal.

Ejemplo: En el conmutador, NV=VLAN1. En el enrutador, no creamos una subinterfaz para VLAN1. ¿Por qué? Si se crea, el tráfico desde el enrutador será etiquetado, y el conmutador descartará el tráfico etiquetado para la NV.

Por lo tanto, la dirección IP para la NV (VLAN1) debe estar configurada en la propia interfaz GigabitEthernet 0/0 del enrutador del ejemplo anterior. Es un esquema poco común, pero funcional.

Riesgos de Seguridad: El Ataque de Doble Etiquetado (VLAN Hopping)

Aquí surge una aparente contradicción: ¿cómo es posible este ataque si previamente se estableció que un puerto troncal descarta las tramas etiquetadas que coinciden con su NV? La clave del ataque reside en cómo el primer switch procesa la trama antes de enviarla a través del enlace troncal.

El escenario es el siguiente:

Supongamos que para los enlaces troncales, la NV = VLAN10, y esta misma VLAN10 se utiliza para los ordenadores de los usuarios. La VLAN20 se utiliza para los servidores.

El ataque de doble etiquetado se desarrolla en estos pasos:

1. Un atacante, conectado a un puerto de acceso configurado en la VLAN nativa (VLAN10), envía una trama con doble etiquetado: una etiqueta externa para la VLAN10 y una interna para la VLAN objetivo (VLAN20).
2. El primer switch (S1) recibe la trama en su puerto de acceso. Para reenviarla a través del enlace troncal, procesa la etiqueta externa. Al identificar que corresponde a la VLAN nativa (VLAN10), S1 retira esta etiqueta, ya que el tráfico de la NV debe enviarse sin etiquetar por el troncal.
3. Al retirar la etiqueta externa, queda expuesta la etiqueta interna (VLAN20). La trama, que ahora tiene una sola etiqueta para la VLAN20, es enviada a través del enlace troncal.
4. El segundo switch (S2) recibe una trama etiquetada estándar para la VLAN20. La procesa normalmente y la reenvía a todos los puertos pertenecientes a la VLAN20, alcanzando así el servidor objetivo.

De este modo, la vulnerabilidad no contradice la regla de descarte, sino que explota el comportamiento del switch de salida (S1) al procesar el tráfico de la VLAN nativa.

El ataque tiene éxito porque el segundo switch nunca recibe una trama etiquetada con su propia VLAN nativa.

Este tipo de vulnerabilidad subraya la importancia de una correcta segmentación y seguridad en la capa 2, un tema que he cubierto en mi guía sobre amenazas y soluciones de seguridad en redes.

Casos de Uso y Lecciones del Mundo Real

Cuándo es Conveniente Cambiar la VLAN Nativa

Aunque no se recomienda usar la NV para el tráfico de usuario, a veces puede ser muy conveniente.

Ejemplo: Un colega del departamento de servidores me pidió que configurara un switch. En este switch solo habrá servidores, todos en la misma VLAN de servidores.

Sin embargo, no se sabe en qué puertos se conectarán los servidores de virtualización. La conexión la realizará un técnico de primera línea… Es necesario que todo funcione al 100% de inmediato.

Configuramos todos los puertos “de usuario” del switch como troncales. Como NV, seleccionamos la VLAN de servidores:

• Los servidores normales con puertos de acceso funcionarán correctamente (ya se explicó por qué).
• Los servidores de virtualización tienen configurado un troncal. El propio servidor de virtualización funcionará a través de la NV del troncal sin etiqueta, mientras que sus máquinas virtuales de diferentes VLANs lo harán a través del troncal con etiqueta. Problema resuelto.

Problema de un Entorno de Producción (STP y Multi-Vendor)

Para no limitarnos a la teoría, un pequeño ejemplo de un entorno de producción que me hizo reflexionar.

Tenemos 10 switches Cisco, 4 switches Qtech y 1 D-Link, conectados en una topología de estrella.

Un estudio más a fondo revela que los switches Qtech/D-Link problemáticos no reciben tramas BPDU. Luego se descubre que para todos los troncales del lado del conmutador central, la VLAN1 no está permitida explícitamente. Esta es también la NV para todos los troncales. Añadir la VLAN1 a la lista de permitidas resuelve el problema de inmediato.

Después de varias pruebas, observé que en este entorno concreto las tramas de STP asociadas a la interoperabilidad (especialmente en escenarios con PVST+/Rapid PVST+) estaban relacionadas con VLAN 1, independientemente de cuál fuera la VLAN nativa configurada.

Esto no significa que STP dependa siempre de la VLAN 1, sino que puede ser una particularidad de implementación cuando se mezclan distintos fabricantes y modos de spanning-tree.

Conclusión y Recomendaciones Finales

Como ya hemos visto, la VLAN Nativa es mucho más que una simple configuración por defecto. Es un pilar en el funcionamiento de los enlaces 802.1Q cuya mala configuración puede generar desde fallos de conectividad sutiles hasta brechas de seguridad críticas.

Para tu certificación CCNA y tu carrera, recuerda siempre estos Puntos Clave:

• La VLAN nativa es una VLAN cuyas tramas Ethernet se reenvían a través de un enlace troncal sin que se les agregue, de forma excepcional, una etiqueta VLAN.
• Se puede configurar una VLAN nativa por cada puerto troncal. Es imperativo que la configuración coincida con la del puerto en el extremo opuesto.

Y las recomendaciones de seguridad de Cisco:

• Cambiar la VLAN nativa del valor por defecto (VLAN 1). Utiliza una VLAN dedicada que no esté en uso para tráfico real (dummy VLAN). Esta es una práctica ampliamente discutida y recomendada en foros como el de Cisco Learning Network.
• No utilizar la VLAN nativa para tráfico de usuario. Asígnale una VLAN sin puertos de acceso activos ni hosts conectados, reduciendo el riesgo de ataques de doble etiquetado (VLAN hopping).
• Asegurarse de que la VLAN nativa coincida exactamente en ambos extremos del troncal. Esto evita inconsistencias de PVID y posibles bloqueos por parte de STP.
• Desactivar DTP en enlaces troncales configurados manualmente. Utiliza switchport mode trunk y switchport nonegotiate. Aunque no está directamente ligado a la VLAN nativa, es una mejor práctica de seguridad fundamental al configurar troncales para evitar vulnerabilidades.

Si quieres profundizar, revisa mis comandos esenciales para la seguridad de un router Cisco.

Finalmente, la lección de mis pruebas en producción es clara: el funcionamiento de la VLAN Nativa y el etiquetado 802.1Q no son temas tan sencillos como podrían parecer a primera vista, especialmente en entornos con equipos de diferentes fabricantes.

Espero que esta guía exhaustiva te haya ayudado a consolidar este concepto. Si tienes alguna duda o te has enfrentado a un problema interesante con la VLAN Nativa en el mundo real, ¡déjame un comentario abajo!