Comment trouver la ou les raisons pour lesquelles l'interface réseau laisse tomber des paquets ?

Essayer /sys/class/net/eth0/statistics/ (c'est-à-dire pour eth0 ), il n'est pas parfait mais il décompose les erreurs par transmission/réception et par porteuse, fenêtre, fifo, crc, trame, longueur (et quelques autres) types d'erreurs.

Les chutes ne sont pas la même chose que les "ignorés", netstat Dans les statistiques de niveau interface, un paquet multicast ignoré par un niveau supérieur (couche 3, la pile IP) n'apparaîtra pas comme un drop (bien qu'il puisse apparaître comme "filtré" dans les statistiques de certaines cartes réseau). Les statistiques peuvent être quelque peu compliquées par diverses fonctions de délestage.

Vous pouvez obtenir plus de statistiques si vous avez 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
 [...]

Certaines statistiques dépendent du pilote NIC, de même que la signification exacte. Les données ci-dessus proviennent d'une carte Intel e1000 . Après avoir examiné une poignée de pilotes, certains collectent beaucoup plus de statistiques que d'autres (les statistiques disponibles pour ethtool ont tendance à être conservées dans un fichier source séparé, par exemple. drivers/net/ethernet/intel/e1000/e1000_ethtool.c si vous avez besoin de fouiller).

ethtool -i eth0 affichera les détails du conducteur, la sortie de lspci -v devrait être plus détaillé, mais aussi un peu plus fouillis.

Update En tg3.c fonction tg3_rx() il n'y a qu'un seul endroit qui semble probable avec un tp->rx_dropped++ , mais le code est truffé de goto Il y a donc plusieurs autres causes que la plus évidente, c'est-à-dire tout ce qui contient des goto drop_it ou goto drop_it_no_recycle . (Le compteur de chutes est l'un des rares à être géré par le pilote, les autres étant gérés par l'appareil lui-même).

La source du pilote que j'ai sous la main est la 3.123. Ma meilleure hypothèse est ce code :

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

Vérifier le MTU, les causes possibles sont les trames jumbo, ou des trames Ethernet légèrement surdimensionnées pour permettre l'encapsulation. Je ne peux pas expliquer pourquoi tcpdump pourrait modifier le comportement, il n'est pas connu pour modifier le MTU de l'interface. Notez également que vous pouvez "voir" des paquets plus grands que le MTU avec tcpdump もし TSO / LRO est activée ( explication ).