Suppose you connect a trunk port from a VLAN capable network switch to a (VLAN incapable) consumer-grade network switch via a direct cable. Now the former switch send the later switch a 802.1Q-tagged Ethernet frame. What should the later switch do? Drop the frame? Forward the frame? Undefined behavior?

If the behavior is undefined, what is most probable?

Edit: Thank you for your answers. To summarize, the behavior of the consumer switch depends on:

  1. How it handles frames with 0x8100 in the EtherType field1
  2. How it handles jumbo frames, or frames with payload larger than 1500 bytes

Wikipedia has a nice diagram comparing an untagged and a tagged Ethernet frame:

Ethernet Frame

There are reports that some consumer-grade switches pass VLAN-tagged frames just fine.

1 or more precisely, where an EtherType field is expected for non-tagged frames

  • 1
    I hope you arent asking in hopes of using said consumer switch in a production rack somewhere... Nov 24, 2011 at 5:09

3 Answers 3


I have actually seen this on a cheapo-switch. Someone had connected a switch between a trunk port which had a couple vlans. The frames were forwarded with the vlan tagging intact. The other ports on that switch where able to use the un-tagged vlan.

A switch only needs the source/destination mac to decide which ports to forward the frames to, so this isn't too surprising, a tagged frame still has the source and destination macs, in the same location in the frame header.

Keep in mind that Ethernet actually supports many different frame-types on the same wire. It was designed to be pretty flexible about what it can do.

  • If the switch doesn't know the Ether Type used for tagged frames, it is going to process it as if it was a normal Ether Type. That will mostly work, but it can fail in complicated setups where destination port depends on both MAC and tag. For example if you install a bridging firewall between two tagged VLANs, the switch with no VLAN support could send some packets in the wrong direction. Other than that an obvious problem that can happen is packets getting dropped because they exceed the maximum size of untagged frames.
    – kasperd
    Jun 5, 2015 at 6:55

Usually overly large ethernet frames can be and are discarded. In the presence of things like jumbo sized frames large ethernet frames are hard to define, so it really depends - but discarding will be probably the most frequent behavior encountered.

edit: To elaborate: Standard IEEE 802.3 Ethernet frame size is 1518 bytes, 802.3Q adds 4 bytes to the frame so has a total MTU of 1522 bytes which might be too large for some switches.

  • Could you elaborate what large ethernet frames have to do with 802.1Q VLAN tagging? Nov 22, 2011 at 21:46
  • Are you saying the tag would make the frame too large? Nov 22, 2011 at 21:47
  • 7
    @ShaneMadden Some 802.1q implementations bump the effective MTU up to 1522b for tagged frames, which will be dropped by switches with only a 1500b MTU.
    – sysadmin1138
    Nov 22, 2011 at 22:05
  • 3
    +1 for sysadmin1138 and +1 for pfo: Some old switches will discard tagged frames because 802.1q increased the Ethernet MTU. Nov 22, 2011 at 22:06
  • VLAN tagging increases the maximum frame size by 4 bytes so it's larger than 1518 bytes and is by definition a "jumbo" frame.
    – pfo
    Nov 22, 2011 at 22:06

The consumer-class switch will attempt to forward the frame -destination MAC address is all it cares about. If the destination MAC address is not in its CAM table, it will flood the frame out of all its ports, except the one the packet was received from.

A switch that uses Cut Through forwarding method will definitely forward the frame, since it begins forwarding as soon as the destination MAC address is read -even if the total size of the frame is greater that the MTU -since it can't calculate the size of the frame with this forwarding method.

A switch based on Store And Forward technique will probably (as long as the frame size is <= MTU) do the same, as long as the FCS is OKAY.

If the 802.1Q-incapable switch interconnects end devices, the devices will receive the frame and discard it, since they don't "know" how to process 802.1Q (type 0x8100) frames.

I speculate if the consumer-class switch interconnects 802.1Q capable switches (the horror!), the frames will be forwarded and processed by the 802.1Q -as long, of course, as they're received on trunk ports.

  • Eh. Linux end-point devices handle tagged frames just fine. I have seen them do it.
    – Zan Lynx
    Nov 23, 2011 at 7:55
  • 1
    @ZanLynx True. Though end-point devices are not supposed to handle tagged frames -you miss the whole point of VLANs by configuring end-point devices to receive and handle 802.1q frames. Nov 23, 2011 at 9:06
  • FCS = fast circuit switching? What determines whether "the FCS is OK"?
    – netvope
    Nov 23, 2011 at 23:43
  • 2
    @netvope: FCS - Frame check sequence: en.wikipedia.org/wiki/Frame_check_sequence Nov 24, 2011 at 0:24
  • 1
    @dkaragasidis There are perfectly valid reasons to configure some hosts to use tagged frames. But one better ensure that VLAN tagging is disabled on ports facing hosts you do not want to use tagged frames. Reasons for using tagged frames on a Linux host includes one acting as a router between VLANs or a server which need to be reachable from clients on different VLANs.
    – kasperd
    Jun 5, 2015 at 6:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .