Sunteți pe pagina 1din 28


1 2 3 4 5 6 7 8




Virtual Local Area Networks or VLANs are one of the latest and coolest network technologies developed in the past few years, though have only recently started to gain recognition. The non-stop growth of Local Area Networks (LANs) and the need to minimize the cost for this expensive equipment, without sacrificing network performance and security, created the necessary soil for the VLAN seed to surface and grow into most modern networks. The truth is that VLANs are not as simple as most people peceive it to be. Instead they cover extensive material to be a whole study in itself as they contain a mixture of protocols, rules, and guidelines that a network administrator should be well aware of. Unfortunately, most documentation provided by vendors and other sites is inadequate or very shallow. They lightly touch upon the VLAN topic and fail to give the reader a good understanding on how VLANs really work and the wonderful things one can do when implementing them. Like most topics covered on our site, VLANs have been broken down into a number of pages, each one focusing on specific areas to help the reader build up their knowledge as preparation for designing and building their own VLAN network. Since VLANs is a topic that requires strong background knowledge of certain areas, as they contain a lot of information at the techincal and protocol level, we believe that the reader should be familiar and comfortable with the following concepts:

Switches and hubs Broadcast and collision domains Internet Protocol (IP) IP routing

As we cover all the theory behind VLANs and how they are implemented within various network topologies, we will finally demonstrate the configuration of a Cisco powered network utilising VLANs! Protocols such as Spanning Tree Protocol (STP) are essential when implementing VLANs within a mid to large sized network, so we will briefly touch upon the topic, without thoroughly analysing it in great detail because STP will be covered as a separate topic.

VLAN Concept
The Traditional Switched Network

Almost every network today has a switch interconnecting all network nodes, providing a fast and reliable way for the nodes to communicate. Switches today are what hubs were a while back - the most common and necessary equipment in our network, and there is certainly no doubt about that. While switches might be adequate for most type of networks, they prove inadequate for mid to large sized networks where things are not as simple as plugging a switch into the power outlet and hanging a few Pc's from it! For those of you who have already read our "switches and bridges" section, you will be well aware that switches are layer 2 devices which create a flat network:

The above network diagram illustrates a switch with 3 workstations connected. These workstations are able to communicate with each other and are part of the same broadcast domain, meaning that if one workstation were to send a broadcast, the rest will receive it.


Welcome to the wonderful world of VLANs! All the above problems, and a lot more, can be forgotten with the creation of VLANs...well, to some extent at least. As most of you are already aware, in order to create (and work with) VLANs, you need a layer 2 switch that supports them. A lot of people new to the networking field bring the misconception that it's a matter of simply installing additional software on the clients or switch, in order to "enable" VLANs throughout the network - this is totally incorrect! Because VLANs involve millions of mathematical calculations, they require special hardware which is built into the switch and your switch must therefore

support VLANs at the time of purchase, otherwise you will not be able to create VLANs on it! Each VLAN created on a switch is a separate network. This means that a separate broadcast domain is created for each VLAN that exists. Network broadcasts, by default, are filtered from all ports on a switch that are not members of the same VLAN and this is why VLANs are very common in today's large network as they help isolate network segments between each other. To help create the visual picture on how VLANs differentiate from switches, consider the following diagram:


What we have here is a small network with 6 workstations attached to a VLAN capable switch. The switch has been programmed with 2 VLANs, VLAN1 and VLAN2 respectfully, and 3 workstations have been assigned to each VLAN. VLANs = Separate Broadcast Domains With the creation of our VLANs, we have also created 2 broadcast domains. This mean that if any workstation in either VLAN sends a broadcast, it will propagate out the ports which belong to the same VLAN as the workstation that generated the broadcast:

This is clearly illustrated in the diagram above where Workstation 1, belonging to VLAN1, sends a network broadcast (FF:FF:FF:FF:FF:FF). The switch receives this broadcast and forwards it to Workstation 2 and 3, just as it would happen if these three workstations were connected to a normal switch, while the workstations belonging to VLAN2 are totally unaware of the broadcast sent in VLAN1 as they do not receive any packets flowing in that network.

