Około 15% strat pakietów przez miedziany SFP+ S+RJ10 na CRS518-16XS-2XQ, podczas gdy bezpośrednia ścieżka 100G jest czysta
Puszczamy ruch z serwera testowego do CRS518-16XS-2XQ przez uplink 100G QSFP28, a wychodzi ze switcha przez miedziany SFP+ MikroTik S+RJ10 do zwykłego hosta 1G RJ45. Po stronie odbierającej brakuje sporej części pakietów i nie mogę tego przypiąć do niczego oczywistego.
Konfiguracja:
- MikroTik CRS518-16XS-2XQ, uplink 100G QSFP28 od źródła ruchu
- miedziany SFP+ MikroTik S+RJ10 w jednej z klatek, urządzenie 1G RJ45 na drugim końcu
- przechwytywanie ruchu działające na hoście odbierającym
Co mówi przechwytywanie:
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%Co już próbowałem:
- podłączyłem to samo źródło bezpośrednio na 100G, zero strat, więc sam nadawca jest w porządku
- ściągnąłem CPU switcha w dół, teraz siedzi na 1%, a straty nadal się zdarzają
- wyjąłem i osadziłem ponownie S+RJ10 i podmieniłem patchcord do urządzenia 1G
Moduł miedziany to w tym momencie mój główny podejrzany, ale link jest czysty, a interfejs w ogóle nie pokazuje błędów. Czy S+RJ10 jest znany z tego, że tak zjada ruch, czy powinienem szukać gdzie indziej wewnątrz switcha?
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
Średnia 400-500 Mbps przy nierównomiernie nadającym źródle to cała historia. Twój ruch nie jest rozłożony równomiernie: krótkie zrywy opuszczają źródło szybciej niż 1 Gbps, a wszystko powyżej tej linii musi siedzieć w buforze wyjściowym portu, dopóki strona 1G go nie opróżni. Kiedy bufor się zapełnia, switch upuszcza pakiety. To dokładnie mówi ci ruch licznika rx-overflow, i dlatego bezpośrednie połączenie 100G nic nie pokazuje - tam nie ma żadnego zejścia w prędkości, wobec którego trzeba by buforować.
Transceiver jest niewinny. Cokolwiek w tej klatce, miedziane czy światłowodowe, zachowałoby się tak samo, bo strata dzieje się na zejściu ze 100G na 1G, a nie wewnątrz modułu.
Dwie rzeczy do zrobienia. Prawdziwa naprawa jest po stronie nadawcy: rozłóż go tak, żeby pakiety szły równomiernie, zamiast być zapisywane zrywami. Kiedy źródło przestaje produkować zrywy powyżej prędkości wyjściowej, strata znika.
Na switchu możesz sprawić, żeby sytuacja z buforem była mniej wroga:
To kupuje trochę zapasu i pozwala zrywowi dłużej się przejechać, ale nie usuwa przyczyny - jeśli nadawca zrywa wystarczająco mocno i wystarczająco długo, żaden rozmiar bufora cię nie uratuje. Po zmianie dalej obserwuj statystyki QoS switcha i liczniki rx-overflow, żeby widzieć, czy nadal uderzasz w sufit, czy tylko go czasem dotykasz.
Warto zapamiętać ogólną lekcję: port z czystym linkiem, bez błędów i ze zdrowym modułem nadal może zgubić dwucyfrowy procent ruchu wyłącznie z powodu zejścia w prędkości między portami.
Zanim obwinisz moduł, zobacz, co naprawdę mówią liczniki portu. Uruchom
na porcie wejściowym 100G i na klatce z S+RJ10, i celuj konkretnie w linię rx-overflow, a nie w zwykłe liczniki błędów rx/tx. Miedziany SFP+, który jest naprawdę zepsuty, ogłasza się błędami FCS albo migającym linkiem, a nie schludnym ścięciem 15% z poza tym zdrowego strumienia.
Drugie pytanie: jaka jest średnia prędkość na tej ścieżce i czy masz jakieś pojęcie o szczytach? Gubienie jednego pakietu na siedem przy CPU na 1% pachnie o wiele bardziej portem wyjściowym, któremu kończy się bufor, niż awarią transceivera.
Najpierw liczniki: żadnych błędów na żadnym z portów, link cały czas stoi, moduł nie zgłasza niczego niezwykłego. rx-overflow to jedyne miejsce, gdzie liczby w ogóle się ruszają.
Jeśli chodzi o prędkość, ścieżka daje średnio 400-500 Mbps, więc na papierze to w ogóle nie zbliża się do nasycenia strony 1G. Nie mam pomiaru szczytów, ale ruch z natury jest zrywami - nadawca zapisuje porcję i potem na chwilę cichnie. CPU nadal jest na 1%, a pakiety znikają.
Inna awaria, ta sama lekcja o ufaniu licznikom bardziej niż intuicji. Miałem CRS354-48G-4S+2Q+RM na SwOS 2.18 ze stale rosnącymi Rx FCS Errors na obu portach QSFP+ i Rx MAC Errors w wolniejszym tempie. Oba porty stały na 40G pełny dupleks z MTU 1500, a po drugiej stronie były hosty ESXi z kartami Mellanox ConnectX-3 Pro CX324A.
Ciekawa część: strona karty sieciowej nie zgłaszała zupełnie niczego.
Czysto. Kable, o których wiadomo, że są dobre, niczego nie zmieniły, a porty 10G SFP+ tego samego urządzenia przez cały czas zostawały bez błędów. Nigdy nie dostałem prawdziwej diagnozy - przeniesienie switcha z SwOS na RouterOS sprawiło, że liczniki zniknęły, co liczę bardziej jako ukrycie problemu niż jego rozwiązanie.
Metoda, która się sprawdziła: wyczyść liczniki, odczytaj je ponownie po ustalonym czasie i zobacz, czy błędy podążają za wolumenem ruchu. W twoim przypadku będą podążać za zrywami, w moim nie podążały za niczym użytecznym, i już sama ta różnica mówi, po której stronie dalej kopać.
Jedna rzecz do zapamiętania, gdy eksperymentujesz na tym porcie: nie sięgaj po wymuszoną prędkość i dupleks jako wyjście z sytuacji. Udokumentowane zachowanie miedzianych modułów MikroTika, zarówno S-RJ01, jak i S+RJ10, jest takie, że działają tylko z włączoną auto-negocjacją - przypnij prędkość na sztywno i link w ogóle nie wstanie. Praktyka częściowo temu przeczy, bo kilku właścicieli RB5009 i RB4011 zgłasza coś przeciwnego i ustabilizowało S-RJ01 dopiero po wymuszeniu 1G pełny dupleks, więc to bardziej sprawa "sprawdź oba warianty na swoim sprzęcie" niż reguła. Tak czy inaczej to objazd od twojego prawdziwego problemu, który leży po stronie bufora.
Jeszcze jeden szczegół o S+RJ10 warty zapamiętania na potem: pobiera zauważalnie więcej mocy niż zwykła optyka i mocno się grzeje, więc nie jest polecany w urządzeniu z chłodzeniem pasywnym bez dodatkowego przepływu powietrza. Jeśli ten moduł kiedyś zacznie się źle zachowywać w ciepłym chassis, temperatura to pierwsza rzecz, którą bym sprawdził.