My previous Daily Drill Down in this series, ”VLANs and switching technology: Why and how to implement VLANs in your Cisco switched network environment,” described the reasons for and advantages of using VLANs in a Cisco switched network environment. In this Daily Drill Down, I’ll further our discussion by elaborating on the different types of VLANs, as well as certain options and features that can enhance and simplify your VLAN implementation.
Types of VLANs and a bit of irony
To gain a better understanding of the flexibility of VLANs, let’s first look at the different types. They fall into two basic categories: dynamic and static. As we define these terms, we can find a bit of irony. Dynamic VLANs allow you to include someone in a particular VLAN by MAC address. Although this option may have seemed like a good idea originally, it does have its drawbacks. Administering dynamic VLANs can be difficult because someone must actively maintain a list of users, their MAC addresses, and associated VLAN memberships.
The basic fallacy of dynamic VLANs is the association of the user to the MAC address. In roaming-user environments, this can be nearly impossible to maintain. Another obvious problem is that NICs can fail or be upgraded, thereby requiring further VLAN maintenance time. For these reasons, you will rarely see dynamic VLANs implemented in production networks. It is much more common to see VLANs configured in a static fashion. Static VLANs are more flexible and easier to maintain than their dynamic counterparts.
With static VLANs, we simply configure each switch port for membership in one of our VLANs. Within the static category, we can implement VLANs in different ways to suit individual network and workgroup needs. One of the simplest methods of configuring your VLAN is in a local fashion. In a local VLAN, you can place all or some of your switch ports in the same VLAN, which is local and unique to that particular switch or physical switch group. This method is well suited for workgroups that are all in the same area. It also works well if all users require universal access to resources. When users connect to the network, they are included in a VLAN based on physical location.
Another way to configure the VLAN is in an end-to-end manner. End-to-end VLAN implementations take an overall network view of the switch fabric. In other words, your VLAN configuration will now cross some, if not all, of your switches and VLAN membership has little or nothing to do with physical locale. You can include anyone connected to any switch in any VLAN. This one attribute truly exemplifies the flexibility of VLANs. Sometimes, the distinction is not quite so clear between the local and end-to-end models. The VLAN configuration may have started out locally and slowly evolved to a mixed model that is predominantly local with a few switches handling end-to-end access ports.
To better illustrate the different implementations, let’s consider a few examples. First, we’ll look at a simple local VLAN configuration in a network environment consisting of three switches. We’ll assume that each switch is outfitted with three, 48-port Ethernet modules:
Switch1> (enable) set vlan 10 2/1-48, 3/1-48, 4/1-48
Switch2> (enable) set vlan 20 2/1-48, 3/1-48, 4/1-48
Switch3> (enable) set vlan 30 2/1-48, 3/1-48, 4/1-48
In this example configuration, we’ve configured three different switches, each as its own, local VLAN. Now let’s compare this to a typical, end-to-end VLAN setup:
Switch1> (enable) set vlan 10 2/1-48
Switch1> (enable) set vlan 20 3/1-48
Switch1> (enable) set vlan 30 4/1-48
Switch2> (enable) set vlan 10 2/1-48
Switch2> (enable) set vlan 20 3/1-48
Switch2> (enable) set vlan 30 4/1-48
Switch3> (enable) set vlan 10 2/1-48
Switch3> (enable) set vlan 20 3/1-48
Switch3> (enable) set vlan 30 4/1-48
In this end-to-end VLAN example, we’ve configured each switch to host all three VLANs: 10, 20, and 30. All the ports in the second module of each switch have been allocated to VLAN 10, the third module to VLAN 20, and the fourth module to VLAN 30. This would be the way to go if personnel from different departments were dispersed all around your organization. The beauty of the end-to-end VLAN model is that you can locate anyone from any department off any switch. As previously mentioned, an environment where the local and end-to-end concepts mix can be a bit sketchy. This configuration would usually occur over time in a network that was originally configured in a local manner. As the network grows, people tend to move around and you may need to make allowances. In this case, we need to introduce the end-to-end element in the local VLAN configuration. Essentially, you’ll be borrowing a few local ports from your switches and placing them in other VLANs. Consider the following example:
Switch1> (enable) set vlan 10 2/1-48, 3/1-48, 4/1-40
Switch1> (enable) set vlan 20 4/41-48
Switch2> (enable) set vlan 20 2/1-48, 3/1-48, 4/1-40
Switch2> (enable) set vlan 30 4/41-48
Switch3> (enable) set vlan 30 2/1-48, 3/1-48, 4/1-30
Switch3> (enable) set vlan 10 4/31-40
Switch3> (enable) set vlan 20 4/41-48
In this example, switch1 is predominantly hosting VLAN 10. However, over time, we’ve borrowed ports 4/41-48 and allocated them to a different VLAN: 20. Notice that most of the ports on switch2 are members of VLAN 20, as in our original, local VLAN example. But ports 4/41-48 have been moved to VLAN 30. Switch3 is mostly a VLAN 30 system, but several ports have been moved to both VLANs 10 and 20. Technically, this would be considered an end-to-end VLAN setup. But, as you can see, what started as a local configuration has changed as personnel have moved physically around the network.
If you have multiple switches in your network, how do you go about organizing and implementing VLANs across the switch fabric of your network? This is a good question, indeed. You could do it the old-fashioned way and manually configure each switch with the VLANs required on that switch. Or you could just configure all of the VLANs on all of the switches. Unfortunately, mistakes in configuration can yield an inconsistent and problematic VLAN implementation.
Isn’t there a better alternative, you may ask? And the answer is: VTP. The VLAN trunk protocol was developed by Cisco to communicate such VLAN information between the switches on your network. In this way, you can automatically impose a level of consistency on the VLANs of your network. To use VTP, you need to understand a bit more about how it works. The first concept you need to grasp is the VTP domain. This is a grouping of switches within your LAN that will share the same VLAN information. Oftentimes, all the switches in the LAN are included in the same VTP domain.
Another important concept is the mode. You can configure a switch for several different modes. If you configure a switch in server mode, you can create and modify VLANs for the entire network via a VTP server switch. You can also configure a switch for client mode. A VTP client switch will receive information about the VLAN environment from a VTP server switch within the same VTP domain. Alternatively, you can configure a switch for VTP transparency, in which case it does not participate in the VTP communication process. Generally speaking, it’s a good idea to configure at least one core switch as a VTP server. When you want to modify the VLAN environment, you simply make the changes on the VTP server switch and the server communicates this information to the client switches. Let’s take a look at a simple example of VTP configuration on two switches:
Switch1> (enable) set vtp domain dom1
Switch1> (enable) set vtp mode server
Switch2> (enable) set vtp domain dom1
Switch2> (enable) set vtp mode client
In this VTP configuration example, we’ve configured the first switch as the server in the VTP domain, dom1. The second switch is configured as a client in domain dom1. All changes to the VLAN environment would then be made on switch1 and then communicated to switch2. One aspect that we have not yet considered is potential corruption of the VLAN environment. In some cases, if a switch is connected or moved from a different location, it could cause problems with your VLAN setup. Specifically, if a switch configured as a server for the same or a different domain has a different VLAN configuration, it could corrupt the VLAN configuration if connected to the network. For this reason, it is recommended that you clear this information from a switch before connecting it to your network. You can use the clear config command followed by a hardware reset to accomplish this:
Newswitch> (enable) clear config all
Although this is a viable option, you may not have the opportunity to exercise it if someone accidentally connects such a switch to your network. In an effort to prevent this type of errant event from disrupting the VLAN configuration of the network, VTP provides a feature that you can use to secure your VLAN setup. When you implement VTP passwords, a switch has to authenticate to the VTP domain using a password configured for the VTP domain. Any server or client that has not been configured with this password information will not be able to participate in the VTP communication process. Therefore, it would be highly unlikely that a misconfigured switch would trash the established VLAN design. To use this extra level of protection, you would configure VTP as in the following example:
Switch1> (enable) set vtp domain dom1
Switch1> (enable) set vtp mode server
Switch1> (enable) set vtp passwd pwd-dom1
Here, we’ve configured a VTP domain server with the password pwd-dom1. You’ll also want to configure the other switches within the domain dom1 with the same password. Now that the VLANs are secure and we’re managing our VLAN configurations more effectively, let’s consider for a moment the traffic issue. If VTP has communicated all of our VLAN information to all switches, how do we keep VLAN broadcast traffic from switch trunks that don’t need to carry it? For instance, in the previous example of a mixed local and end-to-end VLAN configuration, remember that every switch did not have ports on all of the VLANs. Naturally, we don’t want those switches to handle VLAN traffic for which they are not configured. Again, Cisco has provided for this contingency. VLAN pruning is a process whereby we can limit such unnecessary VLAN traffic. The goal is to confine a VLAN’s broadcasts to itself. We can configure VTP to do so, as follows:
Switch1> (enable) set vtp domain dom1 mode client
Switch1> (enable) set vtp pruning enable
Switch1> (enable) clear vtp pruneeligible 2-1000
Switch1> (enable) set vtp pruneeligible 30
In this example, we’ve enabled pruning on a client switch and designated VLAN 30 to be prune-eligible.
We can verify our VTP configuration, as well as trunking, using the following commands:
Switch1> (enable) show vtp domain
Switch1> (enable) show trunk