To help clear any questions or doubts on how the above setup works, the diagram below shows the logical equivalent setup of our example network:

By this stage, you should begin seeing the clear advantages offered by the use of VLANs within your network. Security, cost and network traffic are reduced as more hosts are added to the network and the number of VLANs are increased.

Designing VLANS
VLANs are usually created by the network administrator, assigning each port of every switch to a VLAN. Depending on the network infrastructure and security policies, the assignment of VLANs can be implemented using two different methods: Static or Dynamic memberships - these two methods are also known as VLAN memberships. Each of these methods have their advantages and disadvantages and we will be analysing them in great depth to help you decide which would best suite your network. Depending on the method used to assign the VLAN membership, the switch may require further configuration, but in most cases it's a pretty straight forward process. This page deals with Static VLANs while Dynamic VLANs are covered next. Static VLANs Static VLAN membership is perhaps the most widely used method because of the relatively small administration overhead and security it provides. With Static VLANs, the administrator will assign each port of the switch to one VLAN. Once this is complete, they can simply connect each device or workstation to the appropriate port. The picture below depicts an illustration of the above, where 4 ports have been configured for 4 different VLANs:

The picture shows a Cisco switch (well, half of it :>) where ports 1, 2, 7 and 10 have been configured and assigned to VLANs 1, 5, 2 and 3 respectively. At this point, we should remind you that these 4 VLANs are not able to communicate between each other without the use of a router as they are treated as 4 separate physical networks, regardless of the network addressing scheme used on each of them. However, we won't provide further detail on VLAN routing since it's covered later on.

Static VLANs are certainly more secure than traditional switches while also considerably easy to configure and monitor. As one would expect, all nodes belonging to a VLAN must also be part of the same logical network in order to communicate with one another. For example, on our switch above, if we assigned network to VLAN 1, then all nodes connecting to ports assigned to VLAN 1 must use the same network address for them to communicate between each other, just as if this was an ordinary switch. In addition, Static VLANs have another strong point - you are able to control where your users move within a large network. By assigning specific ports on your switches throughout your network, you are able to control access and limit the network resources to which your users are able to use. A good example would be a large network with multiple departments where any network administrator would want to control where the users can physically connect their workstation or laptop and which servers they are able to access.The following diagram shows a VLAN powered network where the switches have been configured with Static VLAN support.

The network diagram might look slightly complicated at first, but if you pay close attention to each switch, you will notice that it's quite simple - six switches with 6 VLANs configured- one VLAN per department, as shown. While each VLAN has one logical network assigned to it, theIT department has, in addition, placed one workstation in the following departments for support purposes: Management, R&D, and HR department. The network administrator has assigned Port 1 (P1) on each department switch to VLAN 5 for the workstation belonging to the IT department, while the rest of the ports are assigned to the appropriate VLAN as shown in the diagram.

This setup allows the administrator to place any employee in the IT department, anywhere on the network, without worrying if the user will be able to connect and access the IT department's resources. In addition, if a user in any of the above departments e.g the Management department, decided to get smart by attempting to gain access to the IT department's network and resources by plugging his workstation to Port 1 of his department's switch. He surely wouldn't get far because his workstation would be configured for the network (VLAN 1), while Port 1 requires him to use a network address (VLAN 5). Logically, he would have to change his IP address to match the network he is trying to gain access to, and in this case this would be network
Dynamic VLANs

Dynamic VLANs, as opposed to Static VLANs, do not require the administrator to individually configure each port, but instead, a central server called the VMPS (VLAN Member Policy Server). The VMPS is used to handle the on-the-spot port configuration of every switch participating on the VLAN network. The VMPS server contains a database of all workstation MAC addresses, along with the associated VLAN the MAC address belongs to. This way, we essentially have a VLANto-MAC address mapping:

The above diagram works as an aim to help us understand the mapping relationship that exists in the VMPS server. As shown, each MAC address, which translates to a host on the network, is mapped to a VLAN, allowing this host to move inside the network, connecting to any switch that is part of the VMPS network and maintain its VLAN configuration. You can now start to imagine the initial workload involved when configuring a VMPS server for a network of over 300 workstations:)

