Jak każdy NOS waliduje moduł
Między „module detected” a „port up” każdy sieciowy system operacyjny wykonuje sprawdzenie danych identyfikacyjnych modułu. To, co porównuje, co robi, gdy porównanie się nie zgadza, i czy administrator może to obejść, różni się w zależności od producenta, platformy i wydania — i ta różnica jest całym tematem kompatybilności transceiverów. Ta strona zestawia te zachowania obok siebie, tak jak dokumentują je producenci i jak obserwuje się je w terenie, żeby moduł odczytany na stanowisku dało się ocenić względem urządzenia, do którego jest przeznaczony.
Co można sprawdzić
| Sprawdzenie | Zaangażowane bajty | Kto to robi |
|---|---|---|
| Sumy kontrolne CC_BASE / CC_EXT | SFP 63/95, QSFP 191/223, CMIS 222/255 | niemal wszyscy — błąd to invalid EEPROM (Sumy kontrolne) |
| Spójność identyfikatora / złącza / kodowania | SFP 0, 2, 11; QSFP 0, 130, 139 | większość; nieznane typy pokazywane jako takie |
| Kody zgodności względem portu | SFP 3–10, 36; QSFP 131–138, 192; aplikacje CMIS | większość — speed and type not supported (Kody zgodności) |
| Nazwa producenta + numer katalogowy względem listy | SFP 20–35, 40–55; QSFP 148–163, 168–183 | platformy rygorystyczne i częściowo rygorystyczne (Numeracja części) |
| Sygnatura specyficzna dla producenta | obszar producenta (SFP 96–127, QSFP 224–255, CMIS custom) | nieliczni OEM; hash powiązany z numerem seryjnym |
| Format numeru seryjnego / kod daty | SFP 68–91; QSFP 196–219 | rzadkie; inżynierowie wsparcia sprawdzają je ręcznie |
| Klasa mocy względem portu | SFP 64; QSFP 129/107; CMIS 200–201 | wszyscy, którzy implementują zarządzanie mocą (Zasilanie i temperatura) |
Zachowanie według producenta
Publicznie dostępne komendy i zachowania na moment ostatnich wydań; szczegóły zależą od platformy i wersji.
| Producent / NOS | Sprawdzenia | Przy niepowodzeniu | Obejście | DDM dla innych producentów |
|---|---|---|---|---|
| Cisco IOS / IOS-XE (Catalyst, ISR) | lista producent/PN i sprawdzenie specyficzne dla producenta; sumy kontrolne | %PHY-4-UNSUPPORTED_TRANSCEIVER, port errdisabled (gbic-invalid), laser wyłączony | service unsupported-transceiver (ukryte) + no errdisable detect cause gbic-invalid; nie na wszystkich platformach; niewspierane przez TAC | pokazywane po zaakceptowaniu; niektóre pola puste |
| Cisco NX-OS (Nexus) | jak wyżej, mniej rygorystyczne na wielu platformach DC | często up z logiem; rygorystyczne SKU errdisable | service unsupported-transceiver | zwykle pokazywane |
| Cisco IOS-XR | lista optyki dla platformy, klasa mocy | stan unsupported, port może pozostać nieaktywny | ograniczone; zależne od platformy | częściowe |
| Arista EOS | sumy kontrolne, spójność typu | loguje unsupported; łącze się podnosi | niepotrzebne | pełne |
| Juniper Junos | lista producent/PN dla etykiety „supported”, sumy kontrolne | łącze zwykle aktywne; show chassis pic oznacza jako unsupported; niektóre platformy EX/QFX wstrzymują DDM albo prędkości dla nieznanych PN | brak oficjalnego | pełne dla znanych PN, częściowe dla nieznanych |
| Huawei VRP | producent/PN; nie-Huawei → alarm | łącze aktywne z powtarzającymi się alarmami phony transceiver; niektóre platformy ograniczają | transceiver phony-alarm-disable (system view) | pełne |
| H3C Comware | jak VRP | alarm | transceiver phony-alarm-disable | pełne |
| HPE Aruba AOS-S / AOS-CX | lista producent/PN | unsupported, port nieaktywny | allow-unsupported-transceiver | pełne |
| Dell OS10 / OS9 / PowerConnect | sumy kontrolne; na starszym sprzęcie czasem sprawdzenie wg listy | loguje; starsze: errdisable | service unsupported-transceiver (starsze) | pełne |
| Extreme EXOS / VOSS | sumy kontrolne, typ | loguje, aktywne | — | pełne |
| Ruckus/Brocade ICX (FastIron) | sumy kontrolne; monitoring optyczny tylko dla PN Brocade na niektórych | aktywne; DDM może brakować | — | częściowe |
| Brocade FOS (SAN) | na większości platform Gen 5/6/7 wymagany PN i numer seryjny pod marką Brocade | port Mod_Inv, not enabled | brak | tylko optyka Brocade |
| Nvidia/Mellanox (Onyx, Cumulus, IB) | Ethernet: sumy kontrolne, typ; InfiniBand: informacje o kablu weryfikowane przez fabric manager | Ethernet aktywny z logiem; IB może działać z obniżoną prędkością albo zgłosić flagę | — | pełne |
| SONiC / white-box | wtyczka platformy: sumy kontrolne, parsowanie CMIS | aktywne; nieznane pola pokazywane surowo | — | pełne (zależne od wtyczki) |
| MikroTik RouterOS / SwOS | nic poza parsowaniem | aktywne | — | pełne |
| Ubiquiti | nic poza parsowaniem | aktywne | — | pełne |
| Karty NIC serwerów (Intel, Broadcom, Mellanox) | białe listy sterownika na niektórych rodzinach Intel | sterownik odmawia aktywacji portu | parametr modułu allow_unsupported_sfp=1 (Intel ixgbe/i40e) | przez ethtool -m |
Tam, gdzie istnieje obejście producenta, jest ono zwykle oferowane as is: moduł działa, ale producent nie zobowiązuje się wspierać tej kombinacji. Decyzje dotyczące floty należą do właściciela sieci (Optyka innych producentów).
Co musi spełniać moduł „zakodowany pod producenta X”
| Klasa platformy | Minimum do akceptacji | Dodatkowo wskazane |
|---|---|---|
| Pobłażliwa (Arista, SONiC, MikroTik, Extreme…) | prawidłowe sumy kontrolne, spójne kody typu | prawdziwa nazwa producenta i PN — kodowanie OEM nic nie daje |
| Sprawdzająca wg listy (Juniper, Aruba, Huawei/H3C, NX-OS na wielu SKU) | nazwa producenta i PN dokładnie jak na liście platformy, poprawne kody zgodności dla portu | pasujący przyrostek/klasa PN; wiarygodny numer seryjny i kod daty |
| Sprawdzająca sygnaturę (Cisco IOS/IOS-XE, część XR) | wszystko powyższe plus obszar specyficzny dla producenta wyliczony dla tego numeru seryjnego | pola danych identyfikacyjnych spójne z PN (długość fali, zasięg, technologia) |
| Tylko marka producenta (Brocade FOS) | ciąg producenta Brocade i rodzina PN, format numeru seryjnego | — |
Jak działa to na stanowisku: Blokada producenta i kodowanie, Przekodowanie EEPROM.
Odczytywanie odrzucenia
| Tekst logu / stanu | Znaczenie | Kolejny krok |
|---|---|---|
unsupported transceiver, Mod_Inv, phony | dane identyfikacyjne spoza listy | obejście albo zakodowanie na PN z listy |
invalid EEPROM, checksum error | błędne CC_BASE/CC_EXT | przelicz ponownie (Sumy kontrolne) |
speed and type not supported, unknown media type | kody zgodności nie pasują do portu | popraw kody albo użyj innego trybu portu (Szybkość i przepływność) |
power class exceeds, zablokowany w LowPwr | klasa mocy względem klatki | Zasilanie i temperatura |
Module not ready, stan DP zawieszony | rozruch CMIS | Problemy z CMIS |
Komendy dla poszczególnych NOS, by zobaczyć te stany: Weryfikacja optyki na przełącznikach.
Zmiany przy aktualizacjach oprogramowania
Producenci zaostrzają albo łagodzą sprawdzenia między wydaniami: nowa walidacja sygnatury, nowe listy wspieranej optyki, usunięte ukryte komendy, zmieniona obsługa DDM. Flota optyki innych producentów albo zakodowanej, która działała wczoraj, może po aktualizacji trafić w errdisable (Macierze kompatybilności i firmware).
W CodingBox
CodingBox pokazuje dokładne bajty, które odczytuje każde z powyższych sprawdzeń — nazwę producenta, PN, sumy kontrolne, kody zgodności, klasę mocy — a code database przechowuje dane identyfikacyjne akceptowane przez daną klasę platformy. Zweryfikuj na porcie testowym po zakodowaniu; ostatnie słowo należy do przełącznika, nie do stanowiska (Check transceiver).
Odpowiednik po stronie serwera — białe listy sterownika dla każdego producenta NIC, obejścia Intela, zachowanie Windows i ESXi: Kompatybilność transceiverów w kartach NIC.