Ongeveer 15% pakketverlies via een S+RJ10 koperen SFP+ op een CRS518-16XS-2XQ terwijl het rechtstreekse 100G-pad schoon is
We sturen verkeer van een labserver naar een CRS518-16XS-2XQ via een 100G QSFP28-uplink, en het verlaat de switch via een MikroTik S+RJ10 koperen SFP+ naar een gewone 1G RJ45-host. Aan de ontvangende kant ontbreekt een groot deel van de pakketten en ik kan het nergens duidelijk op vastpinnen.
Opstelling:
- MikroTik CRS518-16XS-2XQ, 100G QSFP28-uplink vanaf de verkeersbron
- MikroTik S+RJ10 koperen SFP+ in een van de cages, 1G RJ45-apparaat aan het verre eind
- capture actief op de ontvangende host
Wat de capture laat zien:
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%Al geprobeerd:
- dezelfde bron rechtstreeks op 100G aangesloten, geen enkel verlies, dus de zender zelf is in orde
- de CPU-belasting van de switch omlaag gebracht, die zit nu op 1% terwijl het verlies zich nog steeds voordoet
- de S+RJ10 opnieuw geplaatst en de patchkabel naar het 1G-apparaat vervangen
De koperen module is op dit moment mijn hoofdverdachte, maar de link is schoon en de interface toont helemaal geen fouten. Staat de S+RJ10 erom bekend dat hij zo verkeer opeet, of moet ik ergens anders in de switch zoeken?
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 gemiddeld met een schoksgewijze zender is het hele verhaal. Je verkeer is niet gelijkmatig verdeeld: korte bursts verlaten de bron sneller dan 1 Gbps, en alles boven die lijn moet in de egress-buffer van de poort wachten tot de 1G-kant het leegtrekt. Als de buffer vol is, dropt de switch. Dat is precies wat de toename in rx-overflow je vertelt, en daarom laat de rechtstreekse 100G-verbinding niets zien - daar is geen snelheidsstap naar beneden om tegen te bufferen.
De transceiver is onschuldig. Alles in die cage, koper of fiber, zou zich hetzelfde gedragen, omdat de drop gebeurt bij de stap van 100G naar 1G en niet in de module.
Twee dingen om te doen. De echte oplossing zit bij de zender: temporiseer hem zodat de pakketten gelijkmatig verspreid worden in plaats van in bursts geschreven. Zodra de bron stopt met bursts boven de egress-rate te produceren, verdwijnt het verlies.
Op de switch kun je de buffersituatie minder vijandig maken:
Dat koopt speelruimte en laat een burst langer uitrijden, maar het haalt de oorzaak niet weg - als de zender hard genoeg en lang genoeg burst, redt geen enkele buffergrootte je. Blijf na de wijziging de QoS-statistieken van de switch en de rx-overflow-tellers in de gaten houden, zodat je kunt zien of je het plafond nog steeds raakt of er nog maar af en toe tegenaan loopt.
De algemene les is de moeite waard om te onthouden: een poort met een schone link, geen fouten en een gezonde module kan nog steeds een dubbelcijferig deel van het verkeer droppen, puur door een snelheidsstap tussen poorten.
Voordat je de module de schuld geeft, kijk eerst wat de poortcounters echt zeggen. Draai
op de 100G-ingresspoort en op de cage met de S+RJ10 erin, en let specifiek op de rx-overflow-regel in plaats van op de gebruikelijke rx/tx-foutentellers. Een koperen SFP+ die echt kapot is, meldt zich met FCS-fouten of een flapperende link, niet met een keurige 15% die van een verder gezonde stroom wordt afgeknipt.
Tweede vraag: wat is de gemiddelde snelheid over dat pad, en heb je enig idee van de pieken? Eén op de zeven pakketten verliezen terwijl de CPU op 1% staat, ruikt veel meer naar een egress-poort die zonder buffer komt te zitten dan naar een transceiverfout.
Eerst de counters: geen fouten op beide poorten, de link blijft de hele tijd up en de module meldt niets ongewoons. rx-overflow is de enige plek waar de cijfers überhaupt bewegen.
Qua snelheid haalt het pad gemiddeld 400-500 Mbps, dus op papier is het nergens in de buurt van het verzadigen van de 1G-kant. Ik heb geen piekmeting, maar het verkeer is van nature schoksgewijs - de zender schrijft een brok en valt dan een tijdje stil. De CPU staat nog steeds op 1% terwijl er pakketten verdwijnen.
Ander mankement, zelfde les over counters vertrouwen boven intuïtie. Ik had een CRS354-48G-4S+2Q+RM op SwOS 2.18 met gestaag oplopende Rx FCS Errors op beide QSFP+-poorten, en Rx MAC Errors in een lager tempo. Beide poorten stonden op 40G full duplex met MTU 1500, en aan de andere kant zaten ESXi-hosts met Mellanox ConnectX-3 Pro CX324A-kaarten erin.
Het interessante deel: de NIC-kant meldde helemaal niets.
Schoon. Kabels waarvan bekend was dat ze goed waren, veranderden niets, en de 10G SFP+-poorten van dezelfde box bleven de hele tijd foutvrij. Ik heb er nooit een echte diagnose voor gekregen - de switch van SwOS naar RouterOS verhuizen liet de counters verdwijnen, wat ik reken tot het verbergen van het probleem in plaats van het oplossen ervan.
De methode die overeind bleef: de counters wissen, ze over een vast interval opnieuw uitlezen en kijken of de fouten het verkeersvolume volgen. In jouw geval zullen ze de bursts volgen, in mijn geval volgden ze niets bruikbaars, en dat verschil alleen al vertelt je aan welke kant je moet blijven graven.
Eén ding om in gedachten te houden terwijl je op die poort experimenteert: grijp niet naar geforceerde snelheid en duplex als uitweg. Het gedocumenteerde gedrag van de koperen MikroTik-modules, zowel S-RJ01 als S+RJ10, is dat ze alleen werken met auto-negotiation ingeschakeld - zet de snelheid statisch vast en de link komt helemaal niet op. De praktijk spreekt dat deels tegen, want een paar eigenaars van RB5009 en RB4011 melden het tegenovergestelde en kregen een S-RJ01 alleen stabiel door 1G full duplex te forceren, dus het is eerder een kwestie van "allebei uitproberen op je eigen hardware" dan een vaste regel. Hoe dan ook is het een omweg van je eigenlijke probleem, dat aan de bufferkant zit.
Het andere S+RJ10-detail dat het onthouden waard is: hij trekt merkbaar meer stroom dan een normale optiek en wordt heet, dus wordt hij niet aanbevolen in een passief gekoeld apparaat zonder extra luchtstroom. Als die module ooit gek begint te doen in een warm chassis, is temperatuur het eerste wat ik zou controleren.