As one would expect, the above model works very well and also requires the switches to be in constant contact with the VMPS server, requesting configuration information everytime a host connects to a switch participating in the VLAN network. Of course, there is a lot more information we can use to configure the VMPS database, but we won't be covering that just as yet. Like all network services offered, Cisco has cleverly designed this model to be as flexible as our network might require. For example, you are able to connect more than one host on one dynamically configured port, as long as all hosts are part of the same VLAN:
Dynamic VLANs & FallBack VLANs

Another very interesting and smart feature Dynamic VLANs support is the fallback VLAN. This neat feature allows you to automatically configure a port to a VLAN specially created for workstations whose MAC address is not in the VMPS server. Consider company visitors or clients who require specific or restricted access to your network, they can freely connect to the network and have Internet access, alongside with limited rights on public directories. In the event the fallback VLAN has not been configured and the MAC address connected to the switch's port is unknown, the VMPS server will send an 'accessdenied' response, blocking access to the network, but the port will remain active. If the VMPS server is running in 'secure-mode', it will proceed and shutdown the port as an additional security measure.

The above diagram represents a portion of a large scale network using a Cisco 6500 Catalyst as the core switch. The switch has been configured to support Dynamic

VLANs, therefore a VMPS server has been configured inside the switch, alongside with a DHCP server for each created VLAN. The administrator has already assigned the 3 workstations MAC addresses to the VLANs shown and also created the fallback VLAN for any MAC address that does not exist in the database. Now consider this interesting scenario: One morning a visitor arrives in the office and requires Internet connection so he can demonstate a new product to the management. As an administrator, you've already configured a fallback VLAN with a DHCP server activated for the VLAN, pushing the necessary settings to the clients so they may obtain Internet access services. The visitor finds a free RJ-45 socket on the wall, which connects to a Catalyst 3550 switch nearby, and plugs in his laptop. Before the user is allowed to access the network, the Cisco 3550 switch checks the laptop's MAC address and reads 4B:63:3F:A2:3E:F9. At this point, the port is blocked, not allowing the laptop computer to send or receive data. The Cisco 3550 switch sends the MAC address to the 6500 Catalyst switch which is acting as the VMPS server and it checks for an entry that matches the specified MAC address but is unable to find one. Naturally, it determines that this a visitor, so it creates an entry for that MAC address to the fallback VLAN and sends the information back to the Cisco 3550 switch. The switch will then enable access to the port our visitor is connected to by configuring the port to the fallback VLAN. If the visitor's computer is configured to obtain an IP Address automatically, it will do so, once the operating system has booted. When this happens, the visitor's DHCP request will arrive to the 6500 Catalyst switch and its DHCP server will send the requested information, enabling the client (our visitor) to configure itself with all the parameters required to access the VLAN. This will also mean our visitor is now able to access the Internet! Finishing, if the computer is not configured for DHCP, the client must be advised with the correct network settings or asked to enable automatic IP configuration in their network properties.


VLAN Links - Interfaces

When inside the world of VLANs there are two types of interfaces, or if you like, links. These links allow us to connect multiple switches together or just simple network devices e.g PC, that will access the VLAN network. Depending on their configuration, they are called Access Links, or Trunk Links. Access Links Access Links are the most common type of links on any VLAN switch. All network hosts connect to the switch's Access Links in order to gain access to the local network. These links are your ordinary ports found on every switch, but configured in a special way, so you are able to plug a computer into them and access your network. Here's a picture of a Cisco Catalyst 3550 series switch, with it's Access Links (ports) marked in the Green circle:

We must note that the 'Access Link' term describes a configured port - this means that the ports above can be configured as the second type of VLAN links - Trunk Links. What we are showing here is what's usually configured as an Access Link port in 95% of all switches. Depending on your needs, you might require to configure the first port (top left corner) as a Trunk Link, in which case, it is obviously not called a Access Link port anymore, but a Trunk Link! When configuring ports on a switch to act as Access Links, we usually configure only one VLAN per port, that is, the VLAN our device will be allowed to access. If you recall the diagram below which was also present during the introduction of the VLAN concept, you'll see that each PC is assigned to a specific port:

