3

If 802.1q is created Ethertype field is changed to 0x8100 which means what it means - it is a 802.1q frame.

But this means Ethertype is no longer used for marking higher level protocol, for example, 0x0800 for IPv4.

What are the consequences of losing IPv4 marked Ethertype field and having 802.1q marked frame? Assuming L3 protocol hasn't changed.

Thank you.

2 Answers 2

3

The consequences are that the receiving end of the frame has to know what a 0x8100 is. If it doesn't recognize that frame type, it wont be able to receive it. Most versions of Windows can't handle tagged frames (without 3rd party software). Most *nix systems can, though they usually require special configuration.

Layers below L3 wouldn't care: network equipment like a simple L2 Switch wouldn't treat the packet any differently. It's worth noting that 802.1Q isn't the first protocol to use a different EtherType from IPv4. There's a dozen or so EtherTypes that you'll find in relatively common usage around networks.

6
  • Thank you, but Ethertype with 0x8100 value carries Layer 2 information as 802.1q is related to Layer 2 and it has no interaction with higher layers and protocols. But Ethertype value 0x0800 stands for IPv4 which marks Layer 3 protocol, so it's already going layer higher. If we're adding that 802.1q information in Ethertype, we're losing information about IPv4. If device is interested in Layer 3 protocol and is looking at Ethertype for information about that, why should Ethertype used for VLAN which belongs to Layer 2?
    – Vieplis
    Feb 21, 2013 at 14:24
  • 2
    The information might be in the Layer 2 portion of the packet, but it's only relevant to L3 operations. L2 devices plain don't care what's in that field (unless they have some strange filtering going on; which would be possible, but I've never seen such a thing). L3 devices are expected to either understand the EtherType or ignore the packet, that simple. It a device is looking for an IPv4 packet but doesn't understand EtherType 0x8100 then it will not be able to read that packet. This is the normal and desired operation of Ethernet.
    – Chris S
    Feb 21, 2013 at 14:28
  • Ok, that's fine if device doesn't know how to handle VLAN tags and discards the packet. Sorry, I guess I can't get a grasp of something really basic, but if Ethertype contains IPv4 0x800 marking, device knows which stack should process it by looking only at this field. But if Ethertype contains 802.1q 0x8100 marking and device handles VLAN tags just fine, how does the device still know what's Layer 3 protocol and how to process it? In one case Ethertype says it (0x0800), but in other it says completely different information (0x8100).
    – Vieplis
    Feb 21, 2013 at 14:38
  • 2
    If a packet comes in with 0x8100 the stack hands the packet to the part that processes 802.1Q tags. Once that is done the packet is "resubmitted" to the network stack to be processed again. With the vLAN information stripped off the network stack now sees a 0x8000 packet, or whatever type it is, and hands the packets to the L3 system which processes it - and so on for the other layers.
    – Chris S
    Feb 21, 2013 at 14:53
  • According to what you've said: "L2 devices plain don't care what's in that field", so L2 switch is not looking at Ethertype field although it is relevant for making forwarding decision? Or it looks at Ethertype which is 0x8100 and knows there's a 802.1q tag present, so switch takes that into account, but it simply doesn't care anything about L3. Is this correct? But if router receives such a packet, it reads Ethertype and handles 802.1q because of 0x8100 value in it. Next step is taking care of Layer 3 stuff, but where does he get information about L3 protocol? Sorry for confusion. :)
    – Vieplis
    Feb 21, 2013 at 15:19
2

When a plain Ethernet frame is transformed into 802.1Q-tagged frame the original Ethertype field does not get overwritten. Your original presumption -- that when "802.1q is created Ethertype field is changed to 0x8100" -- is incorrect.

The 802.1Q standard uses tags to mutate the original frame. When a plain Ethernet frame is transformed into 802.1Q a special 32-bit field (tag) is inserted between the source MAC address and the original Ethertype field. So the original Ethertype field is not lost but is shifted right by 32-bits of the 802.1Q tag.

And the 802.1Q tag is formatted in such a way that its first 16-bit field carries the same type of information as the original Ethernet Ethertype field. Though it is actually called TPID (Tag protocol identifier) field. This field is located at the exact same position as the Ethertype field in plain Ethernet frames, and is thus used to distinguish the frame from untagged frames. So when an interested party parses the Ethernet frame header and stumbles upon 0x8100 value in the supposedly Ethertype field it knows that this isn't actually the Ethertype field, but rather an 802.1Q's TPID field of the 802.1Q-tagged frame. And to get to the actual Ethertype value the parser will need to ignore the just read 16-bit field and the following 16-bits (32-bits total of the 802.1Q tag).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.