[SunHELP] netstat -I hme0 5, how to interpret ???

Wed May 22 07:00:46 CDT 2002

No sun wizard, (grasshopper is more like it!) but I think I can help here..

Courtesy of Rob Thomas's website, here is what you get from a netstat -k <if>
and what it means. Short answer for you is yes, ipackets (what I think you're
looking at)
are errors you are receiving from somewhere else. Sounds like your machine is
happy
and healthy.  hth - Joe
---------------------------------------------
eg: netstat -k hme0

 - returns a slew of statistics, most of which should be 0 if everything is
working ok.

@(#)How to read the output of netstat -k
14 AUG 2000 Rob Thomas robt at cymru.com

One of the most powerful, yet least utilized options for netstat is the
-k flag.  The "k" stands for kstat, a facility for perusing the kernel
statistics.

Early releases of Solaris (< 2.6) did not allow you to specify the inter-
face.  However, with Solaris 2.6 and higher, you may specifiy the inter-
face on the command line.  Below is a sample, as well as an explanation
of each variable in the output.  I have expanded the description provided
by Sun when I felt it was less than self-explanatory.

example: netstat -k hme0

hme0:
ipackets 85402 ierrors 0 opackets 470 oerrors 0 collisions 1
defer 0 framing 0 crc 0 sqe 0 code_violations 0 len_errors 0
drop 0 buff 0 oflo 0 uflo 0 missed 0 tx_late_collisions 0
retry_error 0 first_collisions 0 nocarrier 0 inits 7 nocanput 0
allocbfail 0 runt 0 jabber 0 babble 0 tmd_error 0 tx_late_error 0
rx_late_error 0 slv_parity_error 0 tx_parity_error 0 rx_parity_error 0
slv_error_ack 0 tx_error_ack 0 rx_error_ack 0 tx_tag_error 0
rx_tag_error 0 eop_error 0 no_tmds 0 no_tbufs 0 no_rbufs 0
rx_late_collisions 0

ipackets           packets received
ierrors            malformed packets received
opackets           packets sent
oerrors            output errors
collisions         transmit collisions for a given packet
defer              deferred output transmissions ( but still sent )
framing            packets seen with framing or alignment errors
crc                packets received with CRC (checksum) errors
sqe                SQE test  errors
code_violations    code violation errors
len_errors         rx len errors (packet too large)
buff               buffer errors recv packet sizes > buffer size
drop               recv packets dropped
oflo               number of recv overflow due to a busy backplane
uflo               number of xmit underflow due to a busy backplane
missed             input packets recv missed
tx_late_collisions late collisions recv
retry_error        number xmit retry failures (for Ethernet, this is > 16
                   retries)
first_collisions   first collisions
nocarrier          carrier (link) lost since system boot
inits              hardware has been initialized by an ioctl call
nocanput           errors trying to send packets upstream, canput() failed
allocbfail         times driver ran out of transmit buffers, allocb() failed
runt               recv runt (packet size < 64 bytes) packets, often
		     the product of collisions
jabber             jabber (improper electrical signal) errors
babble             babble (host transmitting beyond the time limit) errors
tmd_error          chained tx desc. errors
tx_late_error      SBUS tx late error
rx_late_error      SBUS rx late error
slv_parity_error   slave parity errors
tx_parity_error    tx parity errors
rx_parity_error    rx parity errors
slv_error_ack      slave error acks
tx_error_ack       tx error acks
rx_error_ack       rx error acks
tx_tag_error       tx tag error
rx_tag_error       rx tag error
eop_error          eop error
no_tmds            out of tmds
no_tbufs           out of xmit buffers
no_rbufs           out of recv buffers
rx_late_collisions recv late collisions, generally caused by
                   exceeding the maximum cable length dictates
		     or faulty hardware

Rob Thomas, robt at cymru.com
http://www.enteract.com/~robt

>>> <duke.glover at verizon.com> 05/22/02 07:42AM >>>
Hello sun wizards,

I am examining the output of the command "netstat -I hme0 5"

I see input errors (about 5 every 100 packets), but I see no output errors.
How would I read this ?  Does this mean that the errors are being sent to
my hme0 interface from the directly connected router/switch ?  Or does it
mean that my hme0 is having problems accepting the incoming packets ?
Also, I see 0 collisions.  Obviously this is a good thing.   :)

Thank you for any insight.

Duke Glover
*******************************************
_______________________________________________
SunHELP maillist  -  SunHELP at sunhelp.org
http://www.sunhelp.org/mailman/listinfo/sunhelp

>>> <duke.glover at verizon.com> 05/22/02 07:42AM >>>
Hello sun wizards,

I am examining the output of the command "netstat -I hme0 5"

I see input errors (about 5 every 100 packets), but I see no output errors.
How would I read this ?  Does this mean that the errors are being sent to
my hme0 interface from the directly connected router/switch ?  Or does it
mean that my hme0 is having problems accepting the incoming packets ?
Also, I see 0 collisions.  Obviously this is a good thing.   :)

Thank you for any insight.

Duke Glover
*******************************************
_______________________________________________
SunHELP maillist  -  SunHELP at sunhelp.org
http://www.sunhelp.org/mailman/listinfo/sunhelp

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************