Hands-On Lab: Configuring VTP Transparent Mode

This hands-on lab configures a switch in VTP transparent mode, demonstrating how it forwards VTP advertisements between other switches without applying them to its own VLAN database, while still allowing local VLANs to be created independently.

VTP Transparent ModeVTP Advertisement ForwardingLocal VLAN Database

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۳۱ شهریور ۱۴۰۵

Lab Objective

Configure a switch in VTP transparent mode between an existing VTP server and client, verify it does not apply server-originated VLAN changes to its own database, but still forwards those advertisements onward, and confirm it can independently create its own local VLANs.

Lab Purpose

Transparent mode is often misunderstood: a transparent switch behaves like neither a server nor a client for its own VLAN database, yet it still relays VTP advertisements between other switches physically connected through it. Understanding this dual behavior is essential to correctly diagnosing why a VLAN appears on some switches but not others in a VTP domain.

Lab Topology

SwitchServer ---- SwitchTransparent ---- SwitchClient

All three switches connected via trunk links,
all in VTP domain CorpNet (SwitchServer and
SwitchClient already configured from the
previous lab)

Task 1: Configure Transparent Mode

On the middle switch, join the same VTP domain and explicitly set VTP mode to transparent.

Task 2: Create a VLAN on the Server

On SwitchServer, create VLAN 40 named Sales.

Task 3: Verify the Transparent Switch Does Not Apply the VLAN Locally

Check SwitchTransparent's own VLAN database and confirm VLAN 40 is NOT automatically added there.

Task 4: Verify the VLAN Still Reaches the Client

Check SwitchClient's VLAN database and confirm VLAN 40 DID successfully propagate through the transparent switch to reach it.

Task 5: Create a Local VLAN on the Transparent Switch

Create VLAN 50 named LocalOnly directly on SwitchTransparent, and confirm it does NOT appear on either SwitchServer or SwitchClient.

Solution and Verification

SwitchTransparent(config)# vtp domain CorpNet
SwitchTransparent(config)# vtp mode transparent

Setting device to VTP TRANSPARENT mode

SwitchServer(config)# vlan 40
SwitchServer(config-vlan)# name Sales
SwitchServer(config-vlan)# exit

SwitchTransparent# show vlan brief

VLAN Name       Status    Ports
---- ---------- --------- -----
1    default    active
-- VLAN 40 is absent here -- a transparent
-- switch never applies received VTP changes
-- to its own local database

SwitchClient# show vlan brief

VLAN Name       Status    Ports
---- ---------- --------- -----
30   Engineering active
40   Sales       active
-- Yet VLAN 40 successfully reached the client,
-- confirming SwitchTransparent forwarded the
-- advertisement onward without applying it locally

SwitchTransparent(config)# vlan 50
SwitchTransparent(config-vlan)# name LocalOnly
SwitchTransparent(config-vlan)# exit

SwitchServer# show vlan brief | include 50
-- (no output -- VLAN 50 never appears)

SwitchClient# show vlan brief | include 50
-- (no output -- VLAN 50 never appears)

Key Takeaway

A transparent-mode switch is functionally split in two: it acts purely as a pass-through relay for VTP advertisements originating elsewhere in the domain, while simultaneously maintaining a completely independent, locally managed VLAN database that neither sends updates to nor receives updates from any other switch — VLANs created on it stay strictly local, and VLANs created elsewhere pass through it but never take effect on it.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه