PA-3220: SFP+-Interface linkt nie, sys.s1.p13.state zeigt board_port_sfp_invalid_0
Bringe einen 10G-Uplink von einem PA-3220 zu einem neuen Core-Switch hoch. Das Modul kam in eine freie Cage an der Firewall, die Switch-Seite ist konfiguriert und wartet, und das Interface will einfach nicht hochkommen. Die Port-LED blinkt, weswegen ich angenommen habe, dass das Modul zumindest Strom bekommt.
- Palo Alto PA-3220, Modul in Port 13
- generische 10G-SFP+-Optik, Duplex-LC
- derselbe Optiktyp linkt mit 10G zwischen zwei Switches über die andere Strecke in dieser Faserführung
- HA-Paar, und das ist die aktive Einheit
Was der State-Tree zum Port sagt:
show system state filter-pretty sys.s1.p13.state
board_port_sfp_invalid_0sys.s1.p13.status meldet den Link als down. Nichts in den Logs, das Interface ist einfach tot.
Bisher versucht:
- Modul neu gesetzt und die Anschlüsse gereinigt
- eine zweite Optik desselben Typs eingesetzt
- die Faser mit dem Switch-zu-Switch-Paar bewiesen, das linkt mit 10G
- die Interface-Konfiguration geprüft, es ist ein reines Layer-3-Interface in der richtigen Zone
Was bedeutet board_port_sfp_invalid_0 hier tatsächlich, und liegt es am Modul oder an der Firewall?
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
Dieser Zustand ist die Firewall, die das Modul in dieser Cage ablehnt, und die Ursache ist weit häufiger mechanisch als elektrisch. Die Cages sehen von vorne identisch aus, und die Optik sitzt perfekt, aber ein Slot, der nie für 10G verdrahtet wurde, bringt eine 10G-Optik nicht hoch, egal wie gesund sie ist.
Also bei der Port-Map anfangen statt beim Modul.
show system infolegt die genaue Plattform fest, dann sagt einem die Hardware-Referenz für dieses Modell, welche Cages wirklich SFP+ sind. Am PA-3220 ist das der Block Ports 17-20, Port 13 kam also nie infrage. Die Optik zuerst dorthin verschieben.Sobald sie in einer echten SFP+-Cage sitzt, den State-Tree in dieser Reihenfolge durchgehen (die Zeilen unten nutzen Port 17 als Beispiel, den Port einsetzen, auf den tatsächlich verschoben wurde):
.physagt, ob das Medium überhaupt gelesen wurde: Eine 10G-Optik in einer funktionierenden Cage sollte als SFP-Plus-Fiber zurückkommen..statusist der Link-Zustand..stateist die Stelle, an der der bereits bekannte Invalid-Module-Zustand auftaucht, und er sollte verschwinden, sobald das Modul im richtigen Block sitzt.Eine Einschränkung bei einem Paar: den Port an der aktiven Einheit prüfen. An der passiven ist das Interface by design unten, außer passive link state ist auf up konfiguriert.
Das war's. Optik nach Port 17 verschoben,
.phykommt jetzt als SFP-Plus-Fiber zurück, und der Link kam sofort mit 10G hoch, auf der Switch-Seite überhaupt nichts geändert.Ich war davon ausgegangen, dass die Cages austauschbar sind, weil sie von vorne identisch aussehen. Die Hardware-Referenz nennt für dieses Modell tatsächlich 17-20, ich hatte sie nur nie aufgeschlagen, bevor ich einen Abend mit Modulen und Patchkabeln verschwendet habe.
Gutes Ergebnis, und die allgemeine Lehre ist es wert, im Kopf zu bleiben: Ein SFP+-förmiges Loch ist kein Versprechen darüber, was dahintersteckt.
Dieselbe Art von Falle anderswo. Ein QLogic QLE2562 taucht in
lspcials 8-Gb-Fibre-Channel-HBA auf, und seine Cages nehmen Module, die exakt wie Ethernet-Optik aussehen, aber inifconfigerscheint nie ein Interface, weil die Karte nur FC spricht und sonst nichts. An Dell S4048-ON und S6010-ON unter OPX steht ein 407-BBRO-QSA-Adapter mit einem 407-BBOU-SFP+ auf Operational State: DOWN mit Operating Speed: 0, während die konfigurierte Geschwindigkeit 10000 zeigt, weil die Plattform-Konfiguration nie den 10G-Modus für diesen QSFP-Port getragen hat.Und wenn die Cage stimmt und der Port trotzdem unten bleibt, den Modultyp selbst anschauen. Ein HPE 5940 (JH390A) unter Comware hält Ports mit echten 813874-B21-10GBASE-T-SFP+-Modulen auf DOWN und loggt IF_LOCAL_FAULT, während 1G-Kupfer-SFPs in denselben Ports funktionieren. Der Workaround dort war
port up-modeam Interface, mit dem Nebeneffekt, dass der Port danach dauerhaft als up gemeldet wird und ein echter Kabelausfall nicht mehr signalisiert wird.