29

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

netvope
  • 2,113
  • 5
  • 25
  • 35

3 Answers3

15

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.

Shane Madden
  • 112,982
  • 12
  • 174
  • 248
Zoredache
  • 128,755
  • 40
  • 271
  • 413
  • 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 05 '15 at 06:55
14

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.

pfo
  • 5,630
  • 23
  • 36
  • Could you elaborate what large ethernet frames have to do with 802.1Q VLAN tagging? – Martijn Heemels Nov 22 '11 at 21:46
  • Are you saying the tag would make the frame too large? – Shane Madden Nov 22 '11 at 21:47
  • 6
    @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 '11 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. – Evan Anderson Nov 22 '11 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 '11 at 22:06
  • @sysadmin1138 Sure, it just didn't make sense in the context of the question; "what will a switch do with a **tagged** frame" answered with "a switch will drop a **too-large** frame" seems a little out a left field; my prompting was to try to lead this answer back to the question, as it seemed like he was answering a completely different question. It's a great anecdotal caveat to mention as a footnote to an answer, but it doesn't answer the question, except in a network where every single frame is right at the MTU limit (and plenty of consumer switches have jumbo support). – Shane Madden Nov 22 '11 at 23:11
6

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.

dkaragasidis
  • 745
  • 4
  • 11
  • Eh. Linux end-point devices handle tagged frames just fine. I have seen them do it. – Zan Lynx Nov 23 '11 at 07: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. – dkaragasidis Nov 23 '11 at 09:06
  • FCS = fast circuit switching? What determines whether "the FCS is OK"? – netvope Nov 23 '11 at 23:43
  • 2
    @netvope: FCS - Frame check sequence: http://en.wikipedia.org/wiki/Frame_check_sequence – Evan Anderson Nov 24 '11 at 00: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 05 '15 at 06:50