Lessons (6, study in order)

What problem does a VLAN actually solve

Intro · about 8 min

Goal: Understand "what happens without VLANs" so the reason VLANs exist becomes obvious.

First, what a switch looks like with no VLANs

By default every port on a switch is in VLAN 1 — meaning one broadcast domain:
· When any host sends a broadcast (ARP, DHCP discovery), every other host receives it
· Any two hosts can reach each other as long as their IPs are on the same subnet

Fine for a small office. But once the machine count grows, three problems show up.

Problem one: broadcast storms

Broadcast traffic grows quadratically with device count. With 100 machines in one broadcast domain, every machine has to process the other 99's broadcasts — ARP, NetBIOS, all sorts of discovery protocols.
A NIC receiving a broadcast has to interrupt the CPU just to look at it (even if it discards it afterward), so more broadcasts mean sluggish hosts.
The bigger the broadcast domain, the more fragile it is: one machine with a bad NIC flooding broadcasts can take down the whole segment.

Problem two: security and access mixed together

Finance's computers and a guest's computer sharing the same broadcast domain means:
· The guest can directly scan and find Finance's machines
· ARP spoofing can redirect Finance's traffic to the guest's machine
Layer 2 has almost no security mechanisms — sharing a broadcast domain is basically "everyone exposed to everyone."

Problem three: physical location locks in logical grouping

Without VLANs, isolating Finance requires buying a separate switch just for them, and everyone in Finance has to sit near that switch.
Every time someone changes desks, cables have to be re-run — that's simply unmaintainable in the real world.

So what is a VLAN

A VLAN logically slices one physical switch into several switches that can't reach each other.

Remember just this one sentence — everything else follows from it:
· Once sliced apart → cross-VLAN traffic naturally doesn't work (that's the goal, not a fault)
· Grouping is by port, not by location → moving desks only needs one command on the switch
· Each VLAN is its own broadcast domain → broadcasts stay confined to their own VLAN

"VLAN assignment" boils down to configuration as: which ports go in which VLAN.

Key takeaways

• A VLAN = logically slicing one switch into several
• A VLAN is a broadcast domain — broadcasts flood only within their own VLAN
• Cross-VLAN not working is by design, not a fault — reaching across requires extra layer-3 work
• VLANs are assigned by port, so moving desks doesn't require re-cabling

Port types and PVID: the most confusing part of VLANs

Intro · about 12 min

Goal: Split "port type" into two independent questions, and you'll never mix it up again.

First, remember one thing: end hosts have no idea VLANs exist

An 802.1Q tag is added by a switch, and stripped by a switch.
A PC, printer, or camera's NIC always sends out a plain, untagged Ethernet frame, and simply discards any tagged frame it receives (it doesn't recognize it).

So "the port connecting to an end host must strip the tag going out" isn't a rule someone made up — it's a necessity. That's where the access port comes from.

Split port type into two questions

Don't memorize the three type definitions — instead ask two questions:

Question ①: what happens when it receives an "untagged" frame?
The answer is the same for all three types: tag it with this port's PVID.

Question ②: does it tag frames going out?
· Access — never (the far end is an end host)
· Trunk — usually yes, except the PVID VLAN (native), which is untagged
· Hybrid — each VLAN individually decides tagged or untagged

Answer these two questions and you've derived every port type's full behavior.

The PVID only matters in one place

The PVID only governs the case of "receiving an untagged frame."
If a frame is already tagged, it's handled by the VLAN written in the tag — the PVID plays no part at all.

This is the single most-confused point. Many people think the PVID is "which VLAN this port belongs to" —
that happens to be equivalent for an access port, but it means something entirely different for a trunk.

Access port: connects to an end host

· An access port belongs to exactly one VLAN (its PVID)
· Receiving a host's frame → tags it with the PVID
· Sending to the host → strips the tag
· A frame from another VLAN trying to leave this port → dropped outright (this is how cross-VLAN layer-2 isolation is implemented)

Huawei: port link-type access + port default vlan 10
Cisco: switchport mode access + switchport access vlan 10

Trunk port: connects to another switch