In this case, each of the 6 ports used have been configured for a specific VLAN. Ports 1, 2and 3 have been assigned to VLAN 1 while ports 4, 5 and 6 to VLAN 2. In the above diagram, this translates to allowing only VLAN 1 traffic in and out of ports 1, 2and 3, while ports 4, 5 and 6 will carry VLAN 2 traffic. As you would remember, these two VLANs do not exchange any traffic between each other, unless we are using a layer 3 switch (or router) and we have explicitly configured the switch to route traffic between the two VLANs. It is equally important to note at this point that any device connected to an Access Link (port) is totally unaware of the VLAN assigned to the port. The device simply assumes it is part of a single broadcast domain, just as it happens with any normal switch. During data transfers, any VLAN information or data from other VLANs is removed so the recipient has no information about them. The following diagram illustrates this to help you get the picture:

As shown, all packets arriving, entering or exiting the port are standard Ethernet II type packets which are understood by the network device connected to the port. There is nothing special about these packets, other than the fact that they belong only to the VLAN the port is configured for. If, for example, we configured the port shown above for VLAN 1, then any packets entering/exiting this port would be for that VLAN only. In addition, if we decided to use a logical network such as with a default subnet mask of (/24), then all network devices connecting to ports assigned to VLAN 1 must be configured with the appropriate network address so they may communicate with all other hosts in the same VLAN. Trunk Links What we've seen so far is a switch port configured to carry only one VLAN, that is, an Access Link port. There is, however, one more type of port configuration which we mentioned in the introductory section on this page - the Trunk Link. A Trunk Link, or 'Trunk' is a port configured to carry packets for any VLAN. These type of ports are usually found in connections between switches. These links require the ability to carry packets from all available VLANs because VLANs span over multiple switches. The diagram below shows multiple switches connected throughout a network and the Trunk Links are marked in purple colour to help you identify them:

As you can see in our diagram, our switches connect to the network backbone via the Trunk Links. This allows all VLANs created in our network to propagate throughout the whole network. Now in the unlikely event of Trunk Link failure on one of our switches, the devices connected to that switch's ports would be isolated from the rest of the network, allowing only ports on that switch, belonging to the same VLAN, to communicate with each other. So now that we have an idea of what Trunk Links are and their purpose, let's take a look at an actual switch to identify a possible Trunk Link:

As we noted with the explanation of Access Link ports, the term 'Trunk Link' describes a configured port. In this case, the Gigabit ports are usually configured as Trunk Links, connecting the switch to the network backbone at the speed of 1 Gigabit, while the Access Link ports connect at 100Mbits. In addition, we should note that for a port or link to operate as a Trunk Link, it is imperative that it runs at speeds of 100Mbit or greater. A port running at speeds of 10Mbit's cannot operate as a Trunk Link and this is logical because a Trunk Link is always used to connect to the network backbone, which must operate at speeds greater than most Access Links!


VLAN Tagging, also known as Frame Tagging, is a method developed by Cisco to help identify packets travelling through trunk links. When an Ethernet frame traverses a trunk link, a special VLAN tag is added to the frame and sent across the trunk link. As it arrives at the end of the trunk link the tag is removed and the frame is sent to the correct access link port according to the switch's table, so that the receiving end is unaware of any VLAN information. The diagram below illustrates the process described above:

Here we see two 3500 series Catalyst switches and one Cisco 3745 router connected via the Trunk Links. The Trunk Links allow frames from all VLANs to travel throughout the network backbone and reach their destination regardless of the VLAN the frame belongs to. On the other side, the workstations are connected directly to Access Links (ports configured for one VLAN membership only), gaining access to the resources required by VLAN's members. Again, when we call a port 'Access Link' or 'Trunk Link', we are describing it based on the way it has been configured. This is because a port can be configured as an Access Link or Trunk Link (in the case where it's 100Mbits or faster). This is stressed because a lot of people think that it's the other way around, meaning, a switch's uplink is always a Trunk Link and any normal port where you would usually connect a workstation, is an Access Link port! VLAN Tagging Protocol

