Q+DA0001 40G DAC między CRS326-24S+2Q+RM a Huawei S6720: obie strony odczytują kabel, link nie wstaje
Przebudowuję agregację w jednej z naszych lokalizacji: CRS326-24S+2Q+RM obsługuje porty SFP+ klientów i łączy się przez 40G z Huawei S6720. Krótki odcinek w tej samej szafie, więc zamiast optyki - pasywny DAC.
- MikroTik CRS326-24S+2Q+RM, port QSFP+ qsfpplus1-1
- Huawei S6720-54C-EI-48S-AC, zwykły port 40GE
- MikroTik Q+DA0001, pasywny DAC QSFP+ 40G
Oba urządzenia poprawnie odczytują kabel: MikroTik pokazuje go jako własny Q+DA0001, a Huawei w opisie portu podaje kabel miedziany 40G. A potem nic się nie dzieje:
MikroTik: qsfpplus1-1 no-link
Huawei: 40GE... current state : DOWN
Co już sprawdzono:
- spięto ten sam kabel pętlą między dwoma portami QSFP+ na CRS326: link wstaje od razu
- spięto go pętlą między dwoma portami 40GE na Huawei: również wstaje
- zamieniono końce miejscami, przełożono na drugi port QSFP+, wszystko wyjęto i włożono ponownie
- sprawdzono, że żadna strona nie jest wyłączona administracyjnie
Czyli kabel jest sprawny i każdy switch z osobna go akceptuje, tylko para między różnymi vendorami odmawia współpracy. Czy komuś realnie udało się podnieść Q+DA0001 między CRS326 a S6720, i co trzeba było zmienić po którejś ze stron, żeby port wstał?
Comments 5
Problem to właśnie to parowanie default na default, tak samo jak wyłączanie obu końców naraz. To, co zadziałało tu przy tej samej kombinacji, jest asymetryczne - brzmi to dziwnie, kiedy się to zapisze, ale tak to wygląda: port 40GE na Huawei z wyłączonym auto-negotiation, podczas gdy qsfpplus1-1 na MikroTiku zachowuje włączony własny autoneg.
Na Huawei, w interfejsie:
Na MikroTiku zostaw jak jest albo ustaw to jawnie, żeby nikt tego później nie „naprawił":
Link 40G wstał zaraz potem na mojej parze CRS326-S6720 i od tamtej pory jest stabilny. Nie nazwałbym tego naprawą, raczej obejściem: te dwie implementacje najwyraźniej nie zgadzają się co do tego, jak powinna przebiegać negocjacja linku DAC 40G, a ustawienie asymetryczne to po prostu ten jeden punkt, w którym obie strony są zadowolone. Rób to w oknie serwisowym, a nie na działającym uplinku, a jeśli nie zadziała, sprawdź, czy twój obraz Huawei w ogóle pozwala wyłączyć autoneg na tym porcie, bo to nie jest uniwersalne.
Cross-vendor 40G, gdzie obie strony widzą kabel, ale żadna go nie podnosi, niemal zawsze sprowadza się do tego, co obie strony portu próbują wynegocjować.
Podaj stan autoneg z obu stron: konfigurację portu 40GE na Huawei i wartość auto-negotiation dla qsfpplus1-1 na MikroTiku, i napisz, czy zmieniałeś którąś z nich względem domyślnej. Napisz też, czy próbowałeś już to wyłączać - na obu końcach naraz czy tylko na jednym, bo to dwa różne eksperymenty.
Testy pętlą dowodzą tylko tego, że kabel jest sprawny. Nic nie mówią o tym, czy obie strony zgadzają się co do tego samego zachowania negocjacji, a to jest właśnie ciekawa część.
Obie strony są na ustawieniach domyślnych: auto-negotiation=yes na qsfpplus1-1 i negotiation auto na porcie 40GE Huawei, i nie ruszałem żadnej z tych konfiguracji poza podniesieniem interfejsów. Próbowałem wyłączyć to na obu końcach naraz, co nic nie zmieniło; wariant jednostronny w ogóle nie przyszedł mi do głowy.
Stan linku zostaje jako no-link na MikroTiku i DOWN na Huawei, a liczniki w ogóle się nie ruszają, więc nigdy nie dochodzi do etapu, w którym którekolwiek z urządzeń zalogowałoby błąd.
To ostatnie zastrzeżenie zasługuje na więcej niż dopisek, bo to dokładnie tam utknąłem. Na S6320-54C-EI, z RouterOS 7.12 po stronie MikroTika, port 40G w ogóle nie pozwala wyłączyć auto-negotiation, więc ta asymetryczna sztuczka nie ma się gdzie zaczepić.
Poza tym objawy identyczne: obie strony odczytują kabel, port zostaje w dole, żadnych błędów nigdzie. Czyli powyższe obejście jest jak najbardziej realne, ale zależne od platformy, a sama niezgodność między tymi dwiema implementacjami 40G, o ile wiem, wciąż pozostaje otwarta.
Dla każdego, kto tu trafi i w ogóle nie może okiełznać DAC między różnymi vendorami: w pewnym momencie taniej jest przestać z tym walczyć.
Miałem Alta Route 10 naprzeciwko CRS309-1G-8S+, gdzie Route 10 rozpoznawał zarówno DAC SFP+ 10Gtek, jak i FS, zgłaszany jako SFP-H10GB-CU2M, a CRS309 nie pokazywał żadnego link partner advertising, i para linkowała tylko wtedy, gdy wymusić 1G. Wymuszenie 10gbase_r w /cfg/sfpX.txt nic nie dało, i niezależnie od tego, jaki moduł siedział w klatce, ethtool na Route 10 uparcie wypisywał tryby baseT. Zamieniłem oba końce na optykę FS SFP-10GSR-85 i link 10G pojawił się natychmiast.
Inna prędkość, inne urządzenia, ta sama lekcja: jeśli kabel jest sprawdzony i sprawny, a obie strony wciąż się nie dogadują, para modułów optycznych kosztuje mniej niż kolejny tydzień strojenia.