NAME
na.etherif - ethernet interface statistics
DESCRIPTION
na.etherif returns statistics for the Lance (le) and the Intel (ie) Ethernet interfaces. By default the agent reads /vmunix to get the kernel namelist.
A reporting interval is specified by the management application. If a reporting interval is not specified, the agent will send a report every 30 seconds.
ATTRIBUTES
na.etherif has two attribute tables, input and output .
The input table reports input statistics about a particular ethernet interface, using ifname as the key.
ifname
Interface name (string[5])
ipkts
Number of packets received since system boot (counter)
ierrs
Number of input errors since system boot (counter)
If a particular Ethernet interface's error counts are abnormally low while the error counts for other interfaces are high, the interface with the abnormally low error counts is likely to be the one that is malfunctioning.
ierrate
Input error rate since system boot (in thousandths of a percent)
This is an agent-supplied calculation of the input errors over input packets. For simplicity in thresholding and graphing, this value is multiplied by 1000 and returned as a gauge.
Watch for an error rate of less than 25 (0.025%). An error rate higher than this may be due to electrical problems with the transceiver or drop cable, or to packets dropped due to lack of receive buffers. Machines that receive slower than the transmitters (for instance, a Sun-3 server with a bunch of Sun-4 clients) and machines with more than 2 interfaces are most likely to run out of receive buffers.
Under SunOS 4.1 , the file /sys/sunif/ie_conf.c contains default values for the number of ie interface buffers. le_conf.c configures the le interfaces. The values of interest are:
The total size of the Ethernet receive buffers and descriptors must not exceed about 125 Kbytes on a Sun 4/4x0 machine, so that buffers for off-board Ethernet interfaces may be I/O cached.
icrc Number of packets received with CRC errors since system boot (counter)
iover
Number of receive overruns since system boot (counter)
ibufs
(SunOS 4.x only) Current number of receive buffers (gauge)
ibufdesc
(SunOS 4.x only) Current number of receive buffer descriptors (gauge)
idiscard
(SunOS 4.x only) Number of packets missed/discarded since system boot (counter)
iframerr
Number of packets seen with framing/alignment errors since system boot (counter)
iframedesc
(SunOS 4.x only) Current number of receive frame descriptors (gauge) - ie only
imiss
(SunOS 5.x only) Input packets missed
inocanput
(SunOS 5.x only) Number of errors trying to send packets upstream
The output table reports output statistics about a particular Ethernet interface, using ifname as the key.
ifname
Interface name (string[5])
opkts
Number of packets sent since system boot (counter)
oerrs
Number of output errors since system boot (counter)
ocolls
Number of collisions for a given packet since system boot (counter)
odefers
Number of deferred transmissions since system boot (counter). The SunOS 4.0 lance (le) driver doesn't keep this information; it will be returned as zero.
oavail%
Percentage of time (since boot) waiting packets could get onto the wire (gauge)
Each time the Ethernet chip goes to send a packet, the following might happen:
1. Chip detects another transmission on the cable, so defers its own.
2. Chip sends the packet, but it collides with another. The chip then retries later.
3. Chip sends the packet okay.
Other things can happen, like network jams and carrier losses, but we don't worry about those for oavail% .
The ovail% field indicates the percentage of time a packet was able to go out OK: the "availability" of the network since the system was rebooted.
In mathematical terms,
packets sent
If ovail% = 30, the system has been spending a lot of time trying to put packets onto a very busy network. The two attributes ocolls and odefers will point you towards why the availability is so low. It doesn't mean the network load is 70 percent, but numbers that low indicate something is wrong with the system. Or, if these numbers correlate across many machines, you've got too much traffic on the network. See the other attributes (for example, ojams or nodcd) for possible supporting evidence. If you see a high nodcd, perhaps your transceiver or drop cable is bad. You might use 90 percent as a baseline target and worry about values lower than 85 percent.
ojams
(SunOS 4.x only) Number of network jams on this interface since system boot (counter)
nodcd
Number of times carrier lost since system boot (counter)
ounder
Number of transmit underruns since system boot (counter)
odrops
(SunOS 4.x only) Number of output queue packets dropped since system boot (counter)
watchdog
(SunOS 4.x only) Number of watchdog timer resets since system boot (counter). The SunOS 4.0 lance (le) driver doesn't keep this information, so it will be returned as zero.
requeues
Number of transmit requeues/retries since system boot (counter)
obufdesc
(SunOS 4.x only) Current number of transmit buffer descriptors (gauge)
onobufs
Number of times driver ran out of transmit buffers since system boot (counter)
copies
(SunOS 4.x only) Number of output copies since system boot (counter)
nocts
(SunOS 4.x only) Number of times Clear To Send lost since system boot (counter) - ie only
obufs
(SunOS 4.x only) Current number of transmit buffers (gauge) - ie only
oframedesc
(SunOS 4.x only) Current number of transmit frame descriptors (gauge) - ie only
ofreedesc
(SunOS 4.x only) Current number of free transmit buffer descriptors (gauge) - ie only
lcoll
Number of late collisions since system boot (counter) le only
obuferr
(SunOS 4.x only) Number of le BUFF errors since system boot (counter) - le only
oinits
(SunOS 5.x only) Number of times the hardware has been initialized
OPTIONS
The SunOS 4.x version accepts one option: the name of an alternate file to use to get the kernel namelist.
The SunOs 5.x version has no options.
ERRORS
can't read kernel memory
The agent uid does not have permission to read kernel memory, /dev/kmem . Run the agent as root (default case if agent started by inetd (1M) ), or give read permission to the uid the agent is running under.
The error message can also occur if the agent can't find or read the file containing the kernel namelist.
NOTES
Keep in mind that the ovail% attribute is NOT an instantaneous value; it's a measure since boot time. The etherif agent currently has no way of returning output availability as an instantaneous value. Although it would be nice to see such a number, the manager should do the calculation. (The Console, alas, can't do mathematical operations between attributes yet.)
The way collision count is tallied depends on the Ethernet chip (Lance or Intel). The Intel (ie) chip counts every occurrence, while the Lance (le) chip counts collision on a per - packet basis. If a packet is successfully sent after the first retry, the collision count is one. If a packet is successfully sent after two or more retries, the chip returns a maximum count of two collisions. For example, if packet a had four retries and sometime later packet d had five retries, the cumulative collision count is four - two for each packet - and not the real count of nine. This means the ovail% value will tend to be (artificially) higher for le devices.
The description on ierrate was taken from a document written by Hal Stern of Sun's Northeast Area Consulting Group.