We're now familiar with the term 'Trunk Link' and its purpose, that is, to allow frames from multiple VLANs to run across the network backbone, finding their way to their destination. What you might not have known though is that there is more than one method to 'tag' these frames as they run through the Trunk Links or ... the VLAN Highway as we like to call it. InterSwitch Link (ISL) ISL is a Cisco propriety protocol used for FastEthernet and Gigabit Ethernet links only. The protocol can be used in various equipments such as switch ports, router interfaces, server interface cards to create a trunk to a server and much more. You'll find more information on VLAN implementations on our last page of the VLAN topic. Being a propriety protocol, ISL is available and supported naturally on Cisco products only:) You may also be interested in knowing that ISL is what we call, an 'external tagging process'.This means that the protocol does not alter the Ethernet frame as shown above in our previous diagram - placing the VLAN Tag inside the Ethernet frame, but encapsulating the Ethernet frame with a new 26 byte ISL header and adding an additional 4 byte frame check sequence (FCS) field at the end of frame, as illustrated below:

Despite this extra overhead, ISL is capable of supporting up to 1000 VLANs and does not introduce any delays in data transfers between Trunk Links. In the above diagram we can see an ISL frame encapsulating an Ethernet II frame. This is the actual frame that runs through a trunk link between two Cisco devices when configured to use ISL as their trunk tagging protocol. The encapsulation method mentioned above also happens to be the reason why only ISL-aware devices are able to read it, and because of the addition of an ISL header and FCS field, the frame can end up being 1548 bytes long! For those who can't remember, Ethernet's maximum frame size is 1518 bytes, making an ISL frame of 1548 bytes, what we call a 'giant' or 'jumbo' frame!

Lastly, ISL uses Per VLAN Spanning Tree (PVST) which runs one instance of the Spanning Tree Protocol (STP) per VLAN. This method allows us to optimise the root switch placement for each available VLAN while supporting neat features such as VLAN load balancing between multiple trunks. Since the ISL's header fields are covered on a separate page, we won't provide further details here. IEEE 802.1q The 802.1q standard was created by the IEEE group to address the problem breaking large networks into smaller and manageable ones through the use of VLANs. The 802.1q standard is of course an alternative to Cisco's ISL, and one that all vendors implement on their network equipment to ensure compatibility and seamless integration with the existing network infrastructure. As with all 'open standards' the IEEE 802.1q tagging method is by far the most popular and commonly used even in Cisco oriented network installations mainly for compatability with other equipment and future upgrades that might tend towards different vendors. In addition to the compatability issue, there are several more reasons for which most engineers prefer this method of tagging. These include:

Support of up to 4096 VLANs Insertion of a 4-byte VLAN tag with no encapsulation Smaller final frame sizes when compared with ISL

Amazingly enough, the 802.1q tagging method supports a whopping 4096 VLANs (as opposed to 1000 VLANs ISL supports), a large amount indeed which is merely impossible to deplet in your local area network. The 4-byte tag we mentioned is inserted within the existing Ethernet frame, right after theSource MAC Address as illustrated in the diagram below:

Because of the extra 4-byte tag, the minimum Ethernet II frame size increases from 64 bytes to 68 bytes, while the maximum Ethernet II frame size now becomes 1522 bytes. If you require more information on the tag's fields, visit our protocol page where further details are given. As you may have already concluded yourself, the maximum Ethernet frame is considerably smaller in size (by 26 bytes) when using the IEEE 802.1q tagging method rather than ISL. This difference in size might also be interpreted by many that the IEEE 802.1q tagging method is much faster than ISL, but this is not true. In fact, Cisco recommends you use ISL tagging when in a Cisco native environment, but as outlined earlier, most network engineers and administrators believe that the IEEE802.1q approach is much safer, ensuring maximum compatability. And because not everything in this world is perfect, no matter how good the 802.1q tagging protocol might seem, it does come with its restrictions:

