Come scoprire i motivi per cui l'interfaccia di rete sta rilasciando pacchetti?

C'è un modo su Linux per ottenere statistiche sui vari motivi per cui i pacchetti sono stati eliminati?

Su tutte le interfacce di rete (openSUSE 12.3) su più server ifconfige netstat -isegnalano i pacchetti rilasciati alla reception. Quando faccio un tcpdump, il numero di pacchetti rilasciati smette di aumentare, il che significa che le code delle interfacce non sono piene e rilasciano i dati. Quindi ci devono essere altri motivi per cui ciò sta accadendo (ad esempio pacchetti multicast ricevuti mentre l'interfaccia non fa parte di questo gruppo multicast).

Dove posso trovare tali informazioni? (/ proc? / sys? alcuni registri?)

Esempio di statistiche (unione di / sys / class / net / <dev> / statistiche e output di 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

Provate /sys/class/net/eth0/statistics/ (vale a dire per eth0), non è perfetto ma rompe gli errori per trasmissione / ricezione e per tipo di errore di carrier, window, fifo, crc, frame, length (e pochi altri).

I drop non sono gli stessi di "ignorati", netstatmostrano le statistiche a livello di interfaccia, un pacchetto multicast ignorato da un livello superiore (layer 3, stack IP) non verrà mostrato come drop (anche se potrebbe apparire come "filtrato" su alcuni Statistiche NIC). Le statistiche possono essere in qualche modo complicate da varie funzionalità di offload.

Puoi ottenere più statistiche se hai 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
 [...]

Alcune statistiche dipendono dal driver NIC, così come il significato esatto. Quanto sopra proviene da un Intel e1000. Dopo aver esaminato una manciata di driver, alcuni raccolgono molte più statistiche rispetto ad altri (le statistiche disponibili per ethtool tendono a essere conservate in un file sorgente separato, ad esempio drivers/net/ethernet/intel/e1000/e1000_ethtool.c, se è necessario frugare).

ethtool -i eth0mostrerà i dettagli del driver, l'output di lspci -vdovrebbe essere più dettagliato, anche se con un po 'di disordine.

Aggiornamento Nella tg3.cfunzione tg3_rx()c'è solo un posto che sembra probabile con a tp->rx_dropped++, ma il codice è disseminato di gotos, quindi ci sono molte altre cause oltre all'ovvio, cioè qualsiasi cosa con goto drop_it o goto drop_it_no_recycle. (Si noti che il contatore delle cadute è uno dei pochi gestiti dal conducente, il resto è gestito dal dispositivo stesso.)

La fonte del driver che devo consegnare è 3.123. La mia ipotesi migliore è questo codice:

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

Controllare l'MTU, le possibili cause sono frame jumbo o frame ethernet leggermente sovradimensionati per consentire l'incapsulamento. Non riesco a spiegare perché tcpdumppotrebbe cambiare il comportamento, non è noto cambiare l'interfaccia MTU. Si noti inoltre che è possibile "vedere" pacchetti più grandi dell'MTU con tcpdumpse TSO / LRO è abilitato ( spiegazione ).