CCNA: Controlling Trunk Links
"Any fool can know. The point is to understand."
I read this quote the other day, and when I started to write this article it was the very first thing that sprang to mind. Why? Well, that's simple enough. In this article we are going to look at a technology that is invaluable to us as aspiring CCNAs but is also one of those technologies that the majority of us take for granted. VLAN trunks and VLAN trunking is something that almost (and often times does) configure itself on many Cisco devices, and as such we don't normally look closely at their inner workings, and if we don't do that can we honestly say we actually understand how they work.
I mean, we 'know' how to get a trunk up and running, but that doesn't mean that we 'understand' how they work, and when we're studying for a Cisco Certification Exam it is absolutely vital that we understand everything we do. So in this article we are going to focus on the exact process that takes place when we establish a trunk between two switches, how to configure the switches to dynamically decide what VLAN's will be allowed on this trunk, and finally we will look at how to designate VLAN's we don't want the dynamic process to ever be able to remove from a trunk.
Dynamic Trunking Protocol
Dynamic Trunking Protocol (DTP) is a Cisco proprietary networking protocol that is used by IOS to negotiate trunking on a link between two Switches. It is used to negotiate the type of trunk encapsulation that the devices will use, and it operates at Layer 2 of the OSI model. Before we take a look at the encapsulation modes and what they mean we need to take a look at the mechanics of this process and the different modes of operation that DTP can use:
The following switch port mode settings exist, note that specific combinations will or will not form trunks:
autocauses the port to passively be willing to convert to trunking. The port will not trunk unless the neighbor is set to on or desirable. This is the default mode for switches like Catalyst 3560s.
Note that auto-auto links will not form trunks.
onforces the link into permanent trunking, even if the neighbor doesn't agree.
This is accomplished with the switchport mode trunk command.
Note: For this command to work you also must manually define the trunks encapsulation type: switchport trunk encapsulation [isl | dot1q]
offforces the link to permanently not trunk, even if the neighbor doesn't agree.
This is done by using the no switchport command.
desirablecauses the port to actively attempt to become a trunk, subject to neighbor agreement
A trunk will form if the neighbor is set to either on, desirable, or auto.
nonegotiateforces the port to permanently trunk but not send DTP frames.
The neighboring switch must be set to trunking manually.
The following table shows the combination of DTP modes between two connected links, and what the resulting link type will be:
|Dynamic Auto||Dynamic Desirable||Trunk||Access|
DTP is often confused with VLAN Trunking Protocol (VTP) by many aspiring CCNAs. Just keep in mind that VTP is used to communicate VLAN information between switches across trunks where DTP aids in the creation of the trunks themselves.
Trunks formed with the assistance of DTP may utilize one of two trunk encapsulation protocols:
- Cisco Inter-Switch Link (ISL) is a Cisco Systems proprietary protocol that maintains VLAN information in Ethernet frames as traffic flows between switches and routers, or two switches.
- IEEE 802.1Q (DOT1Q) is the industry standard that supports VLANs on an Ethernet network. The standard defines a system of VLAN tagging for Ethernet frames.
Getting Rid of Unwanted VLANs
Now we have created our trunk by using any successful combination of the modes described in the table provided. From this point the important thing to understand is that trunk ports will permit all VLAN traffic across the Layer 2 network by default, but in some cases, it may not make sense for all traffic to be trunked to all switches. For example, consider a switch that does not have any ports configured for VLAN 9. As such, it doesn't make much sense for traffic destined for that VLAN to be sent over the trunk link between this switch and its neighbor. In order to prevent this traffic destined for VLAN 9 from being forwarded across the trunk, we must employ VLAN Pruning.
Once enabled, VLAN pruning will stop unnecessary traffic from being forwarded to a switch with no configured ports on that VLAN. This results in conservation of available bandwidth and switch resources. This pruning of VLANs from switch to switch can happen in one of two ways. The first method we will discuss is VTP pruning, which is a dynamic process handled by VTP. The second method we will look at is manually pruning VLANs.
In real life deployments, there is quite a lot of controversy as to whether to run VTP in networks to start with; it is common to find network deployments where manual pruning is preferred because VTP pruning requires VTP client/server mode operation, and these technologies will simply not be allowed in some business networks. However, for the purpose of our CCNA preparation, we will start with VTP Pruning:
VTP pruning is a global command and affects all the switches in a VTP domain.
It only needs to be configured on one VTP server.
- All VLANs by default are prune eligible, which means that all VLANs can be pruned by this protocol.
- To block specific VLANs from the pruning mechanism, we must use the switchport trunk pruning vlan command.
In the following example, we are going to configure SW1 as a VTP Server for the domain 'CCNA2BE', we will instruct the switch to use VTP pruning, and we will also remove VLAN 6 from the list of VLANs that are eligible to be pruned:
SW1(config)# vtp domain CCNA2BE Changing VTP domain name from NULL to CCNA2BE SW1(config)# vtp pruning SW1(config)# SW1(config)# interface FastEthernet 0/20 SW1(config-if)# switchport trunk pruning vlan remove 6
Manually Pruning VLANs
In the previous section, we allowed VTP to decide what VLANs would be allowed on a trunk and even went so far as to remove a VLAN from the prune eligible list. By doing this we can prevent VTP from ever removing this VLAN from a given trunk. With VTP, we can only configure a VLAN or group of VLANs that can be pruned, not instruct the switch to prune specific VLANs. This begs the question, "How could we keep, let's say, VLAN 5 from ever being forwarded across a trunk?"
SW1(config)#interface FastEthernet 0/20 SW1(config-if)#switchport trunk allowed vlan remove 5
The switchport trunk allowed vlan command allows us to specify what VLAN or group of VLANs we want to be forwarded across a given trunk. It is important that this command be applied on both ends of a given link.
As we have seen, there is more than one way to get the same result when it comes to controlling trunk links. The Dynamic process through VTP Pruning provides us with an easy to use, virtually transparent tool to insure that we conserve switch resources, but it requires the use of VLAN Trunking Protocol and its associated issues. The manual process of pruning VLANs provides the most granular amount of control but it also brings with it more administrative overhead. The point of the exercise is to understand the advantages and drawbacks to using each of these methods, and developing the skills needed to decide which is the best tool to use in different situations.