In a Cisco powered network, the switch maintains one instance of the Spanning Tree Protocol (STP) per VLAN. This means that if you have 10 VLANs in your network, there will also be 10 instances of STP running amongst the switches. In the case of non-Cisco switches, then only 1 instance of STP is maintained for all VLANs, which is certainly not something a network administrator would want. It is imperative that the VLAN for an IEEE 802.1q trunk is the same for both ends of the trunk link, otherwise network loops are likely to occur. Cisco always advises that disabling a STP instance on one 802.1q VLAN trunk without disabling it on the rest of the available VLANs, is not a good idea because network loops might be created. It's best to either disable or enable STP on all VLANs.


The Need For Routing Each network has it's own needs, though whether it's a large or small network, internal routing, in most cases, is essential - if not critical. The ability to segment your network by creating VLANs, thus reducing network broadcasts and increasing your security, is a tactic used by most engineers. Popular setups include a separate broadcast domain for critical services such as File Servers, Print servers, Domain Controllers e.t.c, serving your users non-stop. The issue here is how can users from one VLAN (broadcast domain), use services offered by another VLAN? Thankfully there's an answer to every problem and in this case, its VLAN routing:

The above diagram is a very simple but effective example to help you get the idea. Two VLANs consisting of two servers and workstations of which one workstation has been placed along with the servers in VLAN 1, while the second workstation is placed in VLAN 2. In this scenario, both workstations require access to the File and Print servers, making it a very simple task for the workstation residing in VLAN 1, but obviously not for our workstation in VLAN 2. As you might have already guessed, we need to somehow route packets between the two VLANs and the good news is that there is more than one way to achieve this and that's what we'll be covering on this page. VLAN Routing Solutions

While the two 2924 Catalyst switches are connected via a trunk link, they are unable to route packets from one VLAN to another. If we wanted the switch to support routing, we would require it to be a layer 3 switch with routing capabilities, a service offered by the popular Catalyst 3550 series and above. Since there are quite a few ways to enable the communcation between VLANs (InterVLAN Routing being the most popular) there is a good chance that we are able to view all possible solutions. This follows our standard method of presenting all possible solutions, giving you an in-depth view on how VLAN routing can be setup, even if you do not have a layer 3 switch. Note: The term 'InterVLAN Routing' refers to a specific routing method which we will cover as a last scenario, however it is advised that you read through all given solutions to ensure you have a solid understanding on the VLAN routing topic. VLAN Routing Solution No.1: Using A Router With 2 Ethernet Interfaces A few years ago, this was one of the preferred and fastest methods to route packets between VLANs. The setup is quite simple and involves a Cisco router e.g 2500 series with two Ethernet interfaces as shown in the diagram, connecting to both VLANs with an appropriate IP Address assigned to each interface. IP Routing is of course enabled on the router and we also have the option of applying access lists in the case where we need to restrict network access between our VLANs.

In addition, each host (servers and workstations) must either use the router's interface connected to their network as a 'default gateway' or a route entry must be created to ensure they use the router as a gateway to the other VLAN/Network. This scenario is however expensive to implement because we require a dedicated router to router packets between our VLANs, and is also limited from an expandability prospective.

In the case where there are more than two VLANs, additional Ethernet interfaces will be required, so basically, the idea here is that you need one Ethernet interface on your router that will connect to each VLAN. To finish this scenario, as the network gets bigger and more VLANs are created, it will very quickly get messy and expensive, so this solution will prove inadequate to cover our future growth. VLAN Routing Solution No.2: Using A Router With One Ethernet (Trunk) Interface This solution is certainly fancier but requires, as you would have already guessed, a router that supports trunk links. With this kind of setup, the trunk link is created, using of course the same type of encapsulation the switches use (ISL or 802.1q), and enabling IP routing on the router side.

The downside here is that not many engineers will sacrifice a router just for routing between VLANs when there are many cheaper alternatives, as you will soon find out. Nevertheless, despite the high cost and dedicated hardware, it's still a valid and workable solution and depending on your needs and available equipment, it might be just what you're looking for! Closing this scenario, the router will need to be configured with two virtual interfaces, one for each VLAN, with the appropriate IP Address assigned to each one so routing can be performed. VLAN Routing Solution No.3: Using A Server With Two Network Cards We would call this option a "Classic Solution". What we basically do, is configure one of the servers to perform the routing between the two VLANs, reducing the overal cost as no dedicated equipment is required.

