MRV OptiSwitch OS906: która komenda CLI pokazuje part number SFP i moc RX na punkcie demarkacyjnym
Oddajemy klientom obwody na skrzynkach demarkacyjnych MRV OptiSwitch - głównie OS906, z kilkoma OS904 i OS912 zostawionymi na starszych budowach. Kiedy wpada zgłoszenie o obwodzie, który stoi down albo migocze, chcę dwóch rzeczy przez SSH, zanim ktokolwiek tam pojedzie: jaki moduł faktycznie siedzi w porcie (nikt nie loguje, co wsadziła ekipa terenowa), i moc odbioru, żebym mógł powiedzieć, czy światło kończy się po naszej stronie, czy po ich.
- MRV OptiSwitch OS906 na punkcie demarkacyjnym klienta, OS904 i OS912 na kilku starszych lokalizacjach
- generyczne SFP 1G, mieszani producenci, cokolwiek ekipa terenowa miała w furgonetce
- odcinek jednomodowy z powrotem do naszego POP
Jedyne, co dotąd ustaliłem, to że puste gniazdo odpowiada wprost:
Failed to get EEPROM Data, SFP is not insertedwięc przynajmniej brakujący moduł da się odróżnić od takiego, który jest obecny, ale milczy. Czego wciąż nie potrafię zrobić, to wypisać producenta, part number i długość fali modułu, który jest na miejscu, ani odczytać mocy TX/RX.
Co już próbowałem:
- przeszedłem pomoc CLI pod
show porti wyraźnie ominąłem właściwą podkomendę - wsadziłem znany dobry moduł do laboratoryjnego OS904, żeby zobaczyć, czy wynik się różni - nic nie zobaczyłem
Które komendy na OptiSwitch dają mi zawartość EEPROM i żywe poziomy optyczne? Wolałbym nie wysyłać nikogo z miernikiem mocy na lokalizację, gdzie CLI już ma odpowiedź.
Comments 5
Dwie komendy to załatwiają, i są podzielone dokładnie tak, jak byś chciał: co moduł mówi sam o sobie w jednej, żywe odczyty w drugiej.
show port sfp-paramszrzuca pola EEPROM - producenta, part number, serial, długość fali, deklarowaną przez moduł prędkość nominalną, liczby zasięgu, jakie niesie dla każdego typu włókna, plus bajty identyfikatora i złącza. To odpowiada na pytanie, co faktycznie wsadziła ekipa, i czy jego zasięg w ogóle pasuje do odcinka.show port sfp-diag <portnumber>to żywa połowa: temperatura modułu w obu skalach, napięcie zasilania, bias current po stronie nadawania w mA, i dwie moce optyczne, każda podana dwukrotnie, w dBm i w mW. Wartość RX w dBm to liczba, którą cytujesz operatorowi po drugiej stronie.Zrób najpierw sfp-params - odczyt w dBm niewiele znaczy, dopóki nie wiesz, czy patrzysz na część krótkiego zasięgu, czy long-haul.
String, który już znalazłeś, warto zachować.
Failed to get EEPROM Data, SFP is not insertedznaczy, że gniazdo jest puste, co jest inną usterką niż moduł osadzony, ale nieczytelny. Jeśli kiedyś zeskryptujesz to na stosie skrzynek demarkacyjnych, to jest linia, na którą dopasowujesz.Reszta zestawu na tych skrzynkach:
detail daje konfigurację i stan portu, dwie komendy statistics dają liczniki pakietów, bajtów i błędów, z monitor jako widokiem na żywo, a rate z czasem w sekundach daje przepustowość w tym oknie.
Który koniec właściwie próbujesz udowodnić, i co jest po drugiej stronie odcinka? Jeśli oba końce to OptiSwitch, możesz ściągnąć sfp-params na każdym i porównać producenta, part number i długość fali wprost, a to porównanie łapie klasyczny przypadek, gdy ktoś wsadził moduł długiego zasięgu na jednym końcu, a krótkiego na drugim.
Jeśli drugi koniec należy do klienta albo innego operatora, wciągnij szczegóły ich modułu do zgłoszenia, zanim zacytujesz jakąkolwiek liczbę w dBm, inaczej spędzisz tydzień na kłótni o link, który nigdy nie miał działać optycznie. A gdy już masz wynik: to jeden port wraca pusty, czy każdy port na skrzynce? To dwa różne problemy.
Ta sama klasa problemu na routerach Cisco, gdyby ktoś tu trafił z tamtej strony. Na ISR 4451 nawyk z Catalyst, czyli wpisanie
show interface transceiver, donikąd nie prowadzi, router nie przyjmie tej składni, więc ludzie wnioskują, że platforma w ogóle nie ma DOM. Ma; dostajesz się do niego za to przez drzewo hardware module:To, co wraca, to temperatury modułu, napięcie zasilania i bias current po stronie nadawania, a potem obie liczby mocy. Na martwym linku tutaj GLC-LH-SMD czytał mniej więcej -7,1 dBm wychodząc i -32,2 dBm wracając, co nie jest marginalnym odcinkiem, to ciemność - drugi koniec albo trasa włókna, nic wspólnego z routerem.
Zgrubna skala, na jakiej pracuję: krótki skok wewnątrz budynku siedzi w okolicach -3 do -8 dBm, długi zasięg zmienia się z dystansem, poniżej około -30 dBm nic nie dochodzi. A zanim obwini się włókno: %TRANSCEIVER-3-NOT_SUPPORTED w
show logging, albo media type wypisany jako unknown wshow interface, jedno i drugie znaczy, że router odrzucił moduł.Jeszcze jedna platforma do kolekcji. Na Avaya VSP 7000 to pojedyncza komenda:
Wypisuje to, co switch odczytał z modułu w gnieździe, a rozdział rozwiązywania problemów używa tego wyniku, żeby zdecydować, czy urządzenie liczy się jako wspierane.
Irytująca część: listy kwalifikowanych modułów nie ma w tym rozdziale. Siedzi w osobnym dokumencie instalacji transceiverów, NN47202-302, obok kroków fizycznej instalacji i wymontowania. Moduł wraca jako failed albo unsupported, udokumentowana odpowiedź to zamiana go na coś z tamtej listy.