Most of the time, VLANs are created by a sys admin who proceeds to assign switch ports to each VLAN. VLANs of this type are known as static VLANs. If you don’t mind doing a little more work when you begin this process, assign all the host devices hardware addresses into a database so your switches can be configured to assign VLAN dynamically any time you plug a host into a switch. I hate saying things like “obviously”, but obviously, this type of VLANS is known as Dynamic VLAN. We’ll be covering both static and dynamic VLANs in this article.
Creating static VLANs is the most common way to create a VLAN, and one of the reasons for that is because static VLANs are the most secure. This security stems from the fact that any switch port you’ve assigned a VLAN association will always maintain it unless you change the port assignment manually.
Static VLAN configuration is pretty easy to set up and supervise, and it works really well in a networking environment where any user movement within the network needs to be controlled. It can be helpful to use network management software to configure the ports, but you don’t have to use it of you don’t want to.
In the figure below, each switch port was configured manually with a VLAN membership based upon which VLAN the host needed to be a member of remembering, the device’s actual physical location doesn’t matter a bit. Which broadcast domain your hosts become members of is purely up to you. And again, remember that each host also has to have the correct IP address information. For instance, you must configure each host in VLAN 2 into the 172.16.20.0/24 network for them to become members of that VLAN. It’s also a good idea to keep in mind that if you plug a host into a switch, you have to verify the VLAN membership of that port. If the membership is different than what’s needed for that host, the host won’t be able to gain access to the network services that it needs, such as a workgroup server.
On the other hand, a dynamic VLAN determines a node’s VLAN assignment automatically. Using intelligent management software, you can base VLAN assignments on hardware (MAC) addresses, protocols, or even applications that create dynamic VLANs.
For example, let’s say MAC addresses have been entered into a centralized VLAN management application and you hook up a new node. If you attached it to an unassigned switch port, the VLAN management database can look up the hardware address and both assign and configure the switch port into the correct VLAN. Needless to say, this makes management and configuration much easier because if a user moves, the switch will simply assign them to the correct VLAN automatically. But here again, there’s a catch: you’ve got to do a lot more work initially setting up the database. It can be very worthwhile though!
And here’s some good news: You can use the VLAN Management Policy Server (VMPS) service to set up a database of MAC addresses to be used for the dynamic addressing of your VLANs. The VMPS database automatically maps MAC addresses to VLANs.
A dynamic-access port can belong to one VLAN (VLAN ID 1 all the way up to 4094) and, as we said, is dynamically assigned by the VMPS. The catalyst 2960 switch can be a VMPS client only. You can have dynamic-access ports and trunk ports on the same switch, but you have to connect the dynamic-access port to an end station or hub not to another switch!
Know that switch ports are layer 2 only interfaces that are associated with a physical port. A switch port can belong to only one VLAN if it is an access port or all VLANs if it is a trunk port. You can manually configure a port as an access or trunk port, or you can let the Dynamic Trucking Protocol (DTP) operate on a per-port basis to set the switch port mode. DTP does this by negotiating with the port on the other end of the link.
Switches are definitely pretty busy devices. As frames are switched throughout the network, they’ve got to be able to keep track of all the different types plus understand what to do with them depending on the hardware address. And remember frames are handled differently according to the type of link they’ve traversed.
There are two different types of links in a switched environment.
An access port belongs to and carries the traffic of only one VLAN. Traffic is both received and sent in native formats with no VLAN tagging whatsoever. Anything arriving on an access port is simply assumed to belong to the VLAN assigned to the port. So, what do you think will happen if an access port receives a tagged packet as IEEE 802.1Q tagged? Right, that packet would simply be dropped. But why? Well, because an access port doesn’t look at the source address, so tagged traffic can be forwarded and received only on trunk ports.
With an access link, this can be referred to as the configured VLAN of the port. Any device attached to an access link is unaware of a VLAN membership the device just assumes it’s part of the same broadcast domain, but it doesn’t have the big picture, so it doesn’t understand the physical network topology at all.
Another good bit of information to know is that switches remove any VLAN information from the frame before it’s forwarded out an access-link device. Remember that access-link devices can’t communicate with devices outside their VLAN unless the packet is routed. And you can only create a switch port to be either an access port or a trunk port, not both. So you’ve got to choose one or the other and know that if you make it an access port, that port can be assigned to one VLAN only.
Voice access ports
Not to confuse you, but all that we just said about the fact that an access port can be assigned to only one VLAN is really the only sort of true. Nowadays, most switches will allow you to add a second VLAN to an access port on a switch port for your voice traffic; it’s called the voice VLAN. The voice VLAN used to be called auxiliary VLAN, which allowed it to overlaid on top of the data VLAN, enabling both types of traffic through the same port. Even though this is technically considered to be a different type of link, it’s still just an access port that can be configured for both data and voice VLANs. This allows you to connect both a phone and a PC device to one switch port but still have each device in a separate VLAN.
Believe it or not, the term trunk port was inspired by the telephone system trunks that carry multiple telephone conversations at a time. So it follows that trunk ports can similarly carry multiple VLANs at a time.
A trunk link is a 100 or 1000Mbps point-to-point link between two switches, between a switch and router, or even between a switch and server, and it carries the traffic of multiple VLANs from 1 to 4094 at a time (though it’s really only up to 1005 unless you’re going with extended VLANs).
Trunking can be a real advantage because, with it, you get to make a single port part of a whole bunch of different VLANs at the same time. This is a great feature because you can actually set ports up to have a server in two separate domains simultaneously so your users won’t have to cross a layer 3 device (router) to log in and access it. Another benefit to trunking comes into play when you’re connecting switches. Trunk links can carry various amounts of VLAN information across the link, but by default, if the links between your switches aren’t trunked, only information from the configured VLAN will be switched across that link.
It’s good to know that all VLANs send information on a trunked link unless you clear each VLAN by hand, and no worries. I’ll show you how to clear individual VLANs from a trunk in a bit.
Check out the picture given below. It shows how the different links are used in a switched network. All hosts connected to the switches can communicate to all ports in their VLAN because of the trunk link between them. Remember, if we used an access link between the switches, this would allow only one VLAN to communicate between switches. As you can see, these hosts are using access links to connect to the switch, so they’re communicating in one VLAN only. That means that without a router, no-host can communicate outside its own VLAN, but they send data over trunked links to hosts on another switch configured in their same VLAN.
Okay, it’s finally time to tell you about frame tagging and the VLAN identification methods used in it.
As you now know, you can set up your VLANs to span more than one connected switch. You can see that going on in the previous picture, which depicts hosts from various VLANs spread across a bunch of switches. This flexible, power-packed capability is probably the main advantage of implementing VLANs.
But it can get kind of complicated even for a switch so there needs to be a way for each one to keep track of all the users and frames as they travel the switch fabric and VLANs. When we say, “switch fabric” I’m just referring to a group of switches that share the same VLAN information. And this just happens to be where frame tagging enters the scene. This frame identification method uniquely assigns a user-defined ID to each frame. Sometimes people refer to it as a “VLAN ID” or even “color”.
Here’s how it works: Each switch that the frame reaches must first identify the VLAN ID from the frame tag. It then finds out what to do with the frame by looking at the information in what’s known as the filter table. If the frame reaches a switch that has another trunked link, the frame will be forwarded out of the trunk-link port.
Once the frame reaches an exit that’s determined by the forward filter table to be an access link matching the frame’s VLAN ID, the switch will remove the VLAN identifier. This is so the destination device can receive the frames without being required to understand their VLAN identification.
Another thing about trunk ports is that they will support tagged and untagged traffic simultaneously (if you are using 802.1Q trunking, which we will see in the future article). The trunk port is assigned a default port VLAN ID (PVID) for a VLAN that all untagged traffic will travel on. This VLAN is also called the native VLAN and is always VLAN 1 by default (but can be changed to any VLAN number).
Similarly, any untagged or tagged traffic with a NULL (unassigned) VLAN ID is assumed to belong to the VLAN with the port default PVID (again, VLAN 1 by default). A packet with a VLAN ID equal to the outgoing port default PVID is sent untagged and can only communicate to hosts or devices in VLAN 1. All other VLAN traffic has to be sent with a VLAN tag to communicate in a particular VLAN that corresponds with that tag.
VLAN Identification Methods
VLAN identification is what switches use to keep track of all those frames as they’re traversing a switch fabric. It’s how switches identify which frames belong to which VLANs, and there’s more than one trunking method.
Inter-switch Link (ISL)
Inter-switch Link (ISL) is a way of explicitly tagging VLAN information onto an Ethernet frame. This tagging information allows VLANs to be multiplexed over a trunk link through an external encapsulation method (ISL), which allows the switch to identify the VLAN membership of a frame over the trunked link.
By running ISL, you can interconnect multiple switches and still maintain VLAN information as traffic travels between switches on trunk links. ISL functions at layer 2 by encapsulating a data frame with a new header and cyclic redundancy check (CRC).
Of note is that this is proprietary to Cisco switches, and it’s used for Fast Ethernet and Gigabit Ethernet links only. ISL routing is pretty versatile and can be used on a switch port, router interfaces, and server interface cards to trunk a server.
Created by the IEEE as a standard method of frame tagging, IEEE 802.1Q actually insert a field into the frame to identify the VLAN. If you’re trunking between a Cisco switched link and a different brand of a switch, you’ve got to use 802.1Q for the trunk to work.
It works like this: you first designate each port that is going to be a trunk with 802.1Q encapsulation. The ports must be assigned a specific VLAN ID, which makes them the native VLAN, in order for them to communicate. The ports that populate the same trunk create a group with this native VLAN and each port gets tagged with an identification number reflecting that again the default is VLAN 1. The native VLAN allows the trunk to carry information that was received without any VLAN identification or frame tag.
The 2960s support only the IEEE 802.1Q trunking protocol, but the 3560s will support both the ISL and IEEE methods.
VLAN Trunking Protocol (VTP)
Cisco created this one too. The basic goals of the VLAN Trunking Protocol (VTP) are to manage all configured VLANs across a switched internetwork and to maintain consistency throughout that network VTP allows you to add, delete, and rename VLANs information that is openly propagated to all other switches in the VTP domain.
Here’s a list of some of the cool features VTP has to offer;
- Consistent VLAN configuration across all switches in the network.
- VLAN trunking over mixed networks, such as Ethernet to ATM LANE or even FDDI.
- Accurate tracking and monitoring of VLANs
- Dynamic reporting of added VLANs to all switches is the VTP domain
- Plug and Play VLAN adding.
Very nice, but before you can get VTP to manage your VLANs across the network, you have to create a VTP server. All servers that need to share VLAN information must use the same domain name, and a switch can be in only one domain at a time. So basically, this means that a switch can only share VTP domain information with other switches if they’re configured into the same VTP domain. You can use a VTP domain if you have more than one switch connected in a network, but if you’ve got all your switches in only one VLAN, you just don’t need to use VTP. Do keep in mind that VTP information is sent between switches only via a trunk port. Switches advertise VTP management domain information as well as a configuration revision number and all known VLANs with any specific parameters. But there’s also something called VTP transparent mode. In it, you can configure switches to forward VTP information through trunk port but not to accept information updates or update their VTP databases.
If you’ve got sneaky users adding switches to your VTP domain behind your back, you can include passwords, but don’t forget every switch must be set up with the same password. And as you can imagine, this little snag can be a real hassle administratively.
Switches detect any added VLANs within a VTP advertisement, then prepare to send information on their trunk ports with the newly defined VLAN in tow. Updates are sent out as revision numbers that consist of the notification plus 1. Any time a switch sees a higher revision number, it knows the information it’s getting is more current, so it will overwrite the existing database with the latest information.
You should know these three requirements for VTP to communicate VLAN information between switches:
- The VTP management domain name of both switches must be set the same.
- One of the switches has to be configured as a VTP server.
- No router is necessary.
Now that you’ve got that down, we’re going to delve deeper into the world of VTP with VTP modes and VTP operations.
VTP Modes of Operation
the following picture shows you all three different modes of operation within a VTP domain:
This is the default mode for all catalyst switches. You need at least one server in your VTP domain to propagate VLAN information throughout that domain. Also important: The switch must be in server mode to be able to create, add, and delete VLANs in a VTP domain. VTP information has to be changed in server mode, and any change made to a switch in server mode will be advertised to the entire VTP domain. In VTP server mode, VLAN configuration is saved in NVRAM.
In client mode, switches receive information from VTP servers, but they also send and receive updates, so in this way, they behave like VTP servers. The difference is that they can’t create, change, or delete VLANs. Plus, none of the ports on a client switch can be added to a new VLAN before the VTP server notifies the client switch of the new VLAN. Also good to know is that VLAN information sent from a VTP server isn’t stored in NVRAM, which is important because it means that if the switch is reset or reloaded, the VLAN information will be deleted. Here’s a hint: If you want a switch to become a server, first make it a client so it receives all the correct VLAN information, then change it to a server so much easier!
So basically, a switch in VTP client mode will forward VTP summary advertisements and process them. This switch will learn about but won’t save the VTP configuration in the running configuration, and it won’t save it in NVRAM. Switches that are in VTP client mode will only learn about and pass along VTP information that’s it!
Transparent switches in transparent mode don’t participate in the VTP domain or share its VLAN database, but they’ll still forward VTP advertisements through any configured trunk links. They can create, modify, and delete VLANs because they keep their own database one they keep secret from the other switches. Despite being kept in NVRAM, the VLAN database in transparent mode is actually only locally significant. The whole purpose of transparent mode is to allow remote switches to receive the VLAN database from a VTP server configured switch through a switch that is not participating in the same VLAN assignment.
VTP only learns about normal-range VLANs, with VLAN IDs 1 to 1005; VLANs with IDs greater than 1005 are called extended-range VLANs and they’re not stored in the VLAN database. The switch must be in VTP transparent mode when you create VLAN IDs from 1006 to 4094, so it would be pretty rare that you’d ever use these VLANs. One other thing: VLAN IDs 1 and 1002 to 1005 are automatically created on all switches and can’t be removed.
VTP gives you a way to preserve bandwidth by configuring it to reduce the number of broadcasts, multicasts, and unicast packets. This is called Pruning. VTP pruning enabled switches to send broadcasts only to trunk links that actually must have the information.
Here’s what this means: If switch A doesn’t have any ports configured for VLAN 5 and broadcast is sent throughout VLAN 5, that broadcast wouldn’t traverse the trunk link to Switch A. by default, VTP pruning is disabled on all switches. Seems to me this would be a good default parameter.
When you enable pruning on a VTP server, you enable it for the entire domain. By default, VLANs 2 through 1001 are pruning eligible, but VLAN 1 can never prune because it’s an administrative VLAN. VTP pruning is supported by both VTP version 1 and version 2.
By using the show interface trunk command, we can see that all VLANs are allowed across a trunked link by default:
S1#sh int trunk Port mode Encapsulation status native vlan Fa0/1 auto 802.1q trunking 1 Fa0/2 auto 802.1q trunking 1 Port vlan allowed on trunk Fa0/1 1-4094 Fa0/2 1-4094 Port vlans allowed and active in management domain Fa0/1 1 Fa0/2 1 Port vlans in spanning tree forwarding state and not pruned Fa0/1 1 Fa0/2 none S1#
Looking at the preceding output, you can see that VTP pruning is disabled by default. We are going to go ahead and enable pruning. It only takes one command and it is enabled on your entire switched network for the listed VLANs. Let’s see what happens.
S1#config t S1(config)#int f0/1 S1(config-if)#switchport trunk ? Allowed set allowed VLAN characteristics when interface is in trunking mode Native set trunking native characteristics when interface is in trunking mode Pruning set pruning VLAN characteristics when interface is in trunking mode S1(config-if)#switchport trunk pruning ? Vlan set VLANs enabled for pruning when interface is in trunking mode S1(config-if)#switchport trunk pruning vlan 3-4
The valid VLANs that can be pruned are 2 to 1001. Extended-range VLANs (VLAN IDs 1006 to 4094) can’t be pruned, and these pruning ineligible VLANs can receive a flood of traffic.
Routing between VLANs
Hosts in a VLAN live in their own broadcast domain and can communicate freely. VLANs create network partitioning and traffic separation at layer 2 of the OSI, and as we said when we told you why we still need routers, if you want hosts or any other IP-addressable device to communicate between VLANs, you just have to have a layer 3 device period.
For this, you can use a router that has an interface for each VLAN or a router that supports ISL or 802.1Q routing. The least expensive router that supports ISL or 802.1Q routing is the 2600 series router. (You’d have to buy that from a used-equipment reseller because they are the end of life or EOL). 1600, 1700, and 2500 series don’t support ISL or 802.1Q routing. We’d recommend at least 2800 as a bare minimum, and that only supports 802.1Q Cisco is really moving away from ISL, so you probably should only be using 802.1Q any way. (some IOSs on 2800 may support both ISL and 802.1Q)
As shown in the picture below, if you had only a few VLANs (two or three), you could get by with a router equipped with two or three Fast Ethernet connections. And 10baseT is okay for home use, and we mean only for home use, but for anything else we’d honestly recommend Fast Ethernet or Gigabit interfaces for something serious under the hood.
The router connecting three VLANs together for inter-VLAN communication one interface for each VLAN.
What we see in the picture above is that each router interface is plugged into an access link. This means that each of the router’s interface IP addresses would then become the default gateway address for each host in each VLAN.
If you have more VLANs available than router interfaces, you can configure trunking on one Fast Ethernet interface or buy a layer 3 switch, like the Cisco 3560 or a higher-end switch like a 6500.
Instead of using a router interface for each VLAN, you can use one Fast Ethernet interface and run ISL or 802.1Q trunking. The below picture shows how a Fast Ethernet interface on a router will look when configured with ISL or 802.1Q trunking. This allows all VLANs to communicate through one interface. Cisco calls this a “router on a stick”.
The router connecting all VLANs together allowing for inter-VLAN communication using only one router interface(router on a stick).
We need to point out that this creates a bottleneck, as well as a single point of failure, so your host/VLAN count is limited. How many? That depends on your traffic level. To really make things really right, you’d be better off using a higher-end switch and routing on the backplane, but if you just happen to have a router sitting around, configuring this method is free, right?