Ethernet frame size
-
In another thread, there was some discussion of Ethernet frame size and the ability of non-VLAN equipment to pass VLAN frames. There is an update to the 802.3 standard, in 2006, 802.3as about "Envelope expansion". This was intended to accommodate the additions to Ethernet, such as VLAN tags, among others.
Here's some info:
From http://mapyourtech.com/entries/general/the-ethernet-frame-a-walkthroughEnvelope Prefix and Suffix
As networks grew in complexity and features, the IEEE received requests for more tags to achieve new goals. The VLAN tag provided space for a VLAN ID and Class of Service (CoS) bits, but vendors and standards groups wanted to add extra tags to support new bridging features and other schemes.
To accommodate these requests, the 802.3 standards engineers defined an “envelope frame,” which adds an extra 482 bytes to the maximum frame size. The envelope frame was specified in the 802.3as supplement to the standard, adopted in 2006. In another change, the tag data was added to the data field to produce a MAC Client Data field. Because the MAC client data field includes the tagging fields, it may seem like the frame size definition has changed, but in fact this is just a way of referring to the combination of tag data and the data field for the purpose of defining the envelope frame.
The 802.3as supplement modified the standard to state that an Ethernet implementation should support at least one of three maximum MAC client data field sizes. The data field size continues to be defined as 46 to 1,500 bytes, but to that is added the tagging infor‐ mation to create the MAC client data field, resulting in the following MAC client data field sizes:
1,500-byte “basic frames” (no tagging information)1,982-byte “envelope frames” (1,500-byte data field plus 482 bytes for all tags)
1,504-byte “Q-tagged frames” (1,500-byte data field plus 4-byte tag)Last week the 802.3as task force decided on a length of 2,000 bytes as the new maximum envelope frame size, up from the current standard of a maximum of 1,518 bytes. The additional space would be used for header and trailer information.
The specification would warn that some standards-compliant implementations might not be able to handle anything longer than 1,518 bytes.
So, frames larger than 1518 bytes are part of the spec and have been since 2006. Please note, this does not refer to jumbo frames, which can be 9K bytes or more, but are not IEEE spec.
-
So? What's your point?
People: Use a managed switch for your VLANs.
If you must use something like an unmanaged switch to extend a trunk link past 100m or something it should work.
-
heheeh - just will not let this drop will you jknott.. going to QTE this here..
People: Use a managed switch for your VLANs.
-
So? What's your point?
People: Use a managed switch for your VLANs.
If you must use something like an unmanaged switch to extend a trunk link past 100m or something it should work.
My point is that people will often take "common knowledge" and hold it as absolute truth, when it's not. Back when Ethernet was created, there was a hard limit imposed by hardware, at a time when hardware was expensive ( I hand wired some Ethernet controllers for Data General Eclipse computers, back in the '80s. I also connected some VAX 11/780 computers with 10base5 "ThickNet" at about the same time.). There were also considerations about the compromise with network efficiency vs data loss, in a collision environment. These days, with advances in the technology, the spec and more, the only hard limit is the length field in 802.3, which does not apply with Ethernet II, as is normally used by IP. This has allowed for VLAN tags, MPLS labels, jumbo frames and more. In all probability, any equipment made after 802.3ac was added will be compliant with larger frames, as there is no reason not to be.
My point about VLANs was in regard to all the "common knowledge" that unmanaged switches would cause problems, even though they generally won't. Please note that I am not advocating against managed switches for handling VLANs. In fact, I am in favour of them for this and other reasons. So, my overall point would apply to a situation, such as an access point with multiple SSIDs & VLANs, which would likely not require a new managed switch, when an existing unmanaged switch would probably work fine. In this example, one would configure the AP for a VLAN and configure pfSense with the same VLAN and all should work fine, as everything else will simply ignore the VLAN frames. As for broadcasts, there would be no more than if a VLAN was not used, when carrying the same traffic.
-
heheeh - just will not let this drop will you jknott.. going to QTE this here..
People: Use a managed switch for your VLANs.
Hi Johnpoz. As I mentioned in the previous message, this is more of an attack on "common knowledge" where people won't go beyond it to see what's actually happening. I have been working in telecom, computers and networks for many years (I first worked with LANs in 1978, before there was such a thing as Ethernet or IPv4) and have come across many people who get stuck on the common knowledge and show they don't really understand the fundamentals.
-
Fundamentals such as using separate broadcast domains for your VLANs?
-
No, fundamentals as in understanding how things work at the base level, which would lead to understanding why VLANs, managed switches and more would be appropriate. That is something a lot of people are missing and it interferes with their ability to solve problems. As an example, I was at a customer site a few weeks ago, where their admin was scared of the command line. As long as he could click on something, he was OK, but really didn't understand what was happening. I come from a hardware background at time when you had to know how things actually worked. I've even worked with CPU microcode, that's the code within a CPU that makes it understand the instruction set. I also started out first by learning what bits on the wire looked like (Yep, waveforms on a 'scope.). I started at that level and worked up from there, knowing how the various things fit together to make a system. Over the years I occasionally built from scratch or even designed the hardware needed to do a job (At one point I designed and built an 8 port serial I/O card for my IMSAI 8080 computer). So, yeah, my knowledge about a lot of things is much greater than many others have. For example, I have often mentioned using Wireshark. Well, using protocol analyzers is nothing new to me. I was using them 40 years ago on data circuits. Back then, I was also adjusting the equalization that was necessary for modems. But above all, I am constantly learning to understand how things work. Always have, always will.
This is my first computer, which I bought in 1976. I built it from what was essentially bare boards and bags of parts. I also wrote software for it in assembler.
https://en.wikipedia.org/wiki/IMSAI_8080 -
Dude you can also use a sledge hammer to open a can of beans.. Doesn't mean its the correct tool ;)
Your advice is amount to suggesting people use a hammer they have in the drawer vs buying the $1 can opener..
I am going to say this yet again, and will continue to say it if you continue with this nonsense. If your going to do vlans - then get a switch that does vlans.. Period! There are plenty of ways to open that can of beans.. You could if need be find a rock and use that - does not mean you should go suggesting people just use a rock off the ground to open their cans vs buying a can opener..
If you want to attack "common knowledge" how about pick out some of the FUD out there and attack it. I will join you in that quest for sure..
Some example off the top of my head that come up here
"IPv6 is less secure because it does not require NAT"
"VPNs Make You Anonymous"If you want to really help out the common man.. Spread info on what a transit network is.. Pretty much every single day we get some question(s) about why this isn't working - because they have a asymmetrical mess and don't understand what a stateful firewall actually is ;)
-
"IPv6 is less secure because it does not require NAT"
"VPNs Make You Anonymous"If you want to really help out the common man.. Spread info on what a transit network is.. Pretty much every single day we get some question(s) about why this isn't working - because they have a asymmetrical mess and don't understand what a stateful firewall actually is ;)
Actually, I have tried explaining things like this to others. I've come across some who still insist IPv4 is adequate. I tell them it stopped being adequate the day NAT became necessary to conserve addresses. While VPNs and transit networks don't come up often, one friend of mine wished for years that he had a T1 for Internet access, even though he already had much better bandwidth than 1.544 Mb. It was just something he'd heard about for years, not understanding what it was. Another friend is one who claims NAT is a security feature. He should know better, as he has worked with networks & equipment, whereas the other guy could be excused because he's an accountant. I've also been told that Ethernet bandwidth is set by the cable type and somehow the NIC can tell whether it's CAT5 or CAT6 cable attached, or that CAT5 can't carry gigabit or how some switches don't handle VoIP well, ignoring the fact that switches only pass Ethernet frames, or that Ethernet wasn't designed to work in the presence of phone lines, etc. I've got a long list of such stories, often from people who really should know better.
-
In another thread, there was some discussion of Ethernet frame size and the ability of non-VLAN equipment to pass VLAN frames. There is an update to the 802.3 standard, in 2006, 802.3as about "Envelope expansion". This was intended to accommodate the additions to Ethernet, such as VLAN tags, among others.
Here's some info:
From http://mapyourtech.com/entries/general/the-ethernet-frame-a-walkthroughEnvelope Prefix and Suffix
As networks grew in complexity and features, the IEEE received requests for more tags to achieve new goals. The VLAN tag provided space for a VLAN ID and Class of Service (CoS) bits, but vendors and standards groups wanted to add extra tags to support new bridging features and other schemes.
To accommodate these requests, the 802.3 standards engineers defined an “envelope frame,” which adds an extra 482 bytes to the maximum frame size. The envelope frame was specified in the 802.3as supplement to the standard, adopted in 2006. In another change, the tag data was added to the data field to produce a MAC Client Data field. Because the MAC client data field includes the tagging fields, it may seem like the frame size definition has changed, but in fact this is just a way of referring to the combination of tag data and the data field for the purpose of defining the envelope frame.
The 802.3as supplement modified the standard to state that an Ethernet implementation should support at least one of three maximum MAC client data field sizes. The data field size continues to be defined as 46 to 1,500 bytes, but to that is added the tagging infor‐ mation to create the MAC client data field, resulting in the following MAC client data field sizes:
1,500-byte “basic frames” (no tagging information)1,982-byte “envelope frames” (1,500-byte data field plus 482 bytes for all tags)
1,504-byte “Q-tagged frames” (1,500-byte data field plus 4-byte tag)Last week the 802.3as task force decided on a length of 2,000 bytes as the new maximum envelope frame size, up from the current standard of a maximum of 1,518 bytes. The additional space would be used for header and trailer information.
The specification would warn that some standards-compliant implementations might not be able to handle anything longer than 1,518 bytes.
So, frames larger than 1518 bytes are part of the spec and have been since 2006. Please note, this does not refer to jumbo frames, which can be 9K bytes or more, but are not IEEE spec.
Ohhh, thanks for the info.
When looking for switches, I don't notice any 802.3as. Switches tend to either support jumbo frames or they don't. Implementing 802.3as is optional and it seems few or none have chosen to do so. Just get a vLan+jumbo frame switch and don't worry.
-
802.3as is not about jumbo frames, it's about supporting VLAN tags etc. Jumbo frames are not part of the spec and not supported by the IEEE. 802.3as supports 2000 bytes max. Jumbo frames can be 9K or more.
These days, with Ethernet controllers essentially a single ASIC chip, there is no reason for a manufacturer to build for 1500 bytes, rather than 2000. This is quite different from years ago, when controllers were built from discrete logic. I mentioned wiring up some controllers for Data General computers. Those took up most of a 15" square board and had things like 8 bit shift registers etc. So, back then 2000 bytes would have added significantly to the cost for no benefit. These days, no cost difference but significant benefit. Also, 802.3as is now part of the 802.3 spec. I don't know when it was rolled in, but it was certainly in 802.3-2012.
See section 3.2.7.
http://www.trincoll.edu/Academics/MajorsAndMinors/Engineering/Documents/IEEE%20Standard%20for%20Ethernet.pdf -
802.3as is not about jumbo frames, it's about supporting VLAN tags etc. Jumbo frames are not part of the spec and not supported by the IEEE. 802.3as supports 2000 bytes max. Jumbo frames can be 9K or more.
These days, with Ethernet controllers essentially a single ASIC chip, there is no reason for a manufacturer to build for 1500 bytes, rather than 2000. This is quite different from years ago, when controllers were built from discrete logic. I mentioned wiring up some controllers for Data General computers. Those took up most of a 15" square board and had things like 8 bit shift registers etc. So, back then 2000 bytes would have added significantly to the cost for no benefit. These days, no cost difference but significant benefit. Also, 802.3as is now part of the 802.3 spec. I don't know when it was rolled in, but it was certainly in 802.3-2012.
See section 3.2.7.
http://www.trincoll.edu/Academics/MajorsAndMinors/Engineering/Documents/IEEE%20Standard%20for%20Ethernet.pdfI know 802.3as is not about jumbo frames, I never said I thought it was. What I said was I have never seen a modern switch that supports 802.3as. I have never seen a 2000 byte frame switch, only 1518, 1522, 1526, or 9000+ bytes. I can't even get any useful google hits when searching for "802.3as". IEEE may have defined it, but no one seems to use it.
-
I know 802.3as is not about jumbo frames, I never said I thought it was. What I said was I have never seen a modern switch that supports 802.3as. I have never seen a 2000 byte frame switch, only 1518, 1522, 1526, or 9000+ bytes. I can't even get any useful google hits when searching for "802.3as". IEEE may have defined it, but no one seems to use it.
I just looked at the specs for a Cisco switch. It says 802.3, but not which year, so you can't tell what updates have been added to it. However, as 802.3ac has been rolled into the main 802.3, I don't know if any manufacturer would mention it separately. It's not a major feature, like VLAN tagging. When you look through the 802.3 spec, such as the one I linked to, you see a lot of things that have been added, but you're not likely to see in product descriptions.
-
So there's no way to know but to try it.
As has been said many times, it might or might not work. Want to process dot1q? Use a dot1q switch.
