it-swarm.com.de

Wie kann man herausfinden, warum die Netzwerkschnittstelle Pakete verwirft?

Gibt es unter Linux eine Möglichkeit, Statistiken über die verschiedenen Gründe für das Verwerfen von Paketen abzurufen?

Auf allen Netzwerkschnittstellen (openSUSE 12.3) auf mehreren Servern ifconfig und netstat -i melden verworfene Pakete an der Rezeption. Wenn ich ein tcpdump mache, steigt die Anzahl der verworfenen Pakete nicht mehr an, was bedeutet, dass die Schnittstellenwarteschlangen nicht voll sind und die Daten verworfen werden. Es muss also andere Gründe geben, warum dies geschieht (z. B. empfangene Multicast-Pkts, während die Schnittstelle nicht Teil dieser Multicast-Gruppe ist).

Wo finde ich solche Informationen? (/ proc?/sys? einige Protokolle?)

Beispiel für Statistiken (Zusammenführung der Ausgabe von/sys/class/net/<dev>/statistics und 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
20
Huygens

Versuchen Sie /sys/class/net/eth0/statistics/ (Dh für eth0), Es ist nicht perfekt, aber es gliedert Fehler nach Senden/Empfangen und nach Carrier-, Fenster-, Fifo-, CRC-, Frame-, Längen nd einigen weiteren) Typen von Fehlern.

Drops sind nicht dasselbe wie "ignoriert". netstat zeigt Statistiken auf Schnittstellenebene an. Ein Multicast-Paket, das von einer höheren Ebene (Schicht 3, IP-Stack) ignoriert wird, wird nicht als Drop angezeigt (obwohl es möglicherweise angezeigt wird wie bei einigen NIC -Statistiken) "gefiltert". Statistiken können durch verschiedene Offload-Funktionen etwas kompliziert werden.

Sie können mehr Statistiken erhalten, wenn Sie ethtool haben:

# 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
 [...]

Einige Statistiken hängen vom Treiber NIC) ab, ebenso wie die genaue Bedeutung. Die obigen Angaben stammen von einem Intel e1000. Einige haben sich eine Handvoll Treiber angesehen und sammeln viel mehr Statistiken als andere (Die für ethtool verfügbaren Statistiken werden normalerweise in einer separaten Quelldatei gespeichert, z. B. drivers/net/ethernet/intel/e1000/e1000_ethtool.c, wenn Sie stöbern müssen).

ethtool -i eth0 Zeigt die Treiberdetails an. Die Ausgabe von lspci -v Sollte detaillierter sein, allerdings auch mit etwas Unordnung.


Update In der Funktion tg3.ctg3_rx() gibt es nur einen Ort, der mit einem tp->rx_dropped++ Wahrscheinlich aussieht. aber Der Code ist mit gotos übersät, daher gibt es mehrere andere Ursachen als die offensichtlichen, dh alles mit goto drop_it oder goto drop_it_no_recycle. (Beachten Sie, dass der Drop-Zähler einer der wenigen ist, die vom Treiber verwaltet werden, der Rest wird vom Gerät selbst verwaltet.)

Die Treiberquelle, die ich zur Hand habe, ist 3.123. Meine beste Vermutung ist dieser Code:

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

Überprüfen Sie die MTU. Mögliche Ursachen sind Jumbo-Frames oder --- (leicht übergroße Ethernet-Frames , um die Kapselung zu ermöglichen. Ich kann nicht erklären, warum tcpdump das Verhalten ändern könnte. Es ist nicht bekannt, dass die Schnittstellen-MTU geändert wird. Beachten Sie auch, dass Sie möglicherweise Pakete "sehen", die größer als die MTU mit tcpdump sind, wenn TSO / LRO ist aktiviert ( Erklärung ).

25
mr.spuratic