Articles

VLAN Interview Questions: Trunks, Native VLANs, and One-Way Connectivity

Practice VLAN interview questions with a two-switch frame ledger, native VLAN mismatch, STP blocking, trunk eligibility, and layered connectivity checks.

VLAN interview questions often start with two hosts that should communicate and a trunk that appears to be up. The useful answer follows a frame through ingress classification, trunk tagging, receive classification and forwarding eligibility. A matching VLAN number in a diagram does not prove that every device assigns the frame to that VLAN.

Work through the original two-switch ledger below before changing configuration. For related diagnostic practice, use Does a Successful Ping Mean Port 443 Is Reachable? Diagnosing Server Connectivity to separate what a network observation proves from what remains unknown.

Official Cisco documentation supplies the scoped platform rules; the topology, frame ledger and troubleshooting exercises are original preparation material.

VLAN interview questions: access, trunk and native VLAN

A VLAN separates a Layer 2 broadcast domain within a switched network. On an ordinary static access port, an untagged host frame is assigned to the port's configured access VLAN. A trunk carries traffic for multiple VLANs over one link, using tagging and a declared policy for untagged traffic.

Cisco's Catalyst VLAN membership guide describes static access membership and trunk membership with an allowed-VLAN list. Keep the ordinary access-port example scoped: voice VLAN and other specialized features can add behavior beyond “one untagged host, one access VLAN.”

The native VLAN is the trunk's classification for untagged traffic under the default behavior described in the Catalyst trunk guide. Traffic belonging to that outgoing native VLAN is normally sent untagged; other VLAN traffic is tagged. Explicit native-tagging configuration can change this contract, so identify the actual platform and settings.

Native VLAN does not mean management VLAN, default gateway or “the VLAN allowed everywhere.” Those are separate configuration choices. Two ports can agree about which VLANs are allowed while disagreeing about the identity of an untagged frame.

What does an 802.1Q tag tell you?

Cisco's 802.1Q frame-format reference describes a four-byte tag containing a 12-bit VLAN identifier alongside priority-related fields. The VLAN identifier concerns Layer 2 membership; it is not an IPv4 prefix length or a host address.

For a tagged frame, inspect the actual VLAN ID and the receiver's admission rules. For an untagged frame, inspect the receiving port's configured classification. A frame does not carry a hidden “I was VLAN 10 on the previous switch” label once it crosses the link without a tag.

The identifier field's possible bit values should not be confused with ordinary configurable VLAN IDs. The cited Catalyst guides use IDs from 1 through 4094; reserved or priority-tagging values have distinct meanings. Do not infer that every possible 12-bit value is a normal user VLAN.

Also distinguish a switch's internal VLAN association from the bytes seen by a capture tool. A mirror destination, NIC offload or capture location can affect whether you observe a tag. An untagged capture on the host access link does not establish that the same frame crossed the inter-switch trunk untagged.

Trace the original two-switch mismatch

Host A connects to an access port in VLAN 10 on switch A. Host B connects to an access port in VLAN 10 on switch B. The inter-switch link is a trunk at both ends. A's native VLAN is 10; B's native VLAN is 20. Both VLANs exist and are allowed on both sides.

For this abstract classification exercise, assume the relevant VLANs are forwarding, native traffic is sent untagged, and a received tag of 10 is accepted as VLAN 10 even where 10 is native. These are explicit model assumptions, not a prediction that every physical switch will forward this misconfiguration. Check tagged-native admission on the actual implementation.

Direction and originating VLAN	Wire encoding in this model	Receiving classification	Consequence
A to B, originating in VLAN 10	Untagged because A's native is 10	B assigns it to native VLAN 20	It does not belong to Host B's VLAN 10
B to A, originating in VLAN 10	Tagged 10 because B's native is 20	A accepts tag 10 as VLAN 10 under the stated assumption	It remains in Host A's VLAN 10

The asymmetry comes from applying each sender's egress policy and each receiver's ingress policy. The two switches do not negotiate a common meaning for an untagged frame simply because the link is physically up.

Now align B's native VLAN with A's at 10, while preserving the other assumptions. VLAN 10 frames cross untagged in both directions and both receivers classify them as 10. That repairs this classification mismatch. It does not prove that STP, filtering, host configuration or the application is healthy.

Why might real switches block instead of showing asymmetry?

Cisco's official PVID inconsistency troubleshooting guide explains how PVST+ can detect inconsistent VLAN information in BPDUs and place affected ports/VLANs into an inconsistent state that blocks traffic. That protection can invalidate the forwarding assumption in the previous ledger.

Consequently, “native mismatch causes one-way connectivity” is an incomplete answer. Native mismatch can produce misclassification, protection-triggered blocking, or a different symptom depending on topology, tagging policy and implementation. Inspect the observed STP state before predicting user traffic.

An original interview follow-up supplies an allowed list containing VLAN 10 but an STP output showing PVID_Inc. The decisive evidence is the blocked forwarding state. Adding VLAN 10 to the allowed list again does not resolve the inconsistent native configuration.

Explain the mismatch and restore a consistent intended design. Do not disable spanning tree to force the abstract ledger to appear on a production network. The model helps reason about classification; the device's protection state helps explain why a real frame may never traverse the modeled path.

