The first time I really understood the value of VTP pruning was watching broadcast traffic from a VLAN with exactly two access ports flood across a dozen trunk links it had no business touching. Every switch in the campus was carrying that VLAN’s broadcast and unknown-unicast traffic just because the trunk allowed it — regardless of whether any device on the far end actually needed it. VTP pruning exists precisely to stop that waste, and it’s one of those quietly powerful features that’s easy to enable and easy to forget about entirely.
What VTP Pruning Does
By default, a trunk link carries traffic for every VLAN allowed on it, and broadcast/multicast/unknown-unicast frames for a given VLAN get flooded to every switch that has that VLAN active — even switches with no access ports assigned to it. VTP (VLAN Trunking Protocol) pruning dynamically restricts flooded traffic so it only travels over trunk links leading to switches that actually have active ports in that VLAN.
This matters because:
- It reduces unnecessary broadcast/multicast flooding across the switched infrastructure
- It conserves trunk bandwidth, especially over lower-speed inter-switch or WAN-extended L2 links
- It scales naturally as VLANs are added/removed without manual trunk
allowed vlantuning
VTP Modes Recap (Prerequisite Context)
VTP pruning only functions meaningfully within a VTP domain using client/server mode (VTP transparent switches don’t participate in pruning negotiation, since they don’t process VTP advertisements the same way):
- Server — can create/modify/delete VLANs and originates pruning-eligible advertisements
- Client — receives VLAN database updates, cannot independently modify VLANs
- Transparent — forwards VTP advertisements but maintains its own local VLAN database, unaffected by domain-wide pruning
Given VTP’s history of causing accidental VLAN database wipes when a switch with a higher revision number joins a domain, many enterprises today run VTP transparent mode or VTPv3 with authentication instead of VTPv1/2 client/server. This guide covers pruning within a client/server domain as the classic use case, and notes the VTPv3 equivalent.
How Pruning-Eligible VLANs Work
Not every VLAN is subject to pruning by default. VLANs 2 through 1001 are pruning-eligible by default; VLAN 1 and extended-range VLANs (1002-1005 reserved, and 1006+ in some platforms) are never pruned, since VLAN 1 typically carries control traffic (CDP, VTP, PAgP, DTP) that must always be present on trunks.
Topology for This Guide
Three switches in a triangle: SW1 (VTP server), SW2 and SW3 (VTP clients), connected via trunks. VLAN 20 has active access ports only on SW1 and SW2 — SW3 has no ports in VLAN 20.
SW1 (Server)
/ \
SW2 (Client) SW3 (Client)
Step 1: Configure the VTP Domain and Mode
On SW1 (server):
SW1(config)# vtp domain CORP
SW1(config)# vtp mode server
SW1(config)# vtp password VtpSecure123
On SW2 and SW3 (clients):
SW2(config)# vtp domain CORP
SW2(config)# vtp mode client
SW2(config)# vtp password VtpSecure123
Verify the domain is consistent:
SW1# show vtp status
VTP Version capable : 1 to 3
VTP version running : 2
VTP Domain Name : CORP
VTP Pruning Mode : Disabled
VTP Traps Generation : Disabled
Device ID : 0011.2233.4455
VTP Password : configured
Step 2: Enable VTP Pruning on the VTP Server
Pruning only needs to be enabled on the VTP server — it propagates the setting to clients via VTP advertisements:
SW1(config)# vtp pruning
Verify propagation on a client:
SW2# show vtp status
VTP Pruning Mode : Enabled
Step 3: Confirm Trunk Ports Are Participating in Pruning
SW1(config)# interface GigabitEthernet0/1
SW1(config-if)# switchport trunk pruning vlan 2-1001
By default, all pruning-eligible VLANs (2-1001) are candidates on a trunk. You can restrict which VLANs are eligible for pruning on a specific trunk if needed:
SW1(config-if)# switchport trunk pruning vlan remove 100,200
Or explicitly set the pruning-eligible list:
SW1(config-if)# switchport trunk pruning vlan 10,20,30
Step 4: Verification
Check which VLANs are actually pruned on a given trunk:
SW1# show interfaces GigabitEthernet0/1 pruning
Port Vlans pruned for lack of request by an switch
Gi0/1 20 (toward SW3, if SW3 has no active ports in VLAN 20)
Check the trunk’s pruning-eligible list:
SW1# show interfaces GigabitEthernet0/1 switchport
Name: Gi0/1
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Confirm broadcast/flood traffic behavior with a test: generate broadcast traffic on VLAN 20 from a host on SW2, then use show interfaces counters on SW3’s trunk to confirm it does not show incrementing broadcast counts for that VLAN, since SW3 has no VLAN 20 ports.
VTPv3 Note
If your domain runs VTPv3 (recommended for its improved security and support for extended VLANs), pruning is configured almost identically:
SW1(config)# vtp version 3
SW1(config)# vtp domain CORP
SW1(config)# vtp mode server
SW1(config)# vtp pruning
VTPv3 additionally supports primary server election and MST-region-aware behavior, but the pruning mechanism concept remains the same.
Real-World Enterprise Scenario: Multi-Building Campus
Imagine a university campus with a VTP domain spanning a dozen closet switches trunked back to a distribution pair. Each building typically only hosts a handful of the fifty-plus VLANs defined domain-wide (dorm VLANs, faculty VLANs, IoT VLANs, guest VLANs). Without pruning, broadcast storms or heavy ARP traffic on any VLAN — even one used by just one building — would flood across every trunk in the entire campus topology. Enabling VTP pruning ensures a broadcast surge in, say, a residence hall’s VLAN never reaches the library or the science building switches that have no active ports in that VLAN, meaningfully reducing background noise on shared trunk links and improving overall campus network stability during high-broadcast events (like a DHCP storm or ARP scan).
Security Best Practices
- Always configure a VTP password to prevent unauthorized switches from joining the domain and altering the VLAN database
- Prefer VTPv3 with primary server authentication over legacy VTPv1/2 due to the well-known revision-number takeover risk
- Consider VTP transparent mode domain-wide in security-sensitive environments, and manage VLANs/trunk pruning manually via
switchport trunk allowed vlanandswitchport trunk pruning vlaninstead of relying on server/client propagation - Regularly audit
show vtp statusrevision numbers across the domain to catch any switch with an unexpectedly high revision number before it’s connected to production
Common Configuration Mistakes
- Enabling pruning without a consistent VTP domain name/password across all switches, preventing them from forming the intended VTP relationship
- Assuming VLAN 1 or other reserved VLANs can be pruned — they cannot, by design
- Forgetting that pruning only manages flooded traffic (broadcast/multicast/unknown-unicast) — it doesn’t prevent a VLAN from being technically allowed on a trunk
- Connecting a new switch with a higher VTP revision number and an empty/wrong VLAN database, accidentally wiping the domain’s VLAN configuration (the classic VTP disaster scenario)
- Not verifying pruning is actually happening with
show interfaces pruning, and assumingvtp pruningalone guarantees results
Troubleshooting Checklist
show vtp status— confirm domain name, mode, and pruning status match across switchesshow interfaces <trunk> pruning— confirm which VLANs are actually being pruned on that linkshow interfaces <trunk> switchport— confirm the pruning-eligible VLAN list- Verify VTP password consistency; a mismatch silently prevents advertisement processing
- Check
show vtp statusrevision numbers before connecting any new switch to a live VTP domain
Performance Tuning
- VTP pruning is most valuable in topologies with many VLANs and many switches, where the ratio of “VLANs defined domain-wide” to “VLANs actually active per switch” is high
- In small, flat topologies (a handful of switches, most VLANs present everywhere), pruning offers minimal benefit and adds a small layer of operational complexity — weigh it against actual need
- Combine pruning with proper storm control (
storm-control broadcast level) on access ports for defense-in-depth against broadcast storms, since pruning reduces unnecessary propagation but doesn’t cap the source
FAQs
Does VTP pruning work in VTP transparent mode? No — transparent switches don’t process VTP pruning advertisements from a server; pruning requires client/server participation (or VTPv3 equivalent).
Which VLANs are pruning-eligible by default? VLANs 2 through 1001; VLAN 1 and extended-range VLANs are excluded from pruning by default.
Is VTP pruning the same as trunk VLAN allowed-list filtering? No — allowed-list filtering (switchport trunk allowed vlan) is a static, manually configured restriction; pruning is dynamic and based on real-time VLAN activity reported across the VTP domain.
Can I use VTP pruning without running VTP server/client mode at all? No, pruning as described here depends on VTP domain participation. If you’re in transparent mode domain-wide, you’d achieve similar bandwidth savings manually via careful allowed vlan trunk configuration instead.
Summary
VTP pruning is a small configuration change with real payoff in larger multi-switch environments: it stops broadcast, multicast, and unknown-unicast traffic for a VLAN from flooding trunks leading to switches that have no active ports in that VLAN. Enable it on your VTP server, verify propagation to clients, and confirm actual pruning behavior with show interfaces pruning rather than assuming the command alone did the job. Paired with a secure VTP domain configuration (or VTPv3), it’s a clean way to keep flooded traffic contained to where it’s actually needed.
References
- Cisco: Configuring VTP
- Cisco Catalyst 9000 Series Switches VLAN Configuration Guide
