Brauche Hilfe beim Verstehen der von ethtool gemeldeten Paketverluststatistiken (EL7/EL8)

Question

Ich habe versucht, die Details zu Drops nachzulesen, da sie von verschiedenen Tools (und auf verschiedenen Ebenen) des Betriebssystems gemeldet werden. Bisher erscheinen mir die meisten Informationen, die ich durch Googeln ausgraben konnte, eher „vage“.

Lassen Sie mich zunächst feststellen, dass der Beispielhost, den ich mir ansehe, NULL Drops in aufweist /proc/net/softnet_stat. Das deutet für mich darauf hin, dass die NIC-Ringpuffer wahrscheinlich ausreichend dimensioniert sind. Nun zu ethtool...

So sieht die NIC-Multi-Warteschlange aus:

# 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

So sehen die RX-Drops für dieselbe Schnittstelle aus:

# 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

Meine Annahme hierist, dass sich die 16 einzelnen Warteschlangen hier auf die Multi-Warteschlange des NIC-Ringpuffers beziehen. Alle Nullen hier scheinen mit dem übereinzustimmen, was ich in sehe softnet_stat. Außerdem gehe ich davon aus, dass alle in gezählten Drops softnet_statin dieser Ausgabe widergespiegelt würden ethtool, wenn sie stattfinden würden (was derzeit nicht der Fall ist).

Damit bleibt das eher vage 'rx_dropped'Feld, das tatsächlich inkrementiert wird. Meine Annahme hierzu ist also, dass es NICHT mit dem NIC-Ringpuffer zusammenhängt, sondern ein Drop-Zähler eines höheren Protokolls ist. Diese Anzahl spiegelt sich tatsächlich in den ip -sStatistiken für die Schnittstelle wider:

# 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

Ich glaube, dass diese Ausfälle auf eine Reihe protokollbezogener Probleme zurückzuführen sein könnten, beispielsweise fehlerhafte Pakete, fehlerhafte Ports, überlastete App-Puffer usw. usw.

Scheint dies eine vernünftige Analyse zu sein, die die von gemeldeten „unterschiedlichen“ Drop-Statistiken erklärt ethtool -S?