A VLAN is a logical Layer 2 boundary—not just a number typed into a switch
A virtual LAN lets one physical switching system support multiple separate Layer 2 broadcast domains. The useful mental model is membership → carriage → local forwarding → Layer 3 crossing. First determine which VLAN an endpoint belongs to. Then determine whether that VLAN is carried where it must go. Only after the local Layer 2 path is established should you investigate routing between VLANs.
After reviewing segmentation, test the whole path in the AP Networking Switching, VLANs, and Ethernet Practice Test. Compare access membership, trunk allowances, native handling, and gateway policy; a working physical uplink is not proof that every intended VLAN crosses it.
VLAN separation changes where Layer 2 broadcasts can travel
Imagine one switch with Student VLAN 10, Staff VLAN 20, and Management VLAN 30. A Layer 2 broadcast generated in VLAN 10 is handled inside VLAN 10's broadcast domain; it is not simply flooded into VLANs 20 and 30. This is why two endpoints can be plugged into the same physical switch yet occupy different logical networks.
VLAN 10 — Students [PC-A] [PC-B] ─┐ VLAN 20 — Staff [PC-C] [PC-D] ─┼─ same switching hardware VLAN 30 — Management [SW-MGMT] ─────┘ Broadcast from PC-A → VLAN 10 members/path only Crossing VLAN 10 → VLAN 20 requires Layer 3 forwarding when they are separate IP networks.
An access port maps an ordinary endpoint into a VLAN
A typical workstation sends and receives ordinary Ethernet frames without managing an 802.1Q trunk itself. The switch access port associates that traffic with its configured VLAN. This makes access-port configuration a critical piece of evidence when a single endpoint behaves as though it is on the wrong network.
Hypothetical access configuration interface Gi1/0/7 switchport mode access switchport access vlan 10 Expected host: Student-PC-07 Expected network: VLAN 10 / 10.10.10.0/24
If that port were accidentally assigned to VLAN 20, the cable could still negotiate normally. “Link up” would therefore be true while “correct VLAN membership” would be false.
A trunk solves a different problem: carrying multiple VLANs across one link
When VLAN 10 exists on endpoints attached to two different switches, the switches need a way to preserve VLAN identity across their shared link. IEEE 802.1Q tagging supplies that context for tagged VLAN traffic. A trunk can therefore carry multiple VLANs without merging those VLANs into one broadcast domain.
Access VLAN 10 Access VLAN 10
PC-A ── SW1 Gi1/0/7 ──┐ ┌── SW2 Gi1/0/9 ── PC-B
├══ 802.1Q ══┤
Staff VLAN 20 ─────────┘ trunk └───────── Staff VLAN 20The trunk is Layer 2 carriage. It is not itself a route between VLAN 10 and VLAN 20.
A healthy trunk can still fail one VLAN
Suppose an uplink carries VLANs 10, 20, and 30, but VLAN 20 is accidentally omitted from the allowed list on one side. The physical uplink can remain up and VLANs 10 and 30 can continue working. That pattern is valuable because it argues against treating the shared cable as the first suspect.
Hypothetical trunk evidence Port Mode VLANs allowed Gi1/0/48 trunk 10,30 Requirement: VLANs 10,20,30 must cross this uplink Observation: VLAN 10 works; VLAN 30 works; VLAN 20 fails
The missing VLAN 20 is a discriminating configuration difference. The smallest justified correction is VLAN-specific—not replacing a working uplink.
Native-VLAN reasoning is about how untagged trunk traffic is interpreted
On designs that use a native VLAN, untagged traffic on an 802.1Q trunk is associated with the configured native VLAN according to the devices' behavior. If the two ends expect different native VLANs, the same untagged traffic can be classified differently on each side.
For a focused diagnostic page, see VLAN Mismatch Symptoms.
The MAC table can connect a physical port to a logical VLAN
Switch-A# show mac address-table VLAN MAC Address Type Port 10 00aa.1000.0007 DYNAMIC Gi1/0/7 20 00bb.2000.0012 DYNAMIC Gi1/0/12 30 00cc.3000.0001 DYNAMIC Gi1/0/24
If Student-PC-07's MAC is expected on Gi1/0/7 in VLAN 10 and appears there, the table supports that Layer 2 learning condition. If the same MAC appears under VLAN 20, the evidence points toward unintended VLAN placement or carriage. It still does not prove the host's IP settings, DHCP success, gateway, or application.
Use MAC Address Table Explained to deepen the artifact-analysis side.
A VLAN boundary changes which local IPv4 neighbors can be discovered by broadcast
When an IPv4 host needs the Layer 2 address for a local neighbor, ARP uses a broadcast request within the local Layer 2 domain. A host does not ordinarily broadcast an ARP request through a router to discover a host in another IP network. For a remote destination, the source instead needs the Layer 2 address of its local gateway.
Separate VLAN/subnet pairs need a Layer 3 crossing point to communicate
Consider VLAN 10 as 10.10.10.0/24 and VLAN 20 as 10.10.20.0/24. Host 10.10.10.25 recognizes 10.10.20.80 as remote, so it sends the packet toward its default gateway rather than attempting a direct same-LAN delivery. A router or multilayer switch can then route between the networks, subject to policy.
See Routing for AP Networking for route-selection reasoning.
A multilayer switch can make an SVI the default gateway for a VLAN
VLAN 10: 10.10.10.0/24 SVI gateway: 10.10.10.1 VLAN 20: 10.10.20.0/24 SVI gateway: 10.10.20.1 VLAN 30: 10.10.30.0/24 SVI gateway: 10.10.30.1
An SVI gives the VLAN a Layer 3 interface on the multilayer switch. Same-VLAN traffic can remain Layer 2 switched; traffic crossing into another IP network enters the Layer 3 function. That distinction is explored in Network Switching.
Wrong VLAN membership can look like a DHCP problem because DHCP begins inside a broadcast domain
A new IPv4 client may not yet have an address, so early DHCP discovery relies on local broadcast behavior. If the client is accidentally placed in the wrong VLAN, its discovery enters the wrong Layer 2 domain. If the DHCP server is remote, a correctly configured Layer 3 relay path is also required.
| Observation | Plausible boundary | Next evidence |
|---|---|---|
| One client gets no intended lease | Endpoint/access-port state | Port VLAN, MAC learning, client config |
| Entire VLAN gets no leases | Shared VLAN/DHCP dependency | VLAN path, SVI/relay, scope state |
| Other VLANs receive leases | Server may be broadly available | Compare failing VLAN's relay/scope/path |
Swipe horizontally to see the full table.
For scope-specific failures, continue with DHCP Scope Exhaustion.
VLANs create useful boundaries, but the Layer 3 crossing policy determines permitted access
Separating guests, students, staff, servers, IoT devices, and management systems can reduce shared Layer 2 exposure and create clean control points. But a VLAN ID is not an access-control rule. If every inter-VLAN flow is freely routed, the design does not provide least-privilege isolation simply because multiple VLANs exist.
A stronger design states the requirement first—for example, “Student VLAN may reach the learning server on HTTPS but not the management VLAN”—then configures and verifies policy at the crossing path.
Do not confuse a smaller broadcast domain with a complete security boundary
VLAN segmentation can contain Layer 2 broadcast traffic and separate logical groups. Security, however, also depends on what traffic is allowed to cross at Layer 3, how management access is protected, and whether trunk/access configurations preserve the intended segmentation.
Link is up, but the student receives an address from the staff network
A student laptop on Gi1/0/7 should be in VLAN 10 but receives addressing associated with VLAN 20. The physical link is healthy, so replacing the cable is weakly justified. Inspect the access VLAN and MAC-table VLAN context. If Gi1/0/7 is configured for VLAN 20, the observed address behavior now has a mechanism: the client's broadcasts entered the staff broadcast domain.
Repair: restore the intended access VLAN. Verify: renew addressing, confirm the expected VLAN/MAC context, reach the intended gateway, and test the required student service.
Only VLAN 20 fails between two switches
VLAN 10 and VLAN 30 users communicate across the same uplink, while VLAN 20 users cannot. Shared-link success for two VLANs is evidence against a total physical-uplink failure. Compare VLAN 20's allowed-list and VLAN presence/state at both ends.
If the operational/configuration artifact shows VLAN 20 omitted while 10 and 30 are allowed, correct that specific difference. Then verify VLAN 20 end-to-end without assuming that success automatically proves inter-VLAN routing.
Same-VLAN traffic works, but cross-VLAN access fails
A VLAN 10 workstation reaches another VLAN 10 workstation and its 10.10.10.1 gateway, but cannot reach a required VLAN 20 server. Those successful tests preserve useful evidence: local attachment and the tested gateway path work. Next inspect the route, Layer 3 policy, destination VLAN path, and return path.
Changing the access VLAN at this point could destroy a known-good condition. Troubleshooting should move forward from the strongest evidence, not restart from the first OSI layer after every failed test.
Correct VLAN and DHCP lease, but DNS/application access fails
A host is learned in the expected VLAN, receives the intended subnet and gateway, and can reach a remote numeric IP. That evidence pushes the unresolved dependency beyond basic VLAN membership. Investigate DNS or the exact application path rather than changing trunks because “networking is broken.”
This case matters because VLAN troubleshooting also requires knowing when to stop blaming the VLAN.
Inter-VLAN routing works, but a forbidden management flow also works
Required staff-to-server traffic succeeds, but a student host can also initiate management access that policy says should be denied. Connectivity is not the only success criterion. The routing path works; the security requirement does not.
The next artifact is the Layer 3 ACL/firewall policy. Make the narrowest justified policy correction, then perform both a positive test for required traffic and a negative test for prohibited student-to-management traffic.
Use the scope of failure to distinguish VLAN-specific from shared failures
| Failure pattern | What becomes more plausible | Discriminating evidence |
|---|---|---|
| One endpoint affected | Access port, endpoint IP, local attachment | Port VLAN, MAC entry, IP/prefix |
| One VLAN affected on one switch | VLAN-specific local configuration | VLAN existence/state, access assignments |
| One VLAN affected across an uplink | Allowed-list/tagging/VLAN carriage | Both trunk ends and VLAN-specific state |
| All VLANs across uplink fail | Shared trunk/link dependency | Link state, trunk mode, shared path |
| Local VLAN works; remote VLAN fails | Gateway/routing/policy/return path | Gateway test, routes, ACLs, destination |
| IP path works; hostname fails | DNS resolution path | Resolver config and lookup result |
Swipe horizontally to see the full diagnostic table.
What common VLAN artifacts prove—and what they do not
| Evidence | Supports | Does not prove |
|---|---|---|
| Port shows link up | Physical/link attachment condition | Correct access VLAN |
| MAC learned in VLAN 10 | Source learned in that VLAN context | Correct IP, DHCP, gateway |
| VLAN 10 allowed on trunk | Configured carriage condition | Complete end-to-end VLAN path |
| Correct DHCP lease | Tested addressing service path succeeded | Every routed service works |
| Gateway reachable | Tested host-to-gateway path works | Remote route/policy/application |
Swipe horizontally to see the full evidence table.
Seven VLAN claims that are too broad
- “Same switch means same LAN.” VLANs can logically separate ports on the same hardware.
- “Link up means the VLAN is right.” Physical and logical membership are different evidence.
- “A trunk joins VLANs together.” It carries multiple distinct VLANs.
- “VLAN allowed means VLAN works end to end.” It proves only part of the path.
- “Different VLANs can communicate because they share a switch.” They need Layer 3 forwarding when separated into different IP networks.
- “VLANs are a firewall.” They create segmentation boundaries, not a complete permitted-flow policy.
- “Every connectivity problem on a VLAN is a VLAN problem.” DHCP, routing, DNS, security policy, and applications can fail after VLAN membership is correct.
Turn VLAN evidence into a bounded technical claim
Observation: state exactly what works and fails.
Scope: one host, one VLAN, one trunk, or all VLANs?
Artifact: cite access VLAN, MAC table, trunk list, SVI, DHCP result, route, or policy.
Mechanism: explain how the artifact could create the observed failure.
Boundary: say what the artifact does not yet prove.
Next evidence: choose the test that separates remaining causes.
Verification: repeat the required flow and preserve intended isolation.
24 VLAN digital flashcards
Practice access ports, trunks, 802.1Q, native VLANs, ARP scope, gateways, DHCP, security, evidence boundaries, and troubleshooting. Before revealing each answer, state what artifact you would inspect to prove your claim.
Connect VLAN membership to switching, routing, and troubleshooting
Read the evidence. Make a decision. Check your reasoning.
Use these connected resources to move from an explanation to a real networking decision.