VLAN

Two hosts plugged into the same switch do not automatically belong to the same local network. In the field, a problem may look like “the IP is wrong” or “the firewall is blocking it”, but it may have died earlier at the Layer-2 boundary: ARP broadcasts only spread on part of the ports, DHCP Discover never leaves the segment, and packet capture shows traffic on the link while the target device still acts as if it were on another network.

VLAN handles exactly that problem. It is not there so the switch can “have one more numbering feature”. It is there so one physical Layer-2 infrastructure can be split into multiple independent logical LANs, and so broadcast, MAC learning, and Layer-2 forwarding all converge according to VLAN boundaries.

The core of VLAN is not “put another number on a frame”. It makes the question of which frame belongs to which Layer-2 broadcast domain explicit, and then lets switches learn, forward, and isolate by that boundary

This article follows IEEE 802.1Q. It focuses on why VLAN appeared, what the tag on the frame actually means, how switches process ingress and egress by VLAN, and how to hook up a host to a tagged network on Ubuntu for implementation, capture, and troubleshooting.

Why It Appears

Without VLANs, every port on one switch is part of the same Layer-2 broadcast domain by default. That creates some very practical problems:

• Broadcast and unknown unicast spread across the whole Layer-2 network
• Different business units, tenants, or device types are hard to isolate at Layer 2
• Network changes often require rewiring instead of logical changes
• The cost of carrying multiple logical networks on the same physical access layer is high

The early workaround was physical isolation: one network per switch fabric, or at least separate port groups and uplinks. That works, but it scales poorly and is expensive to operate. As enterprise networks, campus networks, ISP access networks, and later virtualization environments became more complicated, the network side needed a way to cut the Layer-2 broadcast domain and forwarding boundary apart without rebuilding the whole physical network.

VLAN is the answer. It pulls “which logical network this Layer-2 traffic belongs to” out of cable placement and turns it into explicit information that switches can recognize, configure, and carry across links.

The Background It Came From

VLAN is not a private trick from one switch vendor. It is a standardized capability in the IEEE 802.1 family, centered on IEEE 802.1Q. From the start, it served the switching fabric itself, not one host:

• Enterprise and campus networks needed multiple departments and business domains to share the same access infrastructure
• Management and operational traffic needed to be isolated from normal business traffic
• Multi-switch topologies had to preserve the isolation relationship across the switch fabric
• Later server virtualization, host multi-tenancy, and container networking all reused the same mechanism heavily

That shaped the design:

• The focus is the forwarding boundary inside a bridge network, not Layer-3 addressing
• The focus is compatibility with existing Ethernet, not a brand-new Layer-2
• The focus is on carrying tags along the switching path, not on forcing every endpoint to understand them

So VLAN has both a standardized side and a lot of vendor terminology. The common terms access, trunk, and hybrid are useful, but they are not fields inside the 802.1Q frame. They are vendor-friendly abstractions for ingress and egress behavior.

Grasp the Main Model First

Keep these four objects in mind:

• VLAN: a separate Layer-2 forwarding and broadcast boundary
• VLAN ID: the identifier of the VLAN the frame belongs to, usually written as VID
• Tag: the 802.1Q header carrying the VID and priority information
• VLAN-aware bridge: the switch that learns MAC addresses per VLAN and forwards per VLAN

You can compress the logic like this:

Frame enters the switch
  -> First decide which VLAN it belongs to
  -> Learn the source MAC in that VLAN’s table
  -> Forward or flood only inside ports that belong to that VLAN
  -> The outgoing port decides whether the frame leaves with a tag

The important thing is not the tag itself. It is “assign VLAN first, then forward”. If you do not keep that order stable, a lot of symptoms will be misread:

• Why two hosts on the same switch cannot ARP each other
• Why DHCP Discover only appears on some ports
• Why a Linux host must be connected to a port that can accept tagged frames
• Why packet captures look different on the physical interface and the VLAN subinterface

The Most Common Main Path

Here is the most typical path: a PC is attached to an access port in VLAN 10, a server is also on an access port in VLAN 10, and the switches in between are connected by an uplink that can carry multiple VLANs.

Three things happen on this path:

1. The original frame from the endpoint has no VLAN tag.
2. The first switch classifies it as VLAN 10 based on the ingress rule, and if it has to cross a VLAN-aware link, it carries VID 10 on the uplink.
3. The last hop to a normal endpoint usually sends it untagged, so the endpoint does not need to understand VLAN.

That means the most common deployment pattern is not “every device tags frames itself”. Instead:

• Endpoints usually do not know about VLAN
• Switches carry the VLAN semantics inside the fabric
• Tags only become visible when they have to preserve meaning across a VLAN-aware link

What Is Actually Inside the Tag

802.1Q inserts a 4-byte field between the source MAC and the original EtherType. It is not “a different Ethernet frame format”. It is a compatibility-friendly way to add VLAN and priority semantics to Ethernet.

Important fields:

The key point is VID. It is not a permanent property of the host. It means “which VLAN this frame belongs to right now”. VLAN is decided per frame, and the switch does the work on a per-frame basis.

How Switches Actually Process VLANs

Many guides reduce VLAN to access and trunk ports. A more stable mental model is ingress and egress.

Ingress: decide which VLAN the frame belongs to when it arrives

When a port receives a frame, the switch first asks: which VLAN does this frame belong to?

There are two common cases:

• The frame already has an 802.1Q tag: the switch reads the VID
• The frame has no tag: the switch assigns it according to the port’s default VLAN

That default is usually what people call PVID, the Port VLAN ID. It does not mean the port only belongs to one VLAN. It means “for untagged ingress, which VLAN should be used to classify the frame?”

So the most important job of PVID is untagged ingress classification. It does not rewrite tagged frames, and it does not make any Layer-3 routing decision.

Egress: decide whether to keep the tag when sending out

Once the frame has been classified into a VLAN inside the switch, the switch still has to decide whether to keep the tag when sending it out another port.

Common cases:

• To a normal endpoint port: usually send untagged
• To a switch interconnect, router subinterface, or server host port: usually keep the tag

That is what access and trunk are trying to express:

• access behaves like an untagged VLAN-facing endpoint port
• trunk behaves like a port that can carry multiple VLAN tags across the link

But note that the 802.1Q standard itself talks about port membership, PVID, ingress filtering, and egress tagging. Different vendors do not always use the same CLI terms for native VLAN or allowed-list behavior.

Why VLAN Is More Than Broadcast Isolation

Broadcast-domain splitting is the most obvious effect, but VLAN changes the whole Layer-2 forwarding model.

MAC learning is separated by VLAN

The same MAC address can exist in different VLANs independently. The switch does not maintain one global “MAC to port” table. It is closer to:

(VLAN, MAC) -> port

That means the switch learns, floods, and forwards separately for each VLAN. If you forget that, packet captures and forwarding behavior look very strange.

Broadcast and unknown unicast only spread inside the VLAN

ARP requests, DHCP Discover, and unknown-destination flooding do not cross VLANs by default. Their boundary is not “the whole switch”. It is the VLAN the frame belongs to.

So when two devices are “on the same switch but cannot find each other”, the cause is often not physical connectivity. More likely:

• Their ports are in different VLANs
• One side sends tagged frames and the other side only accepts untagged ones
• The uplink does not allow the relevant VID

VLAN is not Layer 3

Different VLANs do not talk to each other by default. To let VLAN 10 access VLAN 20, you need Layer-3 forwarding such as a router or an SVI on a Layer-3 switch.

That boundary matters:

• VLAN handles Layer-2 isolation and broadcast-domain slicing
• Layer-3 devices handle inter-VLAN routing and access control

If you mix those up, a lot of troubleshooting will point in the wrong direction.

The Design Choices That Look Awkward but Matter

Normal endpoints usually do not see VLAN

That is not because VLAN is unimportant. It is because one of the design goals was to let many endpoints that do not understand VLAN still work. The switch takes over most of the VLAN semantics.

The tradeoff is:

• Packet captures on the endpoint may not directly show tags
• One small port mismatch can produce “physical link works, logical network does not”
• Problems often have to be traced back from the switch fabric and port mode

Tags only become obvious when they need to survive a VLAN-aware link

