Как узнать причину (почему), почему сетевой интерфейс отбрасывает пакеты?

Есть ли способ в Linux получить статистику о различных причинах отказа пакетов?

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

Где я могу найти такую ​​информацию? (/proc? /sys? некоторые журналы?)

Пример статистики (слияние /sys /class /net /<dev> /статистика и выход 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
14 голосов | спросил Huygens 13 FriEurope/Moscow2013-12-13T12:46:16+04:00Europe/Moscow12bEurope/MoscowFri, 13 Dec 2013 12:46:16 +0400 2013, 12:46:16

1 ответ


21

Попробуйте /sys/class/net/eth0/statistics/ (т.е. для eth0), это не идеально, но оно ломает ошибки с помощью ошибок передачи /приема и с помощью несущей, окна, fifo, crc, frame, length (и еще нескольких) ошибок.

Капли не совпадают с «проигнорированными», 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. Посмотрев на несколько драйверов, некоторые собирают гораздо больше статистических данных, чем другие (статистика, используемая ethtool, как правило, хранится в отдельном исходном файле, например drivers/net/ethernet/intel/e1000/e1000_ethtool.c, если вам нужно рыться).

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


Обновление В tg3.c функция tg3_rx() есть только одно место который выглядит скорее с помощью tp->rx_dropped++, , но код завален goto s, поэтому есть несколько других причин, чем очевидное, то есть что-либо с 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 включен ( объяснение ).

ответил mr.spuratic 13 FriEurope/Moscow2013-12-13T15:21:57+04:00Europe/Moscow12bEurope/MoscowFri, 13 Dec 2013 15:21:57 +0400 2013, 15:21:57

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132