skip to content

On an IEEE 802.1Q trunk, how are native-VLAN frames and the allowed-VLAN list handled, and what breaks when the two ends disagree?

level: middleimportance: should knowfreq 32%

answer

  1. one VLAN may cross bare
  2. untagged in means the port's own VLAN
  3. the frame never says where it came from
  4. membership decides what crosses at all

basics

~20 s

Native-VLAN frames cross an 802.1Q trunk untagged, and the receiver files any untagged frame into its own native VLAN; the allowed list decides which VLANs cross at all. A native mismatch silently joins two VLANs; an allowed-list mismatch cuts one off.

solid answer

~50 s

"Native VLAN" is the industry name for 802.1Q's **PVID** on a trunk combined with **untagged egress** for that VLAN: the sender transmits that VLAN's frames with no tag, and the receiver assigns every untagged or priority-tagged frame arriving on the port to **its own** PVID. Nothing in an untagged frame records its origin, so if switch A's native VLAN is 10 and switch B's is 20, A's VLAN 10 and B's VLAN 20 become one broadcast domain across that link, and neither VLAN works end to end across it; 802.1Q itself raises no error. The **allowed-VLAN list** is the trunk's VLAN membership: a frame for a VLAN outside it is not transmitted, and with ingress filtering a tagged frame for a non-member VLAN is dropped on arrival. If only one end allows VLAN 30, VLAN 30 is silently cut between the switches while every other VLAN works.

go deeper

for a junior

Remember that one VLAN, the native VLAN, crosses a trunk untagged, and that a trunk carries only the VLANs on its allowed list.

for a middle

Explain classification: an untagged arrival goes into the receiving port's PVID, so mismatched native VLANs merge two VLANs, and a VLAN missing from one end's allowed list is cut silently.

for a senior

Diagnose the half-working trunk: one direction of one VLAN broken, DHCP leases from the wrong scope, MACs learned in an unexpected VLAN, and fix it by aligning both ends.

for a principal

Set the trunk standard for the estate: an unused native VLAN or tagged native traffic, explicit allowed lists, and change procedures that edit both ends of a link together.

## Native VLAN is the trunk's PVID IEEE 802.1Q never uses the phrase "native VLAN"; the industry does. The standard's terms, restated in the Q-BRIDGE MIB (RFC 4363), are: - **PVID** (port VLAN ID): "the VLAN-ID assigned to untagged frames or Priority-Tagged frames received on this port". Its default is **1**. - **Untagged set**: for each VLAN, the ports that transmit that VLAN's frames **without** a tag. By default VLAN 1 is untagged on every port. - **Acceptable frame types**: a port either admits all frames or admits only VLAN-tagged frames, discarding untagged and priority-tagged ones. A trunk's native VLAN is simply the VLAN that is the trunk port's PVID and is also in that port's untagged set: it leaves untagged, and anything arriving untagged is put into it. Out of the box both are VLAN 1, which is why VLAN 1 is the native VLAN on so many trunks. ## How an untagged frame is classified 1. A frame arrives on a trunk port. 2. If it carries an 802.1Q tag with a non-zero VLAN ID, that VID decides its VLAN. 3. If it is untagged, or priority-tagged with VID 0, the switch assigns it to the **receiving** port's PVID. 4. The sender's idea of which VLAN the frame belonged to is lost; only the receiver's configuration counts. ## The native VLAN mismatch Take the three-department office: Finance is VLAN 10, Engineering VLAN 20, Guests VLAN 30, and switches A and B share one trunk. A technician sets the trunk's native VLAN to 10 on A and to 20 on B. | Traffic | Sent by | On the wire | Classified by the receiver as | |---|---|---|---| | Finance frames | A | untagged (A's native) | VLAN 20 on B | | Engineering frames | A | tagged VID 20 | VLAN 20 on B, correct | | Engineering frames | B | untagged (B's native) | VLAN 10 on A | | Finance frames | B | tagged VID 10 | VLAN 10 on A, correct | The result is confusing because it is half-broken: - Finance on A and Engineering on B now share one broadcast domain across the link. Broadcasts, ARP requests and DHCP discovers from each reach the other department. - Neither VLAN works end to end: Finance traffic from A never reaches Finance hosts on B, and Engineering traffic from B never reaches Engineering hosts on A. - Hosts can be handed an address from the other department's DHCP scope, so the fault shows up as "wrong subnet" or "intermittent" rather than "link down". - 802.1Q carries no field that would let the receiver notice; the link stays up. Some implementations detect the mismatch through their own control protocols and log a warning, but that is a product feature, not part of the standard. ## The allowed-VLAN list "Allowed VLANs" is the implementation term for the trunk port's **VLAN membership**: the set of VLANs whose member set includes this port. - On **egress**, the switch only transmits frames of VLANs the port is a member of. A frame for VLAN 30 that is not on the list never leaves through that trunk, whether it is broadcast or unicast. - On **ingress**, when ingress filtering is enabled, the switch discards a tagged frame for a VLAN the port is not a member of, so the far end cannot inject a VLAN the trunk was not meant to carry. - Pruning the list to the VLANs actually needed on each trunk also shrinks the area over which broadcasts and unknown-unicast floods travel. ## When the allowed lists disagree If A allows VLANs 10, 20 and 30 and B allows only 10 and 20, then: - Guests (VLAN 30) on A cannot reach Guests on B, or their gateway if it sits beyond B, while Finance and Engineering work perfectly. - The failure is silent: no error frame exists, the trunk is up, and only one VLAN is missing. - The usual cause is an edit applied to one side of the link only, for example a "replace the list" change that dropped an ID instead of adding one. ## Good practice that follows from the mechanism - Configure the **same native VLAN on both ends** of every trunk, and check it as part of the link's acceptance test. - Make the native VLAN a VLAN that **no access port uses**, so that untagged traffic on the trunk carries nothing of value and cannot be reached from a desk. - Where the implementation supports it, **tag the native VLAN too** or set the trunk to admit only tagged frames, so no frame crosses untagged at all. - Keep allowed lists explicit and identical on both ends, and add or remove VLANs rather than replacing the whole list.

  • Why is VLAN 1 the native VLAN on so many trunks?
    Because it is the default. 802.1Q makes 1 the default PVID of every port, and by default VLAN 1 is transmitted untagged on all ports, so a trunk left unconfigured sends VLAN 1 untagged and files untagged arrivals into VLAN 1. Hardening usually moves the native VLAN to an unused ID.
  • If you set a trunk to admit only tagged frames, what happens to the native VLAN?
    Untagged and priority-tagged frames arriving on that port are discarded, so nothing can enter the switch untagged through it. Both ends must then tag every VLAN, including the one previously sent untagged; if the far end keeps sending its native VLAN untagged, that VLAN's traffic is dropped.
  • How would you spot a native VLAN mismatch from its symptoms alone?
    Look for one VLAN broken in one direction across a single trunk while others work, hosts receiving addresses or broadcasts from another department's subnet, and MAC addresses from one VLAN learned in a different VLAN on the far switch. Comparing the PVID and untagged settings on both ends confirms it.

saying these in an interview costs you the question

  • Native VLAN frames cross the trunk with an 802.1Q tag carrying VLAN ID 0.
  • 802.1Q refuses to bring up a trunk whose ends disagree on the native VLAN.
  • The allowed-VLAN list only filters broadcasts, not unicast frames.
  • A trunk always drops untagged frames.
  • Removing a VLAN from a trunk's allowed list deletes that VLAN from the switch.