ネットワークインターフェイスがパケットをドロップしている理由を調べる方法

Linuxでパケットがドロップされたさまざまな理由に関する統計を取得する方法はありますか？

複数のサーバー上のすべてのネットワークインタフェース（openSUSEの12.3）に、ifconfigおよびnetstat -i受信にドロップされたパケットを報告しています。を実行するtcpdumpと、ドロップされたパケットの数が増えなくなります。つまり、インターフェイスキューがいっぱいにならず、データがドロップされます。そのため、これが発生する理由は他にもあるに違いありません（たとえば、マルチキャストパケットは受信されますが、インターフェイスはこのマルチキャストグループの一部ではありません）。

そのような情報はどこで入手できますか？（/ proc？/ sys？いくつかのログ？）

統計の例（/ sys / class / net / <dev> / statisticsと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

試してみてください/sys/class/net/eth0/statistics/ （例：）、eth0完璧ではありませんが、エラーを送信/受信およびキャリア、ウィンドウ、FIFO、CRC、フレーム、長さ（およびその他の）エラーの種類ごとに分類します。

ドロップは「無視」とはnetstat異なり、インターフェイスレベルの統計情報を表示します。より高いレベル（レイヤー3、IPスタック）によって無視されたマルチキャストパケットはドロップとして表示されません（ただし、 NIC統計）。統計は、さまざまなオフロード機能によって多少複雑になる場合があります。

次のものがある場合、より多くの統計情報を取得できます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
 [...]

正確な意味と同様に、一部の統計はNICドライバーに依存します。上記はIntelからのものe1000です。一握りのドライバーを見て、一部のドライバーは他のドライバーよりも多くの統計を収集します（ethtoolで使用可能な統計は、たとえばdrivers/net/ethernet/intel/e1000/e1000_ethtool.c、突っ込む必要がある場合など、別のソースファイルに保持される傾向があります）。

ethtool -i eth0ドライバーの詳細が表示されますが、出力はlspci -vより詳細である必要がありますが、少し混乱しています。

更新は でtg3.c機能tg3_rx()可能性が高いとルックスという一つだけの場所がありますtp->rx_dropped++、しかし、コードが散らばっているgotoのは、そうで明白、すなわち何よりも他のいくつかの原因があるgoto drop_it かをgoto drop_it_no_recycle。（ドロップカウンターはドライバーが管理する数少ないものの1つであり、残りはデバイス自体が管理することに注意してください。）

手元にあるドライバーソースは3.123です。私の最良の推測はこのコードです：

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

MTUを確認します。考えられる原因は、ジャンボフレーム、またはカプセル化を許可するわずかに大きすぎるイーサネットフレームです。tcpdumpインターフェースのMTUを変更することは知られていないので、なぜ振る舞いを変更するのか説明できません。また、TSO / LROが有効になっているtcpdump場合、MTUよりも大きいパケットを「見る」場合があることに注意してください（説明）。