PA-3220 : l'interface SFP+ ne monte jamais, sys.s1.p13.state affiche board_port_sfp_invalid_0
Mise en service d'un uplink 10G d'un PA-3220 vers un nouveau switch cœur de réseau. Le module a été placé dans une cage libre du firewall, le côté switch est configuré et en attente, et l'interface refuse tout simplement de monter. La LED du port clignote, ce qui m'a fait supposer que le module était au moins alimenté.
- Palo Alto PA-3220, module dans le port 13
- optique SFP+ 10G générique, LC duplex
- le même type d'optique monte à 10G entre deux switches sur l'autre paire de cette liaison fibre
- paire HA, et c'est l'unité active
Ce que dit l'arbre d'état sur le port :
show system state filter-pretty sys.s1.p13.state
board_port_sfp_invalid_0sys.s1.p13.status rapporte le lien down. Rien dans les logs, l'interface est juste morte.
Déjà essayé :
- réinséré le module et nettoyé les connecteurs
- remplacé par une seconde optique du même type
- prouvé la fibre avec la paire switch à switch, qui monte à 10G
- vérifié la config de l'interface, c'est une interface de couche 3 toute simple dans la bonne zone
Qu'est-ce que board_port_sfp_invalid_0 signifie réellement ici, et est-ce le module ou le 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
Cette condition, c'est le firewall qui refuse le module dans cette cage, et la cause est bien plus souvent mécanique qu'électrique. Les cages se ressemblent toutes de face et l'optique s'insère parfaitement, mais un emplacement qui n'a jamais été câblé pour le 10G ne fera jamais monter une optique 10G, aussi saine soit-elle.
Commencez donc par la carte des ports plutôt que par le module.
show system infofixe la plateforme exacte, puis la référence matérielle de ce modèle vous dit quelles cages sont réellement du SFP+. Sur un PA-3220 ce bloc, ce sont les ports 17-20, donc le port 13 n'a jamais été un candidat. Déplacez d'abord l'optique là.Une fois dans une vraie cage SFP+, parcourez l'arbre d'état dans cet ordre (les lignes ci-dessous utilisent le port 17 comme exemple, substituez celui vers lequel vous avez déplacé le module) :
.phydit si le média a même été lu : une optique 10G dans une cage fonctionnelle devrait revenir comme SFP-Plus-Fiber..statusest l'état du lien..stateest l'endroit où la condition de module invalide que vous avez déjà apparaît, et elle devrait disparaître une fois le module dans le bon bloc.Une réserve avec une paire : vérifiez le port sur l'unité active. Sur l'unité passive, l'interface est down par conception sauf si l'état de lien passif est configuré comme up.
C'était ça. Déplacé l'optique vers le port 17,
.phyrevient maintenant comme SFP-Plus-Fiber et le lien est monté à 10G immédiatement, aucun changement côté switch.J'avais supposé que les cages étaient interchangeables parce qu'elles se ressemblent toutes de face. La référence matérielle indique bien 17-20 pour ce modèle, je ne l'avais simplement jamais ouverte avant de perdre une soirée sur des modules et des cordons de brassage.
Bon résultat, et la leçon générale vaut la peine d'être retenue : un trou de forme SFP+ n'est pas une promesse sur ce qui se trouve derrière.
Même genre de piège ailleurs. Un QLogic QLE2562 apparaît dans
lspcicomme un HBA Fibre Channel 8Gb et ses cages acceptent des modules qui ressemblent exactement à des optiques Ethernet, mais aucune interface n'apparaît jamais dansifconfig, parce que la carte parle FC et rien d'autre. Sur des Dell S4048-ON et S6010-ON sous OPX, un adaptateur QSA 407-BBRO portant un SFP+ 407-BBOU reste à Operational State: DOWN avec Operating Speed: 0 alors que la vitesse configurée indique 10000, parce que la config de la plateforme n'a jamais porté le mode 10G pour ce port QSFP.Et quand la cage est la bonne et que le port reste quand même down, regardez le type de module lui-même. Un HPE 5940 (JH390A) sous Comware maintient les ports DOWN avec des modules 10GBASE-T SFP+ 813874-B21 authentiques et journalise IF_LOCAL_FAULT, alors que des SFP cuivre 1G fonctionnent dans les mêmes ports. Le contournement là-bas était
port up-modesur l'interface, avec pour effet secondaire que le port est ensuite signalé up en permanence et qu'une véritable perte de câble cesse d'être signalée.