Comment connaître la ou les raisons pour lesquelles l'interface réseau perd des paquets?

Existe-t-il un moyen sur Linux d'obtenir des statistiques sur les différentes raisons pour lesquelles les paquets ont été abandonnés?

Sur toutes les interfaces réseau (openSUSE 12.3) sur plusieurs serveurs, ifconfiget netstat -isignalent les paquets perdus à la réception. Quand je fais un tcpdump, le nombre de paquets abandonnés cesse d'augmenter, ce qui signifie que les files d'attente d'interfaces ne sont pas pleines et abandonnent les données. Il doit donc y avoir d'autres raisons pour lesquelles cela se produit (par exemple, les paquets de multidiffusion reçus alors que l'interface ne fait pas partie de ce groupe de multidiffusion).

Où puis-je trouver ces informations? (/ proc? / sys? quelques journaux?)

Exemple de statistiques (fusion de la sortie / sys / class / net / <dev> / statistics et 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

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

Les gouttes ne sont pas les mêmes que «ignorées», netstataffichent les statistiques au niveau de l'interface, un paquet de multidiffusion ignoré par un niveau supérieur (couche 3, la pile IP) ne s'affichera pas comme une goutte (bien qu'il puisse apparaître comme «filtré» sur certains Statistiques NIC). Les statistiques peuvent être quelque peu compliquées par diverses fonctionnalités de déchargement.

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, tout comme la signification exacte. Ce qui précède est d'un 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 devez fouiller).

ethtool -i eth0affichera les détails du pilote, la sortie de lspci -vdevrait être plus détaillée, mais avec un peu d'encombrement aussi.

Mettre à jour dans la tg3.cfonction tg3_rx()il n'y a qu'un seul endroit qui semble probable avec a tp->rx_dropped++, mais le code est jonché de gotos, il y a donc plusieurs autres causes que l'évidence, c'est-à-dire n'importe quoi avec goto drop_it ou goto drop_it_no_recycle. (Notez que le compteur de gouttes est l'un des rares gérés par le conducteur, le reste est géré par l'appareil lui-même.)

La source du pilote que je dois remettre est 3.123. Ma meilleure supposition 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érifiez le MTU, les causes possibles sont des trames jumbo ou des trames Ethernet légèrement surdimensionnées pour permettre l'encapsulation. Je ne peux pas expliquer pourquoi tcpdumppourrait changer le comportement, il n'est pas connu de changer l'interface MTU. Notez également que vous pouvez "voir" des paquets plus grands que le MTU avec tcpdumpsi TSO / LRO est activé ( explication ).