Manual pruning on trunk links upstream or downstream and STP instances

[Mark Rigby]

Greetings, during some routine maintaince i came across something that for many years i have put little thought into, But its a topic that one would assume could improve convergence times on the LAN, i have had a look through the SRND guides for any referances to this but cant find anything specific.

This relates to whether you should apply manual pruning of VLAN's on a trunk link either upstream (on the access switch) or downstream (on the distribution switch) with the aim of redudcing the number of STP instances on access layer switches.

I have always configured manual pruning at the distribution layer in conjuction with R-PVST, whilst this is effective in removing un-eligable VLAN's from trunk links  it doesnt reduce the number of STP instances on the access switch.

Testing proves that the number of STP instances can be reduced to that of the number of active VLAN's on the access switch if you apply manual pruning at the access layer.

Just interested to see where other people apply manual pruning, if at all on the LAN. I agree that if you were to follow the SRND guides to the letter you would have your access switches in VTP transparent mode which would mitigate this problem entirely, however i know that many people use VTP and have access switches in client mode thus propagating all VLAN's even though they arnt spanned across access layer switches.

Scenario #1 - Pruning at distribution layer

Distribution switch

!

interface GigabitEthernet2/0/27

description --- Uplink to Access-Switch---

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,2,8,9,19,60,61

switchport mode trunk

logging event trunk-status

switchport nonegotiate

carrier-delay msec 0

Access Switch

!

interface GigabitEthernet1/0/1

description --- Uplink to Distribution-Switch ---

switchport trunk encapsulation dot1q

switchport mode trunk

logging event trunk-status

carrier-delay msec 0

udld port aggressive

--------------------------------------------------------------------------------------

Access-switch#sh spanning-tree summary

Switch is in rapid-pvst mode

Root bridge for: VLAN0001-VLAN0002, VLAN0008, VLAN0010, VLAN0020, VLAN0030

  VLAN0040, VLAN0050, VLAN0060, VLAN0070, VLAN0080, VLAN0090, VLAN0110

  VLAN0120, VLAN0130, VLAN0140, VLAN0187, VLAN0300-VLAN0304, VLAN0390

  VLAN0590-VLAN0593, VLAN0600-VLAN0603

Extended system ID           is enabled

Portfast Default             is enabled

PortFast BPDU Guard Default  is disabled

Portfast BPDU Filter Default is disabled

Loopguard Default            is disabled

EtherChannel misconfig guard is enabled

UplinkFast                   is disabled

Stack port is StackPort1

BackboneFast                 is disabled

Configured Pathcost method used is short

Name                   Blocking Listening Learning Forwarding STP Active

---------------------- -------- --------- -------- ---------- ----------

VLAN0001                     0         0        0          7          7

VLAN0002                     0         0        0          7          7

VLAN0008                     0         0        0          7          7

---------------------- -------- --------- -------- ---------- ----------

48 vlans                     0         0        0        246        246

Scenario #2 - Pruning at access layer

Distribution switch

!

interface GigabitEthernet2/0/27

description --- Uplink to Access-Switch ---

switchport trunk encapsulation dot1q

switchport mode trunk

logging event trunk-status

switchport nonegotiate

carrier-delay msec 0

Access Switch

!

interface GigabitEthernet1/0/1

description --- Uplink to Distribution-Switch ---

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,2,8,9,19,60,61

switchport mode trunk

logging event trunk-status

carrier-delay msec 0

udld port aggressive

Access-switch#sh spanning-tree summary

Access-Switch#sh spanning-tree summary

Switch is in rapid-pvst mode

Root bridge for: none

Extended system ID           is enabled

Portfast Default             is enabled

PortFast BPDU Guard Default  is disabled

Portfast BPDU Filter Default is disabled

Loopguard Default            is disabled

EtherChannel misconfig guard is enabled

UplinkFast                   is disabled

Stack port is StackPort1

BackboneFast                 is disabled

Configured Pathcost method used is short

Name                   Blocking Listening Learning Forwarding STP Active

---------------------- -------- --------- -------- ---------- ----------

VLAN0001                     1         0        0          1          2

VLAN0002                     1         0        0          1          2

VLAN0008                     1         0        0          1          2

VLAN0009                     1         0        0          1          2

VLAN0019                     1         0        0          1          2

VLAN0060                     1         0        0         38         39

VLAN0061                     1         0        0         38         39

---------------------- -------- --------- -------- ---------- ----------

7 vlans                      7         0        0         81         88

[mullzkBern_2 · Accepted solution]

Hi Mark

You are right about reducing SPT-Instances, but the point of pruning is reducing flooded traffic from uplinks - which of course only works when the traffic is pruned on sender side, which would be the distribution layer. So moving the pruning to the access Layer makes little sense.

What could make sense is to do the pruning on both sides:

- Reduces flooded traffic

- Less SPT-Instances on Access-Switch

- Easier Troubleshooting: If a Vlan does not work on a Access-Switch, you do not have to SSH onto another (Distribution-) Switch to see wether it gets pruned.

BUT:

- If reducing SPT-Instances is a concern for you, I'd suggest you look into Multiple Spanning-Tree (MST).

- If you already use VTP, I'd suggest you use its most useful and less dangerous feature: vtp pruning. The hassle with manuel pruning is IMHO the only valid reason for using VTP at all (unless of course vlan pruning is part of your security concept, this cannot be done with vtp pruning)

Greetings from Berne, Mullzk

[Kyle McKay · Accepted solution]

I agree with above.

In our environment we manually prune all access layer, distribution and core links of unnecessary VLANs. The benefits of this methodology easily outweigh the amount of work necessary to do so; Such as reduced range of broadcasts (smaller STP domains), reduced bandwidth used as well as protection from a Layer 2 loop. Should a specific VLAN encounter a layer 2 loop, that will not negatively impact other switch blocks where this VLAN does not traverse.

[Mark Rigby]

Thank you gents for your opinions they are most welcome and insightful.

Strange that you should mention MST as it's partly the reason this has all come about, as we are carrying out a forklift upgrade of our distribution switches and migrating from MST to RPVST+.

Regards