Does manual VLAN prunning on switch trunks improve switch performance

[mbroberson1]

Just curious what people have to say about this questio.

Does manually prunning vlans (vlan allowed command) on trunk links improve switching performance. Does it help keep the switch CPU and memory utilization down (lower) than if no manual vlan prunning was being done? Say your compamy has 100 vlans total on their core but a specifc switch which connects to the core needs access to only 5 or 10 of them, will only allowing the nessesary vlans across the trunk (on both sides of the trunk) increase the switches performance with CPU and memory utilization?

Thanks

[pille1234]

Hi,

simple answer: yes.

complex answer: probably depends on the STP variant you use. Remember that RSTP means per-vlan-spanning tree. As a result, your switch has to handle a single spanning tree instance for every vlan on every physical switchports.

-> 100 vlans * 100 interfaces = 10.000 stp instances, that of course is a burden for hardware resources. Manually pruning reduces the number of stp instances.

Btw every switch type has its on configuration limits in regards to stp instances, so in big datacenter environments with hundreds of vlans this could become a serious problem.

Regards

Pille

[Peter Paluch]

Hi Pille,

An interesting answer indeed! Please allow me to have a few comments.

The one-and-only true RSTP, the 802.1D RSTP (formerly known as 802.1w), is not a per-VLAN STP incarnation. The RSTP runs in a single instance for an arbitrary number of VLANs. Cisco adapted the RSTP into its own RPVST+ or PVRST+ (both acronyms are used and relate to the same thing). Only this RPVST+ runs in a per-VLAN fashion but the pure RSTP does not.

I do not entirely agree with your description that basically says that a per-VLAN STP runs in a per-VLAN-per-port fashion. It is certain that for each port, you have to maintain STP state information for each VLAN the port is a member of. I do not doubt that. However, a port state information is not a STP instance per se. Think more of STP instance as a collection of all data that is required for the STP to operate within a single VLAN on a single switch, including all member ports. Surely, the more ports you have in a VLAN, the more memory you consume. But I have never seen a Cisco switch complain about the inability to run a new STP instance just because of too many ports. Whenever I saw a Cisco switch complain about exceeding the platform limit for a number of running STP instances, it was always related purely to the number of created VLANs, even if each of these VLANs contained just a single active port.

Manually pruning VLANs off trunks certainly conserves CPU and memory usage. The amount of saved memory and CPU power is questionable, though. Ultimately, this is an implementation detail and only a person involved in Cisco's STP code could tell us how much memory we save by pruning VLANs off trunks. The switching throughput of a switch should not be directly influenced by VLAN pruning at all because the switching is done in specialized hardware that is not influenced by storing/processing less information about VLANs.

I see VLANs pruned manually for different reasons - mostly to limit their span, or for security purposes, or to make the behavior of STP more predictable in a more constrained topology, etc.

Best regards,

Peter

[pille1234]

Hi Peter,

you are right of course about RSTP being a single instance STP. I should have been more precise to make clear I was speaking of Per-VLAN-RSTP.

With your second part I disagree, in parts at least. You say you have never seen a Cisco switch complain about the number of running STP instances. Unfortunatly I had a 6500 once sending syslog messages about the number of virtual ports exceeding the recommended platform limits. Only thing I could do was to check if all the vlans on the trunks were still needed and if not to manually prune (remove) them.

This is what Cisco has to say about it:

In a Layer 2 looped topology design, spanning tree processing instances are created on each interface for each active VLAN. These logical instances are used by the spanning tree process in processing the spanning tree-related packets for each VLAN. These instances are referred to as active logical ports and virtual ports. Both active logical ports and virtual ports are important values to consider in spanning tree designs because they affect STP convergence time and stability. These values are usually only of concern on the aggregation layer switches because they typically have a larger number of trunks and VLANs configured than other layers in the data center topology.

[...]

An STP instance for all VLANs defined in the system configuration is present on each trunk unless manual VLAN pruning is performed. For example, on each trunk configuration the switchport trunk allowed vlan X,Y command must be performed to reduce the number of spanning tree logical interfaces being used on that port. The VTP Pruning feature does not remove STP logical instances from the port.

[...]

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DC_Infra2_5/DCI_SRND.pdf

best Regards,

Pille

[Peter Paluch]

Hello Pille,

Thank you for your insightful answer!

I have indeed not had the opportunity to see a Catalyst complain about exceeding the recommended limit for virtual ports as I work with fixed-configuration switches with modest number of ports.

I believe that there is a fairly free understanding and usage of the term "STP Instance". I tend to understand it in an object programming-oriented way: an STP instance for a particular VLAN holds all per-platform information such as root ID, bridge ID, root path cost, root port information, timers, etc., and furthermore, a number of STP virtual port instances that describe the individual per-port STP data (priorities, costs, best stored BPDU, etc.). So I definitely distinguish between an STP instance and an STP port instance. From this viewpoint, there is always a single STP instance per VLAN per platform, and each such STP instance internally holds a number of STP virtual port instances.

It may be perceived as a words play I don't argue that. Ultimately, it all depends on how the STP in IOS is coded... But I can see your logic better now, and I am not saying it is wrong.

Best regards,

Peter