RX Discards: Ursache finden / beheben

[Friedemann Stoyan]

Hallo NG!

Ich habe eine Router (Debian 11) mit einem Outside Interface 1GBit/s:

$ ethtool -S outside
NIC statistics:
tx_packets: 11396345
rx_packets: 44032072
tx_errors: 0
rx_errors: 0
rx_missed: 434
align_errors: 0
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 43654305
broadcast: 362314
multicast: 15453
tx_aborted: 0
tx_underrun: 0

Der snmpd meldet bei Bitraten jenseits 200MBit/s immer mal wieder RX-Discards:

$ netstat -ni | grep -Ei "iface|outside"
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
outside 1500 44034075 0 436 0 11398059 0 0 0 BMRU

Als HW ist verbaut:

$ lshw -short -c network
H/W path Device Class Description
===========================================================
/0/100/2.1/0.2/9/0 outside network RTL8125 2.5GbE Controller


Hat jemand eine Idee, wie man den Grund rausbekommt warum der RX-Drop
aufgetreten ist? Google hat mich nicht so recht weitergebracht.


mfg Friedemann

[Marco Moock]

Am Sonntag, 22. Mai 2022, um 08:55:51 Uhr schrieb Friedemann Stoyan:

> Hat jemand eine Idee, wie man den Grund rausbekommt warum der RX-Drop
> aufgetreten ist?

Was bedeutet RD-Drop?
Wird da das Frame verworfen, weil es fehlerhaft ist (zu kurz/lang,
Prüfsumme falsch) oder weil es den Rechner nicht interessiert (z.B.
Multicast-Traffic, wo der Rechner auf keine passende Multicast-IP
lauscht, es aber trotzdem da ankommt und anhand der MAC schon verworfen
werden kann)?

Ich konnte in der Manpage von ethtool bzw. netstat dazu nichts finden.

Bei höheren Datenraten deutet aber eher auf Übertragungsprobleme hin.
Verwendest du geschirmte und korrekt gecrimpte Kabel?

[Sven Hartge]

Friedemann Stoyan <use...@ip6-mail.de> wrote:

> Ich habe eine Router (Debian 11) mit einem Outside Interface 1GBit/s:

> $ ethtool -S outside
> NIC statistics:
> tx_packets: 11396345
> rx_packets: 44032072
> tx_errors: 0
> rx_errors: 0
> rx_missed: 434
> align_errors: 0
> tx_single_collisions: 0
> tx_multi_collisions: 0
> unicast: 43654305
> broadcast: 362314
> multicast: 15453
> tx_aborted: 0
> tx_underrun: 0

> Der snmpd meldet bei Bitraten jenseits 200MBit/s immer mal wieder RX-Discards:

> $ netstat -ni | grep -Ei "iface|outside"
> Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
> outside 1500 44034075 0 436 0 11398059 0 0 0 BMRU

RX Discards können u.a. auftreten wenn:

- die CPU nicht nachkommt
- die NIC nicht nachkommt
- die inneren Interface die Daten nicht schnell genug abnehmen können
(z.B. wenn der Empfang 1GBit/s ist und der Ausgang nur 100MBit/s,
etc.)
- das Paket ein Broadcast oder Multicast war, das aber doch nicht für
das System war.
- das Paket für ein VLAN war, das nicht am Interface konfiguriert ist

In deinem Fall würde ich 0.001% an Discards jetzt nicht als Problem
bewerten.

S°

--
Sigmentation fault. Core dumped.

[Sven Hartge]

Marco Moock <mo...@posteo.de> wrote:
> Am Sonntag, 22. Mai 2022, um 08:55:51 Uhr schrieb Friedemann Stoyan:

>> Hat jemand eine Idee, wie man den Grund rausbekommt warum der RX-Drop
>> aufgetreten ist?

> Was bedeutet RD-Drop?
> Wird da das Frame verworfen, weil es fehlerhaft ist (zu kurz/lang,
> Prüfsumme falsch)

Das wäre RX-Err.

> oder weil es den Rechner nicht interessiert (z.B. Multicast-Traffic,
> wo der Rechner auf keine passende Multicast-IP lauscht, es aber
> trotzdem da ankommt und anhand der MAC schon verworfen werden kann)?

Das wäre RX-Drp.

[Marco Moock]

Am Sonntag, 22. Mai 2022, um 10:44:32 Uhr schrieb Sven Hartge:

> RX Discards können u.a. auftreten wenn:

[...]

> - das Paket ein Broadcast oder Multicast war, das aber doch nicht für
> das System war.
> - das Paket für ein VLAN war, das nicht am Interface konfiguriert ist

Das widerspricht aber deinem anderen Post:

[Sven Hartge]

Drop/Discard sind synonym.

Error ist dagegen speziell, wenn das Paket defekt ist. (Falsche
Checksumme, zu klein, zu groß, etc.)

[Friedemann Stoyan]

Sven Hartge wrote:

Ich sehe das RX-Drop nur, wenn ich Bitraten >200MBit/s habe. Durch das SNMP
Monitoring ist das überhaupt nur aufgefallen.

> RX Discards können u.a. auftreten wenn:

> - die CPU nicht nachkommt
> - die NIC nicht nachkommt

Würde mich (aus wissenschaftlichen Gründe) interessieren. Das muss sich doch
auch irgendwie monitoren lassen. Das würde ja bedeuten, Frame kommt im NIC an,
aber nicht in SKBUF. Oder sehe ich das falsch?

> - die inneren Interface die Daten nicht schnell genug abnehmen können
> (z.B. wenn der Empfang 1GBit/s ist und der Ausgang nur 100MBit/s,
> etc.)

Kann in diesem Fall nicht sein.

> - das Paket ein Broadcast oder Multicast war, das aber doch nicht für
> das System war.

Glaube ich nicht. Müsste dann ja immer wieder mal passieren. Sehe ich aber
nicht.

> - das Paket für ein VLAN war, das nicht am Interface konfiguriert ist

Kann auch nicht sein. Alles untagged. Niemand weiss etwas von 802.1Q.

> In deinem Fall würde ich 0.001% an Discards jetzt nicht als Problem
> bewerten.

Ja, ist mir schon klar.


mfg Friedemann

[Friedemann Stoyan]

Marco Moock wrote:

> Bei höheren Datenraten deutet aber eher auf Übertragungsprobleme hin.
> Verwendest du geschirmte und korrekt gecrimpte Kabel?

Fällt mir schwer zu glauben. Ist nur ein kurzes Industriekabel zwischen meinem
Router und dem Carrier-Router¹.

mfg Friedemann

¹: Bei diesem Router handelt es sich um eine 6490Cable.

[Sven Hartge]

Friedemann Stoyan <use...@ip6-mail.de> wrote:
> Sven Hartge wrote:

> Ich sehe das RX-Drop nur, wenn ich Bitraten >200MBit/s habe. Durch das SNMP
> Monitoring ist das überhaupt nur aufgefallen.

>> RX Discards können u.a. auftreten wenn:

>> - die CPU nicht nachkommt
>> - die NIC nicht nachkommt

> Würde mich (aus wissenschaftlichen Gründe) interessieren. Das muss sich doch
> auch irgendwie monitoren lassen. Das würde ja bedeuten, Frame kommt im NIC an,
> aber nicht in SKBUF. Oder sehe ich das falsch?

Das ist über meinem Wissenshorizont.

Die Realtek-NICs sind ja außerdem nicht gerade für hohe Qualität des
Siliziums bekannt, je nach Hardware-Revision gab es in der Vergangenheit
immer schon auftretende Merkwürdigkeiten.

Spiel doch einmal mittels ethtool mit den diversen Offloading-Varianten
bei RX, vielleicht liegt es daran.

Ich z.B. hatte massive Probleme mit den Intel-Enterprise-NICs der
X740-Klasse und den älteren Firmwares. Da war so ziemlich alles defekt,
was Intel so vollmündig angekündigt hatte. Erst wenn man alle
Offloading-Features bei TX und RX deaktiviert hatte, war das Ding
stabil. Und erst Jahre nach Release des Chips hat Intel dann eine
Firmware gebracht, die brauchbar stabil war, aber auch 50% der Features
der Chips deaktiviert hat.

[Friedemann Stoyan]

Sven Hartge wrote:

> Die Realtek-NICs sind ja außerdem nicht gerade für hohe Qualität des
> Siliziums bekannt, je nach Hardware-Revision gab es in der Vergangenheit
> immer schon auftretende Merkwürdigkeiten.

Ja, Realtek hat nicht den besten Ruf. Irgendwie wurde aber kolpotiert, dass
das jetzt besser sei als früher.

> Spiel doch einmal mittels ethtool mit den diversen Offloading-Varianten
> bei RX, vielleicht liegt es daran.

