Einschätzung zu package drop in 10G+ Netzwerk

[Skysnake]

Hi Leute,

Ich stehe immer wieder vor dem Problem das u der Netzwerk als nicht reliable angesehen wird sobald es zu irgendeinem Problem kommt. Ihr kennt ja die Standardantworten vom Support. Alle sind Schuld nur die nicht...

Intensive Tests über lange Zeiträume zeigen aber das
1. Volle linerate erreicht wird mit iperf
2. Pings sauber aussehen

Die Software meldet aber alle paar Monate mal package reordering. Sehe ich aber nicht wirklich als Problem an. Das kann ja MAL passieren... wird aber natürlich gleich vorgezogen und das Netzwerk als Ursache dargestellt....

Also habe ich weiter analysiert und an sich keinerlei Hinweise auf Probleme im Netz gefunden bei den netstats. Bis auf eine Ausnahme. Ich sehe auf den 10/40G Interfaces der Systeme package drop.

Ich habe echt lange gesucht aber nichts Vernünftiges gefunden....

Zur Einordnung. Wir machen reines L2 Switching im lokalen Netz. Also alles im Umkreis von 40m.

An sich sehe ich die package Drops nicht wirklich als Problem an. Das sind bei 100MBit <100 pro Sekunde und wie gesagt ein Ping zeigt keinen Packetverlust und iperf die erwartete Leistung mit TCP. Und selbst mit UDP kommt noch 30%+ raus wenn ich mich richtig erinnere.

Klar, auf den Systemen sind hunderte, eher tausende von Verbindungen pro Minute offen und auch Last da, daher bin ich nicht gänzlich überrascht, das hin und wieder mal Pakete gedropped werden. Aber das ist jetzt halt nur meine bescheidene Meinung und mit ist nicht klar was man dagegen noch machen könnte. Die Ringbuffer haben wir schon hochgestellt. Hat auch etwas gebracht aber mehr geht nicht.

Also was ist eure Meinung?

 

[AlanK]

Meine Meinung.
Viel Text das wichtigste fehlt.
Alle Geräte aufzählen die du hast.
Zumindest Router / Switch und die NIC.
Kabel prüfen, vor allem auch ob die richtig verlegt, aufgelegt sind.
Frohe Weihnachten 🤞

 

[wahli]

Ping ist nicht vergleichbar.
<100 Pakete pro Sekunde gehen verloren?
Pakete mit UDP kommen nur zu 30% an?
Aus deiner Sicht ist alles in Ordnung? Wirklich? Im Ernst? Echt jetzt?
Ich habe zwar nur 1GBit, aber trotzdem hatte ich nur 17 verlorene Pakete insgesamt die letzten 20 Tage.

Welche Kabel?

 

[DonConto]

Wo wird denn gedropt und wo siehst du das? Outgoing auf dem Interface, an dem das Endgerät hängt? Dann liegt's eher am Endgerät. Oder Outgoing auf dem Interface, an dem ein weiteres Netzgerät hängt? Dann würde ich im Netz nach der Ursache suchen.
Drops sind immer schlecht. Im Normalfall hast du im laufenden Betrieb keine.

 

[dvor]

An sich sehe ich die package Drops nicht wirklich als Problem an. Das sind bei 100MBit <100 pro Sekunde und wie gesagt ein Ping zeigt keinen Packetverlust und iperf die erwartete Leistung mit TCP. Und selbst mit UDP kommt noch 30%+ raus wenn ich mich richtig erinnere.

Ganz offensichtlich hat das Netzwerk gravierende Probleme. 1 verlorenes Paket am Tag ist bereits zu viel.
30% UDP kommen an? Das ist grauenhaft.

 

[Skysnake]

Pakete mit UDP kommen nur zu 30% an?

Nein, wenn ich mit iperf draufballere, dann habe ich bis min 30% von Peak keinen einzigen Paketverlust. Drüber raus wird es dann halt irgendwann mehr. Mit UDP bekommst du bei iperf nicht den Link speed. Das ist ganz normal.

<100 Pakete pro Sekunde gehen verloren?

Im Peak bei mehreren Millionen Paketen in der Zeit. Die Auflösung sind 10s. Das ist also wirst case. Unser traffic ist recht bursty. Daher gehe ich davon aus, dass die Drops auch bursty sind. Wir reden also von sowas wie 1 Paket pro Millionen oder weniger. Und das heißt ja nur, das wenn überhaupt ein resend kommt bei tcp. Kann aber auch sein, dass das von ebenfalls recht bursty udp traffic kommt.

