VTP Pruning

[parthrawat979]

Can someone help me understand the concep of vtp pruning.
In my topology SW1 is the server and the rest are clients. Vlans configured are 10,20,30,40
So as far as I know if vtp pruning is enabled and  a device in vlan 10 ping to another device on vlan 10 in my topology(vpc 5 ping to vpc 7) the arp(broadcast) should never reach Sw4 because it doesn't have any ports bind to vlan 10. But in the capture I found out that the arp is reaching till SW4?? Why's that happening??

This is the output of trunk interface on Sw4

Port Vlans allowed on trunk
Et0/0 1-4094

Port Vlans allowed and active in management domain
Et0/0 1,10,20,30,40

Port Vlans in spanning tree forwarding state and not pruned
Et0/0 1,10,20,30,40
&&
this is on sw3 
Port Vlans in spanning tree forwarding state and not pruned
Et0/0 1,10,20
Et0/1 1,30,40
so if sw3 int e0/1(interface toward sw4) only sends traffic of vl 1,30,40 so why am I getting an arp request with a tag of vlan 10.

[Joseph W. Doherty]

I'm responding from my phone, and cannot view your attachment.

However, one consideration of VTP pruning, I've noticed it may take several minutes (possibly up to 5?) to actually prune.

[Joseph W. Doherty]

Ok, I'm on a PC and can see your attachment.

Yes, logically, SW4 shouldn't be seeing V10 traffic, if VTP pruning in play.  (Again, I've noticed, when you enable VTP pruning, it's pruning isn't necessarily instantaneous.  So, has the network been running for a multiple minutes before trying the ping and seeing the V10 ARP packet?

Are these switches actual hardware?  If so, switch model and IOS version being used.

[parthrawat979]

Those switches aren't physical devices. I am performing the lab on eve!!

[Cristian Matei]

Hi,

    Can you provide a diagram with the physical connectivity of all these switches? Additionally, can you provide the output of following commands from all switches: "show vlan brief" , "show vtp status" , "show vtp password" , "show vtp interface" , "show vtp devices" , "show interfaces trunk" , "show cdp neighbors".

Thanks,

Cristian.

[parthrawat979]

These switches aren't physical. I am performing the lab on eve-ng. Since you didn't specify any switch so I am just providing the stats on Switch 4

sh vl br

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Et0/3
10 VLAN0010 active
20 VLAN0020 active
30 VLAN0030 active Et0/1
40 VLAN0040 active Et0/2
1002 fddi-default act/unsup

sh vtp st
VTP Version capable : 1 to 3
VTP version running : 1
VTP Domain Name : ccna
VTP Pruning Mode : Enabled
VTP Traps Generation : Disabled
Device ID : aabb.cc80.4000
Configuration last modified by 0.0.0.0 at 12-29-25 20:27:21

Feature VLAN:
--------------
VTP Operating Mode : Client
Maximum VLANs supported locally : 1005
Number of existing VLANs : 9
Configuration Revision : 6
MD5 digest : 0x1C 0x34 0x71 0xD1 0xE7 0xCD 0x28 0xFE
0x1B 0x8A 0x15 0x2D 0x45 0x92 0xA6 0x97
Switch#sh vtp pass
The VTP password is not configured.

sh int tr

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

Port Vlans allowed on trunk
Et0/0 1-4094

Port Vlans allowed and active in management domain
Et0/0 1,10,20,30,40

Port Vlans in spanning tree forwarding state and not pruned
Et0/0 1,10,20,30,40

sh cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID
Switch Eth 0/0 141 R S I Linux Uni Eth 0/1

[Joseph W. Doherty]

---

@parthrawat979 wrote:

These switches aren't physical. I am performing the lab on eve-ng. Since you didn't specify any switch so I am just providing the stats on Switch 4

---

Actually, @Cristian Matei asked for: "Additionally, can you provide the output of following commands from all switches: "show vlan brief" , "show vtp status" , "show vtp password" , "show vtp interface" , "show vtp devices" , "show interfaces trunk" , "show cdp neighbors"."

[parthrawat979]

On Switch 1:

Switch#sh vl br

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Et0/3
10 VLAN0010 active Et0/1
20 VLAN0020 active Et0/2
30 VLAN0030 active
40 VLAN0040 active
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
Switch#sh vtp st
VTP Version capable : 1 to 3
VTP version running : 1
VTP Domain Name : ccna
VTP Pruning Mode : Enabled
VTP Traps Generation : Disabled
Device ID : aabb.cc80.1000
Configuration last modified by 0.0.0.0 at 12-29-25 20:27:21
Local updater ID is 0.0.0.0 (no valid interface found)