Werde ich mal machen. Was ich aber noch sehe ist:

$ ip -s -s link show dev outside
2: outside: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc cake state UP mode DEFAULT group default qlen 1000
link/ether 18:c0:4d:af:23:0e brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
58416495331 44204940 0 2 434 16320
RX errors: length crc frame fifo overrun
0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
2023373971 11560336 0 0 0 0
TX errors: aborted fifo window heartbeat transns
0 0 0 0 2

Die Frames sind "missed" nicht "dropped". Holla! Werde mal in diese Richtung
googeln!


mfg Friedemann

[Marco Moock]

Am Sonntag, 22. Mai 2022, um 12:44:57 Uhr schrieb Sven Hartge:

> Drop/Discard sind synonym.
>
> Error ist dagegen speziell, wenn das Paket defekt ist. (Falsche
> Checksumme, zu klein, zu groß, etc.)

Danke für die Aufklärung.
Bedeutet also, beim TO treten keine Übertragungsfehler auf. Gibt es
eine Option, die gedroppten Frames irgendwie mitzuschneiden, sodass man
z.B. die Sache mit Multicast abklären kann.

[Friedemann Stoyan]

Friedemann Stoyan wrote:

> Die Frames sind "missed" nicht "dropped". Holla! Werde mal in diese Richtung
> googeln!

Ich befürchte, die Sache hat sich geklärt.

Die Counter stammen aus der Struktur: rtnl_link_stats64
https://docs.kernel.org/networking/statistics.html#struct-rtnl-link-stats64

Dort genau aus: rx_missed_errors. Die Doku sagt:

"Counts number of packets dropped by the device due to lack of buffer space.
This usually indicates that the host interface is slower than the network
interface, or host is not keeping up with the receive packet rate."

Das heisst übersetzt: Realtek ist schrottige Consumer-Hardware. In der Spitze
hatte ich ca. 20 Kpps und da ist bei Realtek halt Schluß. Muss mal überlegen,
ob ich da mal eine Intel Karte reinstecke.

mfg Friedemann

[Marco Moock]

Am Sonntag, 22. Mai 2022, um 14:40:53 Uhr schrieb Friedemann Stoyan:

> "Counts number of packets dropped by the device due to lack of buffer
> space. This usually indicates that the host interface is slower than
> the network interface, or host is not keeping up with the receive
> packet rate."
>
> Das heisst übersetzt: Realtek ist schrottige Consumer-Hardware. In
> der Spitze hatte ich ca. 20 Kpps und da ist bei Realtek halt Schluß.
> Muss mal überlegen, ob ich da mal eine Intel Karte reinstecke.

Kann aber auch eine andere Stelle sein.
Nehme ich beispielsweise eine 80139 (FE Vollduplex) und stecke die in
einen 586er mit PCI, wird es da sicher auch Probleme mit dem Durchsatz
geben.

Deine Karte soll 2,5 GBit/s können, da hätte ich erwartet, dass dann 1
GBit/s locker durchgeht.

[Sven Hartge]

Marco Moock <mo...@posteo.de> wrote:
> Am Sonntag, 22. Mai 2022, um 12:44:57 Uhr schrieb Sven Hartge:

>> Drop/Discard sind synonym.
>>
>> Error ist dagegen speziell, wenn das Paket defekt ist. (Falsche
>> Checksumme, zu klein, zu groß, etc.)

> Bedeutet also, beim TO treten keine Übertragungsfehler auf. Gibt es
> eine Option, die gedroppten Frames irgendwie mitzuschneiden, sodass
> man z.B. die Sache mit Multicast abklären kann.

Die Pakete werden ja schon in der NIC verworfen und nicht im Treiber
(vermutlich), daher ist wenig mitzuschneiden.

Und wenn man tcpdump/wireshark nutzt und die NIC im promiscous mode ist,
dürften die Pakete durchkommen und nicht mehr gedropt/discarded werden,
so dass man nicht mehr sieht, welche es gewesen wären.

Man müßte als einen Switch mit Mirror-Port-Funktion haben, die Pakete
zusätzlich auf einem anderen System mitschneiden (und im
non-promisc-Mode auf dem ersten) und dann ein PCAP-Diff machen um zu
sehen, was fehlt.

[Friedemann Stoyan]

Marco Moock wrote:

