web-dev-qa-db-fra.com

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

Existe-t-il un moyen sous 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, ifconfig et netstat -i signalent des paquets perdus à la réception. Lorsque 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
linuxnetworkingkernel
20
Huygens

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 porteuse, fenêtre, fifo, crc, trame, longueur (et quelques autres) types des erreurs.

Les gouttes ne sont pas les mêmes que "ignoré", netstat affiche les statistiques de niveau d'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 certaines 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 provient d'un processeur 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 eth0 Affichera les détails du pilote, la sortie de lspci -v Devrait être plus détaillée, mais avec un peu d'encombrement aussi.

Mise à jour Dans la fonction tg3.ctg3_rx() il n'y a qu'un seul endroit qui semble probable avec un 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 pilote, 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 les trames jumbo, ou trames Ethernet légèrement surdimensionnées pour permettre l'encapsulation. Je ne peux pas expliquer pourquoi tcpdump pourrait 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 tcpdump si TSO / LRO est activé ( explication ).

25
mr.spuratic