Feature VLAN:
--------------
VTP Operating Mode : Server
Maximum VLANs supported locally : 1005
Number of existing VLANs : 9
Configuration Revision : 6
MD5 digest : 0x1C 0x34 0x71 0xD1 0xE7 0xCD 0x28 0xFE
0x1B 0x8A 0x15 0x2D 0x45 0x92 0xA6 0x97
Switch#sh vtp in
Switch#sh vtp interface

Interface VTP Status
------------------------------------
Ethernet0/0 enabled
Ethernet0/1 enabled
Ethernet0/2 enabled
Ethernet0/3 enabled
Switch#sh vtp de
Switch#sh int tru

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

Port Vlans allowed on trunk
Et0/0 1-4094

Port Vlans allowed and active in management domain
Et0/0 1,10,20,30,40

Port Vlans in spanning tree forwarding state and not pruned
Et0/0 1,10,20,30,40
Switch#sh cdp ne
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID
Switch Eth 0/0 173 R S I Linux Uni Eth 0/0

Total cdp entries displayed : 1

On Switch 2:

sh vl br

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active
10 VLAN0010 active Et0/2
20 VLAN0020 active Et0/3
30 VLAN0030 active
40 VLAN0040 active
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
Switch#sh vtp st
VTP Version capable : 1 to 3
VTP version running : 1
VTP Domain Name : ccna
VTP Pruning Mode : Enabled
VTP Traps Generation : Disabled
Device ID : aabb.cc80.2000
Configuration last modified by 0.0.0.0 at 12-29-25 20:27:21

Feature VLAN:
--------------
VTP Operating Mode : Client
Maximum VLANs supported locally : 1005
Number of existing VLANs : 9
Configuration Revision : 6
MD5 digest : 0x1C 0x34 0x71 0xD1 0xE7 0xCD 0x28 0xFE
0x1B 0x8A 0x15 0x2D 0x45 0x92 0xA6 0x97
Switch#sh int tru

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

Port Vlans allowed on trunk
Et0/0 1-4094
Et0/1 1-4094

Port Vlans allowed and active in management domain
Et0/0 1,10,20,30,40
Et0/1 1,10,20,30,40

Port Vlans in spanning tree forwarding state and not pruned
Et0/0 1,10,20
Et0/1 1,30,40
Switch#sh cdp ne
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID
Switch Eth 0/0 138 R S I Linux Uni Eth 0/0
Switch Eth 0/1 137 R S I Linux Uni Eth 0/0

Total cdp entries displayed : 2

On SW3:

Switch#sh vl br

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active
10 VLAN0010 active
20 VLAN0020 active
30 VLAN0030 active Et0/2
40 VLAN0040 active Et0/3
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
Switch#sh vtp st
VTP Version capable : 1 to 3
VTP version running : 1
VTP Domain Name : ccna
VTP Pruning Mode : Enabled
VTP Traps Generation : Disabled
Device ID : aabb.cc80.3000
Configuration last modified by 0.0.0.0 at 12-29-25 20:27:21

Feature VLAN:
--------------
VTP Operating Mode : Client
Maximum VLANs supported locally : 1005
Number of existing VLANs : 9
Configuration Revision : 6
MD5 digest : 0x1C 0x34 0x71 0xD1 0xE7 0xCD 0x28 0xFE
0x1B 0x8A 0x15 0x2D 0x45 0x92 0xA6 0x97
Switch#sh vtp int

Interface VTP Status
------------------------------------
Ethernet0/0 enabled
Ethernet0/1 enabled
Ethernet0/2 enabled
Ethernet0/3 enabled
Switch#sh vtp de
Switch#sh vtp devices
Device information can be only retrieved in VTP version 3
Switch#sh int tr

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

Port Vlans allowed on trunk
Et0/0 1-4094
Et0/1 1-4094

Port Vlans allowed and active in management domain
Et0/0 1,10,20,30,40
Et0/1 1,10,20,30,40

Port Vlans in spanning tree forwarding state and not pruned
Et0/0 1,10,20
Et0/1 1,30,40
Switch#sh cdp ne
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID
Switch Eth 0/0 148 R S I Linux Uni Eth 0/1
Switch Eth 0/1 162 R S I Linux Uni Eth 0/0

Total cdp entries displayed : 2

[Cristian Matei]

