Bagaimana cara mengetahui alasan mengapa antarmuka jaringan menjatuhkan paket?

Apakah ada cara di Linux untuk mendapatkan statistik tentang berbagai alasan paket dijatuhkan?

Pada semua antarmuka jaringan (openSUSE 12.3) pada beberapa server, ifconfigdan netstat -imelaporkan paket yang jatuh di resepsi. Ketika saya melakukan tcpdump, jumlah paket yang dijatuhkan berhenti meningkat, yang berarti bahwa antrian antarmuka tidak penuh dan menjatuhkan data. Jadi harus ada alasan lain mengapa hal ini terjadi (mis. Pkts multicast diterima sedangkan antarmuka bukan bagian dari grup multicast ini).

Di mana saya dapat menemukan informasi tersebut? (/ proc? / sys? beberapa log?)

Contoh statistik (gabungan dari / sys / class / net / <dev> / statistik dan output ethtool):

alloc_rx_buff_failed: 0
collisions: 0
dropped_smbus: 0
multicast: 1644
rx_align_errors: 0
rx_broadcast: 23626
rx_bytes: 1897203
rx_compressed: 0
rx_crc_errors: 0
rx_csum_offload_errors: 0
rx_csum_offload_good: 0
rx_dropped: 4738
rx_errors: 0
rx_fifo_errors: 0
rx_flow_control_xoff: 0
rx_flow_control_xon: 0
rx_frame_errors: 0
rx_length_errors: 0
rx_long_byte_count: 1998731
rx_long_length_errors: 0
rx_missed_errors: 0
rx_multicast: 1644
rx_no_buffer_count: 0
rx_over_errors: 0
rx_packets: 25382
rx_short_length_errors: 0
rx_smbus: 0
tx_aborted_errors: 0
tx_abort_late_coll: 0
tx_broadcast: 7
tx_bytes: 11300
tx_carrier_errors: 0
tx_compressed: 0
tx_deferred_ok: 0
tx_dropped: 0
tx_errors: 0
tx_fifo_errors: 0
tx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_heartbeat_errors: 0
tx_multicast: 43
tx_multi_coll_ok: 0
tx_packets: 63
tx_restart_queue: 0
tx_single_coll_ok: 0
tx_smbus: 0
tx_tcp_seg_failed: 0
tx_tcp_seg_good: 0
tx_timeout_count: 0
tx_window_errors: 0

Coba /sys/class/net/eth0/statistics/ (yaitu untuk eth0), itu tidak sempurna tetapi memecah kesalahan dengan mengirimkan / menerima dan oleh operator, jendela, fifo, crc, bingkai, panjang (dan beberapa lagi) jenis kesalahan.

Drops tidak sama dengan "diabaikan", netstatmenunjukkan statistik tingkat antarmuka, paket multicast diabaikan oleh level yang lebih tinggi (layer 3, tumpukan IP) tidak akan ditampilkan sebagai drop (meskipun mungkin muncul sebagai "difilter" pada beberapa Statistik NIC). Statistik agak rumit oleh berbagai fitur pembongkaran.

Anda bisa mendapatkan lebih banyak statistik jika Anda memiliki ethtool:

# ethtool -S eth0
 rx_packets: 60666755
 tx_packets: 2206194
 rx_bytes: 6630349870
 tx_bytes: 815877983
 rx_broadcast: 58230114
 tx_broadcast: 9307
 rx_multicast: 8406
 tx_multicast: 17
 rx_errors: 0
 tx_errors: 0
 tx_dropped: 0
 multicast: 8406
 collisions: 0
 rx_length_errors: 0
 rx_over_errors: 0
 rx_crc_errors: 0
 rx_frame_errors: 0
 rx_no_buffer_count: 0
 rx_missed_errors: 0
 tx_aborted_errors: 0
 tx_carrier_errors: 0
 tx_fifo_errors: 0
 tx_heartbeat_errors: 0
 [...]

Beberapa statistik bergantung pada driver NIC, seperti makna yang sebenarnya. Di atas adalah dari Intel e1000. Setelah melihat beberapa driver, beberapa mengumpulkan lebih banyak statistik daripada yang lain (statistik yang tersedia untuk ethtool cenderung disimpan dalam file sumber yang terpisah, misalnya drivers/net/ethernet/intel/e1000/e1000_ethtool.c, jika Anda perlu mencari-cari).

ethtool -i eth0akan menunjukkan detail driver, output lspci -vharus lebih detail, meskipun dengan sedikit kekacauan juga.

tg3.cFungsi Pembaruan dalam tg3_rx()hanya ada satu tempat yang kemungkinan terlihat dengan tp->rx_dropped++, tetapi kode dikotori dengan gotos, sehingga ada beberapa penyebab lain selain yang jelas, yaitu apa pun dengan goto drop_it atau goto drop_it_no_recycle. (Perhatikan bahwa penghitung drop adalah salah satu dari sedikit yang dikelola oleh pengemudi, sisanya dikelola oleh perangkat itu sendiri.)

Sumber driver yang harus saya tangani adalah 3.123. Tebakan terbaik saya adalah kode ini:

           if (len > (tp->dev->mtu + ETH_HLEN) &&
                skb->protocol != htons(ETH_P_8021Q)) {
                    dev_kfree_skb(skb);
                    goto drop_it_no_recycle;
            }

Periksa MTU, kemungkinan penyebabnya adalah frame jumbo, atau frame ethernet yang sedikit kebesaran untuk memungkinkan enkapsulasi. Saya tidak bisa menjelaskan mengapa tcpdumpmungkin mengubah perilaku, tidak diketahui mengubah antarmuka MTU. Perhatikan juga bahwa Anda dapat "melihat" paket yang lebih besar dari MTU dengan tcpdumpjika TSO / LRO diaktifkan ( penjelasan ).