Co robi host: wykrywanie, walidacja, uruchamianie
Specyfikacje opisują stronę modułu — piny, pamięć, stany. Ta strona opisuje stronę hosta: sekwencję, którą przełącznik, router albo NIC wykonuje od chwili włożenia modułu aż do popłynięcia ruchu, wraz z pinami, bajtami i czasami, jakich używa każdy krok. Znajomość tego zamienia „port mówi unsupported” w „host zatrzymał się na kroku 4”, i wyjaśnia, dlaczego moduł idealny na stanowisku wciąż może zawieść w porcie.
Sygnały niskiej prędkości według formatu obudowy
| Format obudowy | Obecność | Reset / zasilanie | Przerwanie / usterka | Inne |
|---|---|---|---|---|
| SFP / SFP+ / SFP28 | MOD_ABS (niski = obecny) | — (TX_DISABLE steruje laserem) | TX_FAULT, RX_LOS | RS0, RS1 — wybór prędkości |
| XFP | Mod_ABS | P_Down/RST | Interrupt, Mod_NR (nie gotowy), RX_LOS | TX_DIS, Mod_DeSel |
| QSFP+ / QSFP28 | ModPrsL | ResetL, LPMode | IntL | ModSelL |
| QSFP-DD | ModPrsL | ResetL, LPMode | IntL | ModSelL |
| OSFP | PRSn | RSTn, LPWn | INT | — (brak pinu wyboru, jedna magistrala na port) |
| SFP-DD | obecność jak w SFP | żądanie niskiej mocy | przerwanie | wybór prędkości jak w SFP |
Funkcje pinów i rozkłady wyprowadzeń dla poszczególnych rodzin: Sprzęt SFP, Sprzęt QSFP, XFP.
Sekwencja
| # | Krok | SFP (SFF-8472) | QSFP (SFF-8636) | CMIS | Jak wygląda błąd |
|---|---|---|---|---|---|
| 1 | Wykrycie | MOD_ABS przechodzi na niski; debounce | ModPrsL niski | ModPrsL / PRSn niski | port pozostaje pusty; moduł „not detected” |
| 2 | Zasilanie i oczekiwanie | 3,3 V jest zawsze włączone; oczekiwanie t_init 300 ms | zasilanie włączone przy LPMode wysoki (tylko klasa 1); oczekiwanie t_init 2 s albo odpytywanie Data_Not_Ready | tak samo; oczekiwanie, aż stan modułu opuści MgmtInit (≤ 2 s) | odczyty zwracają FFh / 00h; dane identyfikacyjne puste |
| 3 | Identyfikacja | odczyt A0h 0–95; bajt 0 = 03h wybiera parser SFF-8472 | odczyt 0–127 i strony górnej 00h; bajt 0 = 0Dh/11h, bajt 1 — rewizja | odczyt strony dolnej i górnej 00h; bajt 0 = 18h/19h…, bajt 1 — wersja CMIS | unknown module type |
| 4 | Weryfikacja | CC_BASE, CC_EXT; spójność identyfikatora / złącza / kodowania | CC_BASE, CC_EXT | suma kontrolna strony 00h | invalid EEPROM, checksum error — Sumy kontrolne |
| 5 | Dekodowanie typu | bajty zgodności 3–10, 36; bajt prędkości 12/66; długości; długość fali | bajty 131–138, 192; 140/222 | typ medium 85, deskryptory aplikacji | speed and type not supported — Kody zgodności |
| 6 | Polityka | nazwa producenta / numer katalogowy (i ewentualnie sygnatura) w tabeli kompatybilności | tak samo | tak samo | unsupported transceiver, errdisable — Blokada producenta |
| 7 | Klasa mocy | bity poziomu bajtu 64 względem budżetu portu | klasa bajtu 129; zapis do bajtu 93 zwalnia niską moc / włącza klasy 5–8 | klasa bajtu 200 względem portu; dezaktywacja LPMode albo wyczyszczenie LowPwrRequestSW → moduł PwrUp → Ready | zatrzymany w niskiej mocy, power exceeds — Zasilanie i temperatura |
| 8 | Konfiguracja | RS0/RS1 albo programowy wybór prędkości; prędkość po stronie hosta, FEC, SGMII/1000BASE-X | CDR wł./wył. (98), wybór prędkości (87–88), linie breakout po stronie hosta | wybór AppSel/DataPathID w staged control set → ApplyDPInit → Init ścieżki danych → Initialized | LOL, niezgodność FEC, breakout odrzucony — Prędkość i przepływność |
| 9 | Włączenie Tx | pin TX_DISABLE niski albo wyczyszczenie bitu programowego (A2h 110.6) | bajt 86 = 00h | strona 10h, bajt 130 = 00h → DPTxTurnOn → DPActivated | daleki koniec widzi −40 dBm — Lista kontrolna braku łącza |
| 10 | Łącze | PHY/MAC widzi sygnał; AN/link training na DAC | tak samo na linię | tak samo na ścieżkę danych | łącze nieaktywne mimo poprawnych poziomów |
| 11 | Monitorowanie | odpytywanie monitorów i flag A2h co kilka sekund; piny TX_FAULT / RX_LOS | IntL → odczyt flag 3–21; odpytywanie monitorów | IntL → flagi modułu + flagi linii strony 11h; VDM | alarmy, flapping — Poziomy DDM, Migotanie łącza |
| 12 | Usunięcie | MOD_ABS wysoki → zamknięcie | ModPrsL wysoki | ModPrsL wysoki | nieaktualny stan, jeśli debounce nie zadziała |
Kroki 3–6 zachodzą w niskiej mocy dla modułów QSFP i CMIS: host weryfikuje moduł, zanim wyda moc na optykę. Dlatego zablokowany albo źle zakodowany moduł nigdy nie zapala lasera, i dlatego daleki koniec odczytuje −40 dBm na module, który elektrycznie jest sprawny.
Czasy, na które czeka host
| Oczekiwanie | SFP | QSFP | CMIS |
|---|---|---|---|
| Gotowość zarządzania po włożeniu | 300 ms | 2 s | ≤ 2 s (MgmtInit), potem stan LowPwr |
| Po zwolnieniu niskiej mocy | — | do skasowania Data_Not_Ready | do stanu modułu Ready (maks. czas zgłasza strona 01h) |
| Inicjalizacja ścieżki danych | — | — | zgłaszane dla każdego kroku (kod półbajtowy: < 1 ms … < 50 min) |
| Od włączenia Tx do światła | t_on ≤ 1 ms | ton_txdis 100 ms / toff 400 ms | czas DPTxTurnOn zgłaszany |
| Od flagi do przerwania | — | ton_IntL 200 ms | według specyfikacji sprzętowej |
Czasy na poziomie magistrali (t_WR, rozciąganie zegara): Interfejs dwuprzewodowy.
Punkty polityki, w których hosty się różnią
- Restrykcyjność białej listy — od „tylko nazwa producenta” po podpisane bloki specyficzne dla producenta.
- Co się dzieje przy odrzuceniu — port wyłączony, laser wyłączony, albo łącze dozwolone z wpisem w dzienniku (Optyka innych producentów).
- Głębokość obsługi CMIS — pełne sterowanie aplikacją/ścieżką danych kontra „zwolnij LPMode i miej nadzieję” (Problemy z CMIS).
- Wartości domyślne FEC i prędkości — wyprowadzone z kodów zgodności albo skonfigurowane statycznie.
- Odpytywanie DDM — interwał, czy progi wyzwalają wyłączenie portu, czy stosowana jest kalibracja zewnętrzna (Kalibracja).
CLI poszczególnych producentów, aby zobaczyć, gdzie zatrzymał się host: Weryfikacja optyki na przełącznikach.
Czym programator różni się od hosta
Programator taki jak CodingBox wykonuje kroki 1–5 i 11, ale bez polityki: odczytuje wszystko, co moduł udostępnia, łącznie z obszarami producenta i bajtami haseł, trzyma moduły CMIS w niskiej mocy, chyba że poproszony inaczej, i nigdy sam nie włącza lasera. Dlatego moduł może wyglądać zdrowo na stanowisku i mimo to zawieść w porcie — stanowisko nie ma kroku 6.
W CodingBox
Check transceiver pokazuje wynik kroków 3–5 tak, jak zobaczyłby je host — typ, prędkość, sumy kontrolne, klasa mocy — i sygnalizuje niespójności, zanim moduł trafi do portu; DDM pokrywa krok 11 monitorami i flagami na żywo.
Sprzęt stojący za krokiem 6 (polityka) i limity grup portów stojące za krokiem 8: Wnętrze przełącznika, Jak każdy NOS weryfikuje moduł.