PA-3220: interfejs SFP+ nigdy nie łączy, sys.s1.p13.state pokazuje board_port_sfp_invalid_0
Podnoszę uplink 10G z PA-3220 do nowego switcha core. Moduł trafił do wolnej klatki na firewallu, strona switcha jest skonfigurowana i czeka, a interfejs po prostu nie chce wstać. Dioda portu miga, więc założyłem, że moduł przynajmniej dostaje zasilanie.
- Palo Alto PA-3220, moduł w porcie 13
- generyczny optyk SFP+ 10G, duplex LC
- ten sam typ optyka łączy się na 10G między dwoma switchami na drugiej parze w tym samym przebiegu światłowodu
- para HA, to jest jednostka aktywna
Co drzewo stanu mówi o tym porcie:
show system state filter-pretty sys.s1.p13.state
board_port_sfp_invalid_0sys.s1.p13.status zgłasza link down. W logach nic, interfejs jest po prostu martwy.
Co już sprawdziłem:
- wyjąłem i włożyłem moduł jeszcze raz, wyczyściłem złącza
- podmieniłem na drugi optyk tego samego typu
- sprawdziłem światłowód na parze switch-switch, tam łączy się na 10G
- sprawdziłem konfigurację interfejsu, to zwykły interfejs warstwy 3 we właściwej strefie
Co właściwie oznacza tu board_port_sfp_invalid_0 i czy to wina modułu, czy firewalla?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 3
Ten komunikat oznacza, że firewall odrzuca moduł w tej klatce, a przyczyna jest mechaniczna dużo częściej niż elektryczna. Klatki wyglądają identycznie od przodu i optyk siada w nich idealnie, ale slot, który nigdy nie był okablowany pod 10G, nie podniesie optyka 10G bez względu na to, jak sprawny on jest.
Zacznij więc od mapy portów, a nie od modułu.
show system infoustala dokładną platformę, a potem hardware reference dla tego modelu mówi, które klatki są naprawdę SFP+. Na PA-3220 to blok portów 17-20, więc port 13 nigdy nie wchodził w grę. Najpierw przełóż tam optyk.Gdy już jest w prawdziwej klatce SFP+, przejdź po drzewie stanu w tej kolejności (poniższe linie używają portu 17 jako przykładu, podstaw port, na który faktycznie przełożyłeś moduł):
.phymówi, czy medium w ogóle zostało odczytane: optyk 10G w działającej klatce powinien zwrócić SFP-Plus-Fiber..statusto stan linku..stateto miejsce, gdzie pojawia się ten komunikat invalid-module, który już masz, i powinien on zniknąć, gdy moduł znajdzie się we właściwym bloku.Jedna uwaga przy parze: sprawdzaj port na jednostce aktywnej. Na pasywnej interfejs jest down z założenia, chyba że passive link state jest skonfigurowany jako up.
To było to. Przełożyłem optyk do portu 17,
.phyteraz zwraca SFP-Plus-Fiber, a link wstał na 10G od razu, bez żadnej zmiany po stronie switcha.Zakładałem, że klatki są wymienne, bo wyglądają identycznie od przodu. Hardware reference jasno podaje 17-20 dla tego modelu, po prostu nigdy wcześniej go nie otworzyłem, zanim zmarnowałem wieczór na modułach i patchcordach.
Dobry efekt, a ogólną lekcję warto zapamiętać: otwór w kształcie SFP+ to żadna obietnica co do tego, co za nim faktycznie siedzi.
Ta sama kategoria pułapki gdzie indziej. QLogic QLE2562 pokazuje się w
lspcijako 8Gb Fibre Channel HBA, a jego klatki przyjmują moduły wyglądające dokładnie jak optyki Ethernet, ale wifconfignigdy nie pojawia się żaden interfejs, bo karta mówi tylko FC i nic poza tym. Na Dell S4048-ON i S6010-ON pod OPX adapter QSA 407-BBRO z SFP+ 407-BBOU siedzi w Operational State: DOWN z Operating Speed: 0, mimo że skonfigurowana prędkość pokazuje 10000, bo konfiguracja platformy nigdy nie niosła trybu 10G dla tego portu QSFP.A gdy klatka jest właściwa, a port mimo to zostaje down, spójrz na sam typ modułu. HPE 5940 (JH390A) na Comware trzyma porty w stanie DOWN z oryginalnymi modułami 813874-B21 10GBASE-T SFP+ i loguje IF_LOCAL_FAULT, podczas gdy miedziane SFP 1G w tych samych portach działają. Obejściem było tam
port up-modena interfejsie, z efektem ubocznym, że port jest wtedy zgłaszany jako up na stałe, a prawdziwa utrata kabla przestaje być sygnalizowana.