Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

i am running centos 6.2 and one of the interfaces has high dropped packets. this is the info from ethtool, is this is a network issue??

[root@w native]# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 10:1F:74:2E:6A:80
          RX packets:38459399 errors:0 dropped:38459399 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2334427918 (2.1 GiB)  TX bytes:258 (258.0 b)

[root@wye native]# ethtool eth1
Settings for eth1:
        Supported ports: [ TP ]
        Supported link modes:   1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes

[root@w native]# ethtool -k eth1
Offload parameters for eth1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off

[root@w native]# ethtool -S eth1
NIC statistics:
     tx_events: 12086471
     rx_crc_errors: 0
     rx_alignment_symbol_errors: 0
     rx_pause_frames: 0
     rx_control_frames: 0
     rx_in_range_errors: 0
     rx_out_range_errors: 0
     rx_frame_too_long: 0
     rx_address_match_errors: 163123495
     rx_dropped_too_small: 0
     rx_dropped_too_short: 0
     rx_dropped_header_too_small: 0
     rx_dropped_tcp_length: 0
     rx_dropped_runt: 0
     rxpp_fifo_overflow_drop: 0
     rx_input_fifo_overflow_drop: 0
     rx_ip_checksum_errs: 0
     rx_tcp_checksum_errs: 4
     rx_udp_checksum_errs: 2
     tx_pauseframes: 0
     tx_controlframes: 0
     rx_priority_pause_frames: 0
     pmem_fifo_overflow_drop: 0
     jabber_events: 0
     rx_drops_no_pbuf: 0
     rx_drops_no_txpb: 0
     rx_drops_no_erx_descr: 0
     rx_drops_no_tpre_descr: 0
     rx_drops_too_many_frags: 0
     rx_drops_invalid_ring: 0
     forwarded_packets: 35
     rx_drops_mtu: 0
     eth_red_drops: 0
     be_on_die_temperature: 50
     rxq0: rx_bytes: 2299912112
     rxq0: rx_pkts: 38331860
     rxq0: rx_polls: 37803085
     rxq0: rx_events: 0
     rxq0: rx_compl: 38331860
     rxq0: rx_mcast_pkts: 14
     rxq0: rx_post_fail: 0
     rxq0: rx_drops_no_skbs: 0
     rxq0: rx_drops_no_frags: 0
     rxq1: rx_bytes: 3398729
     rxq1: rx_pkts: 16154
     rxq1: rx_polls: 9846
     rxq1: rx_events: 0
     rxq1: rx_compl: 16154
     rxq1: rx_mcast_pkts: 3392
     rxq1: rx_post_fail: 0
     rxq1: rx_drops_no_skbs: 0
     rxq1: rx_drops_no_frags: 0
     rxq2: rx_bytes: 206100
     rxq2: rx_pkts: 3379
     rxq2: rx_polls: 3379
     rxq2: rx_events: 0
     rxq2: rx_compl: 3379
     rxq2: rx_mcast_pkts: 3319
     rxq2: rx_post_fail: 0
     rxq2: rx_drops_no_skbs: 0
     rxq2: rx_drops_no_frags: 0
     rxq3: rx_bytes: 30735472
     rxq3: rx_pkts: 105087
     rxq3: rx_polls: 105087
     rxq3: rx_events: 0
     rxq3: rx_compl: 105087
     rxq3: rx_mcast_pkts: 11078
     rxq3: rx_post_fail: 0
     rxq3: rx_drops_no_skbs: 0
     rxq3: rx_drops_no_frags: 0
     rxq4: rx_bytes: 180245
     rxq4: rx_pkts: 2998
     rxq4: rx_polls: 2998
     rxq4: rx_events: 0
     rxq4: rx_compl: 2998
     rxq4: rx_mcast_pkts: 2984
     rxq4: rx_post_fail: 0
     rxq4: rx_drops_no_skbs: 0
     rxq4: rx_drops_no_frags: 0
     txq0: tx_compl: 0
     txq0: tx_bytes: 0
     txq0: tx_pkts: 0
     txq0: tx_reqs: 0
     txq0: tx_wrbs: 0
     txq0: tx_compl: 0
     txq0: tx_stops: 0
     txq1: tx_compl: 0
     txq1: tx_bytes: 0
     txq1: tx_pkts: 0
     txq1: tx_reqs: 0
     txq1: tx_wrbs: 0
     txq1: tx_compl: 0
     txq1: tx_stops: 0
     txq2: tx_compl: 0
     txq2: tx_bytes: 0
     txq2: tx_pkts: 0
     txq2: tx_reqs: 0
     txq2: tx_wrbs: 0
     txq2: tx_compl: 0
     txq2: tx_stops: 0
     txq3: tx_compl: 0
     txq3: tx_bytes: 0
     txq3: tx_pkts: 0
     txq3: tx_reqs: 0
     txq3: tx_wrbs: 0
     txq3: tx_compl: 0
     txq3: tx_stops: 0
     txq4: tx_compl: 3
     txq4: tx_bytes: 258
     txq4: tx_pkts: 3
     txq4: tx_reqs: 3
     txq4: tx_wrbs: 6
     txq4: tx_compl: 3
     txq4: tx_stops: 0
     txq5: tx_compl: 0
     txq5: tx_bytes: 0
     txq5: tx_pkts: 0
     txq5: tx_reqs: 0
     txq5: tx_wrbs: 0
     txq5: tx_compl: 0
     txq5: tx_stops: 0
     txq6: tx_compl: 0
     txq6: tx_bytes: 0
     txq6: tx_pkts: 0
     txq6: tx_reqs: 0
     txq6: tx_wrbs: 0
     txq6: tx_compl: 0
     txq6: tx_stops: 0
     txq7: tx_compl: 0
     txq7: tx_bytes: 0
     txq7: tx_pkts: 0
     txq7: tx_reqs: 0
     txq7: tx_wrbs: 0
     txq7: tx_compl: 0
     txq7: tx_stops: 0
share|improve this question

Can you provide any information on what the server or application is doing? Assuming you have a managed switch, are there any corresponding errors on the switch port?

  • In general, check the physical bits first (cabling).
  • Check the interface statistics on the related switch ports (you tagged this debian, so are you sending data between two systems?)
  • Examine your system load and processor utilization on the system with the interface errors.
  • Run tests. If you're communication between two servers, iperf is a good network load generator for this type of testing.
  • If this is consistent or repeatable, you could analyze a tcpdump of the relevant interface.
  • optional - Explore sysctl.conf settings... This is really based on what your server is doing. If this were a messaging application or something that requires heavy throughout, we could look at network buffer settings, etc. I've been playing with the dropwatch utility described here as well.
share|improve this answer
I don't think this is a physical issue - the kernel is receiving all of these packets w/o errors. The ifconfig indicates that it's part of a bonded link - the bonding configuration on both the host and the upstream switch... It may be receiving frames in the context of the channel that aren't supposed to be delivered. – rnxrx Jun 1 '12 at 20:56
I didn't notice the SLAVE in the ifconfig output. Good catch. There are still missing details, so this is enough to start exploring. – ewwhite Jun 1 '12 at 21:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.