It seems like I can prune a trunk with more than one command. I'm not certain which I should be using.
switchport trunk allowed vlan add 1,2,3, ...etc.
switchport trunk pruning vlan add 1,2,3, ...etc.
Does the first simply specify which VLANs are *permitted* across a trunk (disallowing whatever you haven't identified), where the second actually disallows what you have specified (allowing all others)? Am I understanding that correctly?
Allowed says what vlans are allowed to cross the trunk link. If a vlan is not in that list then it will not be allowed across the trunk whether there are ports in that vlan on the other end or not. More importantly by not allowing a vlan on a trunk you stop STP going across the trunk for that vlan.
Pruning stops traffic being sent across a trunk link if there are no ports on the other side of the trunk link in that vlan. It does not stop STP running for that vlan across the trunk link.
A quick example. You have 2 switches sw1 and sw2
On sw1 & sw2 you have 4 vlans 2, 3, 4 & 5 but on the trunk link between sw1 and sw2 you only allow vlans 2, 3 & 4.
To start with their is nothing in vlan 5 on sw2.
A port is allocated into vlan 5 on sw2 and a PC connected to it. The PC wants to talk to another PC in vlan 5 on sw1.
It will not be able to because you are not allowing that trunk on the link.
Same as above except the vlans are pruned and you include vlan 5 in the list. Note in this scenario if a vlan is not in the prune list it just means traffic will always be forwarded across the link whether it needs to be or not.
So to start with vlan 5 has been pruned off the trunk because there is no port allocated to vlan 5 on sw2.
Again a port is allocated into vlan 5 on sw2 and now that pc will be able to talk to a pc in vlan 5 on sw1 because the vlan will be go from pruned to forwarding on the trunk.
Just a supplement to Jon's post, for Chris's better understanding:
Pruning is a featute within VTP (VLAN Trunking Protocol).
Pruning is negotiated by the neighboring switches on which vlans can be pruned because of absence of hosts on the other.
What happens is the downstream switch requests the upstream switch not to send traffic for vlan 5. The upstream switch then prunes traffic for vlan 5 (does not prune the vlan itself, so the STP instance for vlan 5 remains intact).
When you connect a PC to vlan 5 on the downstream switch, then the pruning is renegotiated, and the traffic for the previously pruned vlan is again allowed.
By default, all vlans are eligible for pruning.
The "switchport trunk pruning vlan 5" makes vlan 5 eligible for pruning, and only vlan 5.
Those vlans that are not allowed for pruning using this command, will not be pruned by the VTP protocol, even if there are no hosts on that vlan on the downstream switch.
I hope I wasn't too complicated:)
[Edit] Only VTP Server or Client switches belonging to the same VTP domain will negotiate pruning.
VTP VLAN pruning, as you have described with negotiation based on what access ports are present on a switch, was something my local Cisco SE recommended against. I forget the technical justification as to why. My switches are setup as VTP Server/Client, all one domain. I have 2 core switches which are the VTP servers, and 16 access switches which are VTP clients.
Again, I wish I could remember what Cisco said about advising against VTP pruning.
Hi everyone, I would like to thank you in advance for any help you can provide a newcomer like myself!
Im studying the 100-105 book by Odom and am currently on the topic of Port security. I purchased a used 2960 and I'm trying to follow a...
While deploying a number of 18xx/2802/3802 model access points (APs), which run AP-COS as their operating platform. It can be observed on some occasions that while many of their access points were able to join the fabric WLC withou...
I am going to design and build an LAN network under a tunnel underground with long distance between the switches.
I will have 2 Catalyst switches and 8 Industrial IE3000, and they will be connected with fiber.
For now I am planning on use Layer-2 s...