Wo wird denn gedropt und wo siehst du das?

Wie gesagt auf den netstats vom Interface als drop_in. Drop_out sollte bei 0 liegen.

Outgoing auf dem Interface, an dem das Endgerät hängt? Dann liegt's eher am Endgerät.

Wie gesagt meines Wissens sollte es sich auf incoming beschränken

Drops sind immer schlecht. Im Normalfall hast du im laufenden Betrieb keine.

Ja, deswegen war ich davon auch recht überrascht. Ich konnte es soweit schon eingrenzen, das es mit nem Service mitwandert, der parallel jede Minute oder so einige hundert bis tausend ipmi Sdr readings macht. Und das halt gleichzeitig.... das macht schon einiges an Last. An sich würde ich das auch gerne weiterhin möglichst synchron halten.

An sich sehe ich das aber auch nicht als wirkliches Problem an. Wir sehen mit unserer eigenen Software genau Null Probleme, nur eine Dritthersteller Software zickt immer mal wieder Rum, wobei ich von allgemeinen Bugs ausgehe und nicht davon, dass das Netzwerk das Problem ist...

Die machen TCP. Da sollte es eh egal sein, da es einen resend gibt und für. Und bei UDP müssen sie eh davon ausgehen, das es eventuell nicht ankommt. Also so what?

Ich meine wir verteilen per Apache httpd Files mit bis zu 80% der line rate über mehrere Minuten ohne Probleme.. und da läuft der ganze Rest einfach mit. Wenn das Netz aber quasi idle ist und mit paar MBit/s rumeiert soll es plötzlich die Ursache für die Probleme sein???? Really? Ich glaube das nicht wirklich.

Wir können mit dem gleichen System auch 10k+ DHCP Requests pro Sekunde handhaben...

 

[Joe Dalton]

Es fehlt immer noch eine Zusammenfassung, welche Komponenten im Netz aktiv sind und ein Auszug aus den Fehlerstatistiken…

Wenn da eine Applikation Ärger macht, dann würde ich mal mit dem Wireshark den Traffic aufzeichnen und schauen, was da passiert.

 

[Raijin]

Die machen TCP. Da sollte es eh egal sein, da es einen resend gibt

Das ist ja nur die Reaktion auf ein Problem. Was ist denn der auslösende Fehler? Mit tcpdump bzw. WireShark müsstest du sehen können welches Problem bei der TCP-Verbindung konkret auftritt. Mit etwas Glück kann man damit besser einschätzen wo die Ursache liegt.

 

[Skysnake]

Es fehlt immer noch eine Zusammenfassung, welche Komponenten im Netz aktiv sind und ein Auszug aus den Fehlerstatistiken…

Das Problem ist unabhängig von der verwendeten Hardware. Ich sehe das bei 1G/10G/40G Installationen als auch bei 1G/10G/40G/100G. Die Switche kommen von unterschiedlichen Herstellern z.b. Juniper oder HPE. Server sind unterschiedliche Generationen
Nichts sind aber immer Mellanox Connect X.

Die Netzwerktopologie ist ein FATTree mit kleinem Blockingfaktor. Die Server oben haben ca 1/4 der Bandbreite von den Servern unten. Im Normalbetrieb ist aber kaum traffic nach unten da. Da kommunizieren fast nur die Server oben und das ist nonblocking. Auf Switchebene sieht man aber keine Probleme, daher ist das ziemlich uninteressant. Das schlimmste was da passiert ist, das nen Server unten per HTTP nur 500MBit/s bekommt statt 1GBit/s, weil halt 20G uplink für 40x1G... aber das ist alles total normal und irrelevant. Das Netz ist dafür designt die Bandbreite zu liefern, die in 0.01% der Zeit benötigt wird. Den Rest der Zeit dümpelt das mit 0.1-5% der Last herum. Also ne ganz gute Auslegung um durch das Netzwerk keine Probleme zu haben. Was ja auch im Großen und Ganzen zutreffend ist. Und wie schon gesagt, der Dritthersteller benutzt meiner Meinung nach das Netzwerk als Ausrede, weil es eben schwer zu beweisen ist, das es keine Probleme gibt.

