Jak dowiedzieć się, dlaczego interfejs sieciowy odrzuca pakiety?

Czy w Linuksie jest sposób na uzyskanie statystyk dotyczących różnych powodów, dla których pakiety zostały odrzucone?

Na wszystkich interfejsach sieciowych (openSUSE 12.3) na kilku serwerach ifconfigi netstat -izgłasza odrzucone pakiety w recepcji. Kiedy robię a tcpdump, liczba upuszczanych pakietów przestaje rosnąć, co oznacza, że ​​kolejki interfejsów nie są pełne i upuszczam dane. Dlatego muszą istnieć inne powody, dla których tak się dzieje (np. Odebrano punkty multiemisji, podczas gdy interfejs nie należy do tej grupy multiemisji).

Gdzie mogę znaleźć takie informacje? (/ proc? / sys? niektóre logi?)

Przykład statystyki (scalenie danych wyjściowych / sys / class / net / <dev> / statistics i 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

Spróbuj /sys/class/net/eth0/statistics/ (tj. Dla eth0), nie jest idealny, ale rozkłada błędy według transmisji / odbioru i według operatora, okna, fifo, crc, ramki, długości (i kilku innych) rodzajów błędów.

Krople nie są tym samym, co „ignorowane”, netstatpokazują statystyki na poziomie interfejsu, pakiet multiemisji ignorowany przez wyższy poziom (warstwa 3, stos IP) nie będzie wyświetlany jako kropla (choć może być wyświetlany jako „filtrowany” na niektórych Statystyki NIC). Statystyki mogą być nieco skomplikowane przez różne funkcje odciążania.

Możesz uzyskać więcej statystyk, jeśli masz 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
 [...]

Niektóre statystyki zależą od sterownika karty sieciowej, podobnie jak dokładne znaczenie. Powyższe pochodzi od Intela e1000. Po zapoznaniu się z garstką sterowników, niektórzy zbierają znacznie więcej statystyk niż inni (statystyki dostępne dla ethtool są zwykle przechowywane w osobnym pliku źródłowym, np. drivers/net/ethernet/intel/e1000/e1000_ethtool.cJeśli potrzebujesz przeszukać).

ethtool -i eth0pokaże szczegóły sterownika, wyjście lspci -vpowinno być bardziej szczegółowe, choć z odrobiną bałaganu.

Aktualizacja W tg3.cfunkcji tg3_rx()jest tylko jedno miejsce, które wygląda prawdopodobnie z tp->rx_dropped++, ale kod jest zaśmiecona gotos, więc istnieje kilka innych przyczyn niż oczywiste, czyli coś z goto drop_it lub goto drop_it_no_recycle. (Należy pamiętać, że licznik upuszczeń jest jednym z niewielu obsługiwanych przez sterownik, pozostałe są obsługiwane przez samo urządzenie).

Źródło sterownika, które mam pod ręką, to 3.123. Domyślam się, że ten kod:

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

Sprawdź MTU, możliwe przyczyny to duże ramki lub nieco za duże ramki Ethernet, aby umożliwić enkapsulację. Nie potrafię wyjaśnić, dlaczego tcpdumpmoże to zmienić zachowanie, nie wiadomo, aby zmienić MTU interfejsu. Zauważ również, że możesz „zobaczyć” pakiety większe niż MTU, tcpdumpjeśli TSO / LRO jest włączony ( wyjaśnienie ).