Solaris Troubleshooting : Ethernet Hardware Error Checking

When troubleshooting for Ethernet hardware issues, it might be useful to check the interface’s error statistics, but what do they mean?

When a host receives a packet, the Ethernet interface performs the integrity checking to verify Ethernet frame validity. Some of the error conditions the interface checks include:

  • Runts If the delivered packet is less than 64 bytes, the packet is too short and is discarded. Runts are usually caused by collisions. They may also be caused by poor wiring and electrical interference.
  • Jabbers If the received packet is greater than 1500 bytes (MTU), the packet is too long and is discarded. Indicates a device is having problems electrically.
  • Bad CRC If the received packet fails the CRC(Cyclical Redundancy Check), the packet is corrupted and therefore discarded
  • Long This is a frame that is between 1518 and 6000 bytes long. Normally it is due to faulty hardware or software on the sending station.
  • Giant This is a frame that is more than 6000 bytes long. Normally it is due to faulty hardware or software on the sending station.
  • Frame Check Sequence(FCS) Error This defines a frame that may or may not have the right number of bits but they have been corrupted between the sender and receiver, perhaps due to interference on the cable.

The interface statistics can be obtained by the kstat command, followed by the interface name and instance. You may want to check for input and output errors and the associated subcounters.

For example, for this eri0 interface we see 3 incoming hardware errors, 2 of them are Jabbers and 1 produced a length error (Long or Giant) :

#kstat eri:0

ierrors                         3
jabber                          2
oerrors                       0
runt                              0
rx_crc_err                0
rx_length_err          1



I have started ( aka in 2009 as my own personal reference blog, and later sometime i have realized that my leanings might be helpful for other unixadmins if I manage my knowledge-base in more user friendly format. And the result is today's' You can connect me at -

7 Responses

  1. dedektif says:

    Woah this weblog is magnificent i really like studying your articles. Keep up the good work! You already know, lots of individuals are searching around for this information, you could aid them greatly.

  2. momoalc says:

    Dear Gurku,

    I new in solaris network and having some error on rxmax_crc_err can i know what is it and on the below logs what is wrong

    bash-3.2# kstat -m nxge -i 2 | grep -i crc
            macrcv_errors                   0
            rxmac_crc_err                   140569

    nxge0: flags=1000843 mtu 1500 index 5
            inet netmask ffffffc0 broadcast
            ether 0:21:28:30:13:a6 
    nxge2: flags=1000843 mtu 1500 index 6
            inet netmask ffffffc0 broadcast
            ether 0:21:28:30:13:a8 

    bash-3.2# dladm show-link
    e1000g0         type: non-vlan  mtu: 1500       device: e1000g0
    e1000g1         type: non-vlan  mtu: 1500       device: e1000g1
    e1000g2         type: non-vlan  mtu: 1500       device: e1000g2
    e1000g3         type: non-vlan  mtu: 1500       device: e1000g3
    e1000g4         type: non-vlan  mtu: 1500       device: e1000g4
    e1000g5         type: non-vlan  mtu: 1500       device: e1000g5
    nxge0           type: non-vlan  mtu: 1500       device: nxge0
    nxge1           type: non-vlan  mtu: 1500       device: nxge1
    nxge2           type: non-vlan  mtu: 1500       device: nxge2
    nxge3           type: non-vlan  mtu: 1500       device: nxge3
    aggr1           type: non-vlan  mtu: 1500       aggregation: key 

    • Ramdev Ramdev says:

      Hello, the CRC error represents that packet sizes that was actually sent from the other end and received from the servers side are mismatch. and most commons cause for these issues is either bad cabling or bad port. you need to get network team help to see if there are any packet drops at the switch port connected to this server.

      also check if there are any packet drops at this interface using # netstat -i

  3. momoalc says:

    Thank You Ramdev,

    The issue has been solved  as recommended by the network team.
    Keep doing the good work 

  4. Ramdev Ramdev says:

    Glad to know that problem resolved.

  1. September 16, 2015

    […] Read – Ethernet Hardware Error Checking […]

  2. September 17, 2015

    […] Read – Ethernet Hardware Error Checking […]

What is in your mind, about this post ? Leave a Reply

  Our next learning article is ready, subscribe it in your email

What is your Learning Goal for Next Six Months ? Talk to us