Hi, do somebody knows why wireshark displays VLAN tags separate? I mean according to standard the VLAN tag is inserted in the middle of the ethernet frame header. Check link below. But wireshark display the capture as it was separate "header" or "layer" in the captured protocol stack. Every answer appreciated. https://ciscohite.files.wordpress.com/2013/05/802.png https://www.cloudshark.org/captures/008c321f16ab asked 28 Oct '16, 10:16  4GOD |
One Answer:
First of all, the picture you refer to is confusing. Actually, all Ethernet frames contain the same header consisting of the destination MAC address, the source MAC address, and the ethertype value indicating the payload type. The rest of the frame is the payload, e.g. an IP protocol if the Ethertype is 0x800, followed by an FCS at the very end. The structure of a "VLAN" Ethernet frame is exactly the same like one of a "plain" Ethernet frame, but the ethertype value of 0x8100 in the Ethernet header indicates that the payload of such Ethernet frame is a VLAN frame. The header part of the VLAN frame begins with the 3 bits of priority, 1 bit of CFI, and the 12 bits of VLAN ID, and continues with another ethertype value which denotes the payload of the VLAN frame. This nesting may even repeat several times if "Q in Q" is used (i.e. a payload of a VLAN frame may be another VLAN frame). So from this perspective, the way the dissection tree is displayed is perfectly logical, because the VLAN header actually follows the Ethernet header, it isn't "in the middle of it", much like the IP header follows the VLAN header, and like the UDP header follows the IP header. The only thing which may seem weird is that if the FCS of the Ethernet frame is present in the capture, Wireshark displays it as part of dissection of the Ethernet header although physically it is located after all the layers of payload. The reason is that the FCS is logically related to the Ethernet layer of the frame despite its physical location. answered 28 Oct '16, 13:50  sindy edited 29 Oct '16, 03:00  Jaap ♦ |
Thank you very much for your response. That would make absolutely sense, just the picture I post seems to be right. Check these two sources: Wikipedia https://en.wikipedia.org/wiki/IEEE_802.1Q "802.1Q does not encapsulate the original frame. Instead, for Ethernet frames, it adds a 32-bit field between the source MAC address and the EtherType/length fields of the original frame" Cisco http://www.cisco.com/c/en/us/support/docs/lan-switching/8021q/17056-741-4.html "EEE 802.1Q uses an internal tagging mechanism which inserts a 4-byte tag field in the original Ethernet frame itself between the Source Address and Type/Length fields."
I found this also on other sources. The Vlan TAG is inserted into the ethernet frame header, at least thats what all the documentation, articles says. Thanks
If an answer has solved your issue, please accept the answer for the benefit of other users by clicking the checkmark icon next to the answer. Please read the FAQ for more information.
Maybe I was too strict. The picture is definitely correct in terms that it gives the correct order of the individual fields. The rest is maybe more a matter of perspective - the "encapsulation" one as described above is more useful for some purposes (like packet analysis starting already from composition of capture filters), the "insertion" one is more useful for other ones, like understanding of the physical tagging and un-tagging of the frames at a switch port. This might explain why Cisco describes it using the "insertion" perspective - at ingress, i.e. when a switch internally using VLANs receives an untagged packet from a wire, it really inserts the four octets of the VLAN tag between the last octet of the source MAC address and the first octet of the original ethertype, and vice versa on egress, untagging simply means that these four bytes are skipped when sending the data out. The FCS is calculated for data actually received or sent over the wire.
The statement on Wikipedia saying "802.1Q does not encapsulate the original frame" is definitely correct - if the original frame would be encapsulated, the VLAN header would have to be prefixed to it, which it clearly isn't. There were good reasons to do it that way - first of all, even switches which have no clue about existence of 802.1Q can transit its frames transparently (if they handle the size of course).
The main problem comes from the other uses of VLAN tagging. It is being used in combination with several other protocols where it is not included in some other header. This gave a series of bug reports when the VLAN dissector was included in the Ethernet dissector and represented the VLAN information as you described. Therefore that change was rolled back and we've settled on this representation since.
Thank you guys, now I got it :-)