IEEE802.3(7) | Standards, Environments, and Macros | IEEE802.3(7) |
ieee802.3
— IEEE
802.3 Ethernet parameters and statistics
The IEEE 802.3 standard specifies the details for Ethernet networking. This page describes the various statistics and tunables that device drivers supporting Ethernet commonly offer. Note that not every device or driver supports every one of these values, and many devices offer additional statistics and tunables that are specific to that hardware. See the device driver's documentation for those specific details.
Values that are statistics are visible kstat(8), whereas properties are visible using the dladm(8) show-linkprop subcommand. Tunables are properties that can be changed using the dladm(8) set-linkprop subcommand. A more useful summary of current operational state can be seen with the dladm(8) show-ether subcommand.
The following statistics are accessible with kstat(8). Note that some statistics are available in both 32- and 64-bit counters, in which case the name of the 64 bit statistic will be the same as the 32-bit, but with “64” appended. For example, ipackets64 is the 64-bit version of the ipackets statistic. These are indicated with the special suffix [64] in the table below.
0 | Unknown. |
1 | Half-duplex. |
2 | Full-duplex. |
pause | asmpause | meaning |
0 | 0 | No flow control. |
1 | 0 | Symmetric flow control. |
0 | 1 | Honor received pause frames. |
1 | 1 | Send pause frames when congested. |
<sys/mac_ether.h>
. For
more information see the section on MAC_PROP_MEDIA
in mac(9E).The following parameters are accessible with dladm(8). Some of these are normally read-only. Other properties that are not specific to IEEE 802.3 / Ethernet links are also available via dladm(8), and are documented in its man page rather than here.
With modern devices, auto-negotiation is normally handled automatically. With 1 Gbps, 10 Gbps, and higher speeds it is mandatory (10GBASE-T also requires full-duplex operation). It is also strongly recommended for use whenever possible; without auto-negotiation the link will usually not operate unless both partners are configured to use the same link mode.
Auto-negotiation, when enabled, takes place by comparing the local capabilities that have been advertised (which must also be supported by the local device), with the capabilities that have been advertised by the link partner (peer). The first of the following modes that is supported by both partners is selected as the link negotiation result:
Advertisement of these modes can be enabled or disabled by setting the appropriate en_ property in dladm(8).
Auto-negotiation may also be disabled, by setting the adv_autoneg_cap property to 0. In this case, the highest enabled link mode (using the above list) is “forced” for the link.
Link layer flow control is available on many modern devices, and is mandatory for operation at 10 Gbps. It requires that the link be auto-negotiated, and that the link be full-duplex, in order to function.
Flow control is applied when a receiver becomes congested. In this case the receiver can send a special frame, called a pause frame, to request its partner cease transmitting for a short period of time.
Flow control can be said to be either symmetric, in which case both partners can send and honor pause frames, or asymmetric, in which case one partner may not transmit pause frames.
The flow control mode used is driven by the flowctrl property. It has the following meanings:
“no” | Neither send, nor honor pause frames. |
“tx” | Send pause frames, provided that the peer can support them, but do not honor them. |
“rx” | Receive and honor pause frames. |
“bi” | Both send and receive (and honor) pause frames. |
The statistics for flow control (adv_cap_pause, adv_cap_asmpause, lp_cap_pause, lp_cap_asmpause, link_pause, and link_asmpause) are based on the properties exchanged in the auto-negotiation and are confusing as a result. Administrators are advised to use the flowctrl property instead.
Beginning with 25 Gbit per-lane Ethernet (100 Gbit QSFP devices use 4 lanes of 25 GbE) the various IEEE Ethernet standards allowed the optional use of forward error correction, often abbreviated FEC. In 25/100 Gbit Ethernet, FEC is considered an optional part of the standard and is subject to auto-negotiation. In 25/100 Gbit Ethernet, there are two explicit types of FEC that are defined and two meta options:
Due to the evolution of FEC support in 25/100 Gbit Ethernet, not all devices support FEC auto-negotiation. Sometimes to form a working link, a particular FEC must be explicitly selected.
With 50 Gbit per-lane Ethernet and higher single-lane and combined speeds, the use of FEC is no longer something separate that is part of auto-negotiation. Instead, it is a mandatory part of higher-speed specifications.
The IEEE 802.3 standard specifies a standard frame size of 1518 bytes, which includes a 4-byte frame checksum, a 14-byte header, and 1500 bytes of payload. Most devices support larger frame sizes than this, and when all possible parties on the same local network can do so, it may be advantageous to choose a larger frame size; 9000 bytes is the most common option, as it allows a transport layer to convey 8 KB (8192) of data, while leaving room for various link, network, and transport layer headers.
Note that the use of frames carrying more than 1500 bytes of payload is not standardized, even though it is common practice.
The mtu property is used to configure the frame size. Note that this is the size of the payload, and excludes the preamble, checksum, and header. It also excludes the tag for devices that support tagging (see Virtual LANs below).
Care must be taken to ensure that all communication parties agree on the same size, or communication may cease to function properly.
Note that the mtu property refers to the link layer property. It may be necessary to configure upper layer protocols such as IP to use a different size when this changes. See ifconfig(8).
Most devices support virtual LANs (and also priority control tagging) though the use of a 4-byte tag inserted between the frame header and payload. The details of configuration of this are covered in the dladm(8) manual.
The correct method for applications to access Ethernet devices directly is to use the DLPI. See dlpi(4P) and libdlpi(3LIB) for further information.
The following DLPI parameters are presented to applications.
Maximum SDU | 1500 (or larger, as determined by the mtu property.) |
Minimum SDU | 0 |
Address length | 6 |
MAC type | DL_ETHER |
SAP length | -2 |
Service mode | DL_CLDLS |
Broadcast address | ff:ff:ff:ff:ff:ff
(6 bytes with all bits set) |
Note that if the application binds to SAP of 0, then standard IEEE 802.3 mode is assumed and the frame length is stored in place of the Ethernet type. Frames that arrive with the type field set to 1500 or less, are delivered to applications that bind to SAP 0.
Ethernet drivers on the support both DLPI style 1 and style 2 operation. Additionally, it is possible to configure provide “vanity” names to interfaces using the dladm(8) rename-link subcommand. Such vanity names are only accessible using DLPI style 1.
There may be other mechanisms available to configure link layer properties. Historically the ndd(8) command, and driver.conf(5) files could be used to do this. These methods are deprecated in favor of dladm(8) properties.
When present, the statistics and properties presented here are Committed. However, note that not every Ethernet device supports all of these, and some devices may support additional statistics and properties.
The DLPI and IEEE 802.3 itself are Standard.
libdlpi(3LIB), dlpi(4P), driver.conf(5), dladm(8), ifconfig(8), kstat(8), ndd(8), netstat(8)
IEEE 802.3: Ethernet, IEEE Standards Association.
Data Link Provider Interface (DLPI), The Open Group, 1997.
STREAMs Programming Guide, Sun Microsystems, Inc., January 2005.
July 25, 2023 | OmniOS |