Як з’ясувати причину, чому мережевий інтерфейс скидає пакети?


18

Чи є можливість в Linux отримати статистику щодо різних причин, які були скинуті?

На всіх мережевих інтерфейсах (openSUSE 12.3) на декількох серверах ifconfigі netstat -iповідомляють про скинуті пакети на прийомі. Коли я це роблю tcpdump, кількість випавших пакетів перестає збільшуватися, це означає, що черги інтерфейсів не заповнені, і дані видаляються. Тому повинні бути інші причини, чому це відбувається (наприклад, отримані пакети багатоадресних повідомлень, тоді як інтерфейс не є частиною цієї групи багатоадресної передачі).

Де я можу знайти таку інформацію? (/ proc? / sys? деякі журнали?)

Приклад статистики (злиття / sys / class / net / <dev> / статистики та результатів ettool):

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

Відповіді:


23

Спробуйте /sys/class/net/eth0/statistics/ (тобто для eth0), це не ідеально, але він розбиває помилки при передачі / отриманні та операторах, вікні, файлі, CRC, кадрі, довжині (та ще кількох) помилках.

Краплі не такі, як "ігноровані", netstatпоказують статистику рівня інтерфейсу, пакет багатоадресної передачі, який ігнорується вищим рівнем (рівень 3, стек IP), не відображатиметься як крапля (хоча на деяких може відображатися як "відфільтрований" Статистика NIC). Статистика може дещо ускладнитися різними особливостями розвантаження.

Ви можете отримати більше статистичних даних, якщо у вас є 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
 [...]

Деякі статистичні дані залежать від драйвера NIC, як і точного значення. Вище сказано від Intel e1000. Оглянувши кілька драйверів, деякі збирають набагато більше статистичних даних, ніж інші (статистика, доступна для ettool, як правило, зберігається в окремому вихідному файлі, наприклад drivers/net/ethernet/intel/e1000/e1000_ethtool.c, якщо вам потрібно перекопати).

ethtool -i eth0покаже деталі драйвера, висновок lspci -vповинен бути більш детальним, хоча і з тріском.


Оновлення У tg3.cфункції tg3_rx()є лише одне місце, яке, мабуть, є a tp->rx_dropped++, але код вписаний gotos, тому існує кілька інших причин, ніж очевидна, тобто що-небудь з goto drop_it або goto drop_it_no_recycle. (Зауважте, що лічильник крапель - один з небагатьох, який підтримує драйвер, решту підтримує сам пристрій.)

Джерело драйвера, яке мені потрібно надати, - 3.123. Моя найкраща здогадка - це цей код:

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

Перевірте MTU, можливими причинами є джомбові кадри або трохи великі кадри Ethernet, щоб дозволити інкапсуляцію. Я не можу пояснити, чому tcpdumpможе змінити поведінку, невідомо, чи змінити інтерфейс MTU. Зауважте також, що ви можете "бачити" пакети, більші за MTU, tcpdumpякщо TSO / LRO увімкнено ( пояснення ).


Дякую за запропоновану відповідь. Інформація, надана статистикою sysfs dir або by ethtool -S, схожа (принаймні, в моїй системі), і я отримую лише інформацію про кількість викинутих пакетів. Я оновлю свою публікацію результатом.
Гюйгенс

Я перевірив вихідний код драйвера (tg3.c) і виявив лише посилання на краплі на помилку VLAN та неправильну довжину буфера сокета. Я ще не знаю, з чого зробити висновок ...
Гюйгенс

Дякую за оновлення, на жаль, я не можу вдруге поставити +1 ;-) Я буду дивитись, якщо tcpdump повідомляє про jumbo-кадри або кадри більше, ніж мій MTU (1500).
Гюйгенс

У мене є TSO та LRO 'on'. Tcpdump має рамки звітів, більші, ніж мій MTU, але мені потрібно було б побачити, чи це пов’язано з LRO ... я побачу в понеділок. Час бути зараз у вихідний.
Гюйгенс

2
Якщо tg3це модуль, і ви дійсно хочете дістатись до його нижньої частини, ви можете використовувати printk()-like netdev_info()для запису деяких подій, у коді вже є випадки, які ви зможете скопіювати. Дивіться include/linux/skbuff.hза sk_buffбудовою (не для слабкого серця). Розсипте кілька дзвінків у відповідних місцях tg3_rx(), переобладнайте та перезавантажте модуль, і зачекайте ...
mr.spuratic
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.