Einschätzung zu package drop in 10G+ Netzwerk

[Skysnake]

Ich sollte es eigentlich gesagt haben, aber ich rede nur von Drops auf dem Ingress von ein paar Servern, wobei der Drop mit einer gewissen Anwendung (Monitoring) mit wandert, aber keinen ersichtlichen Einfluss auf diese hat.

Auf den Switches sehen wir im gesamten Netz auch keine Probleme. Bei 1% Nutzung der Bandbreite und L2 switching ja auch kein Wunder. Da schaffen die Switche wohl zu buffern. Man hat ja sowas wie 500x1G wobei jeder 1-10kB sendet auf 1x10G. Also um die eine ms um die Daten über den 10G link zu übertragen. Da wird die Streuung der Sender sicherlich größer sein und da das nur paarmal pro Minute passiert geht es in den Statistiken völlig unter.

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.

Ja, da geht es nur mit outgoing. Sind halt immer die n:1 Szenarien. Aber das ist halt ein zu erwartendes Verhalten das meiner Meinung nach im Allgemeinen zu keinen Problemen führen darf. Vor allem kann es aber nicht sein, das ich keinen Unterschied sehe, wenn ich die Grundlast von einigen Dutzend Mb/s auf 1Gb/s steigere keinen Unterschied beim Fehlerlogging sehe.... wenn es wirklich ein grundsätzliches Problem wäre müssten die Fehler ja viel viel häufiger auftreten. Tun Sie aber nicht -> Ausrede vom Support..

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....

Ja???

Ergänzung (26. Dezember 2021)

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

Ja, die Switch Ports sind im Allgemeinen komplett sauber. Klar hat man mal nen Flapping Link wegen kaputten Kabel oder nen kaputten Transciever, aber das wird erkannt und erst mal reseeded und dann getauscht.

Genau die Server um die es geht haben 0 errors laut Monitoring aber eben Drops.

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.

Gut, das passt ja zu dem was ich herausgefunden habe als nicht orginärer Netzwerker. Ich kenne mich da durchaus bei Ethernet und IB aus bis in die technischen Details vom Routing/Protokollen, bin aber kein orginärer Netzwerker. Habe also garantiert Wissenslücken...

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.

Hmm... wir verwenden VLANs in der Regel. Eventuell haben wir aber auch eine Installation ohne, wobei ja immer irgendwas mit VLANs unabsichtlich konfiguriert ist... wobei wir die Switche unter Kontrolle haben und dann genau wissen welche VLANs an welchem Port an liegen. Das passt an sich auch. Wir haben da nur statische Configs...

Könnte es aber sein, das ein Endgerät im falschen/keinem VLAN hängt und dann bis zum Server geroutet wird, weil der halt auf dem Port in allen VLANs ist, dann der NIC das aber verwirft, da in dem Subnetz keine IP vorhanden ist? Das kann doch eigentlich nur mit Multicast/Broadcast passieren oder??? Sorry, aber das sind jetzt so kompliziertere Szenarien die ich dann erst mal durchdenken und auch nachschlagen muss...

Oder kurzzeitiges, massives Multicast/Broadcast Aufkommen. Da wird auch gern mal was weg geschmissen, wenn es Schwellwerte überschreitet.

Hmm... das ist ein interessanter Einwurf! Wir haben z.b. bewusst Broadcast Stormprotection ausgeschaltet, da wir sehe schnell alle Server einschalten können wollen. Vom DHCP Server her können wir auch >1000 DHCP requests pro Sekunde bearbeiten und sehen beim Booten auch nicht, dass die Systeme zwei DHCP requests machen müssten. Zumindest wäre uns das bisher nicht aufgefallen. Aber ich werde mal explizit darauf achten.

Ich würde es aber mal ausschließen für die Drops die ich sehe, da wir nur sehr sehr selten solche Bootaktionen haben, darauf aber wegen Verfügbarkeit designen müssen. Also explizit Arbeit reinstecken das performant zu lösen.

Ich wüsste jetzt auch nicht, was ansonsten noch Broad-/Multicasts auslösen könnte. Vor allem nicht in relevanten Umfang. Ich kann mich aber dunkel dran erinnern die Broadcast counter ansteigen zu sehen. Ich bin mir nur nicht sicher ob das nun in oder outgoing traffic ist. Zudem hatte ich mir das während Boots gesehen. Da kamen also von den DHCP Requests welche rein.. ich werde mir das im neuen Jahr definitiv nochmals anschauen!