One cable needs to carry several VLANs at once — how does the far end know which VLAN each frame belongs to?
The tag tells it. So frames leaving a trunk carry an 802.1Q tag (4 extra bytes).

Two things must be configured, and forgetting either causes a fault:
· port trunk allow-pass vlan 10 20 — which VLANs are permitted, must be set on both ends
· The PVID (native VLAN) — must match on both ends

Each of these maps to a common fault class, covered in depth in lesson 4.

Hybrid port: unique to Huawei

Can go either tagged or untagged, set per VLAN individually. On Huawei devices, the default port type is actually hybrid — often a surprise (Cisco defaults to access/dynamic).

Classic use case: one wall jack connects both an IP phone and a PC — the phone sits in the middle, the voice VLAN goes out tagged, the PC's data VLAN goes out untagged, and one cable handles both VLANs.

Key takeaways

• An end host always sends and receives plain, untagged frames — the switch adds the tag
• The PVID only matters when "an untagged frame is received"
• Access always strips the tag going out; a trunk tags everything except the native VLAN; hybrid decides per VLAN
• Both allow-pass and PVID must match on the two ends of a trunk

Crossing switches: why the 802.1Q tag has to exist

Intro · about 10 min

Goal: See what the tag looks like on the wire, and understand why it's "link-local."

First, consider a question

SW1 has hosts in VLAN 10 and VLAN 20, and so does SW2. There's only one cable between them.
When SW1 sends a frame over, how does SW2 know which VLAN that frame belongs to?

A plain Ethernet frame carries no VLAN information at all. So there are only two options:
· Run one cable per VLAN (blows up once VLANs multiply)
· Add a field to the frame that records the VLAN number ← this is 802.1Q

What an 802.1Q tag looks like

4 bytes are inserted right after the "source MAC" in the Ethernet frame:

dstMAC(6) srcMAC(6) [TPID(2) TCI(2)] type(2) data... FCS(4)
                     └── these 4 bytes are the 802.1Q tag

· TPID = 0x8100, a fixed value; a NIC uses it to recognize "this is a tagged frame"
· The 2-byte TCI = PRI (3 bit) + CFI (1 bit) + VLAN ID (12 bit)

12 bits → 0–4095, of which 0 and 4095 are reserved, so usable VLANs are 1–4094.
Those 3 PRI bits are the 802.1p priority, used by QoS — which is also part of why voice gets its own VLAN: only with a tag is there somewhere to write a priority.

The tag is "link-local"

Look at the frame-size column in the hop-by-hop simulation:
· Host ↔ switch (access): 84 bytes, untagged
· Switch ↔ switch (trunk): 88 bytes, tagged

The tag is added entering a switch and stripped leaving one — it only exists on the link segment between switches.

This causes a common confusion: "why can't my packet capture see a VLAN tag?" —
Because you captured on an access port / end host. To see a tag you have to capture on a trunk port, and the NIC running the capture software also has to allow receiving tagged frames.

A trunk is "one cable carrying multiple VLANs," not "anything goes"

A trunk doesn't mean "everything passes through." It only permits VLANs that are in the allow-pass list — anything not on the list gets dropped outright.
This design is intentional — a trunk usually doesn't need to carry all 4094 VLANs, and permitting only what's needed cuts down on pointless broadcast flooding.

But it also causes the single most common VLAN fault, covered in the next lesson.

Key takeaways

• 802.1Q inserts 4 bytes after the source MAC, of which 12 bits are the VLAN ID
• Usable VLANs are 1–4094 (0 and 4095 are reserved)
• The tag is link-local: added entering a switch, stripped leaving one
• Not seeing a tag in a capture is usually because you captured on an access port
• The 3-bit 802.1p priority in the TCI is one of the reasons a voice VLAN exists

Two common fault classes: missing allow-pass, and mismatched PVIDs

Troubleshooting · about 12 min

Goal: Learn to work backward from a symptom straight to which port is misconfigured.

Fault one: a trunk forgot to permit a VLAN

Symptom: some VLANs reach across switches, others don't.

This symptom is almost a fingerprint for this exact fault. If it were a physical issue or the trunk wasn't configured at all, every VLAN would fail to reach; if only some VLANs fail, the trunk itself is fine — it just has that particular VLAN missing from its allow-pass list.

