Cluster SRX1500 sur fibre noire : le port HA CONTROL reste éteint avec un SFP-LH 740-011612
Deux SRX1500 se trouvent dans des centres de données séparés distants de quelques kilomètres, reliés par des paires de fibre noire que nous possédons de bout en bout. Ils doivent monter en cluster de châssis, ce qui signifie que le lien de contrôle doit traverser cette fibre au lieu d'un cordon de brassage à l'intérieur d'une seule baie.
Le montage :
- deux Juniper SRX1500, construction matérielle identique
- Juniper SFP-LH 740-011612 dans le port HA CONTROL de chaque nœud
- une paire de fibre noire dédiée pour le lien de contrôle, brassée directement
- le module cuivre SFP-T livré avec le châssis, utilisé plus tôt pour un test dos à dos
Avec le SFP-LH en place, il n'y a strictement rien. Aucune LED sur la cage, aucun lien, et le cluster ne se forme jamais :
> show chassis cluster interfaces
Control link status: Down
Control interfaces:
Index Interface Status
0 em0 DownCe que j'ai déjà fait :
- déplacé le lien de contrôle sur la seconde paire de fibre, aucun changement sur aucun des deux nœuds
- échangé les modules entre les deux nœuds, même résultat des deux côtés
- remis le SFP-T comme test de sanité, et il est resté down jusqu'à un redémarrage complet du châssis, après quoi il est monté directement
Ce dernier point m'inquiète plus que l'optique morte. Est-ce que le port HA CONTROL d'un SRX1500 accepte le SFP-LH 740-011612 ou le SFP-SX 740-011613 du tout, ou seulement le SFP-T livré d'origine ? Et est-ce que quelqu'un a fait tourner un SFP DWDM dans ce port et l'a vu fonctionner ?
Comments 4
Avant d'accuser l'optique, que voit réellement le boîtier dans cette cage ? Postez
show chassis hardwareavec le SFP-LH inséré et vérifiez si une ligne Xcvr apparaît du tout pour l'emplacement, sur les deux nœuds. Si le module n'est même pas inventorié, ce n'est pas un problème de fibre ou de longueur d'onde et aucun échange de paires ne va changer ça.Deuxième chose, dix minutes de travail : mettez un de ces modules SFP-LH dans un port de production face à un pair connu bon. S'il monte là et reste éteint dans la cage HA, vous avez séparé le module du port et vous pouvez arrêter de discuter de l'installation fibre.
Sur le volet DWDM de la question, il y a au moins un point de donnée : quelqu'un faisant tourner des optiques DWDM Champion ONE sur la série SRX1500 les a fait fonctionner. Avant de partir dans cette voie, confirmez d'abord la longueur d'onde exacte avec le fournisseur d'optiques ou de DWDM, car Juniper ne vend pas forcément un module pour ça, et ensuite vous êtes sur des optiques tierces avec tout ce que ça implique dès que vous ouvrez un dossier.
Le port HA control est une bête différente et je ne présumerais pas qu'il se comporte comme un port de production. Il n'y a pas de liste d'optiques publiée pour lui au-delà du SFP-T livré avec le châssis, et votre propre test indique que la cage n'est pas relue en cours de fonctionnement : le module cuivre n'est revenu qu'après un redémarrage du châssis. Ça ressemble à un port inventorié au démarrage et que rien ne rescanne ensuite.
Si le cluster doit monter bientôt, gardez le transport en dehors du pare-feu. Terminez la longue distance sur du matériel dont c'est le métier de faire des optiques, donnez à chaque SRX un lien court sur le module qu'il est connu pour accepter, et laissez le transport gérer la longueur d'onde. Moins élégant, bien plus rapide à livrer. Ouvrez un dossier quand même, car l'absence même d'une liste d'optiques supportées publiée pour ce port mérite une réponse écrite.
Je confirme la partie sur le fait de ne pas se fier à l'état du port sur ces boîtiers. Nous avons un cluster de deux SRX380-POE-AC sous Junos 21.4R3-S4.9 où la panne va dans l'autre sens : xe-0/0/17 et xe-0/0/18 signalent link UP avec des LED allumées et aucune fibre connectée dessus. Juniper SFP-SX 740-011613 en Xcvr 16-17, SFP+-10G-SR 740-021308 en Xcvr 18-19, les deux nœuds affichant un inventaire identique dans
show chassis hardware, etshow interfaces terseinsistant que les interfaces sont up.Réinsérer les modules n'a strictement rien changé. Ces ports étaient destinés à un reth que nous avons finalement construit sur ge-0/0/14-15, donc personne n'en pâtit, et je n'ai jamais eu de réponse sur l'existence éventuelle d'un PR derrière ça. Entre ça et votre port de contrôle éteint, je ne traiterais pas l'état des optiques sur un SRX en cluster comme une preuve de quoi que ce soit de physique.
Deux remarques annexes pour quand vous irez plus loin sur ce chemin.
Si une optique DWDM finit par se retrouver sur le trajet, vérifiez la grille avant de commander : un accordable 50 GHz face à des optiques fixes 100 GHz à l'autre bout est une façon bien connue de perdre une nuit, et sous Junos le canal vient de l'option de longueur d'onde plutôt que de quoi que ce soit qu'on règle sur l'interface. Ne paniquez pas non plus si le boîtier signale un numéro de canal qui ne correspond pas à ce que vous avez configuré alors que la lumière est sur la bonne longueur d'onde. C'est arrivé assez souvent sur des accordables Cisco pour que la lecture CLI ne soit pas ce en quoi il faut avoir confiance.
Sur le thème général de la documentation maigre pour ces cages : même plateforme, un module cuivre SRX-SFP-1GE-T monte sans problème à 1 Gbps et refuse de monter à 100 Mbps, alors que le guide matériel appelle les ports SFP 100/1000 tandis que la fiche technique du module dit 10/100/1000. Personne n'a pu me dire non plus laquelle des deux versions est vraie.