Назад | Перейти на главную страницу

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

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

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

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

Пример статистики (объединение / sys / class / net / <dev> / statistics и вывода 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), он не идеален, но он разбивает ошибки по типам ошибок передачи / приема и по несущей, окну, фифо, 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
 [...]

Некоторая статистика зависит от драйвера сетевого адаптера, как и точное значение. Вышеизложенное принадлежит Intel e1000. Изучив несколько драйверов, некоторые из них собирают гораздо больше статистики, чем другие (статистика, доступная для ethtool, как правило, хранится в отдельном исходном файле, например drivers/net/ethernet/intel/e1000/e1000_ethtool.c, если нужно покопаться).

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


Обновить В tg3.c функция tg3_rx() есть только одно место, которое выглядит вероятным с 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, возможные причины - jumbo-кадры или немного увеличенные рамки Ethernet для инкапсуляции. Я не могу объяснить почему tcpdump может изменить поведение, об изменении MTU интерфейса не известно. Также обратите внимание, что вы можете «видеть» пакеты больше, чем MTU с tcpdump если TSO/МРО включен (объяснение).