Hands-On Lab: Restricting Allowed VLANs on Trunks and Changing VTP Version

This hands-on lab covers restricting which VLANs are permitted to cross a specific trunk link, preventing unnecessary broadcast traffic and improving security, and separately covers safely changing a switch's VTP version within an existing domain.

Trunk Allowed VLANsVTP Version ChangeTrunk Traffic Restriction

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

Lab Objective

Restrict a trunk link to carry only specific VLANs rather than every VLAN configured on the switch, verify the restriction takes effect, and then change the switch's VTP version while confirming the operation succeeds without disrupting the existing VLAN database.

Lab Purpose

By default, a trunk carries every VLAN known to the switch, which can unnecessarily expose broadcast traffic and security-sensitive VLANs across links that do not actually need them. Restricting allowed VLANs is standard practice on any trunk connecting to a switch that does not need every VLAN present.

Lab Topology

Switch1 ---- Gi1/0/24 (trunk to a remote-office
             switch that only needs VLANs 10 and 20)

Switch1 currently has VLANs 1, 10, 20, 30, and
999 configured, all carried on the trunk by default

Task 1: Verify the Current Trunk Allows All VLANs

Confirm the trunk currently carries every VLAN on the switch.

Task 2: Restrict the Trunk to Only VLANs 10 and 20

Configure the trunk to permit only VLANs 10 and 20.

Task 3: Verify the Restriction

Confirm the trunk now shows only the permitted VLANs.

Task 4: Change the VTP Version

Change Switch1's VTP version from 1 to 2, and confirm the operation succeeds and the existing VLAN database is preserved.

Solution and Verification

Switch1# show interfaces trunk

Port      Vlans allowed on trunk
Gi1/0/24  1,10,20,30,999

Switch1(config)# interface gigabitethernet1/0/24
Switch1(config-if)# switchport trunk allowed vlan 10,20

Switch1# show interfaces trunk

Port      Vlans allowed on trunk
Gi1/0/24  10,20

-- VLANs 1, 30, and 999 will no longer cross
-- this specific trunk, even though they still
-- exist in the switch's own VLAN database

Switch1# show vtp status | include Version

VTP version running    : 1

Switch1(config)# vtp version 2

Switch1# show vtp status | include Version

VTP version running    : 2

Switch1# show vlan brief

VLAN Name       Status    Ports
---- ---------- --------- -----
1    default    active
10   Accounting active
20   Marketing  active
30   Engineering active
999  NativeUnused active
-- All previously configured VLANs remain
-- intact after the version change

Key Takeaway

Restricting allowed VLANs on a trunk operates entirely independently from the switch's own VLAN database — a VLAN can exist locally on a switch while being deliberately excluded from a specific trunk link, giving fine-grained control over exactly which broadcast domains extend across each individual connection.

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

مقالات مرتبط

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.

ادامه