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(1M), whereas properties are
visible using the dladm(1M)
show-linkprop subcommand. Tunables are properties that can
be changed using the dladm(1M)
set-linkprop subcommand. A more useful summary of current
operational state can be seen with the
The following statistics are accessible with
kstat(1M). 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  in the table below.
The following parameters are accessible with
dladm(1M). Some of these are normally
read-only. Other properties that are not specific to IEEE 802.3 / Ethernet
links are also available via dladm(1M),
and are documented in its man page rather than here.
- Advertises 1000 Mbps full-duplex support.
- Advertises 1000 Mbps half-duplex support.
- Advertises 100 Mbps full-duplex support.
- Advertises 100 Gbps support.
- Advertises 100 Mbps half-duplex support.
- Advertises 100BASE-T4 support.
- Advertises 10 Mbps full-duplex support.
- Advertises 10 Gbps support.
- Advertises 10 Mbps half-duplex support.
- Advertises 2.5 Gbps support.
- Advertises 50 Gbps support.
- Advertises 40 Gbps support.
- Advertises 25 Gbps support.
- Advertises 5 Gbps support.
- Advertises auto-negotiation support.
- Advertises asymmetric flow control support.
- Advertises flow control support.
- Remote fault status sent to peer.
- Mis-aligned frames received.
- Broadcast frames received.
- Broadcast frames transmitted.
- Device supports 1000 Mbps full-duplex.
- Device supports 1000 Mbps half-duplex.
- Device supports 100 Mbps full-duplex.
- Device supports 100 Gbps.
- Device supports 100 Mbps half-duplex.
- Device supports 100BASE-T4.
- Device supports 10 Mbps full-duplex.
- Device supports 10 Gpbs.
- Device supports 10 Mbps half-duplex.
- Device supports 2.5 Gbps.
- Device supports 50 Gpbs.
- Device supports 40 Gpbs.
- Device supports 25 Gpbs.
- Device supports 5 Gbps.
- Device supports asymmetric flow control.
- Device supports auto-negotiation.
- Device supports symmetric flow control.
- Device supports remote fault notification.
- Frames dropped due to loss of link.
- Transmits deferred due to link activity.
- Frames dropped due to too many collisions.
- Frames received with bad frame checksum.
- Frames with at least one collision.
- Receive errors.
- Link speed in bits per second.
- Frames received successfully.
- Jabber errors.
- Asymmetric flow control; works together with link_pause.
See the description for it below.
- Link was auto-negotiated.
- Link duplex status, values as follows:
- Link flow control available; works together with
link_asmpause. The meanings of these bits are:
||No flow control.
||Symmetric flow control.
||Honor received pause frames.
||Send pause frames when congested.
- Link state; 0 for down, 1 for up.
- Link is up if 1.
- Peer supports 1000 Mbps full-duplex.
- Peer supports 1000 Mbps half-duplex.
- Peer supports 100 Mbps full-duplex.
- Peer supports 100 Gbps full-duplex.
- Peer supports 100 Mbps half-duplex.
- Peer supports 100BASE-T4.
- Peer supports 10 Mbps full-duplex.
- Peer supports 10 Gbps.
- Peer supports 10 Mbps half-duplex.
- Peer supports 2.5 Gbps.
- Peer supports 5 Gbps.
- Peer supports 50 Gbps.
- Peer supports 40 Gbps.
- Peer supports 25 Gbps.
- Peer supports asymmetric flow control.
- Peer supports auto-negotiation.
- Peer advertises flow control support.
- Peer announces a remote fault.
- Generic receive errors.
- Generic transmit errors.
- Frames with more than one collision.
- Multicast frames received.
- Multicast frames transmitted.
- Receive frames dropped due to lack of resources.
- Transmit frames dropped due to lack of resources.
- Bytes (octets) transmitted successfully.
- Transmit errors.
- Overflow errors.
- Frames successfully transmitted.
- Interface is in promiscuous mode.
- Bytes (octets) received successfully.
- Frames received that were too short.
- Squelch errors.
- Frames received that were too long.
- Late collisions on transmit.
- Underflow errors.
- Frames received with no local recipient.
- Transceiver address.
- Transceiver vendor and device ID.
- Identifies the type of transceiver in use. Values are as follows:
||Unknown or undefined.
With modern devices, auto-negotiation is normally handled automatically. With 10
Gbps and 1000 Gbps, 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.
- Link speed, in Mbps per second (dladm only).
- Link duplex, either "full" or "half".
- Link state, either "up" or "down".
- Maximum link frame size in bytes. See
- Flow control setting, one of "no", "tx",
"rx", or "bi". See
- Advertising 10 Gbps support.
- Enable 10 Gbps support.
- Advertising 1000 Mbps full-duplex support.
- Enable 1000 Mbps full-duplex.
- Advertising 1000 Mbps half-duplex support.
- Enable 1000 Mbps half-duplex.
- Advertising 100 Mbps full-duplex support.
- Enable 100 Mbps full-duplex.
- Advertising 100 Mbps half-duplex support.
- Enable 100 Mbps half-duplex.
- Advertising 10 Mbps full-duplex support.
- Enable 100 Mbps full-duplex.
- Advertising 10 Mbps half-duplex support.
- Enable 10 Mbps half-duplex.
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:
- 10 Gbps (10gfdx)
- 1000 Mbps full-duplex (1000fdx)
- 1000 Mbps half-duplex (1000hdx)
- 100 Mbps full-duplex (100fdx)
- 100BASE-T4 (100T4)
- 100 Mbps half-duplex (100hdx)
- 10 Mbps full-duplex (10fdx)
- 10 Mbps half-duplex (10hdx)
Advertisement of these modes can be enabled or disabled by setting
the appropriate en_ property in
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 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:
||Neither send, nor honor pause frames.
||Send pause frames, provided that the peer can support them, but do not
||Receive and honor pause frames.
||Both send and receive (and honor) pause frames.
The statistics for flow control (adv_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.
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
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
The correct method for applications to access Ethernet devices directly is to
use the DLPI. See dlpi(7P) and
libdlpi(3LIB) for further
The following DLPI parameters are presented to applications.
||1500 (or larger, as determined by the mtu
(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
rename-link subcommand. Such vanity names are only
accessible using DLPI style 1.