Blokada producenta i „unsupported transceiver” · Typowe problemy i rozwiązania · Transceivery optyczne i kable · Dokumentacja · CodingBox
CodingBox Dokumentacja

Blokada producenta i „unsupported transceiver”

Najczęstszy ze wszystkich problemów z transceiverami. Producenci przełączników i kart sieciowych — Cisco, Intel, HPE/Aruba, Juniper, Mellanox i inni — sprawdzają ciągi identyfikacyjne, jakie moduł zgłasza ze swojego EEPROM, i odrzucają albo oznaczają moduły, których nie rozpoznają.

Najważniejsza rzecz, jakiej inżynierowie uczą się na własnej skórze: „nieobsługiwany” nie znaczy „nie będzie działać”. Na większości platform ten status ma charakter informacyjny, a port można uruchomić.

Objawy

PlatformaCo widać
Cisco IOSPort notconnect — unsupported; log %C4K_TRANSCEIVERMAN-3-INCOMPATIBLE
Cisco IOS po aktualizacjiPort przechodzi w stan errdisable, powód gbic-invalid
MellanoxEEPROM jest odczytywany, ale nie ma łącza: speed and type: Not supported
Intel X520 / ixgbeno carrier przy SFP innym niż Intel

Co pomaga

Cisco. Dwie komendy rutynowo trafiają do konfiguracji bazowej, żeby dopuścić moduły innych producentów na wszystkich portach:

service unsupported-transceiver
no errdisable detect cause gbic-invalid

Osobliwości platform: w niektórych wersjach Catalyst 9200 pierwsza komenda zwraca % Ambiguous command — wpisz ją w całości; na Nexus 9000 to ukryta komenda bez uzupełniania tabulatorem, ale jest akceptowana.

Intel X520 (Linux). Załaduj sterownik z opcją, która dopuszcza moduły inne niż Intel:

modprobe ixgbe allow_unsupported_sfp=1

Istnieje trwały wariant, który przestawia bit we własnym EEPROM karty sieciowej, i jest udokumentowany w źródłach poniżej — obchodź się z nim ostrożnie, bo błędny zapis do EEPROM karty sieciowej nie da się odwrócić w terenie.

Seria ASR 9000. Moduł włożony do portu, który jest już up, może nie zostać wykryty: zrób shut na porcie, włóż moduł, a potem no shut.

Radykalne rozwiązanie — przekoduj moduł. Zmień ID producenta i numer katalogowy modułu tak, żeby przedstawiał się jako moduł natywny. Właśnie to robi CodingBox w EEPROM editor, przeliczając najpierw CC_BASE/CC_EXT i tworząc kopię zapasową. Mechanikę tego procesu opisuje Przekodowanie EEPROM.

Rada, którą powtarza każdy

Trzymaj na półce jeden oryginalny moduł OEM każdego typu. Podłącz go, zanim otworzysz zgłoszenie u producenta, żeby nie mógł zrzucić winy na optykę innych producentów.

Weryfikacja na przełączniku

Po każdym z powyższych kroków potwierdź, że moduł jest widziany i odczytywany: komendy dla poszczególnych NOS-ów są w Weryfikacja optyki na przełączniku — porównaj je z danymi identyfikacyjnymi, które CodingBox odczytuje na stanowisku.

Co dokładnie porównuje host — nazwę, PN, OUI, wzorzec numeru seryjnego, sygnaturę producenta — i na którym etapie uruchamiania odrzuca moduł: Pola producenta, Co robi host.

Zachowanie walidacji i obejścia dla poszczególnych producentów w jednej tabeli: Jak każdy NOS weryfikuje moduł; dokładne ciągi PN, jakich oczekują platformy: Numery katalogowe OEM; składnia komend dla poszczególnych NOS-ów: Przepisy konfiguracji portów.


Jeśli znajdziesz nieścisłość lub błąd w tym materiale, zaznacz odpowiedni fragment i naciśnij Ctrl+Enter, aby .