Wobei, wenn ich drüber nachdenke haben wir natürlich doch eine Quelle für Broadcasts. Die Arp Requests. Da könnte es natürlich sein das einige devices im Netz das regelmäßig machen.

Aber wie unterscheide ich denn jetzt warum gedropped wird? Ich habe dazu nichts gefunden 😔

Aber auf jeden Fall vielen Dank für die Antwort. Genau sowas hatte ich mir erhofft. Das ist jetzt ein neuer Input den ich kontrollieren kann, und wenn es das ist, dann ist der letzte Stein ausgeräumt die Sache richtig eskalieren zu lassen....

 

[dzorg]

Hmm... wir verwenden VLANs in der Regel. Eventuell haben wir aber auch eine Installation ohne, wobei ja immer irgendwas mit VLANs unabsichtlich konfiguriert ist... wobei wir die Switche unter Kontrolle haben und dann genau wissen welche VLANs an welchem Port an liegen. Das passt an sich auch. Wir haben da nur statische Configs...

Könnte es aber sein, das ein Endgerät im falschen/keinem VLAN hängt und dann bis zum Server geroutet wird, weil der halt auf dem Port in allen VLANs ist, dann der NIC das aber verwirft, da in dem Subnetz keine IP vorhanden ist? Das kann doch eigentlich nur mit Multicast/Broadcast passieren oder??? Sorry, aber das sind jetzt so kompliziertere Szenarien die ich dann erst mal durchdenken und auch nachschlagen muss...

Da liegst du richtig. In diesem Fall ist eine IP-Konfiguration auf dem Server innerhalb eines VLANs tatsächlich irrelevant. Der Sub-Adapter in dem VLAN auf dem Server schaut nur, ob der Layer 2 Ethernet Frame zu ihm gehört, sprich: ob das VLAN Tag passt. Der Server erhält dann BUM-Traffic (Broadcast, unknown-unitcast, Multicast) aus dem VLAN. Layer 3 Unicast bekommt er nicht, wenn er keine IP hat - er kann ja ohne IP nicht auf ARP antworten.

Drops auf dem Server-Adapter aufgrund eines VLAN Mismatches können dann vorkommen, wenn der Switchport zusätzlich in einem oder mehreren VLANs hängt, die auf dem Server-Adapter (noch) fehlen. Beide Seiten sollten natürlich abgeglichen werden. Eine weitere Möglichkeit wäre, dass der Switchport auch hin un wieder Frames ohne VLAN-Tag sendet. Da können je nach Switch-Hersteller und Konfiguration die interessantesten Dinge passieren. Cisco (und andere) haben bei getaggten Switchports trotzdem gern ihr "untagged native VLAN"; viele Hersteller nutzen zudem ein internes "Control VLAN" für Single-Spanning-Tree, LLDP, sonstige Loop Protection, usw., welches dann untagged mitläuft, während die Nutz-VLANs alle getagged sind. Da gibt es unzählige Möglichkeiten.

Wenn der Server-Adapter dann hin und wieder "incoming Drops" anzeigt, aber KEINE incoming Errors, wäre das aus meiner Sicht ein ganz normales Betriebsverhalten. Der Server sagt entweder "habe ich empfangen, will ich aber nicht haben" oder "habe ich empfangen, kann ich aber gerade nicht verarbeiten - bin zu beschäftigt bzw. meine Queue ist voll".

Erst wenn dein Server "incoming Errors" hochzählt, schaut man auf das Netzwerk. Das kann dann alles mögliche sein... defekte Verkabelung, matschige SFP-Module, ASIC oder Port im Switch defekt, Laufzeitfehler in der Switch-Firmware, die durch einen Reboot behoben werden können, etc.

Hmm... das ist ein interessanter Einwurf! Wir haben z.b. bewusst Broadcast Stormprotection ausgeschaltet, da wir sehe schnell alle Server einschalten können wollen. Vom DHCP Server her können wir auch >1000 DHCP requests pro Sekunde bearbeiten und sehen beim Booten auch nicht, dass die Systeme zwei DHCP requests machen müssten. Zumindest wäre uns das bisher nicht aufgefallen. Aber ich werde mal explizit darauf achten.

Broadcast/Multicast ist ja erstmal nichts schlimmes, solange er in gewissem Rahmen bleibt. Schwache Endgeräte (VoIP-Telefone beispielsweise) bekommst du mit massiv Broadcast/Multicast aber schnell platt. Im Normalbetrieb sieht man hier typischerweise ARP oder auch Router-Standby-Protokolle wie VRRP. Wenn du einen Loop hättest und aufgrund dessen einen Broadcast-Storm, hättest du ganz andere Probleme.