> Deine Karte soll 2,5 GBit/s können, da hätte ich erwartet, dass dann 1
> GBit/s locker durchgeht.

Ich befürchte, dass das Hostinterface der Realtek Karte so billig/schlecht
ist, dass es bei größeren Packet per Second Werten (hier Spitze 20.000)
einfach in die Knie geht. Darf halt alles nichts kosten.

Kucke ich mir das an sehe ich:

$ sudo ethtool -g outside
netlink error: Operation not supported

Nichts! Auf meiner (anderen) Intel Karte:

$ sudo ethtool -g enp1s0f0
Ring parameters for enp1s0f0:
Pre-set maximums:
RX: 4096
RX Mini: n/a
RX Jumbo: n/a
TX: 4096
Current hardware settings:
RX: 512
RX Mini: n/a
RX Jumbo: n/a
TX: 512

Muss wohl doch mal mit anderer HW experimentieren.


mfg Friedemann

[Sven Hartge]

2.5GBit/s mit 1500 oder 9000 Bytes/Paket vermutlich.

Sobald die Paket-Rate hochgeht, weil die Pakete z.B. nur 100Bytes groß
sind, bricht die Sache halt ein.

Das war früher bei den Consumer-Switches schon so, die können zwar
vollen Durchsatz, aber eben nur bei maximal-großen Paketen.

Sobald man diese Switche dann bei einer LAN-Party einsetzt, wo die
meisten Spiele eben mit 64Byte/Paket gearbeitet haben, brach dann der
Durchsatz massiv ein.

[Marco Moock]

Am Sonntag, 22. Mai 2022, um 15:04:30 Uhr schrieb Sven Hartge:

> 2.5GBit/s mit 1500 oder 9000 Bytes/Paket vermutlich.

Messen die das wirklich mit Jumbo-Frames?
Das ist ja ein wirklich seltener Betriebsmodus im Consumer-Bereich.

> Sobald die Paket-Rate hochgeht, weil die Pakete z.B. nur 100Bytes groß
> sind, bricht die Sache halt ein.
>
> Das war früher bei den Consumer-Switches schon so, die können zwar
> vollen Durchsatz, aber eben nur bei maximal-großen Paketen.

OK, ist logisch, da da viel mehr geprüft werden muss als bei großen
Paketen.

[Friedemann Stoyan]

Kleines Followup falls es jemanden interessiert:

> Das heisst übersetzt: Realtek ist schrottige Consumer-Hardware. In der Spitze
> hatte ich ca. 20 Kpps und da ist bei Realtek halt Schluß. Muss mal überlegen,
> ob ich da mal eine Intel Karte reinstecke.

In dem Rechner steckt ja bereits eine Intel-kompatible Karte X520-DA2[1] in der
noch ein SFP+ Slot frei ist. Ich habe mir eine 1000BaseT-SFP[2] besorgt. Alles
sieht seit dem gut aus:

$ sudo ethtool -m outside
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x00 (unknown or unspecified)
Transceiver codes : 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x00
Transceiver type : Ethernet: 1000BASE-T
Encoding : 0x01 (8B/10B)
BR, Nominal : 1300MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 0km
Length (SMF) : 0m
Length (50um) : 0m
Length (62.5um) : 0m
Length (Copper) : 100m
Length (OM3) : 0m
Laser wavelength : 0nm
Vendor name : OEM
Vendor OUI : 00:00:00
Vendor PN : SFP-GE-T
Vendor rev :
Option values : 0x00 0x1a
Option : RX_LOS implemented
Option : TX_FAULT implemented
Option : TX_DISABLE implemented
BR margin, max : 0%
BR margin, min : 0%
Vendor SN : xxxxxxx
Date code : 211025

Keine Probleme mit verlorenem RX mehr, auch bei großen PPS:

$ ip -s -s link show dev outside

4: outside: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 80:61:5f:0a:3a:b1 brd ff:ff:ff:ff:ff:ff

RX: bytes packets errors dropped missed mcast

40954670728 37960451 0 0 0 2754

RX errors: length crc frame fifo overrun
0 0 0 0 0
TX: bytes packets errors dropped carrier collsns

16591002805 25168102 0 0 0 0

TX errors: aborted fifo window heartbeat transns
0 0 0 0 2

[1]: https://ark.intel.com/content/www/de/de/ark/products/39776/intel-ethernet-converged-network-adapter-x520da2.html
[2]: https://www.amazon.de/dp/B01AW5EHKG