PA-3220: SFP+ interface never links, sys.s1.p13.state shows board_port_sfp_invalid_0
Bringing up a 10G uplink from a PA-3220 to a new core switch. The module went into a free cage on the firewall, the switch side is configured and waiting, and the interface simply refuses to come up. The port LED blinks, which is what made me assume the module was at least being powered.
- Palo Alto PA-3220, module in port 13
- generic 10G SFP+ optic, duplex LC
- the same optic type links at 10G between two switches over the other pair in that fibre run
- HA pair, and this is the active unit
What the state tree says about the port:
show system state filter-pretty sys.s1.p13.state
board_port_sfp_invalid_0sys.s1.p13.status reports the link down. Nothing in the logs, the interface is just dead.
Tried so far:
- reseated the module and cleaned the connectors
- swapped in a second optic of the same type
- proved the fibre with the swtch to switch pair, which links at 10G
- checked the interface config, it is a plain layer 3 interface in the right zone
What does board_port_sfp_invalid_0 actually mean here, and is this the module or the firewall?
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
That condition is the firewall refusing the module in that cage, and the cause is mechanical far more often than electrical. The cages look identical from the front and the otic seats perfectly, but a slot that was never wired for 10G will not bring up a 10G optic however healthy it is.
So start with the port map rather than with the module.
show system infopins down the exact platform, then the hardware reference for that model tells you which cages are really SFP+. On a PA-3220 that block is ports 17-20, so port 13 was never a candidate. Move the optic there first.Once it is in a real SFP+ cage, walk the state tree in this order (the lines below use port 17 as the example, substitute whichever port you moved to):
.physays whether the media got read at all: a 10G optic in a working cage should come back as SFP-Plus-Fiber..statusis the link state..stateis where the invalid-module condition you already have turns up, and it should disappear once the module sits in the right block.One caveat with a pair: check the port on the active unit. On the passive one the interface is down by design unless passive link state is configured as up.
That was it. Moved the optic to port 17,
.phynow comes back as SFP-Plus-Fiber and the link came up at 10G straight away, no change on the switch side at all.I had assumed the cages were interchangeable because they look identical from the front. The hardware reference does spel out 17-20 for this model, I just never opened it before wasting an evning on modules and patch cords.
Good outcome, and the general lesson is worth keeping: an SFP+ shaped hole is not a promise about what sits behind it.
Same class of trap elsewhere. A QLogic QLE2562 shows up in
lspcias an 8Gb Fibre Channel HBA and its cages take modules that look exactly like Ethernet optics, but no interface ever appears inifconfig, because the card speaks FC and nothing else. On Dell S4048-ON and S6010-ON under OPX a 407-BBRO QSA adapter carrying a 407-BBOU SFP+ sits at Operational State: DOWN with Operating Speed: 0 while the configured speed reads 10000, because the platform config never carried the 10G mode for that QSFP port.And when the cage is right and the port still stays down, look at the module type itself. An HPE 5940 (JH390A) on Comware keeps ports DOWN with genuine 813874-B21 10GBASE-T SFP+ modules and logs IF_LOCAL_FAULT, while 1G copper SFPs work in the same ports. The workaround there was
port up-modeon the interface, with the side effect that the port is then reported up permanently and a real cable loss stops being signalled.