Rund 15% Paketverlust über ein S+RJ10-Kupfer-SFP+ an einem CRS518-16XS-2XQ, während der direkte 100G-Pfad sauber ist
Wir schicken Traffic von einem Laborserver in einen CRS518-16XS-2XQ über einen 100G-QSFP28-Uplink, und er verlässt den Switch über ein MikroTik S+RJ10 Kupfer-SFP+ zu einem einfachen 1G-RJ45-Host. Auf der Empfangsseite fehlt ein großer Anteil der Pakete, und ich kann es an nichts Offensichtlichem festmachen.
Aufbau:
- MikroTik CRS518-16XS-2XQ, 100G-QSFP28-Uplink von der Traffic-Quelle
- MikroTik S+RJ10 Kupfer-SFP+ in einem der Käfige, 1G-RJ45-Gerät am anderen Ende
- Capture läuft auf dem empfangenden Host
Was das Capture sagt:
100G QSFP28 uplink -> CRS518-16XS-2XQ -> S+RJ10 -> 1G RJ45 host
capture on the 1G host: ~15% of the packets never arrive
same source, direct 100G connection: nothing missing
switch CPU load: 1%Bisher versucht:
- dieselbe Quelle direkt bei 100G angeschlossen, überhaupt kein Verlust, der Sender selbst ist also in Ordnung
- die Switch-CPU heruntergebracht, sie sitzt jetzt bei 1%, während der Verlust weiter passiert
- das S+RJ10 neu eingesetzt und das Patchkabel zum 1G-Gerät getauscht
Das Kupfermodul ist mein Hauptverdächtiger im Moment, aber der Link ist sauber, und das Interface zeigt überhaupt keine Fehler. Ist bekannt, dass das S+RJ10 auf diese Weise Traffic frisst, oder sollte ich anderswo im Switch suchen?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
400-500 Mbps im Schnitt bei einem stoßweise sendenden Absender ist die ganze Geschichte. Euer Traffic ist nicht gleichmäßig verteilt: kurze Bursts verlassen die Quelle schneller als 1 Gbps, und alles oberhalb dieser Linie muss im Egress-Puffer des Ports sitzen, bis die 1G-Seite ihn leert. Ist der Puffer voll, verwirft der Switch. Genau das sagt euch die rx-overflow-Bewegung, und genau deshalb zeigt die direkte 100G-Verbindung nichts - dort gibt es keine Geschwindigkeitsstufe, gegen die gepuffert werden müsste.
Der Transceiver ist unschuldig. Alles in diesem Käfig, Kupfer oder Faser, würde sich gleich verhalten, weil der Verlust bei der Stufe von 100G auf 1G passiert und nicht im Modul.
Zwei Dinge zu tun. Der eigentliche Fix liegt beim Absender: ihn so takten, dass die Pakete gleichmäßig verteilt statt in Bursts geschrieben werden. Sobald die Quelle keine Bursts oberhalb der Egress-Rate mehr produziert, verschwindet der Verlust.
Am Switch lässt sich die Puffersituation weniger feindselig gestalten:
Das kauft Spielraum und lässt einen Burst länger durchhalten, beseitigt aber nicht die Ursache - wenn der Absender lang und hart genug bursted, rettet keine Puffergröße. Nach der Änderung weiter die Switch-QoS-Statistiken und die rx-overflow-Zähler beobachten, um zu sehen, ob die Decke noch getroffen wird oder nur gelegentlich gestreift.
Die generelle Lehre daraus lohnt sich zu behalten: Ein Port mit sauberem Link, ohne Fehler und mit einem gesunden Modul kann trotzdem einen zweistelligen Anteil des Traffics verwerfen, rein wegen einer Geschwindigkeitsstufe zwischen Ports.
Bevor dem Modul die Schuld gegeben wird: nachsehen, was die Port-Zähler tatsächlich sagen. Ausführen
am 100G-Ingress-Port und am Käfig mit dem S+RJ10, und gezielt nach der rx-overflow-Zeile schauen statt nach den üblichen rx/tx-Fehlerzählern. Ein wirklich kaputtes Kupfer-SFP+ meldet sich mit FCS-Fehlern oder einem flatternden Link, nicht mit einem sauberen 15%-Schnitt aus einem sonst gesunden Stream.
Zweite Frage: Wie hoch ist die durchschnittliche Rate auf diesem Pfad, und gibt es eine Vorstellung von den Spitzen? Ein Paket von sieben zu verlieren, bei 1% CPU, riecht viel eher danach, dass dem Egress-Port der Puffer ausgeht, als nach einem Transceiver-Defekt.
Zähler zuerst: keine Fehler auf beiden Ports, der Link bleibt die ganze Zeit oben, und das Modul meldet nichts Ungewöhnliches. rx-overflow ist die einzige Stelle, an der sich überhaupt Zahlen bewegen.
Zur Rate: Der Pfad liegt im Schnitt bei 400-500 Mbps, auf dem Papier also weit davon entfernt, die 1G-Seite zu sättigen. Eine Spitzenmessung habe ich nicht, aber der Traffic ist von Natur aus stoßweise - der Absender schreibt einen Brocken und ist dann eine Weile still. Die CPU liegt weiter bei 1%, während Pakete verschwinden.
Anderer Fehler, gleiche Lektion: Zählern mehr trauen als dem Bauchgefühl. Ich hatte einen CRS354-48G-4S+2Q+RM auf SwOS 2.18 mit stetig wachsenden Rx FCS Errors auf beiden QSFP+-Ports und Rx MAC Errors mit niedrigerer Rate. Beide Ports standen auf 40G Vollduplex mit MTU 1500, und auf der anderen Seite hingen ESXi-Hosts mit Mellanox-ConnectX-3-Pro-CX324A-Karten.
Der interessante Teil: Die NIC-Seite meldete rein gar nichts.
Sauber. Nachweislich gute Kabel haben nichts geändert, und die 10G-SFP+-Ports derselben Box blieben die ganze Zeit fehlerfrei. Eine echte Diagnose habe ich nie bekommen - der Switch-Wechsel von SwOS auf RouterOS ließ die Zähler verschwinden, was ich eher als Verstecken des Problems zähle denn als Lösung.
Die Methode, die überlebt hat: Zähler löschen, über ein festes Intervall neu auslesen und sehen, ob die Fehler mit dem Traffic-Volumen mitgehen. Bei euch werden sie den Bursts folgen, bei mir folgten sie nichts Brauchbarem, und allein dieser Unterschied sagt, auf welcher Seite man weitergräbt.
Eine Sache, die man im Hinterkopf behalten sollte, während an diesem Port experimentiert wird: nicht zu fester Speed und Duplex als Ausweg greifen. Das dokumentierte Verhalten der MikroTik-Kupfermodule, S-RJ01 wie S+RJ10, ist, dass sie nur mit aktivierter Auto-Negotiation funktionieren - die Rate statisch festgenagelt, und der Link kommt überhaupt nicht hoch. Die Praxis widerspricht dem teilweise, denn ein paar RB5009- und RB4011-Besitzer berichten das Gegenteil und haben ein S-RJ01 erst stabil bekommen, indem sie 1G Vollduplex erzwungen haben, es ist also eher ein "bei der eigenen Hardware beides ausprobieren" als eine feste Regel. So oder so ist das ein Umweg vom eigentlichen Problem, das auf der Pufferseite liegt.
Das andere S+RJ10-Detail, das man sich für später merken sollte: Es zieht spürbar mehr Strom als eine normale Optik und läuft heiß, deshalb wird es in einem passiv gekühlten Gerät ohne zusätzlichen Luftstrom nicht empfohlen. Fängt dieses Modul irgendwann in einem warmen Chassis an, sich daneben zu benehmen, wäre die Temperatur das Erste, was ich prüfen würde.