SRX1500-Cluster über Dark Fiber: HA-CONTROL-Port bleibt dunkel mit SFP-LH 740-011612
Zwei SRX1500 stehen in getrennten Rechenzentren, ein paar Kilometer auseinander, verbunden durch Dark-Fiber-Paare, die uns Ende-zu-Ende gehören. Sie müssen als Chassis-Cluster hochkommen, was heißt, der Control-Link muss über diese Faser statt über ein Patchkabel innerhalb eines Racks laufen.
Der Aufbau:
- zwei Juniper SRX1500, identischer Hardware-Aufbau
- Juniper SFP-LH 740-011612 im HA-CONTROL-Port jedes Knotens
- ein dediziertes Dark-Fiber-Paar für den Control-Link, direkt durchgepatcht
- das SFP-T-Kupfermodul, das mit dem Chassis geliefert wurde, vorher für einen Back-to-Back-Test benutzt
Mit dem SFP-LH eingesetzt passiert überhaupt nichts. Keine LED am Käfig, kein Link, und der Cluster bildet sich nie:
> show chassis cluster interfaces
Control link status: Down
Control interfaces:
Index Interface Status
0 em0 DownWas ich schon gemacht habe:
- den Control-Link auf das zweite Faserpaar verlegt, keine Änderung auf beiden Knoten
- die Module zwischen den beiden Knoten getauscht, gleiches Ergebnis auf beiden
- das SFP-T als Sanity-Check wieder eingesetzt, und es blieb down bis zu einem vollständigen Chassis-Neustart, danach kam es sofort hoch
Dieser letzte Punkt stört mich mehr als die tote Optik. Akzeptiert der HA-CONTROL-Port an einem SRX1500 überhaupt SFP-LH 740-011612 oder SFP-SX 740-011613, oder nur das mitgelieferte SFP-T? Und hat schon mal jemand ein DWDM-SFP in diesem Port betrieben und zum Laufen gebracht?
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 4
Bevor man der Optik die Schuld gibt: Was sieht die Box in diesem Käfig tatsächlich?
show chassis hardwareposten mit eingestecktem SFP-LH und prüfen, ob für den Slot überhaupt eine Xcvr-Zeile erscheint, auf beiden Knoten. Wird das Modul nicht einmal inventarisiert, ist das kein Faser- oder Wellenlängenproblem, und kein noch so häufiges Paar-Tauschen wird daran etwas ändern.Zweite Sache, zehn Minuten Arbeit: eines dieser SFP-LH-Module in einen Revenue-Port gegen ein bekannt gutes Gegenstück stecken. Linkt es dort und bleibt im HA-Käfig dunkel, hat man das Modul vom Port getrennt und kann aufhören, über die Faseranlage zu streiten.
Zur DWDM-Hälfte der Frage gibt es zumindest einen Datenpunkt: Jemand, der Champion-ONE-DWDM-Optik auf der SRX1500-Serie betrieben hat, hatte sie am Laufen. Bevor man diesen Weg geht, erst die genaue Wellenlänge mit dem Optik- oder DWDM-Hersteller bestätigen, denn Juniper verkauft nicht zwangsläufig ein Modul dafür, und dann ist man bei Fremdoptik, mit allem, was das bedeutet, sobald man einen Case öffnet.
Der HA-Control-Port ist ein anderes Tier, und ich würde nicht annehmen, dass er sich wie ein Revenue-Port verhält. Es gibt dafür keine veröffentlichte Optik-Liste außer dem SFP-T, das mit dem Chassis geliefert wird, und dein eigener Test sagt, dass der Käfig zur Laufzeit nicht neu gelesen wird: Das Kupfermodul kam erst nach einem Chassis-Neustart zurück. Das liest sich, als würde der Port beim Boot inventarisiert und danach nichts mehr neu gescannt.
Muss der Cluster bald stehen, den Transport außerhalb der Firewall halten. Den Long Haul auf Gerät terminieren, das Optik zum Beruf hat, jedem SRX einen kurzen Link auf dem Modul geben, das er nachweislich akzeptiert, und den Transport die Wellenlänge besitzen lassen. Weniger elegant, deutlich schneller zu liefern. Trotzdem einen Case aufmachen, denn dass es für diesen Port keine gelistete unterstützte Optik gibt, ist selbst eine schriftliche Antwort wert.
Unterstütze den Teil dazu, dem Portstatus auf diesen Boxen nicht zu trauen. Wir haben einen Cluster aus zwei SRX380-POE-AC auf Junos 21.4R3-S4.9, bei dem der Fehler andersrum läuft: xe-0/0/17 und xe-0/0/18 melden link UP mit leuchtenden LEDs, und es hängt überhaupt keine Faser dran. Juniper SFP-SX 740-011613 als Xcvr 16-17, SFP+-10G-SR 740-021308 als Xcvr 18-19, beide Knoten zeigen identisches Inventar in
show chassis hardware, undshow interfaces tersebesteht darauf, die Interfaces seien up.Die Module neu zu stecken hat exakt nichts geändert. Diese Ports waren für ein reth gedacht, das wir am Ende auf ge-0/0/14-15 gebaut haben, niemandem tut das also weh, und ich habe nie eine Antwort bekommen, ob ein PR dahintersteckt. Zwischen dem und deinem dunklen Control-Port würde ich den Optik-Status an einem geclusterten SRX nicht als Beweis für irgendetwas Physisches behandeln.
Zwei Randbemerkungen für später auf diesem Weg.
Landet am Ende doch eine DWDM-Optik im Pfad, vor der Bestellung das Grid prüfen: Ein 50-GHz-Tunable gegen feste 100-GHz-Optik am anderen Ende ist eine bekannte Art, eine Nacht zu verlieren, und unter Junos kommt der Kanal aus der Wavelength-Option und nicht aus irgendetwas, das man am Interface einstellt. Auch nicht in Panik geraten, wenn die Box eine Kanalnummer meldet, die nicht zur Konfiguration passt, während das Licht auf der richtigen Wellenlänge liegt. Das ist bei Cisco-Tunables schon oft genug aufgetaucht, dass man dem CLI-Readout dabei nicht trauen sollte.
Zum allgemeinen Thema dünner Dokumentation für diese Käfige: gleiche Plattform, ein SRX-SFP-1GE-T-Kupfermodul linkt fröhlich bei 1 Gbps und weigert sich, bei 100 Mbps hochzukommen, wobei der Hardware-Guide die SFP-Ports 100/1000 nennt, während das Modul-Datenblatt 10/100/1000 sagt. Welche der beiden Angaben stimmt, konnte mir auch niemand sagen.