PA-3220: SFP+-interface linkt nooit, sys.s1.p13.state toont board_port_sfp_invalid_0
Bezig een 10G-uplink van een PA-3220 naar een nieuwe core-switch op te zetten. De module ging in een vrije cage op de firewall, de switchkant is geconfigureerd en staat te wachten, en de interface weigert gewoon op te komen. Het poort-ledje knippert, waardoor ik aannam dat de module in elk geval gevoed werd.
- Palo Alto PA-3220, module in poort 13
- generieke 10G SFP+-optiek, duplex LC
- hetzelfde optiektype linkt op 10G tussen twee switches over het andere paar in die vezelrun
- HA-paar, en dit is de actieve unit
Wat de statusboom over de poort zegt:
show system state filter-pretty sys.s1.p13.state
board_port_sfp_invalid_0
sys.s1.p13.status meldt de link als down. Niets in de logs, de interface is gewoon dood.
Al geprobeerd:
- de module opnieuw geplaatst en de connectoren gereinigd
- een tweede optiek van hetzelfde type geprobeerd
- de vezel bewezen met het switch-naar-switch-paar, dat linkt op 10G
- de interfaceconfig gecontroleerd, het is een gewone laag 3-interface in de juiste zone
Wat betekent board_port_sfp_invalid_0 hier nou echt, en ligt het aan de module of aan de firewall?
Comments 3
Die toestand is de firewall die de module in die cage weigert, en de oorzaak is veel vaker mechanisch dan elektrisch. De cages zien er vooraan identiek uit en de optiek zit perfect vast, maar een slot dat nooit voor 10G bedraad is, brengt geen 10G-optiek op, hoe gezond die ook is.
Begin dus bij de poortindeling in plaats van bij de module.
show system infolegt het exacte platform vast, en dan vertelt de hardware reference voor dat model welke cages echt SFP+ zijn. Op een PA-3220 is dat blok poorten 17-20, dus poort 13 kwam nooit in aanmerking. Verplaats de optiek daar eerst naartoe.Zodra hij in een echte SFP+-cage zit, loop de statusboom in deze volgorde af (de regels hieronder gebruiken poort 17 als voorbeeld, vervang die door de poort waar je naartoe verplaatst hebt):
.phyzegt of het medium überhaupt is uitgelezen: een 10G-optiek in een werkende cage zou als SFP-Plus-Fiber terug moeten komen..statusis de linkstatus..stateis waar de invalid-module-toestand die je al had opduikt, en die zou moeten verdwijnen zodra de module in het juiste blok zit.Eén kanttekening bij een paar: controleer de poort op de actieve unit. Op de passieve is de interface by design down, tenzij passive link state op up geconfigureerd is.
Dat was het. Optiek naar poort 17 verplaatst,
.phykomt nu terug als SFP-Plus-Fiber en de link kwam meteen op 10G op, helemaal niets veranderd aan de switchkant.Ik was ervan uitgegaan dat de cages verwisselbaar waren omdat ze er vooraan identiek uitzien. De hardware reference vermeldt echt wel 17-20 voor dit model, ik had hem alleen nooit opengeslagen voor ik een avond aan modules en patchkabels verspild had.
Goede afloop, en de algemene les is het onthouden waard: een SFP+-vormig gat is geen belofte over wat erachter zit.
Elders dezelfde soort valstrik. Een QLogic QLE2562 verschijnt in
lspcials een 8Gb Fibre Channel HBA en zijn cages nemen modules die er precies uitzien als Ethernet-optiek, maar er verschijnt nooit een interface inifconfig, omdat de kaart alleen FC spreekt en verder niets. Op Dell S4048-ON en S6010-ON onder OPX staat een 407-BBRO QSA-adapter met een 407-BBOU SFP+ erin op Operational State: DOWN met Operating Speed: 0 terwijl de geconfigureerde snelheid 10000 aangeeft, omdat de platformconfig nooit de 10G-modus voor die QSFP-poort heeft meegekregen.En als de cage klopt en de poort toch down blijft, kijk dan naar het moduletype zelf. Een HPE 5940 (JH390A) op Comware houdt poorten DOWN met echte 813874-B21 10GBASE-T SFP+-modules en logt IF_LOCAL_FAULT, terwijl 1G koperen SFP's in dezelfde poorten werken. De workaround daar was
port up-modeop de interface, met als bijeffect dat de poort daarna permanent als up gemeld wordt en een echt kabelverlies niet meer gesignaleerd wordt.