VTP (VLAN Trunking Protocol) es un protocolo propietario de Cisco diseñado para distribuir información de VLAN entre switches que pertenecen a un mismo dominio VTP. Su objetivo es simplificar la administración cuando varias VLAN deben existir de forma consistente en múltiples switches.
La idea parece sencilla: crear una VLAN en un punto controlado y permitir que otros switches aprendan esa información. Sin embargo, VTP también puede propagar cambios de forma amplia. Una configuración incorrecta, especialmente en implementaciones antiguas, puede provocar que una base de VLAN equivocada se distribuya por la red.
Por eso VTP debe entenderse no solamente como una herramienta de automatización, sino también como un mecanismo que requiere control de cambios, verificación y conocimiento de su versión.
Nota de plataforma: los ejemplos de este artículo se centran en Cisco Catalyst con IOS/IOS XE. El soporte exacto y algunos comportamientos pueden variar según plataforma y versión de software.
¿Qué problema resuelve VTP?
Imagina una red con varios switches y las VLAN 10, 20 y 30. Sin un mecanismo centralizado, el administrador debe crear manualmente esas VLAN en cada switch donde sean necesarias.
En una infraestructura pequeña esto puede ser manejable. Cuando aumenta el número de switches aparecen riesgos de inconsistencia: una VLAN puede existir en un equipo pero no en otro, una nueva VLAN puede no llegar a todos los switches necesarios o una eliminación puede quedar aplicada solamente en parte de la red.
VTP permite distribuir información de la base de VLAN a través de enlaces trunk dentro de un dominio administrativo.
Importante: VTP no sustituye a un trunk. El trunk transporta tráfico de múltiples VLAN entre dispositivos; VTP intercambia información administrativa sobre VLANs.
Si necesitas revisar primero 802.1Q, consulta Trunk: qué es y cómo funciona. Para la base conceptual, revisa también qué es una VLAN y cómo configurarla.
Dominio VTP
Los switches que intercambian información mediante VTP pertenecen a un VTP domain. Un ejemplo sería SEACCNA-LAB.
Switch(config)# vtp domain SEACCNA-LAB
El dominio constituye una frontera administrativa. No debemos conectar un switch y asumir que VTP sincronizará correctamente sin verificar primero su estado, versión y configuración.
VTP Server, Client, Transparent y Off
El comportamiento depende del modo VTP.
| Modo | Sincroniza mediante VTP | Modificación local de la base administrada | Reenvío de anuncios |
|---|---|---|---|
| Server | Sí | Sí, según versión y rol | Sí |
| Client | Sí | No | Sí |
| Transparent | No | Sí | Depende de la versión |
| Off | No | Sí | No |
Server
Switch(config)# vtp mode server
En VTPv3 existe una diferencia fundamental: estar en modo server no significa automáticamente tener autoridad para modificar la base distribuida. Para eso existe el Primary Server.
Client
Switch(config)# vtp mode client
El cliente recibe la información del dominio y mantiene su base de VLAN de acuerdo con las actualizaciones VTP.
Transparent
Switch(config)# vtp mode transparent
El switch no sincroniza su base local a partir de los anuncios VTP. Las VLAN pueden administrarse localmente. El tratamiento de anuncios recibidos depende de la versión.
Off
Switch(config)# vtp mode off
El equipo no participa en la sincronización y tampoco reenvía anuncios VTP. Puede ser útil para establecer una frontera explícita donde VTP no forma parte del diseño.
VTPv1, VTPv2 y VTPv3
Las tres versiones no deben estudiarse como si fueran equivalentes.
VTP versión 1
Representa el funcionamiento clásico de VTP y todavía aparece en redes antiguas, laboratorios y material de certificación.
VTP versión 2
Mantiene gran parte del modelo operacional tradicional y añade mejoras respecto de VTPv1. Elegir VTPv2 solamente porque su número es superior al de VTPv1 no constituye una estrategia de diseño.
VTP versión 3
VTPv3 introdujo controles y capacidades importantes, incluyendo el modelo Primary/Secondary Server y soporte para información que no estaba disponible de la misma manera en las versiones anteriores.
Entre los puntos relevantes están:
- Primary Server para controlar modificaciones;
- Secondary Servers;
- soporte para extended-range VLANs;
- soporte para distribución de información MST en implementaciones compatibles;
- mayor control operacional;
- posibilidad, en plataformas compatibles, de controlar VTP por interfaz.
Para habilitarlo:
Switch(config)# vtp version 3
No debemos asumir que configurar VTPv3 en un único switch migra automáticamente todo el dominio.
Configuration Revision Number: el riesgo que debes entender
Uno de los conceptos más importantes de VTP es el configuration revision number.
La revisión representa la evolución de la información distribuida por VTP y participa en la determinación de qué información es más reciente.
El error clásico es pensar: “este switch acaba de ser instalado, por lo tanto no puede afectar la red”. Lo importante no es cuánto tiempo lleva conectado, sino qué estado VTP contiene y cómo ese estado interactúa con el dominio.
Antes de integrar un switch a un dominio existente, verifica:
Switch# show vtp status
La revisión debe comprobarse antes de integrar el equipo a los trunks de producción.
¿Por qué VTP ganó fama de peligroso?
En implementaciones tradicionales, conectar de manera incorrecta un switch con estado VTP no esperado podía provocar la propagación de una base de VLAN no deseada.
Por eso una operación profesional debe verificar dominio, versión, modo, base de VLAN y revision number antes de incorporar un dispositivo.
VTPv3 mejora considerablemente el control de quién puede originar cambios, pero no sustituye la gobernanza operacional.
Primary Server en VTPv3
Esta es una de las diferencias esenciales de VTPv3.
Un dispositivo configurado como server no obtiene automáticamente autoridad permanente para modificar la base distribuida. Para determinadas modificaciones, un servidor debe asumir explícitamente el rol Primary.
Configuración inicial:
Switch(config)# vtp domain SEACCNA-LAB
Switch(config)# vtp version 3
Switch(config)# vtp mode server
Después, desde privileged EXEC:
Switch# vtp primary vlan
Y verificamos:
Switch# show vtp status
Cuidado con force
Existe también:
Switch# vtp primary vlan force
force no debe convertirse en un comando rutinario. Su propósito es permitir el takeover ignorando determinadas comprobaciones de servidores conflictivos. En producción debe utilizarse solamente cuando el administrador conoce el estado completo del dominio y existe una razón operacional concreta.
Primary no significa “para siempre”
El estado Primary es operacional. Eventos como reload o determinadas transiciones de configuración pueden hacer que sea necesario volver a establecer el rol.
Por eso el procedimiento correcto es verificar el estado real antes de ejecutar cambios, no asumir que un switch continúa siendo Primary porque lo fue anteriormente.
Ejemplo de VTPv3 con tres switches
Consideremos:
- SW1: Server que será promovido a Primary;
- SW2: Secondary Server;
- SW3: Client;
- dominio:
SEACCNA-LAB.
SW1
SW1# configure terminal
SW1(config)# vtp domain SEACCNA-LAB
SW1(config)# vtp version 3
SW1(config)# vtp mode server
SW1(config)# end
SW1# vtp primary vlan
Después de validar el takeover:
SW1# configure terminal
SW1(config)# vlan 10
SW1(config-vlan)# name USERS
SW1(config-vlan)# exit
SW1(config)# vlan 20
SW1(config-vlan)# name VOICE
SW1(config-vlan)# exit
SW1(config)# vlan 30
SW1(config-vlan)# name SERVERS
SW1(config-vlan)# end
SW2
SW2# configure terminal
SW2(config)# vtp domain SEACCNA-LAB
SW2(config)# vtp version 3
SW2(config)# vtp mode server
SW2(config)# end
SW2 participa como servidor secundario. No debemos promover todos los servidores a Primary como parte de una configuración estándar.
SW3
SW3# configure terminal
SW3(config)# vtp domain SEACCNA-LAB
SW3(config)# vtp version 3
SW3(config)# vtp mode client
SW3(config)# end
Los enlaces deben estar correctamente configurados como trunks de acuerdo con el diseño:
SW1(config)# interface GigabitEthernet1/0/48
SW1(config-if)# switchport mode trunk
Verificación:
SW1# show interfaces trunk
SW1# show vtp status
SW1# show vlan brief
Autenticación VTP
VTP permite proteger el dominio con una contraseña compartida. En VTPv3, una configuración puede ser:
Switch(config)# vtp password UnaClaveSegura hidden
La contraseña debe ser consistente entre los participantes.
No confundas esta protección con un sistema completo de autorización administrativa. El password es solamente una parte del diseño; el control del Primary Server, la protección de trunks y el proceso de cambios siguen siendo necesarios.
¿Qué es VTP Pruning?
Un trunk puede transportar múltiples VLAN. Determinado tráfico flooded —como broadcast, multicast y unknown unicast— puede atravesar enlaces donde esa VLAN no tiene receptores que necesiten recibirlo.
VTP Pruning reduce ese flooding innecesario en trunks elegibles.
En un escenario compatible:
Switch(config)# vtp pruning
Pruning no es lo mismo que allowed VLAN
No confundas VTP pruning con:
switchport trunk allowed vlan
La lista de allowed VLANs define administrativamente qué VLANs están autorizadas en el trunk. VTP pruning optimiza la propagación de determinados tipos de tráfico para VLANs elegibles.
Son mecanismos distintos.
VTP Pruning y VTPv3
El comportamiento operacional de pruning no es idéntico entre todas las versiones de VTP. En VTPv3, su habilitación debe analizarse por dispositivo de acuerdo con la plataforma y el diseño.
Además, existen VLANs que no son elegibles para pruning. No utilices pruning como sustituto de un diseño explícito de trunks y allowed VLANs.
VTP por interfaz
En plataformas compatibles con VTPv3, es posible controlar la participación de VTP en interfaces trunk. Esto permite crear fronteras donde un trunk transporta VLANs, pero no queremos propagar VTP a través de ese enlace.
El concepto importante es:
trunk permitido no significa automáticamente VTP permitido.
Comandos esenciales para verificar VTP
La disponibilidad exacta puede variar según plataforma y versión, pero entre los comandos relevantes están:
Switch# show vtp status
Switch# show vtp counters
Switch# show vtp devices
Switch# show vtp interface
Switch# show vlan brief
Switch# show interfaces trunk
show vtp status debe ser una de las primeras verificaciones porque permite comprobar versión, dominio, modo, revision number y otros parámetros operacionales.
show vtp counters ayuda a determinar si existen anuncios enviados o recibidos.
show interfaces trunk permite confirmar que el problema no está simplemente en la conectividad de Capa 2.
Troubleshooting: una VLAN no se sincroniza
Cuando una VLAN no aparece en otro switch, evita cambiar parámetros aleatoriamente. Sigue una secuencia lógica:
- verifica que el trunk esté realmente operativo con
show interfaces trunk; - compara el dominio con
show vtp status; - verifica la versión VTP;
- confirma que el modo sea el esperado;
- valida la autenticación si está configurada;
- en VTPv3, confirma el estado Primary cuando necesitas modificar la base;
- revisa los contadores VTP para comprobar intercambio de anuncios;
- verifica finalmente la base con
show vlan brief.
Este orden ayuda a separar problemas de trunking, protocolo y administración.
VTP y StackWise
Un stack funciona como un sistema lógico y VTP debe analizarse dentro de esa arquitectura. La configuración y el estado deben mantenerse coherentes durante cambios, reemplazos de miembros y operaciones sobre el stack.
Si todavía no revisaste este tema, consulta Stack de switches Cisco: StackWise, StackWise Virtual y alta disponibilidad.
VTP, STP y EtherChannel no hacen lo mismo
Estas tecnologías aparecen juntas en redes de switching, pero resuelven problemas diferentes:
| Tecnología | Función principal |
|---|---|
| VTP | Distribuir información administrativa de VLAN |
| 802.1Q | Transportar múltiples VLANs por un trunk |
| STP/RSTP | Evitar loops de Capa 2 |
| EtherChannel | Agrupar enlaces físicos en un enlace lógico |
| StackWise | Hacer que varios switches operen como un sistema lógico según la plataforma |
Puedes continuar con STP, RSTP y EtherChannel.
¿Debo utilizar VTP hoy?
No existe una respuesta universal.
VTP puede ser útil cuando existe un entorno Cisco controlado, procedimientos maduros de cambio y una razón concreta para distribuir información de VLAN mediante el protocolo.
Sin embargo, muchas organizaciones administran VLANs explícitamente mediante configuración local, templates, controladores o plataformas de automatización. En esos entornos, introducir VTP puede no aportar suficiente beneficio para justificar otra capa de estado distribuido.
La regla práctica es:
utiliza VTP cuando su beneficio operacional sea deliberado y comprendido; no lo habilites solamente porque está disponible.
Buenas prácticas
Antes de implementar o modificar VTP:
- documenta dominio, versión y modos;
- revisa
show vtp statusen los participantes; - valida trunks antes de investigar VTP;
- controla quién asume Primary en VTPv3;
- no conviertas
forceen un procedimiento normal; - protege los parámetros del dominio;
- define cómo incorporar switches nuevos;
- realiza backup antes de cambios;
- monitorea las modificaciones;
- prueba procedimientos críticos en laboratorio.
Preguntas frecuentes
¿VTP crea el trunk automáticamente?
No. VTP y trunking son funciones diferentes. El enlace trunk debe estar configurado correctamente.
¿VTP es un estándar IEEE?
No. VTP es una tecnología propietaria de Cisco. IEEE 802.1Q define el tagging utilizado en trunks Ethernet.
¿VTPv3 elimina completamente el riesgo de borrar VLANs?
No. VTPv3 mejora el control mediante Primary Server y otros mecanismos, pero los errores administrativos siguen siendo posibles.
¿Cuál es una de las principales mejoras de VTPv3?
Separar la existencia de servidores de la autoridad operacional del Primary Server para originar determinadas modificaciones.
¿Transparent recibe las VLAN del servidor?
No sincroniza su base local mediante los anuncios VTP. El tratamiento y reenvío de anuncios depende de la versión.
¿Off es igual a Transparent?
No. Ambos evitan la sincronización de la base local, pero Off también evita la participación en el reenvío VTP.
¿Pruning elimina una VLAN del trunk?
No en el mismo sentido que switchport trunk allowed vlan. Pruning reduce flooding para VLANs elegibles; la allowed list determina qué VLANs están autorizadas administrativamente.
Conclusión
VTP nació para resolver un problema real: mantener información de VLAN consistente entre múltiples switches Cisco. Puede simplificar operaciones, pero también amplifica el alcance de los cambios y por eso debe formar parte de un proceso controlado.
En redes actuales, VTPv3 merece atención especial por introducir el modelo Primary/Secondary Server e incrementar el control respecto de VTPv1 y VTPv2.
La secuencia conceptual que debes recordar es:
dominio → versión → modo → revision number → Primary Server → trunks → pruning → verificación.
Entendiendo esa secuencia, VTP deja de ser una colección de comandos y pasa a ser lo que realmente es: un mecanismo de distribución de estado que debe ser administrado como parte de la arquitectura de switching.