Testing Your NIC



Testing Your NIC

It is always a good practice in troubleshooting to be versed in monitoring the status of your NIC from the command line. The following sections introduce a few commands that will be useful.

Viewing Your Activated Interfaces

The ifconfig command without any arguments gives you all the active interfaces on your system. Interfaces will not appear if they are shut down:

     [root@bigboy tmp]# ifconfig

Note

Interfaces will appear if they are activated but have no link. We'll soon discuss how to determine the link status using commands.


Viewing All Interfaces

The ifconfig -a command provides all the network interfaces, whether they are functional or not. Interfaces that are shut down by the systems administrator or are nonfunctional will not show an IP address line and the word UP will not show in the second line of the output. This can be seen in the next examples.

Shut Down Interface
     wlan0 Link encap:Ethernet  HWaddr 00:06:25:09:6A:D7
           BROADCAST MULTICAST  MTU:1500  Metric:1
           RX packets:2924 errors:0 dropped:0 overruns:0 frame:0
           TX packets:2287 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:100
           RX bytes:180948 (176.7 Kb)  TX bytes:166377 (162.4 Kb)
           Interrupt:10 Memory:c88b5000-c88b6000

Active Interface
     wlan0 Link encap:Ethernet  HWaddr 00:06:25:09:6A:D7
           inet addr:216.10.119.243  Bcast:216.10.119.255
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:2924 errors:0 dropped:0 overruns:0 frame:0
           TX packets:2295 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:100
           RX bytes:180948 (176.7 Kb)  TX bytes:166521 (162.6 Kb)
           Interrupt:10 Memory:c88b5000-c88b6000

Testing Link Status from the Command Line

Both the mii-tool and ethtool commands provide reports on the link status and duplex settings for supported NICs.

When used without any switches, mii-tool gives a very brief report. Use it with the -v switch because it provides more information on the supported autonegotiation speeds of the NIC, and this can be useful in troubleshooting speed and duplex issues.

The ethtool command provides much more information than mii-tool and should be your command of choice, especially because mii-tool will be soon deprecated in Linux. In both of the following examples, the NICs are operating at 100Mbps, full duplex, and the link is ok.

Link Status Output from mii-tool
     [root@bigboy tmp]# mii-tool -v
     eth0: 100 Mbit, full duplex, link ok
       product info: Intel 82555 rev 4
       basic mode:   100 Mbit, full duplex
       basic status: link ok
       capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
       advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
     flow-control
       link partner: 100baseTx-HD
     [root@bigboy tmp]#

Link Status Output from ethtool
     [root@bigboy tmp]# ethtool eth0
     Settings for eth0:
             Supported ports: [ TP MII ]
             Supported link modes:   10baseT/Half 10baseT/Full
                                     100baseT/Half 100baseT/Full
             Supports auto-negotiation: Yes
             Advertised link modes:  10baseT/Half 10baseT/Full
                                     100baseT/Half 100baseT/Full
             Advertised auto-negotiation: No
             Speed: 100Mb/s
             Duplex: Full
             Port: MII
             PHYAD: 1
             Transceiver: internal
             Auto-negotiation: off
             Supports Wake-on: g
             Wake-on: g
             Current message level: 0x00000007 (7)
             Link detected: yes
     [root@bigboy tmp]#

Viewing NIC Errors

Errors are a common symptom of slow connectivity due to poor configuration or excessive bandwidth utilization. They should always be corrected whenever possible. Error rates in excess of 0.5% can result in noticeable sluggishness.

Ifconfig Error Output

The ifconfig command also shows the number of overrun, carrier, dropped packet, and frame errors.

     wlan0   Link encap:Ethernet  HWaddr 00:06:25:09:6A:D7
             BROADCAST MULTICAST  MTU:1500 Metric:1
             RX packets:2924 errors:0 dropped:0 overruns:0 frame:0
             TX packets:2287 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:100
             RX bytes:180948 (176.7 Kb)  TX bytes:166377 (162.4 Kb)
             Interrupt:10 Memory:c88b5000-c88b6000

ethtool Error Output

The ethtool command can provide a much more detailed report when used with the -S switch:

     [root@probe-001 root]# ethtool -S eth0
     NIC statistics:
          rx_packets: 1669993
          tx_packets: 627631
          rx_bytes: 361714034
          tx_bytes: 88228145
          rx_errors: 0
          tx_errors: 0
          rx_dropped: 0
          tx_dropped: 0
          multicast: 0
          collisions: 0
          rx_length_errors: 0
          rx_over_errors: 0
          rx_crc_errors: 0
          rx_frame_errors: 0
          rx_fifo_errors: 0
          rx_missed_errors: 0
          tx_aborted_errors: 0
          tx_carrier_errors: 0
          tx_fifo_errors: 0
          tx_heartbeat_errors: 0
          tx_window_errors: 0
          tx_deferred: 0
          tx_single_collisions: 0
          tx_multi_collisions: 0
          tx_flow_control_pause: 0
          rx_flow_control_pause: 0
          rx_flow_control_unsupported: 0
          tx_tco_packets: 0
          rx_tco_packets: 0
     [root@probe-001 root]#

Possible Causes of Ethernet Errors

The following are possible causes of Ethernet errors:

  • Collisions: The NIC card detects itself and another server on the LAN attempting data transmissions at the same time. Collisions can be expected as a normal part of Ethernet operation and are typically below 0.1% of all frames sent. Higher error rates are likely to be caused by faulty NIC cards or poorly terminated cables.

  • Single Collisions: The Ethernet frame went through after only one collision.

  • Multiple Collisions: The NIC had to attempt multiple times before successfully sending the frame due to collisions.

  • CRC Errors: Frames were sent but were corrupted in transit. The presence of CRC errors, but not many collisions, usually is an indication of electrical noise. Make sure that you are using the correct type of cable, that the cabling is undamaged, and that the connectors are securely fastened.

  • Frame Errors: An incorrect CRC and a noninteger number of bytes are received. This is usually the result of collisions or a bad Ethernet device.

  • FIFO and Overrun Errors: The number of times that the NIC was blocked from transferring data from the network to its memory buffers because of the speed limitations of the hardware. This is usually a sign of excessive traffic.

  • Length Errors: The received frame length was less than or exceeded the Ethernet standard. This is most frequently due to incompatible duplex settings.

  • Carrier Errors: Errors are caused by the NIC losing its link connection to the hub or switch. Check for faulty cabling or faulty interfaces on the NIC and networking equipment.