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.

Vieplis
  • 43
  • 1
  • 7

2 Answers2

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.

Chris S
  • 77,337
  • 11
  • 120
  • 212
  • 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 '13 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 '13 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 '13 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 '13 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 '13 at 15:19
  • An L2 Switch wouldn't look at the EtherType (unless it was doing filtering or something similar). It's not relevant to the forwarding decision. The part of the network stack that handles the 802.1Q vLAN tag doesn't care what kind of payload is in the packet. If a router receives a packet with 0x8100 EtherType and vLAN tag, with a 0x8000 inside that, it does not look at the 0x8000 part initially, and does not make decisions based on that. It takes the 0x8100 tagged packet and hands it to the vLAN processing. Once the tag is stripped the packet is reprocessed, which is now a 0x8000 packet. – Chris S Feb 21 '13 at 15:24
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).

golem
  • 327
  • 1
  • 3
  • 11