In order for the server to perform the routing, it requires two network cards - one for each VLAN and the appropriate IP Addresses assigned, therefore we have configured one with IP Addresses and the other with Once this phase is complete, all we need to do is enable IP routing on the server and we're done. Lastly, each workstation must use the server as either a gateway, or a route entry should be created so they know how to get to the other network. As you see, there's nothing special about this configuration, it's simple, cheap and it gets the job done. Access Lists & InterVLAN Routing Another common addition to the InterVLAN routing service is the application of Access Lists (packet filtering) on the routing switch,to restrict access to services or hosts as required. In modern implementations, central file servers and services are usually placed in their own isolated VLAN, securing them from possible network attacks while controlling access to them. When you take into consideration that most trojans and viruses perform an initial scan of the network before attacking, an administrator can smartly disable ICMP echoes and other protocols used to detect a live host, avoiding possible detection by an attacker host located on a different VLAN.


VTP, a Cisco proprietary protocol, was designed by Cisco with the network engineer and administrator in mind, reducing the administration overhead and the possibility of error as described above in any switched network environment. When a new VLAN is created and configured on a switch without the VTP protocol enabled, this must be manually replicated to all switches on the network so they are all aware of the newly created VLAN. This means that the administrator must configure each switch separately, a task that requires a lot of time and adds a considerable amount of overhead depending on the size of the network. The configuration of a VLAN includes the VLAN number, name and a few more parameters which will be analysed further on. This information is then stored on each switch's NVRAM and any VLAN changes made to any switch must again be replicated manually on all switches. If the idea of manually updating all switches within your network doesn't scare you because your network is small, then imagine updating more than 15-20 switches a few times per week, so your network can respond to your organisation's needs....have we got you thinking now? :) With the VTP protocol configured and operating, you can forget about running around making sure you have updated all switches as you only need to make the changes on the nominated VTP server switch(es) on your network. This will also ensure these changes are magically propagated to all other switches regardless of where they are. Introducing The VTP Modes The VTP protocol is a fairly complex protocol, but easy to understand and implement once you get to know it. Currently, 3 different versions of the protocol exist, that is, version 1, 2 (adds support for Token Ring networks) and 3, with the first version being used in most networks. Despite the variety of versions, it also operates in 3 different modes: Server, client and transparent mode, giving us maximum flexibility on how changes in the network effect the rest of our switches. To help keep things simple and in order to avoid confusion, we will work with the first version of the VTP protocol - VTP v1, covering more than 90% of networks. Below you'll find the 3 modes the VTP protocol can operate on any switch throughout the network:
y y y

VTP Server mode VTP Client mode VTP Transparent mode

Each mode has been designed to cover specific network setups and needs, as we are about to see, but for now, we need to understand the purpose of each mode and the following network diagram will help us do exactly that.

A typical setup involves at least one switch configured as a VTP Server, and multiple switches configured as VTP Clients. The logic behind this setup is that all information regarding VLANs is stored only on the VTP Server switch from which all clients are updated. Any change in the VLAN database will trigger an update from the VTP Server towards all VTP clients so they can update their database. Lastly, be informed that these VTP updates will only traverse Trunk links. This means that you must ensure that all switches connect to the network backbone via Trunk links, otherwise no VTP updates will get to your switches. Let's now take a closer look at what each VTP mode does and where it can be used. VTP Server Mode By default all switches are configured as VTP Servers when first powered on. All VLAN information such as VLAN number and VLAN name is stored locally, on a separate NVRAM from where the 'startup-config' is stored. This happens only when the switch is in VTP Server mode.

For small networks with a limited number of switches and VLANs, storing all VLAN information on every switch is usually not a problem, but as the network expands and VLANs increase in number, it becomes a problem and a decision must be made to select a few powerful switches as the VTP Servers while configuring all other switches to VTP Client mode.