Man hat halt immer mal ein Paket das verworfen wird. Gerade bei UDP. Wenn ich das nicht will Brauch ich halt ne 1:1 Verbindung zwischen jedem Teilnehmer, aber das fördert der Hersteller eben genau nicht....

Hier geht es um kein Spielzeug sondern vernünftiges Zeug das Geld kostet und soweit ersichtlich auch genau so funktioniert wie erwartet im Bereich des Netzwerks. Das Einzige sind halt die Drop_in auf nem Interface. Aber das kann halt passieren wenn viel incoming traffic existiert.

Das ist ja nur die Reaktion auf ein Problem. Was ist denn der auslösende Fehler?

Vermutlich die vielen UDP Verbindungen von den ipmi Requests. Ich denke da läuft einfach der Ringbuffer vom Kernel in den bursts über. Zumindest hat eine Vergrößerung des selbigen das Problem reduziert aber nicht gänzlich gelöst und größer kann man ihn nicht mehr machen...

 

[Joe Dalton]

…immer noch keine Statistik und lediglich eine „Vermutung“ zu UDP-Verbindungen. Zeige doch einfach, was da los ist: dann könnte vielleicht die eine oder andere Vermutung durch gesichertes Wissen ersetzt werden.

 

[Skysnake]

Was willst du denn genau sehen?

nen TCP dump kannste vergessen. Das müsste ja über 4Minuten laufen, damit man ein paar Datenpunkte hat. 30MBit/s * 240s =900MB. Was willst du damit anfangen? Zumal ich selbst den traffic erst mal checken müsste, dass da nichts drin ist, was nicht geteilt werden darf.

Und bei den Werten kann ich aus eigener Erfahrung sagen, dass du dann Misst misst. Wenn du da was Vernünftiges haben willst musst du den traffic auf nen anderen port spiegeln. Und was bringt dir der Aufwand? Richtig nichts, weil ja das Ziel die Pakete dropped. Die kommen also an, werden nur nicht verarbeitet.

Error_in/out etc sind alle 0. Nur eben nicht das hier

drop_in - The total number of received packets dropped by the interface

https://github.com/influxdata/telegraf/blob/master/plugins/inputs/net/NET_README.md

Ja Supi, da werden welche gedropped und nü?

Ergänzung (24. Dezember 2021)

Oder guckst du auch hier https://community.mellanox.com/s/article/counters-troubleshooting-for-linux-driver

rx_dropped
Number of received packets which were chosen to be discarded even though no errors had been detected to prevent them from passing to the upper layer. For example, drop due to buffer overflow.

This counter is increased at point (1) in the figure above.

So und das sagt/hilft mir jetzt genau was? Richtig nichts. Wie gesagt habe ich auch von dem was ich so lesen konnte nicht den Eindruck, das es sich hierbei um ein echtes Problem handelt, das man fixen muss sondern einfach durch hohe Last kommt und die ist halt da.

Ergänzung (24. Dezember 2021)

Btw Zufallsfund als ich für dich die links oben gesucht hatte.

https://www.optiver.com/recruitment-blog/post/searching-for-the-cause-of-dropped-packets-on-linux/

Das deckt sich komplett mit dem was ich beobachte.

Für mich stellt sich das auch nicht als Fehler des Netzwerks dar sondern als working as intended.

Ich finde da kann man sich nicht hinstellen und sagen das Netzwerk tut nicht und damit den Supportrequest abbügeln. Oder nicht?

 

[wahli]

Was läuft denn da bzw. was verursacht die hohe Last?
Hört sich nach "Firma" an. Frag mal ein Systemhaus dazu.

 

[Skysnake]

Habe ich doch schon oben geschrieben, was die hohe Last generiert...

Ja, deswegen war ich davon auch recht überrascht. Ich konnte es soweit schon eingrenzen, das es mit nem Service mitwandert, der parallel jede Minute oder so einige hundert bis tausend ipmi Sdr readings macht. Und das halt gleichzeitig.... das macht schon einiges an Last. An sich würde ich das auch gerne weiterhin möglichst synchron halten.

Und was soll denn das für ne Aussage sein?

Frag mal ein Systemhaus dazu

Ich habe keine Ahnung also geh mal irgendwohin und schau ob die vielleicht für Geld helfen können?