Does one-way frame delivery mean one-way ping success?

No. A single frame reaching its destination is not a complete request-and-response exchange. An ICMP echo test needs the request and the reply to return. Neighbor discovery also needs the necessary resolution messages to reach the appropriate peer.

RFC 826 describes Ethernet address resolution through ARP requests and replies. In the original mismatch model, an ARP request originating in A's VLAN 10 becomes VLAN 20 at B. Host B's VLAN 10 cannot receive it through normal VLAN 10 forwarding. Starting the test from B does not solve the broken return direction.

Even with neighbor information already present, B's request may reach A while A's reply is misclassified at B. Both ping directions can therefore fail despite asymmetric individual frame classification. A stale neighbor cache may change the observed sequence without repairing the network.

To demonstrate the classification hypothesis, specify a one-direction test frame and observe its ingress and egress VLAN association. Do not call that a successful application session. Then separately test neighbor resolution, the complete bidirectional exchange, and the service protocol the user actually needs.

Allowed, active and forwarding are different checks

An allowed-VLAN list expresses which VLANs the trunk is configured to carry. The VLAN must also exist and be active where required, and the relevant forwarding state must permit the path. A port being up or operationally trunking is only part of that evidence.

Use the following original fault-isolation matrix after making the native configuration consistent. Change one variable at a time in a safe lab or an approved maintenance procedure; these are reasoning exercises, not instructions to alter a live customer's network.

Changed condition	Expected diagnostic focus	Evidence that separates it from native mismatch
VLAN 10 removed from one trunk's allowed list	Administrative eligibility	Compare both ends' effective allowed lists
VLAN 10 absent on one switch	Local VLAN availability	Check that switch's VLAN database and port membership
VLAN 10 blocked by STP on the selected path	Forwarding eligibility	Inspect the VLAN's port role/state and inconsistencies
Host B moved to access VLAN 20	Host ingress/egress membership	Verify the actual host-facing port, not its description
Native-tagging policy differs between ends	Wire-format and admission contract	Observe tagged/untagged traffic and inspect both policies

Do not assume every failure in the table produces the same directional symptom. Record where the frame first stops matching the intended contract. That gives you a falsifiable diagnosis instead of a list of unrelated commands.

Which commands would you use, and what do they prove?

For a Catalyst IOS XE discussion, an illustrative read-only starting set is:

show interfaces trunk
show interfaces GigabitEthernet1/0/1 switchport
show vlan brief
show spanning-tree vlan 10
show spanning-tree inconsistentports
show mac address-table vlan 10

These are scoped examples, not universal switch syntax. Check the device's release documentation. The Catalyst command reference and the linked troubleshooting guide establish the relevant configuration and diagnostic concepts. No physical-switch execution is claimed here.

Read operational trunk mode alongside administrative settings. A requested trunk mode and an actual trunk are not interchangeable evidence. Compare the native VLAN and relevant allowed list at both ends, then verify the VLAN's local existence and STP forwarding state.

MAC learning can help locate the path, but interpret its VLAN association. In an original observation, A's source MAC appears under VLAN 20 at B. That supports a classification problem when it matches the expected capture and port path; it does not establish an IP routing failure by itself.

Keep timestamps and port identities with the outputs. A MAC learned ten minutes ago on another port is weak evidence for the current test. Check whether the inspected interface is a port-channel or an individual member before drawing conclusions from only one physical port.

How do VLANs differ from subnets and routing?

VLAN membership defines Layer 2 separation. An IP subnet defines address membership and helps a host decide whether to contact a destination locally or use a gateway. Choosing the same IP prefix on two isolated VLANs does not merge their broadcast domains.

Cisco's inter-VLAN routing guide shows a routing device and switch virtual interfaces providing communication between VLANs. Allowing VLANs 10 and 20 on a trunk carries both domains; it does not itself route packets between them.

In an original extension, assign Host B intentionally to VLAN 20 with a separate IP subnet. Now successful communication requires the correct host gateway, an available routing interface, forward and return routes, and applicable policy. The native-VLAN ledger alone cannot answer that Layer 3 question.

Separate three observations: same-VLAN local communication, reachability to the appropriate gateway, and communication across VLANs. If local peers work but cross-VLAN traffic fails, investigate the routing boundary without assuming every trunk is defective. If the gateway cannot resolve the host, revisit membership and neighbor reachability first.

Explain a repair with a measurable expected result

A useful interview answer names the proposed change and predicts what should change in the evidence. For the original mismatch, align the intended native classification at both ends, preserving the required VLAN list and tagging policy. Anticipate that affected inconsistency states and frame classification should converge, then observe them.

Repeat the same test from the same source, destination and protocol. Verify both directions and the service behavior, rather than declaring success from a link light or one learned MAC. If the predicted classification is repaired but the application still fails, move to the next contract with the evidence already collected.

State rollback and management-access implications before a real change. A native or allowed-list edit on the path carrying your management session can interrupt the session itself. Prefer an appropriate alternate access path and a scoped change; do not turn troubleshooting into a broad “allow everything” experiment.

Sources and Further Reading

Sources checked October 4, 2026. Verify tagging admission, STP behavior and command syntax on the actual switch model and release.