Fortinet 25G-DAC-Link zwischen gleichen FortiSwitches kommt hoch, nur nicht zwischen FS2048 und FS648
Wir fassen zwei Aggregationsreihen auf FortiSwitch zusammen, und das letzte Teilstück ist eine 25G-Verbindung zwischen einem FS2048 und einem FS648 in benachbarten Racks. Alles andere im Design ist beim ersten Versuch hochgekommen, nur dieser eine Link will nicht.
- FortiSwitch 2048, 25G-Port am Frontpanel
- FortiSwitch 648, 25G-Port am Frontpanel
- Fortinet FN-CABLE-SFP28-5, passives DAC, Herstellerkabel, kein Drittanbieter
- Beide Ports sonst unangetastet, bis auf die VLAN-Konfiguration
Das sehe ich:
FS2048 port: down, no rx/tx counters moving
FS648 port: down, no rx/tx counters moving
same FN-CABLE-SFP28-5 between two FS648 units: up at 25G, stableBereits gemacht:
- ein zweites FN-CABLE-SFP28-5 aus derselben Kiste eingesetzt, keine Änderung
- beide Enden auf andere 25G-Ports am jeweiligen Chassis gelegt, keine Änderung
- die Funktion des Kabels bestätigt, indem ich es zwischen zwei identischen FS648 gepatcht habe, wo es sofort hochkommt
Das Kabel ist also in Ordnung, die Ports sind in Ordnung, nur die Kombination nicht. Muss auf den 25G-Ports etwas zwischen den beiden Modellen übereinstimmen, damit der Link trainiert?
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 6
Genau das ist es. Die beiden Chassis basieren auf unterschiedlichen ASIC- und PHY-Generationen, und die Fehlerkorrektur, auf die sich jede Seite bei 25G von selbst einigt, ist auf beiden Seiten nicht dieselbe, also wird das Link-Training nie fertig. Übrig bleibt ein sauberes down/down und in den Logs nichts, woran man sich festhalten kann.
Den gleichen FEC-Modus von Hand auf beiden Ports festnageln:
Mach das auf dem FS2048 und auf dem FS648, jeweils mit dem eigenen Portnamen der Seite. CL91 ist die Reed-Solomon-Variante und räumt deutlich mehr auf als die CL74-Firecode-Option, aber welche der beiden man wählt, spielt viel weniger eine Rolle als beide Male dieselbe zu wählen: Beide PHYs müssen mit einem identischen Schema kodieren und dekodieren, sonst wird das Training nie fertig, und "auto" auf zwei verschiedenen PHY-Familien ist kein identisches Schema.
Der Port sollte hochkommen, sobald die zweite Seite committed ist. Kommt später ein drittes Modell dazu, dort auch explizit setzen, statt anzunehmen, dass der Default übernommen wurde.
Ein Kabel, das zwischen identischen Geräten linkt, aber zwischen unterschiedlichen Modellen stirbt, zeigt, dass sich Layer 1 auf irgendetwas nicht einigt, und bei 25G über Kupfer ist das fast immer FEC.
Vor allem anderen: posten, was fec-state aktuell auf beiden Ports konfiguriert ist. Der Default ist nicht über alle FortiSwitch-Generationen hinweg gleich, und die beiden Modelle, die hier zusammenkommen, sind nicht dieselbe ASIC-/PHY-Familie, also heißt "Werkseinstellung auf beiden Seiten" nicht "dieselbe Einstellung auf beiden Seiten".
Wenn die beiden Ports dabei unterschiedliche Werte liefern, hat man die Antwort, bevor man sonst noch etwas anfasst.
Auf keiner Seite wurde etwas angefasst, beide Ports laufen also mit dem, was das Image standardmäßig setzt. Die FS2048-Seite ist leer:
Auf dem FS648 genauso. Speed und Auto-Negotiation ebenfalls unangetastet, ich habe die Ports nur in das richtige VLAN gelegt. Wenn sich die Defaults je nach Modell unterscheiden, würde das erklären, warum dasselbe Kabel zwischen zwei identischen Geräten völlig zufrieden ist.
Gleiche Problemklasse, weit weg von Fortinet, nur am Rande. Ich hatte ein passives 25G-SFP28-DAC, das zwischen einem UniFi USW-Pro-Aggregation und einem Server mit einer Intel-SFP28-Karte klaglos linkte, und auf sfp28-2 eines MikroTik CCR2004-1G-12S+2XS überhaupt nichts brachte - kein Fehler auf beiden Seiten, einfach kein Link. Ein Ubiquiti UACC-DAC-SFP28-3M und ein Lenovo 7Z57A03558 probiert, gleiches Ergebnis. Einmal kam der Port sogar hoch und fiel nach etwa zwei Sekunden wieder ab, das war der Hinweis, dass etwas beim Training scheitert und nicht das Kabel tot ist.
Wieder FEC: Die Ubiquiti-Seite hält FEC fest an, ohne unterstützten Weg, das zu ändern, und RouterOS hat den Default in 6.49 von fec91 auf kein FEC umgestellt. Geholfen hat hier der Umstieg auf RouterOS 7.4, wo die FEC-Optionen offenliegen, mit
und danach den Port auf fec74 gesetzt, Auto-Negotiation aus, Flow Control in beide Richtungen aus, 25 Gbps Vollduplex, dazu ein Port-Profil-Override auf der UniFi-Seite, das 25G FDX festnagelt. Das ist meine Hardware und meine Firmware, also das Rezept als Ausgangspunkt nehmen und bei euch selbst verifizieren.
Ergänzend: Derselbe Schalter heißt je nach CLI, in der man gerade steckt, anders, und genau das macht es schmerzhaft, sobald in einem Rack mehr als ein Hersteller steht. Bei Cisco-25G-Links zwischen einem Catalyst-9300-Stack und einem Catalyst-9500-Paar hat fec cl108 auf beiden Seiten sie hochgebracht, bei den 100G zwischen diesem 9500-Paar und einem Nexus 9000 hat fec off auf beiden Seiten funktioniert. Gleiche Entscheidung, andere Schlüsselwörter.
Und FEC ist nicht immer etwas, das man einschaltet. Bei einem Nexus 93180YC-EX mit SFP-H25GB-SR in einen Cavium-25G-Adapter stand der Switch-Port auf FEC auto und erwartete FEC wegen der Optik, während die NIC überhaupt keine FEC-Fähigkeit meldete, sodass sich die beiden Enden nie einigten und die Interfaces down blieben, obwohl die Module erkannt wurden. Dort war fec off auf dem Switch-Interface die Lösung, und show interface bestätigt, wie der Modus von Auto auf Off wechselt.
Die Regel lautet also nicht "cl91 benutzen", sondern "den Modus festlegen und ihn dann auf beiden Seiten explizit setzen".
Bestätigt. set fec-state cl91 auf dem FS2048-Port hat für sich allein nichts geändert, dann dasselbe auf dem FS648-Port, und der Link kam innerhalb weniger Sekunden hoch. Counter bewegen sich auf beiden Seiten, und es hat einen Reboot beider Chassis überstanden.
Ab jetzt bleibt die Einstellung auf jedem 25G-Port in diesem Paar explizit gesetzt, statt sich auf einen Default zu verlassen. Zwei Abende lang einwandfreie Kabel getauscht für eine einzige Zeile Konfiguration.