VLANs can be used to create a separate of broadcast domains on a single switch. In this video, you’ll learn about VLANs, 802.1Q trunking, and managing both voice and video across the same connection.
As a very broad description, a local area network, or a LAN, is a group of devices that are in the same broadcast domain. For example, when we connect devices to a switch, all of those devices are in the same broadcast domain. In this diagram, we have one switch on the left, that’s our red switch. And all of the devices connected to that switch are in the same broadcast domain.
On the right side is a blue network. This blue network is also on its own switch. And all of the devices connected to this switch are on their own broadcast domain. Because there are two separate switches and these switches are not connected to each other, no one on the red network can communicate directly with anyone on the blue network.
One of the challenges with this configuration, however, is that we have two devices on the red network and two devices on the blue network. But you can see that there are 24 interfaces on the front of each of these switches. This means we’re running two separate switches with two separate power sources. They’re both taking up space within our rack. And we have to manage each of them individually.
It would be much more efficient, much easier to manage, and much less expensive if we could have all of these devices reside on the same physical switch. We can do exactly that and continue to provide that separation between the red network and the blue network on the same switch by using a functionality known as Virtual Local Area networks or VLANs.
The red network is still on its own broadcast domain and the blue network is on its own broadcast domain. But all of these devices are connected to the same switch. We’ve gone into the switch and defined each interface on the switch as belonging to either the red VLAN or the blue VLAN. And only devices plugged into the blue interfaces would be able to communicate with each other. And only the devices plugged into the red interfaces would be able to communicate with each other.
Instead of colors, VLANs are defined by number. So in this switch we have a VLAN 1, a VLAN 2, and a VLAN 3. We can see that there are devices that are connected to interfaces that are configured for VLAN 1. Other devices connected to interfaces that have been configured for VLAN 2. And still, other devices that are configured for interfaces that will only communicate on VLAN 3.
This becomes a bit of a challenge when you want to connect VLANs across individual switches. For example, you have two switches in this scenario. One of the switches has a VLAN 100 and a VLAN 200. And the other switch also has a VLAN 100 and VLAN 200. We would like for VLAN 100 on one switch to be able to communicate with VLAN 100 on the other switch and perform the same functionality for VLAN 200.
Of course, one of the ways we could do this is to simply connect an ethernet cable between VLAN 200 on both switches and connect another ethernet cable between VLAN 100 on both switches. You can tell, however, that we’re going to run into problems if we want to connect 10, 20, 100, or even 1,000 VLANs across both of these switches.
We can’t connect 1,000 interfaces across each of these. So instead, we should find a way to connect these switches together by using a minimum of physical connectivity. We can do this by implementing a VLAN trunk. This is also referred to as an 802.1Q trunk, or a .1Q trunk.
Instead of having these multiple ethernet connections between VLANs, we have a single ethernet connection between these two switches. And you can see that we’ve configured that interface as a trunk interface. This means that anything sent from VLAN 100 or VLAN 200 across this trunk will be dropped off onto the appropriate VLAN on the other side.
So how is the trunk connection able to keep track of what traffic is coming from VLAN 100 and what traffic is coming from VLAN 200? The way we do this is by tagging each frame. This is a normal ethernet frame. We have a preamble, a start frame delimiter, a destination MAC, a source MAC, a type a payload, and a frame check sequence.
To be able to add additional tags into this frame, we’re going to add an additional field right in the middle right after the source MAC address. And we refer to this as the VLAN tag. These VLAN tags are 12 bits long. And if we’re not counting the VLAN numbers that are reserved, we can have a total of 4,094 VLANs that can traverse that trunk connection.
This makes the process relatively easy for connecting these VLANs together between switches. Instead of having 4,000 physical interfaces that we are connecting to each other, we have a single interface and we’re simply tagging all of the data sent over that connection. Before there was an 802.1Q standard to provide this trunking functionality, there was a proprietary form of trunking known as ISL, or inter-switch link.
ISL is relatively outdated at this point. And it’s likely that any trunk that you’ll ever run into will be an 802.1Q standard trunk. Let’s see how these trunks will use that tag functionality to be able to transfer data from a VLAN 200 on one switch to a VLAN 200 on the other switch.
We’ll start with a normal ethernet frame from a device that is connected to an interface defined as VLAN 200. This packet needs to find its way to a device that is on the other switch on VLAN 200. So that packet will be sent to the trunk interface on the switch.
At that time, an additional tag will be added that includes the VLAN 200, and it is sent across that trunk connection to the other switch. The switch that receives that frame will look at the tag, see that it was destined for VLAN 200, it will remove the tag from the frame, and send that traffic to the end station.
So now we have a much more simplified design. Instead of having a separate cable that’s running between switches for VLAN 1, VLAN 2, and VLAN 3, we can have a single ethernet connection between those two and simply trunk all of the traffic between those switches.
When you first configure a switch, there will be a default VLAN for this switch. That means that every device you connect to this switch by default will be connected to a VLAN. Very commonly, this is VLAN 1 that is defined as the default VLAN. But there’s another type of VLAN configuration that you would have inside of a switch known as a native VLAN.
A native VLAN is one that can traverse a trunk, but a VLAN tag is not added to any of the traffic going over that trunk connection. So it’s common to define a single native VLAN within a switch that will never be tagged as that traffic is sent over that trunk connection. This is because there are some devices that will not communicate over an 802.1Q network. And some of the administrative functions within your switches, where switches are communicating with each other, may need to use the native VLAN to perform that communication.
For example, management traffic or switch notification messages may use the native VLAN rather than being tagged as a separate VLAN inside of that switch. If you’re defining a native VLAN on one switch, you’ll need to make sure that that native VLAN is identical on the other switch that you’re connecting to. Otherwise you’ll see error messages appear in the log of your switch.
Up to this point, we’ve been describing a traditional layer 2 switch that is referring to the OSI layer two or data link layer, where switches make their forwarding decisions based on the MAC address of an ethernet frame. But there’s another type of switch known as a layer 3 switch that’s able to make forwarding decisions based on the OSI layer 3 or network layer of an IP packet.
This is looking at the destination IP address and making a routing decision on where that traffic should go. You’re effectively taking switch functionality at layer 2 and router functionality at layer 3 and combining both of those into the same unit. With a layer 3 switch, we’re not changing the switching process. The switch is still operating at layer 2.
And we’re not changing the way that a router operates. The routing functionality within this device is still operating at layer 3. But both of these are now combined within the same device, saving space, saving power, and making the administration process that much easier. This means that we can have layer 2 functionality within our switch, where we might have separate VLANs within the same physical switch.
But now we can also have routing functionality that allows us to route between those VLANs, all within the same switch. This means that we’ll need to configure interfaces inside of the switch that are designed to route from one VLAN to another. We refer to these as SVIs, or switched virtual interfaces. If you have a layer 3 switch, it may not have the layer 3 functionality turned on by default, so you may need to enable that in your switch configuration.
Many switches require you to restart the switch once you make that configuration change. And you may be thinking, why don’t we use layer 3 switches for everything? Instead of having two separate physical devices, it seems that having one single physical device would be much easier to manage. And in many cases, that’s true. But the routing functionality of a layer 3 switch tends to be less capable than the routing functionality of a standalone router.
There is a term within the industry where we tell the switch needs to switch and a router needs to route. When you start combining those devices together, you begin to lose functionality. So if you have a smaller remote site or perhaps even an internet router at home, you might have this layer 3 switching functionality to be able to route and switch within the same device.
It’s very common on our corporate networks to need both data functionality for our computing devices and voice functionality to be able to make telephone calls. Before the days of voice over IP, we would need to run one cable for our ethernet network and a separate cable for our telephones. Our ethernet cables would connect to a switch and our telephone cables would connect to a PBX, or a private branch exchange.
With the advent of voice over IP technologies, we can get rid of that individual voice cable completely and run both voice and data over the same ethernet connection. And in many enterprise environments you have a switch that is on the network, you have telephone that you would connect to the switch, and on the back of the telephone is an additional ethernet cable where you can plug in your local computing device.
One of the challenges that comes with adding both voice and data to the same network is that you now have a great deal of contention between both of those technologies. Data likes to use a lot of bursty bandwidth on the network. But voice communication prefers a very consistent level of access.
If there’s any type of congestion or a lot of usage on the network, this could affect the voice over IP communication and none of your phone calls would sound very good. To resolve this issue, we can put our voice communication on one VLAN and put our data communication on the other VLAN.
But of course, we’re using a single wire to connect both our phones and our computers, so we can use VLAN technologies to do that within that same cable through the use of trunking. This requires you to use a switch that will recognize that you’re connecting both a phone and a computer at the same time. But once you’re using the right equipment, this becomes a relatively straightforward process.
So now with this switch configuration, we can assign our phones to be VLAN 200, assign our computers to be VLAN 100, and send all of that traffic to our switch, where it will be able to break those two apart and put them on the correct VLAN for that particular use.
This means we can now download as much information as we’d like from our computer while we’re on the phone communicating with others and be able to perform both of those seamlessly.