Ganz ehrlich diese 0815 Antwort ist zu 80% am Thema vorbei in diesem Forumsbereich...

Was sollen die mir denn sagen?
A. Schauen Sie, dass der traffic besser verteilt wird. Ja ne schon klar, den Aufwand will ich aber eigentlich nicht betreiben, da ich alles möglichst im sync haben will.
B. Verteilen Sie die Last auf mehr Systeme. Habe ich schon dran gedacht, aber eigentlich sehe ich es nicht so ganz ein den Aufwand zu betreiben, da an sich alles tut und nur der eine Support sich nen schlanken Fuß macht.
C. Wir können Ihnen leider nicht helfen...

Und das wars dann wahrscheinlich auch schon. Die Problematik ist ja an sich ziemlich klar. Mich habt nur interessiert, wie andere mit großen Netzen das sehen/bewerten. Aber man sieht ja auch hier, dass das Verständnis schwierig ist. Wir zahlen an verschiedenen Stellen für Support und ich selbst mache L2 bzw L3 Support und ich kann nur sagen, den L1 Support kannst du zu 99% knicken. Da geht es nur darum wie man möglichst schnell an dem vorbei kommt. In der überwiegenden Mehrheit wissen die weniger als man selbst und können einem nicht helfen...

Also was versprichst du dir von nem Systemhaus? Haben die expertise in dem Bereich? Wissen die welche Seiteneffekte Vorschläge haben? Ich würde sagen im überwiegenden. NEIN.

wir machen schon recht spezielles Zeug. Da hast du dann auch bei Firmen wie Juniper oder HPE mit dem L1 Support zu kämpfen, weil es einfach zu speziell ist. Vorm L2 brauchst du eigentlich keine großen Hoffnungen zu haben, eine hilfreiche Antwort zu bekommen.

Deswegen nochmals die Frage, wie sehr ihr das mit package Drops unter den Bedingungen? An sich darf doch keine vernünftige Software damit ein Problem haben. Oder nicht?

Also zumindest unsere Software ist das robust genug und juckt das kein Stück....

Aber klar nen.Support stürzt sich mit Freude darauf. Daher erneut. Wie seht ihr das? Blöd aber verschmerzbar oder riesen Problem? Wie würdet ihr da mit so nem zickigen Support umgehen?

Ich würde es inzwischen ja eskalieren lassen und die Drittfirma rausschmeißen und schauen das ich zumindest teilweise die Kohle wiederbekomme. Aber Chefe bremst beim eskalieren...

 

[wahli]

Du brauchst prof. Support für ein sehr spezielles Netzwerk im Grenzbereich. Den bekommst du hier vermutlich eher nicht.
Ich weiß es nur von meiner Firma, dass die dann ein spez. Monitoring drauf schalten und alles mögliche überwachen. Wie - das weiß ich nicht.

 

[Skysnake]

....

Ich will keinen Support ich will MEINUNGEN hören von Leuten die Netzwerke betreiben.

Monitoring vom Netzwerk gibt es, aber öfter als alle 5 Minuten alle Nerzwerkports auslesen ist nicht wirklich drin, weil die snmp Table Walks zu lange brauchen. Vielleicht geht noch etwas mehr, aber jede Minute war zu viel.

Und im Grenzbereich ist das Netzwerk nicht wirklich. Wie gesagt, das Ding läuft meist mit weniger als 1% Last. Ja es gibt bursts aber das ist MEINER MEINUNG nach ein völlig normales Verhalten in nem größeren Netzwerk. Vor allem ballern wir bei gewissen Aktionen ja auch mit >>100GBit/s von mehreren Systemen aus, also n zu m wobei m>>n ohne Probleme. Sprich ja es gibt einige Drops, aber seltsamerweise juckt das keinerlei Software von uns. Nur ein gewisser Drittanbietersupport meint das als goto Lösung für nen Großteil der Supportanfragen missbrauchen zu können....

Das fällt halt in die Kategorie von HPE. Wenn auch nur ein nicht HPE transciever im Gerät steckt, machen die in der Regel die Supporttickets in Sekunden zu.... wobei ich es da ja sogar noch irgendwo verstehe.

Eigentlich hatte ich den Eindruck, das hier ein paar Leute rumrennen die auch größere Systeme betreuen müssen, selbst wenn es nur VM Cluster sind. Aber da hat mich mein Eindruck wohl sehr getäuscht.

