Everything you wanted to know about Ethernet frames, but were afraid to ask, and for good reason
The article turned out to be quite voluminous, the topics covered were Ethenet frame formats, L3 Payload size limits, the evolution of Ethernet header sizes, Jumbo Frame, Baby-Giant, and a lot of things offended by the way. Something you have already seen in the review literature on data networks, but with many, clearly, did not come across, if not deeply engaged in research.
We begin by considering the format of the Ethernet frame headers in the queue of their birth.
Formats Ehternet frames.
1) Ethernet II
')
Fig. one
Preamble - a sequence of bits, in fact, not part of the ETH header that defines the beginning of an Ethernet frame.
DA (Destination Address) - the destination MAC address, it can be a unicast, multicast, broadcast.
SA (Source Address) - MAC address of the sender. Always unicast.
E-TYPE (EtherType) - Identifies the L3 protocol (for example, 0x0800 - Ipv4, 0x86DD - IPv6, 0x8100- indicates that the frame is tagged with an 802.1q header, etc. A list of all EtherType - standards.ieee.org/develop/regauth/ ethertype / eth.txt )
Payload - L3 packet size from 46 to 1500 bytes
FCS (Frame Check Sequences) - 4 byte CRC value used to detect transmission errors. Calculated by the sending side, and placed in the FCS field. The receiving party calculates this value independently and compares it with the received one.
This format was created in collaboration with 3 companies - DEC, Intel and Xerox. In this regard, the standard is also called DIX Ethernet standard . This version of the standard was published in 1982 (the first version, Ehernet I - in 1980. The differences in the versions are small, the format as a whole has remained unchanged). In 1997 This standard was added by IEEE to the 802.3 standard, and at the moment, the vast majority of packets on Ethernet networks are encapsulated according to this standard.
Fig. 2
As you understand, the IEEE Committee could not watch calmly, as power, money and women literally slip away. Therefore, busy with more pressing problems, the standardization of the Ethernet technology came up with some delay (in 1980 they got down to business, in 1983 they gave the world a draft, and in 1985 the standard itself), but with great enthusiasm. By proclaiming innovation and optimization as its main principles, the committee issued the following frame format, which you can see in Figure 2.
First of all, we draw attention to the fact that the “unnecessary” E-TYPE field is converted to the Length field, which indicates the number of bytes following this field before the FCS field. Now, it was possible to understand who was longer at the second level of the OSI system. Life has become better. Life has become more fun.
But, a pointer to the type of protocol of the 3rd level was needed, and IEEE gave the world the following innovation - two fields of 1 byte each - Source Service Access Point ( SSAP ) and Destination Service Access Point ( DSAP ). The goal, the same, is to identify the superior protocol, but what is the implementation! Now, due to the presence of two fields within one session, the packet could be transferred between different protocols, or the same protocol could be called differently at the two ends of the same session. BUT? What is it like? Where is your Skolkovo?
Note: In real life, this is of little use and SSAP / DSAP values ​​usually coincide. For example, SAP for IP - 6, for STP - 42 (full list of values ​​- standards.ieee.org/develop/regauth/llc/public.html )
Without giving themselves a break, IEEE reserved 1 bit in SSAP and DSAP. In SSAP under the instruction of the command or response of the packet, in DSAP under the indication of the group or individual address (see Fig. 6). On Ethernet networks, these things did not get distribution, but the number of bits in the SAP fields was reduced to 7, which left only 128 possible numbers under the instruction of the higher protocol. We remember this fact, we will come back to it.
It was already difficult to stop in the desire to make the best frame format on earth, and in IEEE frame format appears 1 byte field Control . Responsible, not much, not enough, for a Connection-less or Connection-oriented connection!
After exhaling and examining their offspring, IEEE decided to take a break.
Note : The 3 fields considered are DSAP, SNAP and Control and are the LLC header.
Fig. 3
This "lack of standard" revealed to the world of Novell. It was the dashing 80s, everyone survived as they could, and Novell was no exception. Having obtained the 802.3 / 802.2 specification in the process of developing the specification and throwing out the LLC header with a slight movement of the hand, Novell got quite a good frame format (with the ability to measure length at the second level!), But with one major drawback - the lack of the possibility of specifying a higher protocol. But, as you might have guessed, the guys who worked there were not stupid, and due to common thinking they worked out a solution - “but let us turn our shortcomings into our own merits,” and limited this frame format to the IPX protocol, which we supported. And the idea is good, and the plan was strategically correct, but, as history has shown, it was not fortanulo.
As time went. The IEEE committee realized that protocol numbers and money were running out. Grateful users bombarded the editors with letters, where the 3-byte LLC header was placed on a par with such great innovations of humanity as the equipment of a dog with the 5th leg, or with a sleeve that can be used to optimize female anatomy. It was impossible to wait any longer, it was time to declare itself to the world again.
Fig. four
And to help those suffering from a shortage of protocol numbers (there could be 128 of them in total, we mentioned), IEEE introduces a new standard for the Ethernet SNAP frame (Figure 4). The main innovation is the addition of a 5-byte field of the Subnetwork Access Protocol (SNAP), which in turn consists of two parts - a 3-byte field Organizationally Unique Identifier (OUI) and a 2-byte Protocol ID (PID) - Fig. five.
Fig. five
OUI or vendor code - allows you to identify proprietary protocols by specifying the vendor. For example, if you catch WireShark with the PVST + package, then in the OUI field you will see the code 0x00000c, which is the identifier of Cisco Systems (Fig. 6).
Fig. 6
Note: It is quite easy to meet a packet with encapsulation in the frame format 802.3 SNAP and now these are all protocols of the STP family, protocols CDP, VTP, DTP.
The PID field is essentially the same EtherType field from DIX Ethernet II - 2 bytes under the indication of a higher-level protocol. Since earlier DSAP and SSAP fields of the LLC header field were used for this, to indicate that the type of the upstream protocol should be viewed in the SNAP field, the DSAP and SSAP fields take the fixed value 0xAA (also seen in Fig. 6)
Note: When using the LLC / SNAP frame format for transferring IP packets, the IP MTU is reduced from 1,500 to 1,497 and 1,492 bytes, respectively.
According to the headings in the frame format, in principle, everything. I would like to draw attention to another point in the frame format - the size of the payload. Where did this range come from - from 46 to 1500 bytes?
From where did the lower limit come from, perhaps everyone who at least read the first CCNA curriculum knows. This restriction is a consequence of the frame size limit of 64 bytes (64 bytes - 14 bytes of the L2 header - 4 bytes of FCS = 46 bytes) imposed by the CSMA / CD method - the time required to transmit 64 bytes of the network interface is necessary and sufficient to determine collisions in the environment Ethernet
Note: In modern networks, where the occurrence of collisions is excluded, this restriction is no longer relevant, but the requirement remains. This is not the only "appendix" left over from those times, but we'll talk about them in another article.
But where did these notorious 1500 bytes come from, the question is more complicated. I found the following explanation - there were several prerequisites for the introduction of the upper frame size limit:
In total, in the 802.3 standard, the frame size was limited to 1518 bytes from the top, and payload to 1500 bytes (hence the default MTU size for the Ethernet interface).
Note: Frames smaller than 64 bytes are called Runts, frames larger than 1,518 bytes are called Giants. You can view the number of such frames received on the interface using the
With the development of technology and specifications of the IEEE 802 line, the frame size has also changed. Basic further frame resizing (not MTU!):
All these frames of the increased size are grouped under one name - Baby-Giant frames. The silent upper size limit for a Baby-Giant is 1600 bytes. Modern network interfaces will forward these frames, often without even changing the value of the HW MTU.
Separately, pay attention to the specifications of 802.3AS - increases the maximum frame size to 2000 (but retains the MTU size of 1500 bytes!). The increase accounted for the title and trailer. Initially, the increase was planned for 128 bytes - for native support by the standard 802.3 of the extensions listed above, but eventually they agreed on 2 thousand, apparently not to be collected twice (or as IEEE says - this frame size will support the future of future). The standard was approved in 2006, but except at the IEEE presentations, I did not meet it. If anyone has anything to add here (and not only here) - welcome to the comments. In general, the tendency to increase the size of the frame while maintaining the size of PAYLOAD, creates in my head vague doubts about the correctness of the chosen direction of movement.
Note: The FCoE frame is located a little away from the above - the frame size is up to 2500 bytes, often these frames are called mini-jumbo. For their support, you need to enable jumbo-frame support.
And the last Ethernet “bastard” is the Jumbo Frame (although if you translate the Jumbo, then Hodor appears more likely - a reference to the Game of Thrones). This description includes all frames exceeding the standard size of 1518 bytes, with the exception of those discussed above. Jumbo packages are not reflected in the 802.3 specifications at all and therefore the implementation remains on the conscience of each particular vendor. However, jumbo frames exist just as much as ethernet exists. It is defined as follows:
Fig. 7
This medal has a reverse side:
Fig.8
In sum, the pros and cons of using jumbo frames give us an unequivocal indication of where we can use this frame size. And so, in which applications in the data center can we use the Jumbo Frame to everyone's advantage? It turns out such a list (additions are welcome):
Note: Jumbo MTU has an upper size limit. It is determined by the size of the FCS field (4 bytes) and the Cyclic Redundancy Check algorithm and is 11,455 bytes. In practice, Jumbo MTU is usually limited to 9216 bytes in size, on some platforms 9000 bytes, on older hardware 8092 bytes (this is Cisco).
Fuh, basically everything. What I wanted to consider in theory, considered. For the MTU size configuration and the theory with the feints behind these three letters, I ask in my last article - “Maximum Transmission Unit (MTU). Myths and reefs.
In conclusion, the promised link to the Alteon Networks "Extended Frame Sizes for Next Generation Ethernets" report - staff.psc.edu/mathis/MTU/AlteonExtendedFrames_W0601.pdf , and a small announcement for the next article - in it we will fall even lower - to the physical level, and we will deal with the heavy legacy of CSMA / CD, encoding, and, in passing, we will hook on something else from the topical.
We begin by considering the format of the Ethernet frame headers in the queue of their birth.
Formats Ehternet frames.
1) Ethernet II
')
Fig. one
Preamble - a sequence of bits, in fact, not part of the ETH header that defines the beginning of an Ethernet frame.
DA (Destination Address) - the destination MAC address, it can be a unicast, multicast, broadcast.
SA (Source Address) - MAC address of the sender. Always unicast.
E-TYPE (EtherType) - Identifies the L3 protocol (for example, 0x0800 - Ipv4, 0x86DD - IPv6, 0x8100- indicates that the frame is tagged with an 802.1q header, etc. A list of all EtherType - standards.ieee.org/develop/regauth/ ethertype / eth.txt )
Payload - L3 packet size from 46 to 1500 bytes
FCS (Frame Check Sequences) - 4 byte CRC value used to detect transmission errors. Calculated by the sending side, and placed in the FCS field. The receiving party calculates this value independently and compares it with the received one.
This format was created in collaboration with 3 companies - DEC, Intel and Xerox. In this regard, the standard is also called DIX Ethernet standard . This version of the standard was published in 1982 (the first version, Ehernet I - in 1980. The differences in the versions are small, the format as a whole has remained unchanged). In 1997 This standard was added by IEEE to the 802.3 standard, and at the moment, the vast majority of packets on Ethernet networks are encapsulated according to this standard.
2) Ethernet_802.3 / 802.2 (802.3 with LLC header)
Fig. 2
As you understand, the IEEE Committee could not watch calmly, as power, money and women literally slip away. Therefore, busy with more pressing problems, the standardization of the Ethernet technology came up with some delay (in 1980 they got down to business, in 1983 they gave the world a draft, and in 1985 the standard itself), but with great enthusiasm. By proclaiming innovation and optimization as its main principles, the committee issued the following frame format, which you can see in Figure 2.
First of all, we draw attention to the fact that the “unnecessary” E-TYPE field is converted to the Length field, which indicates the number of bytes following this field before the FCS field. Now, it was possible to understand who was longer at the second level of the OSI system. Life has become better. Life has become more fun.
But, a pointer to the type of protocol of the 3rd level was needed, and IEEE gave the world the following innovation - two fields of 1 byte each - Source Service Access Point ( SSAP ) and Destination Service Access Point ( DSAP ). The goal, the same, is to identify the superior protocol, but what is the implementation! Now, due to the presence of two fields within one session, the packet could be transferred between different protocols, or the same protocol could be called differently at the two ends of the same session. BUT? What is it like? Where is your Skolkovo?
Note: In real life, this is of little use and SSAP / DSAP values ​​usually coincide. For example, SAP for IP - 6, for STP - 42 (full list of values ​​- standards.ieee.org/develop/regauth/llc/public.html )
Without giving themselves a break, IEEE reserved 1 bit in SSAP and DSAP. In SSAP under the instruction of the command or response of the packet, in DSAP under the indication of the group or individual address (see Fig. 6). On Ethernet networks, these things did not get distribution, but the number of bits in the SAP fields was reduced to 7, which left only 128 possible numbers under the instruction of the higher protocol. We remember this fact, we will come back to it.
It was already difficult to stop in the desire to make the best frame format on earth, and in IEEE frame format appears 1 byte field Control . Responsible, not much, not enough, for a Connection-less or Connection-oriented connection!
After exhaling and examining their offspring, IEEE decided to take a break.
Note : The 3 fields considered are DSAP, SNAP and Control and are the LLC header.
3) Raw 802.3
Fig. 3
This "lack of standard" revealed to the world of Novell. It was the dashing 80s, everyone survived as they could, and Novell was no exception. Having obtained the 802.3 / 802.2 specification in the process of developing the specification and throwing out the LLC header with a slight movement of the hand, Novell got quite a good frame format (with the ability to measure length at the second level!), But with one major drawback - the lack of the possibility of specifying a higher protocol. But, as you might have guessed, the guys who worked there were not stupid, and due to common thinking they worked out a solution - “but let us turn our shortcomings into our own merits,” and limited this frame format to the IPX protocol, which we supported. And the idea is good, and the plan was strategically correct, but, as history has shown, it was not fortanulo.
4) 802.3 with SNAP Header.
As time went. The IEEE committee realized that protocol numbers and money were running out. Grateful users bombarded the editors with letters, where the 3-byte LLC header was placed on a par with such great innovations of humanity as the equipment of a dog with the 5th leg, or with a sleeve that can be used to optimize female anatomy. It was impossible to wait any longer, it was time to declare itself to the world again.
Fig. four
And to help those suffering from a shortage of protocol numbers (there could be 128 of them in total, we mentioned), IEEE introduces a new standard for the Ethernet SNAP frame (Figure 4). The main innovation is the addition of a 5-byte field of the Subnetwork Access Protocol (SNAP), which in turn consists of two parts - a 3-byte field Organizationally Unique Identifier (OUI) and a 2-byte Protocol ID (PID) - Fig. five.
Fig. five
OUI or vendor code - allows you to identify proprietary protocols by specifying the vendor. For example, if you catch WireShark with the PVST + package, then in the OUI field you will see the code 0x00000c, which is the identifier of Cisco Systems (Fig. 6).
Fig. 6
Note: It is quite easy to meet a packet with encapsulation in the frame format 802.3 SNAP and now these are all protocols of the STP family, protocols CDP, VTP, DTP.
The PID field is essentially the same EtherType field from DIX Ethernet II - 2 bytes under the indication of a higher-level protocol. Since earlier DSAP and SSAP fields of the LLC header field were used for this, to indicate that the type of the upstream protocol should be viewed in the SNAP field, the DSAP and SSAP fields take the fixed value 0xAA (also seen in Fig. 6)
Note: When using the LLC / SNAP frame format for transferring IP packets, the IP MTU is reduced from 1,500 to 1,497 and 1,492 bytes, respectively.
According to the headings in the frame format, in principle, everything. I would like to draw attention to another point in the frame format - the size of the payload. Where did this range come from - from 46 to 1500 bytes?
Size L3 Payload.
From where did the lower limit come from, perhaps everyone who at least read the first CCNA curriculum knows. This restriction is a consequence of the frame size limit of 64 bytes (64 bytes - 14 bytes of the L2 header - 4 bytes of FCS = 46 bytes) imposed by the CSMA / CD method - the time required to transmit 64 bytes of the network interface is necessary and sufficient to determine collisions in the environment Ethernet
Note: In modern networks, where the occurrence of collisions is excluded, this restriction is no longer relevant, but the requirement remains. This is not the only "appendix" left over from those times, but we'll talk about them in another article.
But where did these notorious 1500 bytes come from, the question is more complicated. I found the following explanation - there were several prerequisites for the introduction of the upper frame size limit:
- Transmission delay - the larger the frame, the longer the transmission lasts. For early networks, where the Collision domain was not limited to the port, and all stations had to wait for the transfer to complete, this was a serious problem.
- The larger the frame, the greater the likelihood that the frame will be damaged during transmission, which will result in the need for retransmission, and all devices in the collision domain will have to wait again.
- The restrictions imposed by the memory used by the interface buffers - at that time (1979) an increase in buffers significantly increased the cost of the interface.
- The restriction imposed by the field Length / Type - the standard stipulates that all values ​​above 1536 (from 05-DD to 05-FF.) Indicate the EtherType, respectively, the length must be less than 05-DC. (I really have a suspicion that this is more a consequence than a prerequisite, but it seems to be infa from 802.3 developers)
In total, in the 802.3 standard, the frame size was limited to 1518 bytes from the top, and payload to 1500 bytes (hence the default MTU size for the Ethernet interface).
Note: Frames smaller than 64 bytes are called Runts, frames larger than 1,518 bytes are called Giants. You can view the number of such frames received on the interface using the
show interface gigabitEthernet module/number and show interface gigabitEthernet module/number counters errors. And up to IOS 12.1 (19), the counters were sent as frames with incorrect and correct CRS (although the latter were not always dropped, depending on the platform and conditions). But starting from 12.1. (19), only those runt and giant frames that have incorrect CRS are displayed in these counters, frames are less than 64 bytes, but with correct CRS (the cause is usually associated with 802.1Q detection or source of frames, not problems physical level) from this version fall into the Undersize counter, they drop, or forward further, depends on the platform.The evolution of Ethernet header sizes.
With the development of technology and specifications of the IEEE 802 line, the frame size has also changed. Basic further frame resizing (not MTU!):
- 802.3AC - increases the maximum frame size to 1522 - adds a Q-tag - carrying information about 802.1Q (VLAN tag) and 802.1p (bits for COS)
- 802.1AD - increases the maximum frame size to 1526, support for QinQ
- 802.1AH (MIM) - Provider Bridge Backbone Mac in Mac + 30 bytes to frame size
- MPLS - we increase the size of the frame on the stack of labels 1518 + n * 4, where n is the number of labels in the stack.
- 802.1AE - Mac Security; Security Tag and Message Authentication Code + 68 bytes to the frame size are added to the standard fields.
All these frames of the increased size are grouped under one name - Baby-Giant frames. The silent upper size limit for a Baby-Giant is 1600 bytes. Modern network interfaces will forward these frames, often without even changing the value of the HW MTU.
Separately, pay attention to the specifications of 802.3AS - increases the maximum frame size to 2000 (but retains the MTU size of 1500 bytes!). The increase accounted for the title and trailer. Initially, the increase was planned for 128 bytes - for native support by the standard 802.3 of the extensions listed above, but eventually they agreed on 2 thousand, apparently not to be collected twice (or as IEEE says - this frame size will support the future of future). The standard was approved in 2006, but except at the IEEE presentations, I did not meet it. If anyone has anything to add here (and not only here) - welcome to the comments. In general, the tendency to increase the size of the frame while maintaining the size of PAYLOAD, creates in my head vague doubts about the correctness of the chosen direction of movement.
Note: The FCoE frame is located a little away from the above - the frame size is up to 2500 bytes, often these frames are called mini-jumbo. For their support, you need to enable jumbo-frame support.
And the last Ethernet “bastard” is the Jumbo Frame (although if you translate the Jumbo, then Hodor appears more likely - a reference to the Game of Thrones). This description includes all frames exceeding the standard size of 1518 bytes, with the exception of those discussed above. Jumbo packages are not reflected in the 802.3 specifications at all and therefore the implementation remains on the conscience of each particular vendor. However, jumbo frames exist just as much as ethernet exists. It is defined as follows:
- Benefit of payload ratio to headers. The greater this ratio, the more efficiently we can use communication lines. Of course, the gap here will not be the same as in comparison with the use of packets of 64 bytes and 1,518 bytes for TCP sessions. But you can win your own 3-8 percent, depending on the type of traffic.
- A significantly smaller number of headers generates less load on the Forwading Engine, as well as on the service Engine. For example, the frame rate for a 10G link loaded with 1,500 byte frames is 812,744 frames per second, while the same link loaded with Jumbo frames of 9,000 bytes generates a frame rate of only 138,587 frames per second. Figure 7 shows the graph from the Alteon Networks report (link will be at the bottom of the article) of utilization of the CPU and gigabit link, depending on the type of frame size used.
- Increase TCP Throughput when resizing MTU - staff.psc.edu/rreddy/networking/mtu.html
Fig. 7
This medal has a reverse side:
- The larger the frame, the longer it will be transmitted (Fig. 8):
- Buffers in the memory of network devices are filled faster, which can cause undesirable consequences. In essence, it can be solved at the equipment design stage, but it increases the cost.
- The proprietary implementation of each manufacturer - all devices must support either the same size of the Jumbo frame, or sets of sizes.
- It is essentially impossible to use networks that are under different administrative control over large parts of the network, due to the lack of a Jumbo Frame Discovery mechanism — the intermediate node may not support Jumbo Frame at all or a certain size.
Fig.8
In sum, the pros and cons of using jumbo frames give us an unequivocal indication of where we can use this frame size. And so, in which applications in the data center can we use the Jumbo Frame to everyone's advantage? It turns out such a list (additions are welcome):
- In server clusters
- When backing up
- Network File System (NFS) Protocol
- iSCSI SANs
- FCoE SANs
Note: Jumbo MTU has an upper size limit. It is determined by the size of the FCS field (4 bytes) and the Cyclic Redundancy Check algorithm and is 11,455 bytes. In practice, Jumbo MTU is usually limited to 9216 bytes in size, on some platforms 9000 bytes, on older hardware 8092 bytes (this is Cisco).
Fuh, basically everything. What I wanted to consider in theory, considered. For the MTU size configuration and the theory with the feints behind these three letters, I ask in my last article - “Maximum Transmission Unit (MTU). Myths and reefs.
In conclusion, the promised link to the Alteon Networks "Extended Frame Sizes for Next Generation Ethernets" report - staff.psc.edu/mathis/MTU/AlteonExtendedFrames_W0601.pdf , and a small announcement for the next article - in it we will fall even lower - to the physical level, and we will deal with the heavy legacy of CSMA / CD, encoding, and, in passing, we will hook on something else from the topical.
Source: https://habr.com/ru/post/227729/
All Articles