The current scenario has this exact trap baked in: the trunk only permits VLAN 10, not VLAN 20.

How to check

Huawei: display port vlan — one command shows every port's type, PVID, and permit list, the single most useful one
Cisco: show interfaces trunk — directly lists each trunk's native VLAN and allowed list

When checking, remember: check both ends. Permitting it on only one end is the same as not permitting it, because the frame gets dropped right at the ingress when it arrives from the far end.

Fault two: mismatched PVIDs on the two ends

Symptom: hosts in two different VLANs can somehow reach each other.

This is worse than not working, because "it works" looks normal — nobody reports it as a fault — but VLAN isolation has already broken, which is a security issue.

How it happens:
① SW1's trunk PVID is 10, and VLAN 10 is its native VLAN → sent untagged
② SW2's trunk PVID is 20; it receives an untagged frame → tags it as VLAN 20 by its own PVID
③ SW1's VLAN 10 and SW2's VLAN 20 have effectively become the same broadcast domain

The root cause is the same rule from lesson V2: an untagged frame gets tagged by the receiving port's PVID.

Why does the native VLAN design even exist

If native VLAN is such a common source of trouble, why does it exist at all?
Historical reason: to stay compatible with older devices that don't understand 802.1Q (and hubs). Setting their VLAN as native means the frame goes out untagged, so the old device can still receive it.

Current best practice is:
· Keep the PVID consistent on both ends (usually leave it at 1, or set both to the same value)
· In higher-security settings, change the native VLAN to an unused VLAN (e.g. 999) and don't permit it — that way any frame arriving untagged can't get into a real business VLAN

Troubleshooting order (follow it — don't skip steps)

① Physical layer: is the port up, is the cable good (display interface brief)
② Does the VLAN exist: display vlan — a VLAN that isn't created can't be assigned to a port
③ Is the access port's PVID right: display port vlan — which VLAN the host actually lands in
④ Is the trunk permitting it: check allow-pass on both ends
⑤ Do the trunk PVIDs match: a mismatch leaks VLANs into each other
⑥ If layer 2 is clean by this point and cross-VLAN still doesn't work, go check layer 3

Key takeaways

• Some VLANs don't reach across switches → the trunk is missing an allow-pass entry
• VLANs that shouldn't reach each other somehow do → mismatched PVIDs on the trunk's two ends, isolation has broken
• display port vlan (Huawei) / show interfaces trunk (Cisco) — one command locates most problems
• Check both ends of a trunk — configuring only one end is the same as configuring neither

Cross-VLAN routing: VLANIF and router-on-a-stick

Advanced · about 12 min

Goal: Learn how both approaches are configured, how they differ, and why VLANIF is now the standard.

First, be clear: cross-VLAN not working isn't a fault

The whole point of a VLAN is isolation. Cross-VLAN traffic not working is the design succeeding, not failing.
So "making VLANs talk to each other" is an extra thing you have to set up, and it must go through layer 3 — because two VLANs are two broadcast domains, two subnets, and layer 2 can never reach across them.

The path is always: host → that VLAN's own gateway → layer-3 forwarding → the other VLAN → destination host.

So a host must have a default gateway configured

When a host sees the destination IP isn't on its own subnet, it sends the frame to the default gateway's MAC.
No gateway configured → it doesn't know who to send to → a cross-subnet packet can't even leave for the switch.

When "same VLAN works, cross-VLAN doesn't" and nothing on the switches looks wrong, check the host's gateway and mask first — this step gets skipped often.

Approach one: an L3 switch's VLANIF (today's standard)

Create a virtual interface for each VLAN on the switch, and give it an IP to serve as that VLAN's gateway:

vlan batch 10 20
interface Vlanif10
 ip address 192.168.10.1 255.255.255.0
interface Vlanif20
 ip address 192.168.20.1 255.255.255.0

Cisco calls it an SVI: interface Vlan10, and ip routing must also be enabled, or SVIs won't forward between each other.

Two prerequisites:
① The VLAN must already exist, otherwise interface Vlanif10 can't be created
② For the VLANIF to be up, this VLAN needs at least one up physical port ← the easiest one to trip on

Approach two: router-on-a-stick

