Zyxel RGS200-12P wypisuje "% SFP module doesn't support DDMI" dla dwóch SFP Avago
Przekazujemy szafy przemysłowe z własnym monitoringiem klienta na wierzchu, więc czytelne DDMI na portach uplink jest częścią listy odbiorczej. Na RGS200-12P dwa istotne porty w ogóle nic nie wypisują po włączeniu DDMI, mimo że oba linki są up i przekazują ruch.
- Zyxel RGS200-12P, DDMI włączone
- port 1/9: AVAGO ABCU-5740RZ-HP8, miedziany SFP 1000BASE-T
- port 1/11: AVAGO AFBR-5710PZ, 1000BASE-SX
- oba linki up, czyste liczniki po obu stronach
% SFP module doesn't support DDMI
Co już zrobiłem:
- wyłączyłem DDMI i włączyłem z powrotem, zapisałem, przeładowałem switch
- wyjąłem i włożyłem ponownie oba moduły, przełożyłem je do innych klatek - ta sama odpowiedź na każdym porcie
- sprawdziłem, że same linki są w porządku, ruch przechodzi bez błędów
Więc o co tu chodzi: switch odmawia czytania optyki, której sam nie sprzedał, czy dwie sztuki Avago naprawdę nie mają żadnej diagnostyki do przekazania? Muszę dać klientowi jedną albo drugą odpowiedź przed odbiorem, a nie wzruszenie ramion.
Comments 4
Za jednym komunikatem błędu kryją się u ciebie dwie różne przyczyny.
Port miedziany to zachowanie oczekiwane. SFP 1000BASE-T jako klasa nie implementują diagnostyki cyfrowej - nie ma mocy optycznej do zaraportowania, a te sztuki na ogół w ogóle nie mają strony diagnostycznej, więc 1/9 z ABCU-5740RZ-HP8 nigdy nie pokaże temperatury, napięcia ani mocy, niezależnie od tego, jak skonfigurujesz DDMI. Nie ma czego naprawiać, nie ma co eskalować.
Port światłowodowy to ten sam wynik z innego powodu: ta konkretna sztuka Avago nie ma strony DDM/DDMI w swoim EEPROM. SFF-8472 czyni stronę diagnostyczną opcjonalną, i mnóstwo modułów 1000BASE-SX z tamtej generacji wychodziło z fabryki bez niej. Switch nie blokuje tu obcego modułu, tylko mówi prawdę - w module po prostu nie ma czego czytać.
Test, który rozstrzyga to w pięć minut, to ten już zaproponowany: moduł deklarowany jako DDM-capable w tej samej klatce. Zyxel SFP-LX-10-E w RGS200-12P wypisuje pełny blok DDMI, co dowodzi, że switch i konfiguracja są w porządku. Zwykłe zastrzeżenie przy tym vendorze: ich oficjalne stanowisko jest takie, że optyka firm trzecich nie jest objęta wsparciem i może przynosić utratę pakietów i problemy z łącznością, więc jeśli diagnostyka jest kryterium odbioru, wpisz "DDM/DOM capable" do specyfikacji zakupowej zamiast liczyć na szczęście.
Jeśli optyki w tej szafie nie da się zmienić, monitoruj te dwa porty po stanie linku i licznikach interfejsu, i napisz to wprost w dokumencie odbiorczym. To uczciwa odpowiedź, i jest lepsza niż pusta strona DDMI, której nikt nie wytłumaczy za rok.
Dwie rzeczy warto rozdzielić, zanim cokolwiek zapiszesz. Po pierwsze, czy ten switch w ogóle wypisuje DDMI dla czegokolwiek? Pożycz moduł, o którym wiesz, że jest DDM-capable, włóż go w 1/11 i uruchom to samo polecenie. Jeśli wyjdzie pełny blok, strona switcha jest udowodniona, a jedyną pozostałą zmienną są te dwie sztuki Avago.
Po drugie, nie traktuj modułu miedzianego jako dowodu w żadną stronę, to osobna kategoria. I co dokładnie mówi karta katalogowa AFBR-5710PZ o diagnostyce cyfrowej? Ta sztuka jest wystarczająco stara, że w ogóle nie zakładałbym, że ją ma.
Potwierdzone na stole. Pożyczyłem SFP-LX-10-E, wrzuciłem go do 1/11 z tym samym włóknem, i DDMI wypisuje pełny zestaw - temperaturę, napięcie, prąd polaryzacji, moc Tx i Rx. Wstawiłem z powrotem AFBR-5710PZ i komunikat błędu wraca natychmiast. Port 1/9 z modułem miedzianym zachowuje się dokładnie jak wcześniej, czego teraz oczekuję zamiast za tym gonić.
Czyli switch robi swoje, a odpowiedzią są moduły. Trafia to do dokumentu odbiorczego jako właściwość modułu, a DDM capability trafia do specyfikacji na kolejną partię optyki. Zaoszczędziło mi to kłótni o "zepsuty" switch.
Warto wiedzieć, że ta sama sytuacja czyta się zupełnie inaczej w zależności od platformy, dlatego wciąż wraca jako zgłoszenie buga.
Na PAN-OS
show transceiver-detail allwypisuje polediagnostic-monitorper moduł:Yesznaczy, że implementuje monitoring optyczny,Noznaczy, że nie, a w drugim przypadku moduł wciąż jest identyfikowany normalnie, podczas gdy każda wartość diagnostyczna wraca jakoN/A. Żadnego błędu, same puste pola - dużo łatwiej to zinterpretować niż komunikat odmowy.Na Nokia 7210 SAS brakujące wartości mogą być zamiast tego winą oprogramowania: wczesne wydania w ogóle nie implementują DDM, a dokumentacja dodaje, że dla modułów, których Nokia nie dostarczyła, dane mogą się wyświetlać, ale ich format i dokładność nie są gwarantowane. Trzej możliwi winowajcy jednego pustego pola - moduł, platforma albo wydanie.
A czasem to tylko kwestia interfejsu: na switchach TP-Link zaadoptowanych do Omady nie ma strony DDM w kontrolerze, otwierasz jego terminal, wpisujesz
enablei uruchamiaszshow ddm status.