CodingBox Q&A Ask question

Q+DA0001 40G DAC między CRS326-24S+2Q+RM a Huawei S6720: obie strony odczytują kabel, link nie wstaje

Asked Active Viewed 144 AI translation from English
7

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

Accepted answer

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:

undo negotiation auto

Na MikroTiku zostaw jak jest albo ustaw to jawnie, żeby nikt tego później nie „naprawił":

/interface ethernet set qsfpplus1-1 auto-negotiation=yes

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.

4 United StatesedgewolfUS Show original (English) AI translation

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ęść.

2 Kazakhstanlanbyte59KZ Show original (English) AI translation

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.

0 Indiawaveeng67IN Show original (English) AI translation

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.

2 Italylambdapilot72IT Show original (English) AI translation

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.

1 Franceedgenode83FR Show original (English) AI translation
Log in to comment. Log in