Implementing and Troubleshooting VLANs and Trunking
It’s been a few days since I had a chance to post anything. My daughter just turned 2 and we’ve been working hard cleaning and getting ready for a big birthday party for her this last weekend. It’s been nice taking some time to spend with the Wife and some family and friends. I had a chance to talk to Philip, the guy who runs Hack and Tinker, and can say that I’m excited about some things that are planned in the near future here, so stay tuned! In the meantime, let’s dive into our next CCIE topics!
Implementing and troubleshooting VLANs – now THAT sounds like some CCIE Routing and Switching fun! For sure, this is really getting to the heart of what we’re really trying to become great at as CCIE candidates. Here’s the exam blueprint topics at hand:
2.1.c Implement and troubleshoot VLAN
2.1.c (i) Access ports
2.1.c (ii) VLAN database
2.1.c (iii) Normal, extended VLAN, voice VLAN
This seems like as good a place as any to talk about DTP. DTP isn’t a topic unto itself on the CCIE Blueprint, but plays a key role in a switch’s decision to put a port into an access state or a trunking state. Most of Cisco’s switches, especially those targeted at access-layer switches default to “switchport mode dynamic desirable.” This means that DTP is turned on and is actively trying to force ports into a trunking state. A good practice for all of your switches is to adjust that to a more secure setting the moment you take it out of the box. One such default could be to hard-code them as access ports with the interface switchport mode access command. You can also tell the switch not to send DTP frames or negotiate with other switches that are attempting to send DTP frames with the interface switchport nonegotiate command. You can place a port into a VLAN with the switchport access vlan number command. A great command for viewing switching information on a port is the show int name switchport. It gives a ton of great information!
VLANs are stored in the VLAN.dat file in flash. VLANs are automatically added when you put a port into a non-existant VLAN with the switchport access vlan number command. You can name VLANs with the name command. View VLANs with the show vlan command. It is of note that a VLAN can be suspended or shutdown. A suspended VLAN will still propagate through VTP, whereas a shutdown VLAN will not. Suspending a VLAN in a VTP domain will suspend that VLAN on all switches in the VLAN. There’s a heck of a lot more to talk about with VLANs, but we’ll cover those in sections that are dedicated to their own particular topics, like VTP and spanning-tree. So, for now, we’ll keep this short and sweet.
Normal, Extended VLAN and Voice VLAN
Normal VLANs – the ones that we’re already familiar with – are all in the range of 1 – 1005. For some time, those were the only VLANs that could exist in a network. Later, support was added for the Extended VLAN range of 1006 – 4094. VTP versions 1 and 2 are not capable of working with these VLAN numbers, so you must operate your switch in VTP transparent mode if you plan on using them with these VTP versions. As for the voice VLAN, this allows phones to tag traffic over an access port. When a Cisco phone is plugged into a port running CDP and a voice vlan, the switch uses CDP to tell the phone “tag your own traffic with this voice VLAN 802.1q tag, and leave traffic from devices attached through you untagged.”
While Cisco doesn’t explicitly include “internal VLANs” with this blueprint topic, I feel it’s good to comment on here. Internal VLANs are those that are used by a switch for internal functions. An example of an internal function is a VLAN interface. These can be viewed with the show vlan internal usage command. Unfortunately, these VLAN numbers are not consistent, either between vendors, or even between models made by the same vendor. Switches automatically allocate these according to their configured vlan internal allocation policy direction command. You can view usage with the show vlan internal usage command. One major potential for trouble is that a switch might be using a VLAN that is already reserved as an internal VLAN number on another switch. This can produce a very diffictult scenario to trace and troubleshoot.
Next on our list of blueprint topics:
2.1.d Implement and troubleshoot trunking
2.1.d (i) VTPv1, VTPv2, VTPv3, VTP pruning
2.1.d (ii) dot1Q
2.1.d (iii) Native VLAN
2.1.d (iv) Manual pruning
Again, since DTP is not a topic unto itself, I’ll comment on it first, briefly covering its implications in light of trunks. Again, the show interface number switchport command gives a great deal of information about an interface, and can be very useful when troubleshooting trunking issues. DTP can negotiate both trunk status, and trunk encapsulation method. It will first try to negotiate ISL if supported. If not, it will negotiate dot1q encapsulation, and then will fall back into access port mode if trunking cannot benegotiated. DTP, when running, can be running in desirable or in auto mode. A switch in auto mode will only react to DTP messages, it will not begin sending them. Only a switch in DTP desirable mode will actively send DTP frames unprompted. Remember that configuring DTP will cause an interface flap, so you don’t want to do it outside of a maintencance window for links over which critical data passes. Configure a trunking mode with the interface switchport mode dynamic desirable or switchport mode dynamic auto commands. Surprisingly, one of the requirements for DTP to work is that both switches must have the same VTP domain name configured, even if that configured name is the NULL domain, which is default.
VTPv1, VTPv2, VTPv3 and VTP Pruning
The original VTP allowed network admins to create VLANs once on a server and allow that to propagate out to all members of the VTP domain, saving time and administrative burden. Going back to our CCNA days, we remember the huge caveat: it can blow everything up if you plug in a switch with a higher revision number than your production environment. VTPv1 can only carry the normal VLAN ranges and does not allow for carrying unrecognized information. In other words, it is not extensible enough to realize that it might need to carry and transmit information that it does not itself understand. In other other words, it is not forward-compatible. VTPv2 fixed this by allowing the carrying of unrecognized information carried in VTP TLV frames. VTP v1 and v2 allow for clients and servers, where only a server can be configured by an administrator to make changes to the VLAN database. They also support transparent mode, where the switch with forward VTP information, but will not pay any attention to it locally. VTP domain name can be configured with the vtp domain name command. Version is configured with the vtp version number command. VTP can require a password with the vtp password string command. VTP will only run on the trunk ports of a switch. View VTP information with the show VTP status command. Cisco switches run VTP by default with a domain name that is NULL. VTP domain name should, at a very minimum be set before moving switches into production, as the first switch that has a VTP domain name configured will update all switches in the NULL domain with the name and VLAN database of the first switch that ends up having a VTP domain assigned. (Yikes!!!) For environments where VTPv1 or VTPv2 are the only options, running your switches in transparent mode is usually a better option. Configure this with the vtp mode transparent command.
VTPv3 is relatively new and might not be supported on all of your switches, so do some checking before starting to implement it in your production environment. The main driver for moving to VTPv3 is really the fact that it fixes the issue where you can overwrite your VLAN database by inserting a switch with a higher revision number than what you have in production. It does this by essentially redifining the server role. VTPv3 has VTP secondary servers and a VTP primary server. It also has better password implementation (they’re no longer stored in plaintext), the abililty to advertise (but not prune) extended VLANs, the ability to turn off completely rather than just be put into transparent mode, and the ability to work with MST and private VLANs.
Here’s the infuriating part about Cisco’s brilliant new version of VTP: you can’t activate it unless VTP is already running.
Think about that – it essentially means that you have to momentarily run VTP in version 1 or 2, which both have massive risk involved if configured in the wrong order. If you are coming from an environment that does not use VTP because of those risks, but decide to use VTPv3 because it is “safe”, you could still end up destroying the VLAN database on your switches, because the default behavior of all switches with a null VTP domain name is to automatically reconfigure themselves with the whatever VTP domain name they first hear other than the null VTP domain. Granted, this would only happen if you aren’t following the best practice of putting switches into VTP transparent mode when you deploy them if you aren’t using VTP, but it still bears repeating: Don’t begin this process unless you are 100% certain that all of your switches are already in the same VTP domain, or they are all in VTP transparent mode.
Once you are sure that you can do so without destroying your environment, configure VTPv3 by first using assigning a VTP domain name. If, at that point, your network still exists (yes, I’m paranoid), configure VTP versions with the global vtp version 3 command. You can now configure your switch as a client, server, or transparent switch for any of the VTP instances that are now running – MST, VLANs or unknown. By default, switches will be VTP servers for all instances, though this can be changed with the vtp mode client <instance> command.
Notice though, that even a VTP server cannot make changes to its VLAN database.
This hints at the major improvement in VTP v3 over its predecessors: protection against accidentally overwriting the VLAN database.
In VTPv3, not even VTP servers assert their own VLAN databases as the database that all other switches in the VTP domain should run. Even if a VTPv3 server exists with a higher configuration revision, it will not cause other VTP domain members to overwrite their VLAN database. In order to cause this replication, the switch must become the PRIMARY server, which causes it to inform all other switches in the VTP domain that it has been configured by an administrator become the source of new VLAN information. Do this by backing out of global config mode (so, back into privileged exec mode) and using the vtp primary <instance> command. It will show you that it verifies with other switches that there is not already a server configured as the VTP Primary server.
Once this is complete, VLAN database replication will kick off. This is obviously a FAR more controlled method of replication as compared to VTPv1 and v2.
While most think of administrative ease of management as the main reason to run VTP, VTP Pruning is actually another benefit that might make running VTP in your environment worthwhile. VTP pruning is a function that allows VTP to take notice of times when a VLAN exists in the VLAN database, but a switch does not have any ports or downstream neighbors that need to receive this traffic. The switch can inform the upstream neighbors that it can prune the unneeded VLANs from its trunks. The main benefit of this is that it will prevent broadcasts or unknown packets from being sent across trunks if the VLANs that those packets are sent on have been pruned on the neighboring switch. Verify that a VLAN is allowed or pruned with the show interface number trunk command. Even in VTPv3 environments, only standard VLAN numbers (2-1001) are eligible to be pruned via VTP. With VTP pruning, you define which VLANs are allowed to be pruned. That means that the VLANs you designate CAN be stripped away, whereas VLANs that you do not define cannot. Define pruning eligible VLANs with the interface switchport trunk pruning vlan number command. You can verify pruning operation with the show interface number pruning command. Note that the output of this command shows the VLANs that the local switch is requesting to have forwarded from the neighbor switch, as well as the VLANs that are being pruned out toward that neighbor, and that the two do not necessarily have to be the same. In order to activate VTP pruning, use the vtp pruning command on a VTP server in the domain. In VTP versions 1 and 2, this will automatically enable VTP pruning throughout the entire VTP domain. For VTPv3, you need to enable pruning on every switch in the domain. VTP is a Cisco-proprietary standard, which means that VTP pruning will not work with other vendor switches. In such an environment, manual VLAN pruning would be needed to accomplish pruning, and to prevent non-Cisco switches from breaking the pruning functions. The reason VTP pruning breaks when facing a non-Cisco switch it that the non-Cisco switch won’t speak VTP, and therefore, won’t be able to communicate which VLANs it needs and which can be pruned, so as a fallback, the Cisco switches have to assume that all VLANs are needed on the port.
Unsurprisingly, 802.1q is the only trunking encapsulation covered on the CCIE exams. ISL has all but gone by the wayside. On some switches, you may still need to configure dot1q on your trunks by using the interface encapsulation dot1q command, but even that is becoming incresingly rare these days. The dot1q header is inserted into an Ethernet frame and adds 32 bits to the ethernet frame’s size. This header contains a Priority Code Point field, which is a 3-bit field that can hold a CoS value, followed by a Drop Eligible Indicator, indicating whether this frame should be considered to be of lower priority, in case of congestion leading to the need to drop certain frames, and then a 12-bit VLAN ID field. 12 bits gives you 4096 possible values, and values 0 and 4095 are reserved, which explains why switches support VLAN ID numbers from 1-4094.
The native VLAN is the VLAN that can traverse the trunk without being tagged. A native VLAN mismatch will cause trunks to malfunction, as traffic will end up in the VLAN of the receiving switch’s native VLAN. You can tell trunks to tag the native VLAN with the global vlan dot1q tag native command. If a switch is configured this way and receives untagged traffic, it will discard those frames, so it’s important to make sure that this is configured on both sided of the trunks. Again, as this is a CCIE-level blog, I won’t go into any further details, as it’s usually pretty safe to assume that Engineers reading this are well familiar with these concepts.
We covered the pruning concept in the VTP pruning section. VLANs can also be manually pruned. On a trunk interface, use the switchport trunk allowed vlan numbers command to define the allowed vlans list. Again, you can verify that a VLAN is allowed or pruned with the show interface number trunk command. One of the most important reasons we need to understand manual pruning is because VTP is a Cisco-proprietary protocol. This means that when using VTP pruning, only Cisco switches will know how to perform pruning via VTP. So, when facing a non-Cisco switch, if you want to prune VLANs, it will be necessary to manually do so.
Thanks again for stopping by – it’s been great to keep discovering the depths of Layer 2 and Cisco switching. I’ll try and keep these coming at a more regular pace now that things have slowed down after the holidays. Stay tuned for our next exam topic on EtherChannel… and then for the next one, which will be absolutely massive: Spanning-Tree. I’ve had these in development for weeks now and I’m very excited to be close to being ready to post. Stay tuned!