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

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

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

Где я могу найти такую ​​информацию? (/ 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

Попробуйте /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()есть только одно место, которое выглядит вероятным с 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 включен ( пояснение ).