Klaster SRX1500 po dark fiber: port HA CONTROL nie zapala się z SFP-LH 740-011612
Dwa SRX1500 stoją w oddzielnych serwerowniach, kilka kilometrów od siebie, połączone parami dark fiber, które mamy od końca do końca na własność. Muszą wstać jako chassis cluster, co oznacza, że control link musi przejść tym światłowodem zamiast patchcordem w obrębie jednej szafy.
Konfiguracja:
- dwa Juniper SRX1500, identyczna konfiguracja sprzętowa
- Juniper SFP-LH 740-011612 w porcie HA CONTROL każdego node'a
- jedna dedykowana para dark fiber dla control linku, spatchowana na wprost
- miedziany moduł SFP-T dołączony fabrycznie do chassis, użyty wcześniej do testu back to back
Z założonym SFP-LH nie dzieje się kompletnie nic. Żadnej diody na cage'u, żadnego linku, klaster w ogóle się nie tworzy:
> show chassis cluster interfaces
Control link status: Down
Control interfaces:
Index Interface Status
0 em0 Down
Co już zrobiłem:
- przeniosłem control link na drugą parę światłowodu, bez zmian na żadnym z node'ów
- zamieniłem moduły między dwoma node'ami, ten sam wynik na obu
- włożyłem z powrotem SFP-T jako test kontrolny, i stał down aż do pełnego restartu chassis, po którym od razu wstał
Ten ostatni punkt niepokoi mnie bardziej niż martwa optyka. Czy port HA CONTROL w SRX1500 w ogóle akceptuje SFP-LH 740-011612 albo SFP-SX 740-011613, czy tylko dołączony fabrycznie SFP-T? I czy ktoś wpinał w ten port DWDM SFP i działało?
Comments 4
Zanim obwinisz optykę, co urządzenie faktycznie widzi w tym gnieździe? Wrzuć
show chassis hardwarez włożonym SFP-LH i sprawdź, czy dla tego slotu w ogóle pojawia się linia Xcvr, na obu node'ach. Jeśli moduł nawet nie jest zinwentaryzowany, to nie jest problem światłowodu ani długości fali i żadna zamiana par tego nie zmieni.Druga rzecz, dziesięć minut roboty: włóż jeden z tych modułów SFP-LH w port produkcyjny naprzeciwko znanego dobrego peera. Jeśli tam się połączy, a w gnieździe HA dalej będzie ciemno, oddzieliłeś moduł od portu i możesz przestać spierać się o sieć światłowodową.
Co do części pytania o DWDM, jest przynajmniej jeden konkretny przypadek: ktoś uruchomił optyki DWDM Champion ONE na serii SRX1500 i działały. Zanim pójdziesz w tę stronę, potwierdź dokładną długość fali u dostawcy optyki albo DWDM, bo Juniper niekoniecznie sprzedaje do tego moduł, a wtedy jesteś na optyce od innego producenta ze wszystkim, co to oznacza w chwili, gdy otwierasz zgłoszenie.
Port HA control to zupełnie inne zwierzę i nie zakładałbym, że zachowuje się jak port produkcyjny. Nie ma dla niego opublikowanej listy optyk poza SFP-T dołączonym do chassis, a twój własny test pokazuje, że gniazdo nie jest odczytywane ponownie w trakcie pracy: miedziany moduł wrócił dopiero po restarcie chassis. To wygląda tak, jakby port był inwentaryzowany przy starcie i nic go później nie skanuje ponownie.
Jeśli klaster musi wstać szybko, trzymaj transport poza firewallem. Zakończ długi odcinek na sprzęcie, który zawodowo zajmuje się optyką, podaj każdemu SRX krótki link na module, który na pewno akceptuje, i niech transport zajmie się długością fali. Mniej eleganckie, dużo szybsze do wdrożenia. Zgłoszenie i tak otwórz, bo sam fakt, że nie istnieje lista wspieranych optyk dla tego portu, zasługuje na pisemną odpowiedź.
Podpisuję się pod tym, żeby nie ufać stanowi portu na tych pudełkach. Mamy klaster dwóch SRX380-POE-AC na Junos 21.4R3-S4.9, gdzie awaria idzie w drugą stronę: xe-0/0/17 i xe-0/0/18 zgłaszają link UP, świecące diody, i kompletny brak podłączonego światłowodu. Juniper SFP-SX 740-011613 jako Xcvr 16-17, SFP+-10G-SR 740-021308 jako Xcvr 18-19, oba node'y pokazują identyczny inwentarz w
show chassis hardware, ashow interfaces terseupiera się, że interfejsy są up.Ponowne osadzenie modułów nie zmieniło kompletnie nic. Te porty miały być pod reth, które ostatecznie zbudowaliśmy na ge-0/0/14-15, więc nikomu to nie zaszkodziło, a odpowiedzi, czy stoi za tym jakiś PR, nigdy nie dostałem. Zestawiając to z twoim martwym control portem, nie traktowałbym stanu optyki na klastrowanym SRX jako dowodu na cokolwiek fizycznego.
Dwie uwagi na boku, gdybyś brnął dalej w tę stronę.
Jeśli w torze faktycznie wyląduje optyka DWDM, sprawdź siatkę kanałów przed zamówieniem: tunable 50 GHz naprzeciwko stałej optyki 100 GHz po drugiej stronie to znany sposób na stracenie całej nocy, a na Junosie kanał bierze się z opcji wavelength, a nie z czegokolwiek, co ustawisz na interfejsie. Nie panikuj też, jeśli urządzenie zgłasza numer kanału niezgodny z tym, co skonfigurowałeś, podczas gdy światło jest na właściwej długości fali. To pojawia się na tunable'ach Cisco na tyle często, że odczytowi z CLI po prostu nie warto ufać.
Ogólnie w temacie ubogiej dokumentacji tych gniazd: na tej samej platformie miedziany moduł SRX-SFP-1GE-T bez problemu linkuje się na 1 Gbps, a odmawia wstania na 100 Mbps, przy czym hardware guide nazywa porty SFP jako 100/1000, a datasheet modułu mówi 10/100/1000. Nikt też nie potrafił mi powiedzieć, które z tych dwóch jest prawdą.