Used when there's no L3 switch: one trunk between the switch and the router, with the router creating a subinterface per VLAN:

interface GE0/0/1.10
 dot1q termination vid 10
 ip address 192.168.10.1 255.255.255.0
 arp broadcast enable      ← without this the subinterface won't reply to ARP, and the gateway won't be pingable

Cisco: encapsulation dot1Q 10 (no need for arp broadcast enable).

The switch-side port must be a trunk permitting every VLAN that needs to talk to another.

What's the difference between the two

| | VLANIF | Router-on-a-stick |
| --- | --- | --- |
| Where forwarding happens | switching chip, line rate | router CPU, an order of magnitude slower |
| Bandwidth | backplane bandwidth, huge | that one cable, and traffic traverses it twice |
| Single point of failure | none extra | that cable or router down = all cross-VLAN traffic stops |
| Cost | needs an L3 switch | an L2 switch plus a router is enough |

So production networks all use VLANIF. Router-on-a-stick today is mostly an interview question and a very small-scale option.
Its value, though, is that it makes "crossing VLANs must go through layer 3" extremely visual — the traffic really does go out the cable and come back down it.

Key takeaways

• Cross-VLAN not working is the design goal — reaching across requires extra layer-3 setup
• A host must have a default gateway configured, or cross-subnet packets can't leave
• VLANIF/SVI needs to be up, which requires at least one up physical port in that VLAN
• Cisco SVIs need ip routing enabled to forward between each other
• A Huawei subinterface needs arp broadcast enable, or the gateway won't be pingable
• Router-on-a-stick traffic traverses the same cable twice, making it a bottleneck

How to test whether VLANs are configured correctly

Troubleshooting · about 10 min

Goal: Build a repeatable verification method instead of just randomly pinging things.

Write down the expected result before testing

This is the most important step, and the one beginners skip most often.

With no inter-VLAN routing configured, the correct result is:
· Same VLAN and same subnet → reachable
· Cross-VLAN → unreachable

With inter-VLAN routing configured:
· Everything reachable

Without an expectation, you can't judge right from wrong. "It can ping" by itself could mean success, or it could mean isolation has failed.

The connectivity matrix: see everything at once

Ping every pair and lay the results out as a matrix. The matrix flags two kinds of deviations separately:

· Should reach but doesn't → a config gap (missing allow-pass, wrong PVID, port down)
· Should be isolated but reaches → PVID mismatch leaking VLANs into each other, a security issue

The second kind is worse than the first, and nobody will ever report it as a fault — you can only catch it by actively testing.

Four commands solve most of it

Huawei:
· display vlan — was the VLAN created, who are its member ports
· display port vlan — the single most useful one: every port's type, PVID, permit list
· display interface brief — is the port up
· display mac-address — was the MAC learned, and in which VLAN

Cisco: show vlan brief / show interfaces trunk / show interfaces status / show mac address-table

The MAC table is layer-2 troubleshooting evidence

display mac-address reveals a lot:
· Was the host's MAC learned → if not, the frame never arrived at all; check physical connectivity and PVID
· Which VLAN it was learned in → if it's not what you expected, the PVID is misconfigured
· Which port it was learned on → if it's not what you expected, a cable is plugged into the wrong place

The gap between "I thought it was in VLAN 10" and "the switch thinks it's in VLAN 20" is obvious the moment you check the MAC table.

Pre-launch checklist

① All VLANs are created (display vlan)
② Every port connecting to a host is type access, with the planned PVID
③ Every trunk permits the needed VLANs on both ends
④ Every trunk has a matching PVID on both ends
⑤ Every VLAN's gateway address is planned, and hosts' configured gateway/mask actually match it
⑥ Every VLAN that needs to talk to another all has a VLANIF, and every VLANIF is up
⑦ Run the connectivity matrix once and compare it cell by cell against expectations

Key takeaways

• Write the expectation before testing — "it works" could mean success or a broken isolation
• display port vlan — one command shows every port's type/PVID/permit list
• The MAC table is layer-2 troubleshooting evidence: was it learned, in which VLAN, on which port
• "Should be isolated but isn't" gets reported by nobody — you can only catch it by actively testing