Нужна помощь в сборе статистики по потере пакетов, полученной от ethtool (EL7/EL8)

Нужна помощь в сборе статистики по потере пакетов, полученной от ethtool (EL7/EL8)

Я пытался прочитать подробности о падениях, которые сообщаются различными инструментами (и на разных уровнях) ОС. До сих пор большая часть информации, которую мне удалось откопать с помощью Google, кажется мне довольно "ручной".

Во-первых, позвольте мне заявить, что рассматриваемый мной пример хоста показывает НУЛЕВЫЕ падения в /proc/net/softnet_stat. Это говорит мне о том, что кольцевые буферы NIC, вероятно, имеют адекватный размер. Теперь перейдем к ethtool...

Вот как выглядит многоочередность сетевых карт:

# ethtool -l em1
Channel parameters for em1:
Pre-set maximums:
RX:     16
TX:     16
Other:      n/a
Combined:   n/a
Current hardware settings:
RX:     16
TX:     16
Other:      n/a
Combined:   n/a

А вот как выглядят полученные данные для того же интерфейса:

# ethtool -S em1 | grep rx.*dropped:
     rx_dropped: 1742
     rx0_dropped: 0
     rx1_dropped: 0
     rx2_dropped: 0
     rx3_dropped: 0
     rx4_dropped: 0
     rx5_dropped: 0
     rx6_dropped: 0
     rx7_dropped: 0
     rx8_dropped: 0
     rx9_dropped: 0
     rx10_dropped: 0
     rx11_dropped: 0
     rx12_dropped: 0
     rx13_dropped: 0
     rx14_dropped: 0
     rx15_dropped: 0

Мое предположение здесьзаключается в том, что 16 отдельных очередей здесь относятся к многоочередности кольцевого буфера NIC. Все нули здесь, похоже, согласуются с тем, что я вижу в softnet_stat. Кроме того, я предполагаю, что любые подсчитанные сбросы softnet_statбудут отражены в этом ethtoolвыводе, если они происходили (чего в настоящее время не происходит).

Это оставляет своего рода неопределенное 'rx_dropped'поле, которое на самом деле увеличивается. Поэтому я предполагаю, что это НЕ связано с кольцевым буфером NIC, а является счетчиком отбрасывания более высокого протокола. Этот счетчик фактически отражен в статистике ip -sдля интерфейса:

# ip -s link show dev em1
2: em1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether 94:18:82:70:2e:42 brd ff:ff:ff:ff:ff:ff
    RX:       bytes      packets errors dropped  missed   mcast
    219512805660516 147616023841      0    1742       0 5624266
    TX:       bytes      packets errors dropped carrier collsns
    649765242476657 450168813646      0       0       0       0

Я считаю, что эти падения могут быть результатом множества проблем, связанных с протоколом, таких как неправильно сформированные пакеты, плохие порты, переполненные буферы приложений и т. д. и т. п.

Кажется ли это разумным анализом, который объясняет «разную» статистику выпадения, сообщаемую ethtool -S?

Связанный контент