Ich debugge einen Fall von verlorenen UDP-Paketen in einem Store-and-Forward-Gigabit-Switch und wollte visualisieren, was innerhalb des Switches passiert, um den Kern des Problems besser zu verstehen.
Das Szenario ist einfach: Zwei stoßweise Datenströme kommen über zwei Ports im Switch und wollen ihn beide über einen dritten Port (den beide gemeinsam haben) verlassen. Der Switch muss also einige Daten eine Zeit lang im Paketpuffer halten.
Das Problem ist: Basierend auf meinen einfachen Berechnungen sollten die Puffer groß genug sein, um den von mir untersuchten Fall zu bewältigen. Ein Datenstrom sendet alle 1,56 ms Bursts von 25 kB (aufgeteilt auf 1514 B-Pakete), der andere sendet alle 1 ms Bursts von 60 kB. Nun hat sogar ein Soho-Switch wie der Netgear GS105E einen Puffer von 128 kB. Die einfache Mathematik (25+60 < 128) sagt also, dass es funktionieren sollte, selbst wenn die Ströme gleichzeitig eingehen (vorausgesetzt, es gibt keinen anderen nennenswerten Verkehr).
Die tatsächlichen Tests zeigen, dass viele Pakete aus beiden Streams bei einigen Switches verloren gehen (das scheint an der Puffergröße zu liegen, aber nicht nur daran). In meiner Simulation kann ich den Puffer nicht überfüllen, wenn er auf 128 kB eingestellt ist.
Ich habe diese Animation für einen 24 kB großen Puffer aufgezeichnet, bei dem es zu einer Überfüllung kommt. Sie können jedoch leicht erkennen, dass eine Vergrößerung des Puffers um nur wenige Bytes das Problem lösen würde und alle Pakete durchkämen.
Ich habe in dieser Simulation einige Vereinfachungen vorgenommen. Alle Pakete haben dieselbe QoS (das ist auch im realen Fall so). Daher habe ich QoS-Warteschlangen aus der Simulation weggelassen und behandle den gesamten Datenverkehr als gleich wichtig. Als nächstes habe ich die Speicherverwaltung des Puffers weggelassen. Ich kann mir vorstellen, dass dies ein wichtiger Teil des Problems ist, aber es würde mich überraschen, wenn meine Vereinfachung mit perfekten Zuweisungen mehr als 10 % vom realen Fall abweichen würde. Ich tue auch so, als ob der Switch die Frame-Länge kennt, wenn er seine ersten Bytes empfängt, sodass er am Anfang den gesamten benötigten Speicher reserviert. Da ich keine Dokumentation über die Größe der Eingangs-/Ausgangswarteschlangen der Ports finden konnte, gehe ich davon aus, dass sie alle im gemeinsam genutzten Paketpuffer platziert sind und einen so großen Teil des Puffers beanspruchen können, wie sie benötigen (obwohl ich denke, dass der Übeltäter irgendwo hier liegen könnte). Ich habe die Verarbeitungsverzögerung jedes Pakets auf 512 ns eingestellt (die Ausbreitungsverzögerung eines 64-B-Pakets).
Ich bin nicht sicher, ob es eine Rolle spielt, aber die Streams bestehen aus fragmentierten UDP-Paketen (d. h. der 25-kB-Burst ist ein einzelnes UDP-Paket, das in 17 IP-Fragmente fragmentiert ist). Der zweite Stream erstellt den Burst als 2 oder 3 20-kB-UDP-Pakete, die jeweils in 14 IP-Fragmente fragmentiert sind.
Iperf 3.7-Befehle zum Replizieren von Streams, die den echten ähneln, lauten:
iperf3 -c sink -u -b 128M -t 600 -l 25256 --pacing-timer 1560
iperf3 -c sink -u -b 400M -t 600 -l 20k --pacing-timer 1000
Habt ihr eine Idee, was ich sonst noch vergessen habe zu berücksichtigen, was dazu führen könnte, dass die Simulation so weit von der Realität entfernt ist? Danke für eure Hilfe!
Der Quellcode für die Animation befindet sich unterhttps://gist.github.com/peci1/a0346538acc6c289b2c6d596b184ad21.
Hier ist meine Ergebnistabelle aus den echten Experimenten. Datenstrom eins ist fest – 128 Mbit/s in 25 kB UDP-Paketen alle 1,56 ms. Ich habe die Parameter des zweiten Stroms geändert, um die Grenze zu finden, ab der Pakete des ersten Stroms vom Switch verloren gehen. Ich habe den -lParameter (Länge) geändert, der die Größe des UDP-Pakets angibt, und den -bParameter (Bandbreite), der angibt, welche Bandbreite diese Pakete generieren sollen. --pacing-timerwar für den zweiten Strom immer auf 1000 eingestellt. Sie können sehen, dass der D-Link und der Netgear GS105 mit den 60 kB-Bursts überhaupt nicht zurechtkommen. Der GS108 schneidet viel besser ab als der GS105, obwohl er fast denselben Switch-Chip hat (dieselbe „Familie“, nur eine andere Anzahl von Ports und einen etwas größeren Puffer).
| Schalten | Puffergröße [kB] | Maximaler Datenverkehr: 1,5 kB Burst | Maximaler Datenverkehr: 20 kB Burst | Maximaler Datenverkehr: 60 kB Burst |
|---|---|---|---|---|
| Gigablox Robust (VSC7512) | 220 | 825 Mbit/s | 825 Mbit/s | 825 Mbit/s |
| Gigablox (RTL8367N-VB-CG) | 250 | 730 Mbit/s | 750 Mbit/s | 790 Mbit/s |
| D-Link DIS-100G-5W (QCA8337N-AL3C) | 128 | 110 Mbit/s | 1 Mbit/s | Jeder Burst verliert Pakete |
| Zyxel XGS 1210-12 (RTL9302B) | 1500 | 800 Mbit/s | 830 Mbit/s | 830 Mbit/s |
| Netgear GS310-TP (RTL8380M) | 520 | 830 Mbit/s | 830 Mbit/s | 835 Mbit/s |
| Netgear GS308T (RTL8380M) | 520 | 830 Mbit/s | 835 Mbit/s | 835 Mbit/s |
| Netgear GS108 v3 (BCM53118) | 192 | 630 Mbit/s | 660 Mbit/s | 710 Mbit/s |
| Netgear GS105E (BCM53114) | 128 | 120 Mbit/s | 1 Mbit/s | Jeder Burst verliert Pakete |
| Renkforce RF-4270245 | ? | 740 Mbit/s | 760 Mbit/s | 800 Mbit/s |
| Mikrotik RB260GS (AR8327) | 128 | 835 Mbit/s | 835 Mbit/s | 835 Mbit/s |
| Juniper EX2300 | 4GB? | 800 Mbit/s | 830 Mbit/s | 830 Mbit/s |
(Diese Frage wurde migriert vonhttps://networkengineering.stackexchange.com/questions/78529/how-to-simulate-what-happens-inside-the-packet-buffer-of-a-simple-switchwo es als Off-Topic markiert wurde).