In my last two Daily Drill Downs on Virtual LANs (VLANs) (“VLANs and switching technology: Types, tuning and enhancements,” and “VLANs and switching technology: Why and how to implement VLANs in your Cisco switched network environment”), I discussed why and how to use them, as well as some of the enhancements that Cisco provides to simplify the process. This time, I’ll get down into the trenches and elaborate on some of the more elusive issues involved in the underlying design process.
The following examples and comments are based on version 5.x of the CatOS deployed on the 4000-6000 series and the RSM routing module with IOS 12.x.
VLAN design issues
Depending on the overall size of your LAN, different design components will come into play. Cisco breaks LAN design constructs into building blocks or layers. Not all layers will exist in every LAN due to size differences. However, the concepts will all be there. The concepts revolve around actual switch blocks or functional groups of switches. The functional groups are known as the core, distribution, and access layers. The access layer is the network entry point for end devices such as workstations and printers; it’s known as the “edge” of the network. The access layer switches connect, in turn, to the distribution layer, where inter-VLAN routing and other functions, such as security, occur. The distribution layer links to the core layer of switches, which generally resides at the center of the network. The function of the core layer is to aggregate all of the distribution layer traffic. Therefore, the key features of the core are speed and reliability.
What does all of this have to do with VLAN design? Everything. Since one of the biggest benefits of VLANs is broadcast control, we have to determine where the VLAN starts and where it ends. In other words, what type of traffic is appropriate across which layers of the standard design model? Broadcast traffic is the main consideration here. Depending on your type of network traffic, broadcasts may be considered overhead, and as such, need to be confined to the perimeter, or the access and distribution layers.
Looking from the edge of the network inward, let’s examine a broadcast generated from a workstation connected at the access layer. This broadcast will traverse the access layer switch and may be propagated to other access layer switches via distribution switches, depending on where the VLAN terminates. Thus far, the broadcast has not made it beyond the distribution layer to the core. But what if we designed our VLANs so that they cross the core of a large network? Potentially many workstation broadcasts would not only reach the core but would cross it to other switch blocks. Since this could easily saturate the core with broadcasts, it is not recommended. I suggest that all efforts be made to terminate your VLANs at the distribution layer.
Oftentimes, networks aren’t so large that all three layers will exist on different switches. In this case, you’ll generally find that the core and distribution layers are combined in a single layer. With this combined layer performing inter-VLAN routing, broadcast control, and aggregation of all access layer traffic, you’ll want to make sure that you employ switches with enough processor and backplane capacity to handle the expected load. In this scenario, you would generally find the routing being performed by a Layer 3 route processor installed in a higher-end Cisco switch deployed as a core/distribution box.
But enough about physical network design. Size user VLANs correctly, as there is generally no need to put all users on a single VLAN. How big should the VLAN be? That depends on what percentage of overall bandwidth is consumed by broadcast traffic. If a significant amount of network utilization is comprised of broadcasts, you’ll want to consider reducing the size of your VLAN. Also, when determining the size, consider other factors such as applications, traffic types, and addressing considerations. If you have a number of chatty apps, you may want to consider breaking down that VLAN into multiple VLANs.
One of the most fundamental features associated with the VLAN is trunking, which allows a single link between network devices to carry traffic for more than one VLAN. Trunking is made possible by tagging each frame with information about its VLAN. Frame tagging is accomplished through the method of encapsulation that is employed. Two methods are available: Inter-switch link (ISL) and 802.1Q. ISL is a proprietary method developed by Cisco. It provides more extensive support for spanning tree and other features. Unfortunately, it achieves frame tagging by actually increasing the size of the Ethernet frame. Keep in mind that you may need to actually increase the MTU size to accommodate the larger frames with ISL. Use of ISL is appropriate in a Cisco-only switching environment. At one time, it was the default encapsulation type and was the recommended method. 802.1Q, on the other hand, is an open standard. Many networking vendors support it in their product lines. 802.1Q was not originally designed for extensive support of spanning tree, unlike ISL. However, there is now greater support for these features, and Cisco appears to be getting onboard with the standard. As a matter of fact, some newer Cisco switch models only support 802.1Q or default to it. Naturally, you’ll want to choose a commonly supported encapsulation type for your network devices to avoid any conflicts.
Often, a trunk can become a bottleneck if too much VLAN traffic is being forced through it. In an effort to alleviate potential bottlenecks, I recommend trunking across an EtherChannel link. This provides not only redundancy but also additional capacity. Optimally, you can utilize Cisco GBICs (Gigabit interface) and fiber connections for uplinks from access switches to distribution and/or core switches. If the additional cost is a problem, you can just as easily group fast Ethernet (10/100 Mbps) ports into an EtherChannel over UTP cables. Either way, you can improve your trunk links in terms of reliability and throughput. As an additional bonus, EtherChannels provide almost instantaneous failover as opposed to spanning tree, which will halt traffic forwarding (for what seems like an eternity) while the spanning tree is recalculated.
Traffic segregation with VLANs
The default or native VLAN on your Cisco switches is VLAN 1. The question is how to use it or not use it. The management interface, Sc0, is typically used for network access to your switch for management functions. Consider moving the management interface to its own dedicated VLAN, rather than using the default, as all ports are initially in VLAN 1 by default. The key here is security. Never allow users general access to the management VLAN. If users have that access, it is much easier for someone to compromise your network by eavesdropping information from the management VLAN, through such services as SNMP. Put users on their own VLAN.
In a network where servers and other resources are centralized, I suggest placing all commonly accessed resources on their own VLAN. Printers can be placed on a separate VLAN if print traffic is high. A common configuration is to designate one switch for servers and place all ports on that switch in a core or server-specific VLAN. Along the same lines, the access layer switches are designated as local VLANs for users. As broadcast traffic increases, you can further subdivide access layer switches by adding more user-based VLANs and spreading the switch ports among them. Utilizing local VLANs generally reduces trunk traffic, but it isn’t always possible because of security and location considerations.
Additionally, how you implement routing between your VLANs needs to be addressed. Consider carefully which VLANs need to be routed. Generally, user-based VLANs don’t need to be routed between one another, especially when resources are centralized. In this case, just route the user VLANs to the core or server VLAN so that they can access necessary network resources.
To summarize, we’ve categorized our VLANs by traffic type and security considerations. This method lays the groundwork for traffic optimization and is the initial step to securing VLAN access using access lists.
VLAN addressing and naming conventions
When addressing VLANs, consider setting aside some space for infrastructure. Consider the reserved address range 172.16.x.x. If you use the third octet for subnetting, you still have 254 useable host addresses in the fourth octet. You could set aside the first 50 or so addresses for VLAN interfaces, printers, servers, and other devices that may be added to the VLAN later. You’ll need to set up DHCP scopes accordingly. You’ll need helper addressing to direct client DHCP requests off their subnet to a centralized DHCP server. Also, you’ll create VLAN interfaces on Layer 3 devices. If you plan it properly, you can make subnet numbers, interfaces, VLAN numbers, and even trunk naming coincide. Standardizing naming and numbering makes your configuration file much easier to read and literally provides self-documentation.
As your network grows and is further subdivided into VLANs, you may find that naming conventions change or that the entire VLAN configuration may be updated to reflect changing business models. If this is the case, you’ll most likely want to hunt down the extinct VLANs you’re no longer using and remove them from your configurations. Doing so may be a simple task, depending on the size of your network. If you have a large, complex network with many VLANs, you’ll want to take an organized approach to this task. You can print a complete list of VLAN interfaces to use as a master list. On this master list, it will be easy to determine some of the unused VLANs, as they may be administratively down. For the not so obviously extinct VLANs, you’ll have to dig a little deeper. Check each VLAN in turn for current activity.
To print the VLAN interface list, use the show ip interface command as follows. We’ll perform this operation on the internal RSM routing module:
Switch-RSM# show ip interface brief
Now, to check for recent activity, let’s use ARP. It stands to reason that any active VLAN will display entries in its ARP cache associated with connected workstations. Anything active should display a list of MAC addresses up to the size of the actual VLAN. You can get a general idea of the VLAN size using the show vlan command to determine the number of ports included in the VLAN. Then, when checking the ARP cache for that VLAN, you should see a number approaching the actual size. This assumes that you’re checking the information during business hours when the majority of workstations are connected to the network and active. To view the ARP cache for VLAN 20, use the following:
Switch-RSM# show ip arp vlan20
You’ll need to run this command for each VLAN. You will see a few addresses regardless of whether the VLAN has active user nodes. These addresses are the other network switches, hubs, or routers. What you’re looking for are workstation entries, anywhere from a few to many. If you have a long list of entries in the cache, it’s safe to assume that the VLAN is actively in use. If you want to delete an extinct VLAN, use the clear vlan command. We’ll execute this command on the actual switch interface:
Switch> (enable) clear vlan 20
Obviously, if you have to remove or replace an active VLAN, it’s generally a good idea to do so after business hours. Keep in mind that when you delete a VLAN, the ports that were members are orphaned. Essentially, they become inactive. You’ll want to reassign these ports to an existing or new VLAN. Naturally, you’ll want to make any changes to your VLAN environment from a VTP server switch so that your changes are propagated to the other switches.
Remember to utilize the enhanced features provided by Cisco in your VLAN design. Employing the nuts and bolts, commonsense design guidelines outlined here in conjunction with VTP, which helps to make your VLANs more consistent, easier to manage, and can help to reduce unnecessary broadcast traffic across trunks, you can be assured of maximizing throughput and managing a problem-free VLAN environment.