The diagram above shows a Cisco Catalyst 3550 selected to take the role of the network's VTP Server since it is the most powerful switch. All other Catalyst switches have been configured as VTP Clients, obtaining all VLAN information and updates from the 3550 VTP Server. The method and frequency by which these updates occur is covered in much detail on the pages that follow, so we won't get into any more detail at this point. However, for those who noticed, there is a new concept introduced in the above diagram that we haven't spoken about: The VTP Domain. The VTP Domain - VLAN Management Domain The VTP Domain, also known as the VLAN Management Domain, is a VTP parameter configured on every switch connected to the network and used to define the switches that will participate in any changes or updates made in the specified VTP domain. Naturally, the core switch (VTP Server) and all other switches participate in the same domain, e.g firewall, so when the VTP Server advertises new VLAN information for the VTP firewall domain, only clients (switches) configured with the same VTP

Domain parameter will accept and process these changes, the rest will simply ignore them. Lastly, some people tend to relate the VTP Domain with the Internet Domain name space, however, this is completely incorrect. Even though the acronym 'DNS' contains the word 'Domain', it is not related in any way with the VTP Domain. Here (in VTP land), the word 'Domain' is simply used to describe a logical area in which certain hosts (switches) belong to or participate in, and are affected by any changes made within it. We should also note that all Cisco switches default to VTP Server mode but will not transmit any VLAN information to the network until a VTP Domain is set on the switch. At this point we are only referencing the VTP Domain concept as this is also analysed in greater depth further on, so let's continue with the VTP modes! VTP Client Mode In Client Mode, a switch will accept and store in its RAM all VLAN information received from the VTP Server, however, this information is also saved in NVRAM, so if the switch is powered off, it won't loose its VLAN information. The VTP Client behaves like a VTP Server, but you are unable to create, modify or delete VLAN's on it. In most networks, the clients connect directly to the VTP Server as shown in our previous diagram. If, for any reason, two clients are cascaded together, then the information will propagate downwards via the available Trunk links, ensuring it reaches all switches:

The diagram shows a 3550 Catalyst switch configured as a VTP Server and 4 Catalyst 2950switches configured as VTP Clients and cascaded below our 3550. When the VTP Serversends a VTP update, this will travel through all trunk links (ISL, 802.1q, 802.10 and ATM LANE), as shown in the diagram. The advertised information will firstly reach the two Catalyst 2950 switches directly connected to the 3550 and will then travel to the cascaded switches below and through the trunk links. If the link between the cascaded 2950's was not a trunk link but an access link, then the 2nd set of switches would not receive and VTP updates:

As you can see, the VTP updates will happlily arrive at the first catalyst switches but stop there as there are no trunk links between them and the 2950's below them. It is very important you keep this in mind when designing a network or making changes to the existing one. VTP Transparent Mode The VTP Transparent mode is something between a VTP Server and a VTP Client but does not participate in the VTP Domain. In Transparent mode, you are able to create, modify and delete VLANs on the local switch,without affecting any other switches regardless of the mode they might be in. Most importantly, if the transparently configured switch receives an advertisement containing VLAN information, it will ignore it but at the same time forward it out its trunk ports to any other switches it might be connected to. Lastly, all switches configured to operate in Transparent mode save their configuration in their NVRAM (just like all the previous two modes) but not to advertise any VLAN information of its own, even though it will happily forward any VTP information received from the rest of the network.

This important functionality allows transparently configured switches to be placed anywhere within the network, without any implications to the rest of the network because as mentioned, they act as a repeater for any VLAN information received:

Our 3550 Catalyst here is configured as a VTP Server for the domain called "Firewall". In addition, we have two switches configured in VTP Client mode, obtaining their VLAN information from the 3550 VTP Server, but between these two VTP Clients, we have placed another switch configured to run in VTP Transparent mode. Our Transparent switch has been configured with the domain called "Lab", and as such, the switch will forward all incoming VTP updates belonging to the "Firewall" domain out its other trunk link, without processing the information. At the same time, it won't advertise its own VLAN information to its neighbouring switches. Closing, the VTP Transparent mode is not often used in live networks, but is well worth mentioning and learning about.