Fortinet 25G DAC-link werkt tussen identieke FortiSwitch-units, maar niet tussen FS2048 en FS648
We voegen twee aggregatierijen samen op FortiSwitch, en het laatste stuk is een 25G-verbinding tussen een FS2048 en een FS648 in aangrenzende racks. Al de rest van het ontwerp kwam in één keer overeind; alleen deze ene link weigert.
- FortiSwitch 2048, 25G front-panel poort
- FortiSwitch 648, 25G front-panel poort
- Fortinet FN-CABLE-SFP28-5 passieve DAC, kabel van de fabrikant zelf, geen third party
- Beide poorten verder ongemoeid, op de VLAN-config na
Wat ik krijg:
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, stableAl gedaan:
- een tweede FN-CABLE-SFP28-5 uit dezelfde doos geprobeerd, geen verschil
- beide kanten op andere 25G-poorten van elk chassis gezet, geen verschil
- bewezen dat de kabel goed is door hem tussen twee identieke FS648-units te pluggen, waar hij meteen opkomt
Dus de kabel is in orde en de poorten zijn in orde, maar de combinatie niet. Zit er iets op de 25G-poorten dat tussen de twee modellen moet overeenkomen voordat de link traint?
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
Dat is precies het probleem. De twee chassis zijn gebouwd op verschillende ASIC- en PHY-generaties, en de foutcorrectie waar elk van de twee zelf op uitkomt bij 25G is niet aan beide kanten hetzelfde, dus de link maakt het trainen nooit af. Je blijft zitten met een keurige down/down en niets in de logs om op te kauwen.
Zet handmatig dezelfde FEC-modus op beide poorten:
Doe het op de FS2048 en op de FS648, met de eigen poortnaam van elke kant. CL91 is de Reed-Solomon-variant en ruimt aanzienlijk meer op dan de CL74 firecode-optie, maar welke van de twee je kiest maakt veel minder uit dan tweemaal dezelfde kiezen: beide PHY's moeten met een identiek schema coderen en decoderen, anders is het trainen nooit klaar, en "auto" op twee verschillende PHY-families is geen identiek schema.
De poort zou moeten opkomen zodra de tweede kant is doorgevoerd. Als je later een derde model in dit mengsel gooit, zet het daar dan ook expliciet in plaats van aan te nemen dat de default is overgenomen.
Een kabel die tussen identieke units linkt en het begeeft tussen verschillende modellen, is de fysieke laag die het ergens niet over eens wordt, en bij 25G-koper is dat vrijwel altijd FEC.
Post voor je iets anders doet welke fec-state nu op beide poorten is ingesteld. De default is niet hetzelfde over de FortiSwitch-generaties heen, en de twee modellen die je koppelt zijn niet dezelfde ASIC/PHY-familie, dus "fabrieksinstellingen aan beide kanten" betekent niet "dezelfde instelling aan beide kanten".
Komen de twee poorten met verschillende waarden terug, dan heb je je antwoord voor je iets anders aanraakt.
Er is aan geen van beide kanten iets aangeraakt, dus draaien beide poorten op wat de image standaard instelt. De FS2048-kant is leeg:
Zelfde op de FS648. Speed en auto-negotiation ook ongemoeid, ik heb alleen de poorten in de juiste VLAN gezet. Als de defaults per model verschillen, zou dat verklaren waarom dezelfde kabel tussen twee identieke units prima gaat.
Voor wat het waard is, hetzelfde soort probleem, ver buiten Fortinet. Ik had een 25G SFP28 passieve DAC die probleemloos linkte tussen een UniFi USW-Pro-Aggregation en een server met een Intel SFP28-kaart, en helemaal niets gaf op sfp28-2 van een MikroTik CCR2004-1G-12S+2XS - geen fout aan geen van beide kanten, gewoon geen link. Een Ubiquiti UACC-DAC-SFP28-3M en een Lenovo 7Z57A03558 geprobeerd, zelfde resultaat. Op een gegeven moment kwam de poort wel op en viel na ongeveer twee seconden weer weg, en dat was de aanwijzing dat er iets niet trainde in plaats van dat de kabel dood was.
Weer FEC: de Ubiquiti-kant houdt FEC aan zonder ondersteunde manier om het te wijzigen, en RouterOS heeft de default in 6.49 van fec91 naar geen FEC verplaatst. Wat hier werkte was overstappen naar RouterOS 7.4, waar de FEC-opties wel toegankelijk zijn, door
te draaien en daarna de poort op fec74 te zetten met auto-negotiation uit, flow control uit in beide richtingen, 25 Gbps full duplex, plus een port profile override aan de UniFi-kant die 25G FDX vastzet. Dat is mijn hardware en mijn firmware, dus behandel het exacte recept als startpunt en verifieer het op de jouwe.
De moeite waard om toe te voegen: dezelfde knop heeft een andere naam afhankelijk van in welke CLI je staat, en dat maakt het vervelend zodra een rack meer dan één leverancier bevat. Bij Cisco 25G-links tussen een Catalyst 9300-stack en een Catalyst 9500-paar was fec cl108 aan beide kanten wat ze omhoog kreeg; bij de 100G tussen dat 9500-paar en een Nexus 9000 werkte fec off aan beide kanten. Dezelfde beslissing, andere keywords.
En FEC is niet altijd iets dat je aanzet. Op een Nexus 93180YC-EX met SFP-H25GB-SR naar een Cavium 25G-adapter stond de switchpoort op FEC auto en verwachtte FEC vanwege de optic, terwijl de NIC helemaal geen FEC-capability rapporteerde, dus de kanten kwamen nooit tot overeenstemming en de interfaces bleven down met de modules wel herkend. Daar was fec off op de switch-interface de oplossing, en show interface bevestigt dat de modus van Auto naar Off gaat.
De regel is dus niet "gebruik cl91", het is "kies de modus, en zet hem dan expliciet aan beide kanten".
Bevestigd. set fec-state cl91 op de FS2048-poort veranderde op zich niets, daarna hetzelfde op de FS648-poort en de link kwam binnen een paar seconden op. Counters lopen aan beide kanten, en het overleefde een reboot van elk chassis.
Vanaf nu blijft de instelling expliciet op elke 25G-poort in dit paar, in plaats van op een default te vertrouwen. Twee avonden perfect goede kabels verwisselen voor één regel config.