Virtual LANs (VLANs)
In the previous chapter, you learned how hosts discover the MAC address of the host they want to communicate with. They do this by sending an ARP Request in a broadcast frame. If the target host is online and connected to the LAN, it responds directly (unicast) to the sender with an ARP Reply that includes its MAC address.
Broadcasts are useful when you don’t know where a host is on the LAN. They also help switches learn which switchport a host is connected to. However, broadcasts come with an important drawback.
Imagine a very large LAN made up of many interconnected switches, with endpoint devices connected to most (or all) switchports.
What happens when a switch receives a broadcast frame (after learning the source MAC address)?
The switch makes copies of the broadcast frame and floods it out of every port, except the port on which the frame was received.
This can significantly impact network performance. It also affects endpoints that receive these broadcast copies. Broadcasts are meant for everyone, so every host that receives a broadcast frame must interrupt its CPU (Central Processing Unit) to process the frame. Even if the IP packet inside the frame isn’t destined for that device’s IP address, the device still has to examine and process the frame.
On a large LAN with hundreds or thousands of endpoints, repetitive broadcasts can become a serious burden because every endpoint receives and processes every broadcast frame.
To address this, Ethernet switches introduced a feature that lets you group physical switchports into separate LANs called “Virtual LANs,” or VLANs.
Virtual LANs (VLANs)
A VLAN segments the broadcast boundary. The area in which broadcasts can propagate is called a Broadcast Domain.
By default:
- All ports on a switch are in the same broadcast domain.
- That means they’re all on the same LAN.
When you connect one switch to another, you extend the LAN and also extend the broadcast domain.
When you create a VLAN and move switchports into it, those switchports become part of a different broadcast domain. As a result:
- Broadcasts propagated within one VLAN can’t reach another VLAN.
- Broadcasts originating within a particular VLAN can only be seen or received by hosts within that same VLAN.
Historically, VLANs were especially helpful because endpoint CPUs were more sensitive to periodic broadcasts due to hardware limitations at the time. Modern CPUs are much more capable, but excessive broadcasts can still cause problems.
Today, VLANs are commonly used as a security and segmentation tool: they separate groups of endpoints so only the intended devices can communicate directly and receive each other’s broadcasts.
By default, all switchports are in the Default VLAN, which is VLAN 1. It’s important to know that you cannot create, modify or delete VLAN 1.
If you want to group endpoints into different VLANs, the steps are:
This process is straightforward. The key detail to remember is that switches associate learned MAC addresses with:
- the switchport they were learned on, and
- the VLAN that switchport is configured to be in.
Take the MAC address table example below. Notice that each MAC address entry includes a VLAN and the port where the MAC address was learned. That VLAN value tells you which VLAN the port belongs to.
Whenever you see “VLAN 1,” that means the switchport is still using its default factory settings and hasn’t been moved into an administratively created VLAN.
Always remember: hosts can only learn the MAC addresses of other hosts within the same VLAN only. That’s because hosts use ARP to discover MAC addresses, and ARP relies on broadcast frames. Since broadcasts from one VLAN can’t reach another VLAN, hosts in a different VLAN never receive the ARP Request and therefore can’t reply.
This doesn’t mean hosts can’t communicate across VLANs. They can, but they need a router (or a Layer 3 switch that can perform routing). We’ll cover that in the routing chapters (IP connectivity).
Let’s take a look at how intra-VLAN communication works in two scenarios:
Scenario 1: Hosts that are connected to a single switch
If two hosts are connected to the same switch and their ports are configured in the same VLAN, they can communicate directly.
However, if we were to create a new VLAN on SW1 (VLAN 2) and moved PC B into that VLAN, PC A and PC B would never be able to communicate with each other directly, because they would not be able to complete ARP.
They would both have to be in the same VLAN to communicate directly. Either VLAN 1 or VLAN 2.
Scenario 2 spanning across multiple switches
In another scenario, suppose Switch 1 is connected to Switch 2, and another host (PC C) is connected to Switch 2 in the same VLAN, which is a non-default VLAN. Let’s say that PC A, PC B and PC B have had their ports moved into VLAN 2.
Would PC C on Switch 2 be able to communicate with PC A and PC B on Switch 1, given they are in the same VLAN?
No.
The “why” comes from a principle you just saw.
PC A and PC B can’t communicate with PC C because the link between Switch 1 and Switch 2 (their GigabitEthernet 0/23 ports) hasn’t been modified. It’s still configured in VLAN 1.
Meanwhile:
- PC A and PC B on Switch 1 (GigabitEthernet 0/2 and GigabitEthernet 0/3) are configured in VLAN 2.
- PC C on Switch 2 (GigabitEthernet 0/1) is also configured in VLAN 2.
Broadcasts only propagate within the VLAN they originate from. That means ARP Requests from PC A and PC B (in VLAN 2) can’t cross the inter-switch link, because the inter-switch ports (GigabitEthernet 0/23 on both switches) are still in VLAN 1 and therefore can’t send or receive VLAN 2 traffic.
So:
- PC C never receives the ARP Requests.
- PC A and PC B never learn PC C’s MAC address.
- PC A and PC B can’t build Ethernet frames destined for PC C.