Hi,

 @Joseph W. Doherty Thanks for hopping in. 

First and most important, enabling VTP pruning in a lab environment for learning purposes is great; however, absolutely never use this functionality in production. Now let me explain why. VTP pruning was a good feature very long time ago, saving BW in times this was expensive and scarce, but most importantly saving CPU time and avoiding CPU overload in times this was expensive and of very low performance on switches. Today, running VTP pruning adds more risk than it adds value, for few different reasons. I bet that today, VTP pruning is no longer a tested or heavily tested feature in Cisco QA, which means, from SW development perspective, there is risk of this feature not working as expected, even if there's obviously no more development being done in this area, and if this feature doesn't work as expected, your entire layer 2 domain goes dark / network down event. Also, very few engineers actually understood how the feature works, thus understood what NOT to do alongside of enabling it to, again, prevent network down event; just to give an example here, if you have a layer 2 domain, with VTP pruning enabled, and on one of the switches, for whatever reason, intentionally or accidentally, you enable VTP transparent mode, you've just isolated that switch from the layer 2 domain, and if this was a transit switch (e.g SW2 or SW3 from your diagram), you end up with two separated layer 2 domains, not being able to communicate in between, left side and right side. And there are couple of more gems in this area, for another time and discussion.

    And just to make a point, from this use case, this is why we, as engineers, need to understand the functionality inside out, as without this, we don't know when to use which feature, how to optimise it and why, what no other features to enable based on the ones already in use or if we do so which additional changes we need to perform so that this new feature integrates and works with existing ones as a single entity in harmony; put it simple, as we build on top of what's existing, we don't break the existing or the while thing. While, unfortunately, most of engineers tend to focus on the easy part, what the feature does in high-level and what is the CLI structure to get the job done. This is what separates today, and in near future, engineers that will still be looked for, and engineers which will be replaced by automation / digital robots. 

   If you've went this far, it means you also deserve the know the answer to your question. Simple answer is, VTP pruning works as expected, what you see is expected, let's understand why. The answer is in the output of command "show interfaces trunk" from your switches, specifically under "Port Vlans in spanning tree forwarding state and not pruned" section of the output.

1. Direction SW1->SW4. SW1 has hosts attached in VLAN 10 and VLAN 20 (so to start with, its E0/0 link towards SW2 has VLAN's 10 and 20 in STP FW mode and not pruned), for which reason SW1 will ask SW2 to send traffic for these VLANs (result is SW2 has E0/0, its link towards SW1, with VLAN's 10 and 20 in STP FW and not pruned); as a result of this request from SW1, now SW2 will further ask SW3 to do the same, namely send traffic for these VLANs (result is SW3 has E0/0, its link towards SW2, with VLAN's 10 and 20 in STP FW and not pruned); as a result of this request from SW2, now SW3 will further ask SW4 to do the same, namely send traffic for these VLANs (result is SW4 has E0/0, its link towards SW3, with VLAN's 10 and 20 in STP FW and not pruned)

2. Direction SW4->SW1. SW4 has hosts attached in VLAN 30 and VLAN 40 (so to start with, its E0/0 link towards SW3 has VLAN's 30 and 40 in STP FW mode and not pruned), for which reason SW4 will ask SW3 to send traffic for these VLANs (result is SW3 has E0/1, its link towards SW4, with VLAN's 30 and 40 in STP FW and not pruned); as a result of this request from SW4, now SW3 will further ask SW2 to do the same, namely send traffic for these VLANs (result is SW2 has E0/1, its link towards SW3, with VLAN's 30 and 40 in STP FW and not pruned); as a result of this request from SW3, now SW2 will further ask SW1 to do the same, namely send traffic for these VLANs (result is SW1 has E0/0, its link towards SW2, with VLAN's 30 and 40 in STP FW and not pruned)

3. From SW2's perspective, it has hosts attached in VLAN's 10 and 20, thus it will ask both SW1 and SW3 to send traffic for these VLAN's  (result is SW3 has E0/0, its link towards SW2, with VLAN's 10 and 20 in STP FW and not pruned, but this was already there from previously explained steps; additional result is that SW1 has E0/0, its link towards SW2, with VLAN's 10 and 20 in STP FW and not pruned)