Mit professionellen IT Netzen hat das hier dann aber nichts mehr zu tun im Unterforum. In anderen Topics hat man ja wenigstens immer wieder einzelne Posts von Leuten gesehen, die das wirklich professionell machen.

 

[andy_m4]

Haste denn schon ein Systemhaus kontaktiert? Und was sagen die so?

 

[DonConto]

Ich interpretiere deine Aussage mal so: Der Server (?) meldet incoming drops auf dem Interface, richtig? Dann liegts am Server, der die Daten nicht schnell genug los wird und daher am Interface verwirft. Also ich würde das Problem erstmal am Server suchen. Sehe da keinen Anhaltspunkt, dass es am Netz liegt sofern ich deine Aussagen richtig deute.

 

[Skysnake]

Jup, das ist das was was ich bisher analysiert habe. Es gibt im Netz keinerlei Anzeichen für ein Problem. Aber auch auf dem Server würde ich es nicht als "Problem" bezeichnen. Es sind halt sehr wahrscheinlich kurze bursts die dazu führen. Das muss MEINER Meinung nach jede Software abkönnen. Denn A. Sie verwendet tcp und dann gibt es halt ein resend und gut ist oder B. Sie verwendet udp und dann darf sie eh NICHT davon ausgehen, dass die Pakete immer ankommen.

Ergo gibt es kein echtes Problem. Klar Ausnahme wäre jetzt, wenn dadurch die tale latency ansteigt und deswegen z.b. gewisse SLAs nicht eingehalten werden. Da würde ich es dann auch als Fehler anschauen, aber sonst?

 

[timeh_]

So ganz habe ich der Beschreibung nicht folgen können weil mir die unterscheidung von Endgerät (server, client) und Netzwerkgerät (Switch, Router) fehlt.

Wenn du incoming drops zwischen zwei switches hast und sofern LWL dann hats was
a) am outgoing interface (sfp) der gegenstelle - eher selten mit so wenig drops
b) etwas mit der verkabelung / verpatchung auf der strecke. kaputes kabel, dreckig etc
c) dämpfung/signalstärke auf der strecke passt nicht -> siehe b)
d) ingress queueing themen wie Head of line blocking, virtual output queues etc. - eher unwahrscheinlich bei dem szenario

Dies müsste aber immer alle Applikationen betreffen welche die strecke verwenden. Oder keinem fällts auf oder meldet es...

Aber das kann halt passieren wenn viel incoming traffic existiert.

Dem kann ich nicht zustimmen wenn es sich um 2 Switches handelt. Dort kann incoming eigentlich auf zb. einem 1G interface nicht mehr als 1G ankommen. auch nicht 1,000001G weil die Gegenstelle genau nur 1G senden kann.


Wenn wie von dir beschrieben es um verschiedene installationen, mit verschiedenen Bandbreiten und verschiedenem Netwerk Equipment, wirklich nur die eine und die selbe Applikation betroffen ist, na dann....

 

[dzorg]

Die Statistiken der Switchports sind alle sauber?
Nur ein/mehrere NICs in den Servern zeigen incoming drops? Aber KEINE incoming Errors?

Das deutet meiner bisherigen Erfahrung nach NICHT auf das Netzwerk hin. Der Adapter im Server entscheidet sich, aus welchen Gründen auch immer, korrekt und fehlerfrei empfangene Pakete zu droppen. An der Stelle ist das Netzwerk bereits außen vor. Die Pakete wurden korrekt übermittelt.

Nur weil ein Server 10G/40G/100G Adapter hat bedeutet das nicht zwangsläufig, dass OS/Kernel/Treiber/Software die Datenmenge auch “wegschaffen“ können, unter allen Umständen. Du hast ja mehrfach betont, dass dein Traffic starken Burst Charakter hat, also brachiale Auslastung für kurze Momente. Da lächelt ein guter Enterprise Switch nur müde drüber, die ihr ja offensichtlich habt. Im Server kann es aber kurzzeitig Limits gesprengt haben.

Es könnte sich aber auch um reguläre Drops handeln von Traffic, der den Server nicht interessiert. Pakete mit keinem oder falschem VLAN Tag zum Beispiel. Oder kurzzeitiges, massives Multicast/Broadcast Aufkommen. Da wird auch gern mal was weg geschmissen, wenn es Schwellwerte überschreitet.