Of Ethernet Frame Types and Packet Sizes
Articles and Tips: article
smiles@thebisgroup.com
01 Mar 2001
This month, the Network Troubleshooter explains why you should use the Ethernet 802.2 frame type, as well as why you shouldn't set the Ethernet packet size smaller than 2048.
Novell's ETHERNET_802.3 frame type complies with the IEEE 802.3 specification in that it defines a 1514-byte maximum packet size. In this specification, the first six bytes contains the destination address, the next six bytes contain the source address, and the next two bytes contain a length field. What's missing is an 802.2 header field, which could tell you what protocol is being run.
Today, implementers "cheat" by counting on the fact that ETHERNET_802.3 frames are followed with a "-1" checksum field (0xFFFF). Since most popular protocols don't use a DSAP (Destination Service Advertising Protocol) or SSAP (Source Service Advertising Protocol) field of 0xFF, you can hack your code to distinguish IPX running on ETHERNET_802.3 frames from something else.
Why to Use the Ethernet 802.2 Frame Type vs. 802.3
However, the 802.2 frame type provides checksums, and it doesn't have the same potential to crash servers as the 802.3 frame type does. To understand why this is, you need to understand how Novell implemented 802.3 frames on NetWare.
In a typical packet, there are several fields in the header; two of those fields identify the checksum (2 bytes) and the protocol ID (1 byte). When 3Com and others first developed the Ethernet standard, they didn't make the entire specifications public. Novell engineers had to reverse-engineer the frame format in order to support it. They ended up with a 2-byte field and a 1-byte field which they couldn't determine the use of. The 2-byte field didn't look like it was being used, so they put a value of 0xFFFF in that field and coded NetWare to identify frames with such a format as IPX traffic.
The problem a server can run into (it is fairly rare, but possible) is when a non-IPX packet hits the server over 802.3 with a valid checksum of 0xFFFF. The LAN driver passes this packet up the protocol stack to IPX, rather than to the correct protocol. Then, when the server tries to decode the packet (which is formatted for a different protocol), the possibility exists that the instructions in the packet are something along the lines of "send me the next 1 quadrillion bytes of information in the buffer." With NetWare 4.x, such an instruction will result most often in a PFPE (Page Fault Processor Exception) Abend (Abnormal End).
The 802.2 frame type is a little slower than 802.3 because of the extra time it takes to calculate the checksums. Because of the way NetWare uses the checksum field in 802.3, though, you cannot enable checksums on those frames (enabling them doesn't accomplish anything), and you can still end up with corrupt packets getting to the server. However, 802.2 is a more stable protocol and gives you the checksums, and is now the standard frame type for Ethernet on NetWare.
For more information on using Ethernet 802.2 frame types, see the following links:
http://netlab1.usu.edu/novell.faq/nvfaq-l.htm#L000
Choosing a Maximum Physical Receive Packet Size for Ethernet
Many have asked if they should set the maximum physical receive packet size to 1514 if they are running Ethernet? The answer is no.
The SET parameter "Maximum Physical Receive Packet Size" has an unfortunate name, as it does not actually specify the physical packet size you use on the network. What it does specify is the size of the packet buffers that NetWare allocates for receiving packets, as well as the largest physically contiguous receive buffer that can be allocated by the driver.
A number of LAN drivers need extra buffer space because of alignment issues or because they use a scratch area in the buffer space, and therefore may require packet buffers to be larger than 1514 bytes. Other hardware implementations may add extra bytes before or after the packet to provide receive packet status information.
The largest known buffer requirement for Ethernet adapters is currently 2048. This buffer size is required by all adapters that are based on Intel PCI Ethernet chips. However, the safest approach is to just leave the buffer size set at the default value (4224 for NetWare 5.x and 4202 for NetWare 4.x). With the large amounts of RAM found in today's servers, the memory used by packet buffers is negligible when compared to the total server memory.
If you need to save a little memory, you can reduce your buffer size to 2048. But never select a buffer size smaller than 2048. If you do, you will run into obscure problems when using a LAN driver that requires 2048 byte buffers. Choosing too small a buffer can lead to degraded performance, excessive "No ECB available" errors, or even to complete lack of communication.
For more information on this subject, check the following links:
http://support.intel.com/support/network/adapter/pro100/23922.htm#2
http://support.novell.com/cgi-bin/search/tidfinder.cgi?10021597
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.