If a frame stays only on a normal endpoint port and within the VLAN it belongs to, the endpoint does not need to see the tag. The tag matters most when:

• It crosses switches
• It goes to a router or firewall VLAN subinterface
• It goes to a Linux / ESXi / KVM host that is directly attached to a tagged network

So “I did not see a tag in capture” does not mean the network is not using VLAN. Often you are simply capturing at the wrong point.

Native VLAN is a deployment convention, not the starting point

Many field guides like to describe native VLAN as the key trunk concept. It is common, but the more stable mental model is still:

• Which VLANs are allowed on this port
• Whether a given VLAN leaves tagged or untagged
• Which PVID is used to classify untagged ingress

Once those three things are clear, the vendor CLI terms native VLAN, allowed VLAN, and tagged/untagged become much easier to read.

How to Configure VLAN on Ubuntu

The most common reason a Ubuntu host joins a VLAN is not “like a normal PC on an access port”, but something like:

• A developer machine connects directly to a tagged port for debugging
• A server host needs to be on multiple VLANs at once
• A capture machine needs to observe 802.1Q frames on the physical NIC

In those cases, you do not assign multiple unrelated IPs to the physical NIC directly. You create VLAN subinterfaces on top of the physical interface.

Temporary setup: iproute2

This example attaches enp3s0 to tagged ports carrying VLAN 10 and VLAN 20, and creates two subinterfaces:

sudo ip link add link enp3s0 name enp3s0.10 type vlan id 10
sudo ip addr add 192.168.10.2/24 dev enp3s0.10
sudo ip link set enp3s0.10 up

sudo ip link add link enp3s0 name enp3s0.20 type vlan id 20
sudo ip addr add 192.168.20.2/24 dev enp3s0.20
sudo ip link set enp3s0.20 up

Check the result:

ip -d link show enp3s0.10
ip addr show enp3s0.10

This is good for temporary debugging and packet capture. If you do not persist it, the interface disappears after reboot.

Persistent setup: Ubuntu Desktop netplan

Ubuntu Desktop is usually managed by NetworkManager. This example keeps the physical interface enp3s0 without an IP and creates a VLAN 10 subinterface on top of it:

# /etc/netplan/01-vlan.yaml
network:
    version: 2
    renderer: NetworkManager
    ethernets:
        enp3s0:
            dhcp4: false
    vlans:
        enp3s0.10:
            id: 10
            link: enp3s0
            addresses:
                - 192.168.10.2/24

Apply the configuration:

sudo netplan try
sudo netplan apply

Then verify the interface name. On Ubuntu, you will usually still see a network device in the form of enp3s0.10. If the host is expected to talk to a tagged network, remember that the switch port must also allow the same VLAN, otherwise the host-side configuration is correct but the line still will not pass.

What to Look At in Packet Capture and Troubleshooting

VLAN troubleshooting is easiest to misread if you start by staring at EtherType or one line of switch output. A more useful order is below.

First check whether this is really one Layer-2 domain

Confirm:

• Are the two hosts in the same VLAN
• Is the uplink carrying the relevant VLAN
• Is the endpoint port access or trunk

Then check what the frame looks like at ingress and egress

Focus on:

• Whether the incoming frame is tagged or untagged
• Which VLAN the switch assigns it to
• Whether the outgoing side keeps or strips the tag

Finally check whether the problem is not really Layer 2 at all

Many symptoms look like VLAN trouble but are actually:

• A default gateway missing
• A DHCP server missing from the VLAN
• A routing issue between VLANs
• A firewall policy problem on the Layer-3 boundary

So VLAN is a Layer-2 boundary problem first. If the two layers above it are wrong, the final symptom may still look like “the network is down”.

What Engineering Should Actually Think About VLAN Today

• Do not think of VLAN as a small numbering feature. It makes the Layer-2 broadcast-domain boundary explicit
• Do not mix up port membership with host identity. VLAN is judged per frame
• Do not forget that MAC learning, flooding, and broadcast scope are all separated by VLAN
• Do not assume physical proximity means one LAN. On a switch, different ports may still belong to different logical networks
• Do not forget that VLAN is only Layer 2. Inter-VLAN communication still needs Layer 3