Beim DHCP Server spielt nur das eigene VLAN für Broadcast eine Rolle. Wenn du in dem betreffenden VLAN nicht gerade einige Zehntausend Clients hast, sollte das kein Problem sein. DHCP-Request aus anderen VLANs werden über die IP-Helper auf den Routern in Unicast in Richtung des DHCP-Servers umgewandelt.

Leider gibt es hier und da mal spezielle Applikationen von Entwicklern, die der Meinung sind, Broadcast/Multicast ist eine tolle Methode, verschiedene Nodes massiv miteinander kommunizieren zu lassen.

Aber wie unterscheide ich denn jetzt warum gedropped wird? Ich habe dazu nichts gefunden 😔

Da bist du wohl leider darauf angewiesen, dass dir dein Endgerät das aufschlüsselt. Wenn das im OS/Kernel/Treiber nicht vorgesehen ist, bleibt das wohl verborgen, wenn es nirgendwo mitgeloggt wird.

Router/Switches schlüsseln das teilweise auf... entweder der Hersteller unterstützt die Funktion, oder halt nicht.

 

[Skysnake]

Broadcast ist ja erstmal nichts schlimmes, solange er in gewissem Rahmen bleibt. Schwache Endgeräte (VoIP-Telefone beispielsweise) bekommst du mit massiv Broadcast/Multicast aber schnell platt. Im Normalbetrieb sieht man hier typischerweise ARP oder auch Router-Standby-Protokolle wie VRRP. Wenn du einen Loop hättest und aufgrund dessen einen Broadcast-Storm, hättest du ganz andere Probleme.

