Going through my CCIE studies, I wanted go deeper into the Ethernet standards and their usage. I've put together following notes on the most important facts surrounding these topics. Hope you'd find this helpful :)
What are we trying to do with Ethernet?
So the whole goal of a Layer 2 protocol should be to provide some means of identifying the start of the incoming frame (could also be considered as Layer 1 function) while providing some form of an indication as to what type of payload (Layer3 process) it carries through and some defined criteria to identify and accommodate the communication between endpoints with in a segment.
In order to facilitate these requirements, over the years, following Ethernet types/standards have been defined.
- Ethernet II (also called DIX)
- IEEE 802.3 (also referred to as IEEE 802.3 LLC)
- IEEE 802.3 SNAP
- Ethernet - Raw
Let's take a look at each Ethernet standard and discuss the importance of each standard.
Ethernet II (DIX)
Ethernet II came first and this frame format was introduced by the three vendors, Digital Equipment Corp., Intel, and Xerox (hence the name "DIX") as a result of a joint research carried out in the beginning. This is the simplest form of all Ethernet standards and the most commonly used one today- probably due to its simplicity and because it was there from the beginning.
Now let's take a closer look at how the frame is structured.
It uses its first 8 bytes (Preamble) to indicate the start of frame by arranging the first 62 bits as alternating "1/0s" and the last two bits as "1"s. Like so,
010101010101010...........................10101011
So when the receiving end sees the "11" it knows where the actual Ethernet header starts. The alternating 1s and 0s will also allow the two endpoints to sync their internal clocks. According to my research, the two end points generally sync up within the first 14 bit time window.
The Preamble function is the same for all Ethernet standards. So I'm not going to elaborate on this again for other Ethernet standards.
The next two octets are used to indicate the Destination and the Source MAC addresses and this is also the same for all Ethernet standards.
The "Type/Length" field is used to indicate the "Type"of the payload (= Layer 3 protocol) which is indicated as a Hexadecimal value. Now.. in the case of Ethernet II, this field is used only to indicate the Type whereas with other Ethernet standards (discussed later), This field is used to indicate the Length. We will later discuss how this field is used in a way so the Ethernet controller won't get confused trying to figure out if the value refers to a Type or a Length.
Let's look at some EtherType examples,
Some common EtherTypes:
- IPv4 : 0x0800
- ARP : 0x0806
- IPv6 : 0x86DD
- LLDP : 0x88CC
- FCOE : 0x8906
- 802.1Q : 0x8100
Note that all EtherTypes defined are always higher than the value 0x0600. This is not a coincidence, this is done on purpose, Why? keep on reading and you'll know..
Packet capture of an Ethernet II frame:
Below is a packet capture showing a real life example. This is for IPv4. Note the EtherType 0x0800
IEEE 802.3
IEEE 802.3 is basically the standardized, extended version to the Ethernet II.
So what was done here is, without defining the EtherType (or Layer3 Protocol ID) as a part of the MAC/physical layer, the functionality has been moved to a new upper sub layer protocol as defined in LLC (802.2). This is more of an effort to make the frame format comply with the 7 Layer OSI model (in which case the MAC/Ethernet fields are considered as part of Layer-1 and Layer-1 upper sub-layers)
LLC introduces a new way of defining the EtherType (Layer 3 Payload type) and also enables some additional capabilities like error correction and flow control at layer 2.
Lets first look at the Frame format first.
Expanded LLC/802.2 Format
As you can see, the previously used EtherType field is now solely used to indicate the "Length" of the Payload. Now.. if you think about it, we have a fundamental problem here... an Ethernet controller that supports both Ethernet II and IEEE 802.3 has to have some mechanism to distinguish between the two frame types (Ethernet II vs IEEE 802.3) just by inspecting the Length/Type field. But how ?
Well, easy... You make sure you assign all Layer 3 protocols with an EtherType number higher than 0x0600 which corresponds to the decimal value of 1536 which is greater than the maximum byte size of an Ethernet encapsulated payload. So with this rule, if the Type/Length field evaluates to a value less or equal to 1500, you can assure that it corresponds to a "Length" and thereby deciding that this is an IEEE 802.3 frame. If it is higher than 1500, it should be referring to an EtherType assignment so it's an Ethernet II frame (- and this is why all your EtherTypes have Hex values higher than 0x0600, So now you know...)
LLC introduces two fields, SSAP and DSAP basically referring to the Layer 3 protocol Types of the Source and Destination. In a more general case, for a given communication, the SSAP and DSAP addresses should contain the same value.. right? For example, if this is an IP communication, the source and the destination both will use IP as the Layer 3 protocol. The registered SAP address for IP protocol is 0x06, so in this case the numbers would be, SSAP = 0x06 and DSAP = 0x06.
It should be noted that in LLC, with the concept of SAP (Service Access Point), if you ever implemented two different Layer-3 protocols with different SAP IDs and architectured them in a such way so they can understand and interact with each other, LLC will facilitate the pathway for these two protocols to communicate - But there are very few protocols that behave this way. (I actually found pair of these during my research but totally forgot where it was.. :) I believe it's something to do with Token Ring - Maybe someone can point this out in the comment section
Some registered SAP assignments:
- 0x00 Null LSAP
- 0x06 ARPANET Internet Protocol (IP)
- 0x18 Texas Instruments
- 0x42 IEEE 802.1 Bridge Spanning Tree Protocol
- 0x7E ISO 8208 (X.25 over IEEE 802.2 Type 2 LLC)
- 0x80 Xerox Network Systems (XNS)
- 0x98 ARPANET Address Resolution Protocol (ARP)
- 0xAA SubNetwork Access Protocol (SNAP)
- 0xF0 IBM NetBIOS
- 0xE0 IPX
- 0xFF Global LSAP
- 0x43 STP (802.1D)/RSTP/MST
The Control field in LLC provides segment-to-segment flow and error
control capabilities at Layer 2 which is something almost never used in today's IP based communications as the same functionality is provided at Layer 4 by TCP or some Application specific mechanism. The only difference is that TCP does this as an end-to-end protocol sitting between the source and destination as opposed to the segment-to-segment controlling facilitated here with LLC.
LLC defines 2 flow types,
- Type1 - Connection-less unreliable
- Type2 - Connection oriented reliable
When LLC operates in Type1, this is called an Unnumbered Information (UI) Frame and the control field value is set to 0x03. You will see this value set in LLC header in almost all modern communications. (Check the packet captures provided below showing the control field value)
Note that, LLC is a standard on it's own and is not something specifically defined for Ethernet. It is intended to be used in conjunction with any OSI complaint communication system. So there's much more to this than what is explained here. If you need more information find some good information here:
http://standards.ieee.org/getieee802/download/802.2-1998.pdf
https://www.princeton.edu/~achaney/tmve/wiki100k/docs/IEEE_802.2.html
Note that the diagram above depicts an 8 Byte preamble, The IEEE 802.3 standard regards to this as 7 byte preamble + 1 byte SFD (Start of Frame Delimiter) to better represent its functioning. But technically nothing's changed. So nothing's new there. This is true for the IEEE 802.3 SNAP standard which we take a look at next.
Packet capture of an IEEE 802.3 frame:
Below is a packet capture showing a real life example. This is a BPDU frame of 802.1D. Note the DSAP,SSAP and the Length field assignments.
IEEE 802.3 SNAP
After the initial IEEE 802.3 release, IEEE soon realized that the 1 byte allocated for SAP assignment is not enough to accommodate future needs. So they basically came up with a clever 'hack' on the original IEEE 802.3 standard to facilitate more Layer 3 Payload types.
They introduced another header (or a protocol if you will) called SNAP (Sub-Network Access Protocol) and inserted it immediately after the LLC (802.2) header and assigned a new LLC/SAP address 0xAA for this new protocol. Let's have a closer look at the frame format and discuss the important aspects of it.
SNAP header is 5 Bytes long, 3 Bytes allocated for OUI (Organizational Unit Identifier/ Vendor ID) and 2 Bytes for the "SNAP Protocol ID" which is basically the Layer3 Payload type. Here, the "SNAP Protocol ID" is the same as the EtherType Address used in the Ethenet II standard. So there is no need to assign whole bunch of new addresses to be used as SNAP IDs and it also allows for 2byte long field for Payload Type definition - so problem solved.
This also allows the assignment of vendor specific protocol types. So any Vendor can simply come up with their own higher layer protocol and use it in conjunction with their registered OUI. For example, Cisco is registered with the OUI: 0x00000C and they have defined lots of protocols that can be used within the "IEEE 802.3 SNAP" for their own implementations.. Ever wonder how Cisco does some of the magical things they do.. well this is how it is done :) - See the Cisco's CDP SNAP header example above.
So how do you define standard protocol like IPv4 within IEEE 802.3 SNAP frame?
OK.. for all standard/NON-vendor specific Layer 3 Protocols, you simply set the OUI field with the value: 0x000000 and use the normal EtherType (as used in Ethernet II) as the SNAP Protocol ID.
For example, IPv4 will have the OUI: 0x000000 and SNAP: 0x0800 as seen in the diagram above.
Some Cisco's well known SNAP IDs:
- Cisco CDP : 0x2000
- Cisco VTP : 0x2003
- Cisco DTP : 0x2004
- Cisco PVSTP+ : 0x010B
Packet capture of an IEEE 802.3 SNAP frame:
Below is a packet capture showing a real life example. This is for BPDU of PVST+. Note the DSAP,SSAP assignments (0xaa) and OUI for Cisco (0x000003) and the SNAP PID of 0x010b which is specific to Cisco.
Ethernet Raw
Apart from all the Ethernet Types we talked about so far, there is yet another type that you might run in to. This is referred to as an "Ethernet Raw" type. What is it?
Well, early days (when there were no proper Ethernet standards) Novell Netware which was a very popular standard, used to encapsulate IPX protocol directly inside the Ethernet in the following form.
|Preamble|DMAC|SMAC|Length|IPX|FCS|
Now if you think about this, the IPX packet starts exactly where the DSAP field of the IEEE 802.3 field should be. So how would your device know whether the incoming frame is an 'Ethernet RAW' frame or an IEEE 802.3 ?. Well fortunately, the IPX header starts with a check-sum value (as defined in IPX protocol) which is almost never used and always set to the value 0xFFFF which can not be a valid DSAP address. So this avoids any conflictions.
I was able to get a packet capture of an "Ethernet Raw" as well.
Other things you might want to know about Ethernet..
Ethernet II is the most popular protocol. If you sniff a modern IP network, you'd see lots of Ethernet II frames. Basically all modern applications use Ethernet II. You may also see some IEEE 802.3 frames specially since STP/RSTP and MST all use this frame format. If you have Cisco's PVST+ or some vendor specific protocols running, you might see some 802.3 SNAP frames as well. So this means that a modern NIC or a Network device will have to support all these standards.
Although there is a SAP ID defined for IPv4 allowing it to be used directly inside IEEE 802.3, this is not recommended according to the
RFC-1042 and it is recommended to be used encapsulated in IEEE 802.3 SNAP frame. As a matter of fact, IPv6 doesn't even have a SAP ID defined, forcing us to use it with either the Ethernet II or IEEE 802.3 SNAP.
Ethernet has maximum and minimum frame sizes defined where "maximum" size is the standardized maximum frame size a vendor should support at a minimum - so if the vendor want's they can allow for larger frame size. No matter which Ethernet standard it is, if the incoming frame is less than 68 Bytes long the frame will be dropped. These frames are called Runts. If the frame is bigger than 1518 bytes, and the vendor supports only up to 1518 Bytes, the frame will be dropped as well. These are called Giant frames. Here the frame size is defined as |L2 Header + L3 Payload + L2 Trailer(FCS)|. Preamble (or SFD) is not considered in the frame size calculation. As different Ethernet standards have L2 headers with different sizes, to facilitate this maximum frame size rule, L3 Payload size needs to be adjusted.
For Ethernet II, IEEE 802.3 and IEEE 802.3-SNAP, the maximum L3 Payload sizes are 1500,1497,1492 respectively - you derive these numbers by deducting 14, 17 or 22 bytes (for each respective L2 header) plus an additional 4 bytes for FCS from the supported maximum frame size of 1518 bytes. As mentioned earlier, 1518 Byte is not a hard rule.. if your device supports bigger Ethernet frames, you can effectively send bigger IP payloads. In Cisco's world, you can have some control over these MTU values by changing the Sytem MTU and the IP MTU. - it is recommended to do this on both ends of the segment.
EtherType 0x08100 is a bit of a special case as this is the "Type" used when you have VLAN (802.1q) tagging on your network. When switches (or any capable endpoint) see the EtherType 0x8100, it knows that a 2 Byte VLAN tag follows.
Ethernet II only has a Type field and it does not have any reference to the length of the frame. So how does the receiving party figures if the full frame has been received?.. Well it doesn't, it simply counts the incoming bits and when the carrier signal drops, it assumes the end of frame. In fact, even for IEEE 802.3 and IEEE 802.3-SNAP, this is how the end of frame is detected regardless of the "Length" field readily available in the header.