4. From SW3's perspective, it has hosts attached in VLAN's 30 and 40, thus it will ask both SW2 and SW4 to send traffic for these VLAN's  (result is SW2 has E0/1, its link towards SW3, with VLAN's 30 and 40 in STP FW and not pruned, but this was already there from previously explained steps; additional result is that SW4 has E0/0, its link towards SW3, with VLAN's 30 and 40 in STP FW and not pruned)

    Just to make something clear, when you use "show interfaces trunk" and see that on a given trunk only lets's say VLAN's 10 and 30 are in STP FW state and not pruned, it means that the switch will NEVER sent traffic for other VLAN's than 10 an 30 out on that specific trunk.

  If you now put this logic on your diagram, you'll see it perfectly matches the section "Port Vlans in spanning tree forwarding state and not pruned" from output of command "show interfaces trunk", across your 4 switches. However, although from control-plane perspective (show interfaces trunk command) VTP pruning does the job, from forwarding-plane perspective (which traffic, for which VLAN's get forwarded on which trunk links) the switch fails to act on that; per your diagram, a packet sourced from VLAN 10 from SW1 should never reach SW3 and implicitly SW4, it should stop at SW2. So what you're seeing is unexpected, it's software bug which happens almost always with the virtual switch models you're testing. If you want to see this actually working in a virtual lab environment, use a Catalyst 9k Virtual image, however note that this box requires much more resources in terms of CPU and RAM, but at the same time you have less bugs.

Thanks,

Cristian.

[parthrawat979]

I can actually test it in real device like on catalyst 3750, but I don't know how to make sure that the broadcast(like arp) never reaches to sw4 or sw3, because in the real devices we ain't given to capture traffic using wireshark and as far as I know there are no such debug option to do so. The 'debug arp' method doesn't capture any reques I don't know why. Is there any go through of this in real cisco switches??

[Cristian Matei]

Hi,

    You have two options:

1. Use SPAN, so for example configure SPAN on SW3, with source being the trunk interface towards SW2 and destination being a port where you have a PC connected (on PC use Wireshark to see all traffic): https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10570-41.html#topic5

2. Use embedded packet capture on SW3, if supported by the platform and code version, to capture traffic received on trunk link towards SW2:

https://community.cisco.com/t5/networking-knowledge-base/configuration-example-embedded-packet-capture-on-cisco-ios-and/ta-p/3145491

Thanks,

Cristian.

[parthrawat979]

SPAN isn't provided to us and in embedded packet  capture it's not possible to get the capture out of the device since we don't have that much privilege.

[Cristian Matei]

Hi,

   Well, you don't have much options in this case. You can use a WA as follows:

1. On your host in VLAN 10, assuming VLAN 10 associated subnet is 10.10.10.0/24, create a static ARP mapping, like 10.10.10.10 being mapped to a MAC address of 0a0a.1111.2222

2. On SW3 configure an ACL as follows, and apply it ingress on the trunk towards SW2:

ip access-list extended TEST
 permit tcp 10.10.10.0 0.0.0.255 any log-input
 permit udp 10.10.10.0 0.0.0.255 any log-input
 permit icmp 10.10.10.0 0.0.0.255 any log-input
 permit ip any any log-input
!
interface Ethernet0/0
 switchport trunk encapsulation dot1q
 switchport mode trunk
 ip access-group TEST in
!
ip access-list logging interval 1000
ip access-list log-update threshold 1

 

3. Generate traffic, like ICMP / PING from that host on VLAN 10 towards 10.10.10.10; if VTP pruning works as expected, from forwarding-plane perspective, you should not have any matches on the first entries of the ACL, also visible via "show logging"

4. Disable VTP pruning, validate via "show interfaces trunk" that now all VLAN's are allowed on all trunks, run previous step again and now you should see matches on the first entries of the ACL, also visible via "show logging"

Thanks,

Cristian.

[parthrawat979]

it's an ip acl how will it gonna help like if I ping from vlan 10 to vlan 10 the ping will be succesfull so how I am gonna detect that. I actually want to see the unnecessary broadcast like an arp that reaching till SW4 so is there any way to do so??

[Joseph W. Doherty]

The 'debug arp' method doesn't capture any reques I don't know why.

That might be due to the switch doesn't have a L3 interface on the VLAN with ARPs.

Switches, in particular, are especially sensitive what traffic is passed through to the switch's control plane.  Remember, ideally all data plane traffic is processed by ASICs, which may not support capturing such traffic for any debug feature.

Logically, you might think a debug would examine all traffic physically enterting the switch, but it may ignore pure transit traffic that the switch, itself, has no "host" interest in.

Features such as SPAN or embedded packet capture, make all traffic, as configured, relevant.

BTW, where a similar issue is sometimes seen on switches, is a switch not updating all expected (higher level) stat counters.