Oh ja, mit ner Loop im Netz schießt man sich schnell die BMC ab. Ist echt toll, wenn jemand hin muss und Dutzende Server stromlos machen muss, weil der BMC tot ist und die Server gerade wegen Wartung offline waren... dann kannst ja kein Cold Reset mehr vom Host aus machen ;(

DHCP-Request aus anderen VLANs werden über die IP-Helper auf den Routern in Unicast in Richtung des DHCP-Servers umgewandelt.

Wir haben flache Netzwerke ohne IP Helper DHCP forwarding. Klar könnte man das machen, bis jetzt haben wir dafür aber noch keinen Grund gesehen und dann spart man sich natürlich die Konfiguration. Ist dann ja nur eine unnötige zusätzliche Fehlerquelle und damit nicht KISS.

Leider gibt es hier und da mal spezielle Applikationen von Entwicklern, die der Meinung sind, Broadcast/Multicast ist eine tolle Methode, verschiedene Nodes massiv miteinander kommunizieren zu lassen.

Overlaynetzwerke z.b.

Hat ein Kunde auf unserem Netzwerk laufen und toi toi bisher keine Probleme deswegen gesehen, was mich ehrlich gesagt ziemlich überrascht hat. Ich wollte mal auch das Monitoring für den Teilbereich checken und notfalls ergänzen um mir das im Detail anschauen zu können. Aber Zeit.....

Da bist du wohl leider darauf angewiesen, dass dir dein Endgerät das aufschlüsselt. Wenn das im OS/Kernel/Treiber nicht vorgesehen ist, bleibt das wohl verborgen, wenn es nirgendwo mitgeloggt wird.

Kann das Linux? Also ein RH derivat?

Router/Switches schlüsseln das teilweise auf... entweder der Hersteller unterstützt die Funktion, oder halt nicht.

Naja, da es das Endgerät ist sollte man das ja nicht sehen. Broadcasts sehe ich. Ob nach VLAN weiß ich ehrlich gesagt nicht...

 

[DonConto]

Oh ja, mit ner Loop im Netz schießt man sich schnell die BMC ab. Ist echt toll, wenn jemand hin muss und Dutzende Server stromlos machen muss, weil der BMC tot ist und die Server gerade wegen Wartung offline waren... dann kannst ja kein Cold Reset mehr vom Host aus machen ;(

Öhm. Sowas kann man verhindern. Entweder mit einem Limiter für Broadcast oder...

Wir haben flache Netzwerke ohne IP Helper DHCP forwarding. Klar könnte man das machen, bis jetzt haben wir dafür aber noch keinen Grund gesehen und dann spart man sich natürlich die Konfiguration. Ist dann ja nur eine unnötige zusätzliche Fehlerquelle und damit nicht KISS.

...keine flachen Netze bauen sondern Microsegmente.

 

[Skysnake]

Öhm. Sowas kann man verhindern. Entweder mit einem Limiter für Broadcast oder...

Limitiert wären mir jetzt nicht bekannt in den von uns verwendeten Switchen.

...keine flachen Netze bauen sondern Microsegmente.

Bei uns muss aber jeder mit jedem Kommunizieren können mit voller line rate.

Im Zweifel auch mit 100% der line rate der Server.

Ein segmentiertes Netz sehe ich da nicht wirklich, lasse mich aber auch gerne vom Gegenteil überzeugen.

 

[dzorg]

Och, gute L3 Switches schaffen auch Line Rate Routing.

 

[Skysnake]

Ja klar, haben wir von Juniper und HPE im Einsatz, wobei ich mir nicht sicher bin ob die wirklich line rate können, aber die Kosten schon ne Stange Geld... und wenn es nicht sein muss, muss man ja auch kein Geld zum Fenster raushauen.

5-10 mal 40-100G und 40-200x10G werden solche L3 Switche im Vergleich zu L2(+) schon echt verdammt teuer. Ich denke du kannst da nachvollziehen, warum man sich dagegen sträubt. Vor allem weil das wirklich ein LAN ist und kein WAN.

 

[DonConto]

Sicherlich alles eine Frage des Geldes. Aber wenn man Fehlerdomänen (kann man googeln) klein halten möchte, dann segmentiert man sein Netz. Ein Hauptgrund sind nämlich die von dir bemängelten Broadcaststürme, die man damit zumindest lokal begrenzen kann. Das hat nichts mit dem WAN zu tun. Routing im LAN ist Standard. Aber ich möchte natürlich niemandem ein bestimmten Design aufschwatzen. Jede Umgebung muss individuell bewertet werden. Pauschale Aussagen zeugen oft von Unkenntnis

 

[Skysnake]

Ja klar, i h weiß was du meinst. Bei uns ist es aber so, dass das Gesamtsystem meist nicht mehr als Funktional angesehen wird, wenn 10% vom System weg sind zudem läuft über Ethernet rein das Management. Es muss überhaupt tun, aber selbst 100Mbit wären akzeptabel. Klar, für die Abnahme muss 1G teils sein, weil man ansonsten das eine oder andere Commitment wegen ein paar Sekunden eventuell nicht einhält. Aber im Normalbetrieb juckt das eigentlich keinen, weil man es eigentlich nicht sieht.... der Link darf nur nicht ko.plett weg sein...

Hier mit Bonding zu arbeite. Wird aber kein Kunde bezahlen. Dafür ist es einfach zu unwahrscheinlich. Kenne genug die selbst beim Core Switch auf Redundanz verzichten und Sie haben oft Recht damit. Für ne Uni ist es egal wenn das System au h mal ne Woche steht, dafür aber über die Laufzeit mehr Compuecycles zur Verfügung stehen.

Aber klar auf der anderen Seite haben wir Kunden, da wird nen zweiter Standort aufgebaut um georeplikation zu haben. Aber selbst da sind die Client Server ohne Bonding angeschlossen. Da stellst lieber paar mehr Server hin. Bis jetzt fahren wir damit gut.

 

[Skysnake]

Btw mal ein kleines Update. Wir haben jetzt seit einigen Wochen die RX buffer vergrößert und zusätzlich noch per sysctl den Kernel Parameter für Die Zeit angehoben die der Kernel hat um den Ringbuffer zu leeren.

Man hat nämlich gesehen, dass der Kernel reported hat das er es nicht geschafft hat den kleinen Ringbuffer in einem timeslice zu leeren.

Zusammen hat es die Problematik komplett gelöst. Selbst unter sehr hoher Netzwerklast nahe der line rate haben wir quasi keine gedropped packages mehr. Da das aber quasi nie vorkommt und eine Sonderrolle einnimmt.

Die Vermutung mit den zu vielen Packeten innerhalb eines sehr kleinen Zeitfensters war also richtig.

Was ich noch gesehen hatte war, das wohl keine flowcontrol an war/ist. Das wäre an sich nich ne Idee gewesen, aber dann hätten wir halt das Problem der reduzierten Bandbreite, was ja wie man sieht nicht nötig ist weil man es auch anders gelöst bekommt.

Vielleicht hilft es ja jemanden der mal das selbe Problem hat. Auch wenn es wohl nicht viele treffen wird, denn ein paar hundert Clients braucht es schon die quasi gleichzeitig senden.