Why we have VLANs - Cisco CCNA Tutorial

In this Cisco CCNA training tutorial, I will cover Virtual Local Area Networks (VLANs) which is a Layer 2 feature implemented on switches. To understand why we have them, you need to understand the problem that they solve first. Scroll down for the video and also text tutorial.

Why We Have VLANs – Video Tutorial

First, let’s look at the router operations. Routers operate at Layer 3 of the OSI Stack. Hosts on separate IP subnets must send traffic via a router to communicate. That’s the main job of a router, routing traffic between different IP subnets.

Security rules on routers or firewalls can be used to easily control traffic that is allowed between different IP subnets at layer 3. For example, all engineering hosts are in the 10.10.10.0/24 subnet and accounts hosts are in 10.10.20.0/24. If you don’t want the engineering hosts to have access to the accounting hosts, security rules can be implemented on a router or firewall to block traffic from the 10.10.10.0 subnet to the 10.10.20.0 subnet.

You can pass your CCNA exam at the first attempt by taking my Cisco CCNA Complete course in conjunction with the AlphaPrep test engine.

Routers do not forward broadcast traffic by default. They provide performance and security by splitting networks into smaller domains at layer 3.

Switches operate at layer 2 and they do forward broadcast traffic by default, unlike routers. So by default, a campus switched network is one large broadcast domain. Your switches flood broadcast traffic everywhere including between different IP subnets. That raises performance and security concerns.

Known Unicast Traffic

Let’s take a look at the example above. We have a simple LAN with one switch and a few engineering and sales PCs attached. The engineering and the sales PCs are in different IP subnets at layer 3 and we have a router to route traffic between them.

If we send unicast traffic within the same IP subnet to a destination MAC address which the switch has already learned about, the switch will forward the traffic out only the relevant port. For example if the sales PC2 at 10.10.20.10 wants to communicate with the sales PC1 at 10.10.20.11, the switch will send it out only the port where the sales PC1 is connected. Traffic only goes exactly where it needs to go so this is very good for performance and security.

If we send learned unicast traffic between different IP subnets it will be sent via the router. Let's say a sales PC wants to talk to an engineering PC. The sales PC can see that the engineering PC is in a different subnet based on its IP address, so it knows to send the traffic via the router’s MAC address. The sales PC sends traffic that comes into the switch, the switch then sends that onto the router out only the relevant port.

The router will then route the traffic out its engineering subnet interface. The traffic will reach the switch and be sent out only the port which the engineering PC is plugged into.

From these examples you can see that switches send known unicast traffic out only the exact ports it needs to be sent out of, whether it's within the same or between different subnets. This provides good security and performance.

The Problem – Broadcast Traffic

Broadcast traffic however acts differently. Using the example above, let’s have a look at this and see how it works. The sales PC, PC2, sends out some broadcast traffic which comes into the switch. The switch floods broadcast traffic out all ports apart from the one that it was received from. The traffic goes absolutely everywhere, including to PCs that are in both the engineering and sales subnets.

This affects security because the traffic bypasses any router or firewall layer 3 security policies at layer 2. Even if you have security configured, when a sales PC sends out broadcast traffic it will bypass that and still hit the engineering PCs. A layer 2 attack will reach PCs in the other subnet even though you are blocking traffic between them at layer 3.

It also affects performance. Every end host has to process the traffic, and the traffic will use up bandwidth and switch resources on links it was not required to travel over.

To highlight that, let's use the slightly different network topology above. We've got the same switch in the middle where sales and engineering PCs are connected. That switch is also connected to another switch in a different part of the building, and on that switch there are accounting PCs plugged in. When the sales PC sends some broadcast traffic, it gets flooded out all ports. That will traverse to the other switch and that switch will do the same on all its ports. Broadcast traffic hits the accounts switches and PCs even when it’s not required there.

The Solution - VLANs

The performance and security issues caused by large broadcast domains are resolved by Virtual Local Area Networks (VLANs). VLANs are a layer 2 feature which segment the LAN into separate broadcast domains at layer 2.

Typically, there’s a one-to-one relationship between an IP subnet and a VLAN. For example engineering PCs are in the 10.10.10.0/24 IP subnet at layer 3, and VLAN 10 at layer 2. Sales PCs are in the 10.10.20.0/24 IP subnet at layer 3, and its associated VLAN 20 at layer 2.

Let’s use the same network topology as an example. We create an engineering VLAN and a sales VLAN on the switch. All the engineering PCs and the router interface for the engineering subnet are put into the engineering VLAN while all the sales PCs and router interface for the sales subnet are put into the sales VLAN. The switch only forwards traffic within the same VLAN.

Nothing changes for the unicast traffic within the same IP subnet scenario. The switch sends traffic from sales PC2 to sales PC1 out only the port to which sales PC1 is plugged into.

The behavior of unicast traffic between different IP subnets also remains changed. Sales PC2 sends traffic to an engineering PC. The switch only allows traffic within the same VLAN, but since the destination MAC address is the sales PC2’s default gateway on the router interface which is also in the sales VLAN, this isn’t a problem. The switch sends out only the port which the router’s sales VLAN interface is connected to.

The router will then route the traffic to the engineering VLAN and send it out its interface in the engineering VLAN. The traffic comes back into the switch on an engineering VLAN port and is then forwarded out only the port which the engineering PC is connected to.

Unicast traffic both within the same subnet or between different subnets, works the same whether we're using VLANs or not.

The big difference and benefit is for broadcast traffic. For example, sales PC2 sends out broadcast traffic, it hits the switch and is flooded out all ports… but only those ports that are in the same VLAN. This improves security and performance as it will not be forwarded to any of the engineering PCs, the traffic only gets flooded where it needs to go.

Broadcast traffic needs to be flooded within the same IP subnet and VLAN so that ARP requests can work. 10.10.10.10 wouldn’t be able to find the MAC address of 10.10.10.11 and communicate with it without sending broadcast ARP requests.

Broadcast traffic such as ARP does not need to be flooded across IP subnets and VLANs though. If 10.10.10.10 wants to communicate with 10.10.20.10, it sends a broadcast ARP request for its default gateway router which is in the same VLAN. The router has interfaces in both subnets and VLANs so it is able to forward traffic between them.

Routers segment your network at layer 3, VLANs segment it at layer 2. Implementing both in your network provides performance and security.