Link DAC Fortinet a 25G tra FortiSwitch identici ok, ma non tra FS2048 e FS648
Stiamo unificando due row di aggregazione su FortiSwitch, e l'ultimo tassello è un collegamento a 25G tra un FS2048 e un FS648 in rack adiacenti. Nel progetto è andato tutto su al primo tentativo, tranne questo link, che non ne vuole sapere.
- FortiSwitch 2048, porta frontale a 25G
- FortiSwitch 648, porta frontale a 25G
- DAC passivo Fortinet FN-CABLE-SFP28-5, cavo del vendor, non di terze parti
- Per il resto le porte non sono state toccate, a parte la configurazione VLAN
Ecco cosa ottengo:
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, stableGià fatto:
- sostituito con un secondo FN-CABLE-SFP28-5 dalla stessa scatola, nessun cambiamento
- spostati entrambi gli estremi su porte 25G diverse su ciascuno chassis, nessun cambiamento
- verificato che il cavo funziona collegandolo tra due FS648 identici, dove sale subito
Quindi il cavo va bene e le porte vanno bene, ma la combinazione no. C'è qualcosa sulle porte 25G che deve corrispondere tra i due modelli perché il link riesca a fare il training?
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
Esatto, è proprio quello. I due chassis sono costruiti su generazioni diverse di ASIC e PHY, e la correzione d'errore che ciascuno sceglie da solo a 25G non è la stessa sui due lati, quindi il link non finisce mai il training. Ti ritrovi con un down/down pulito e nei log non c'è niente su cui ragionare.
Fissa manualmente la stessa modalità FEC su entrambe le porte:
Falla sia sul FS2048 sia sul FS648, usando il nome di porta di ciascun lato. CL91 è la variante Reed-Solomon e pulisce parecchio di più rispetto all'opzione firecode CL74, ma quale delle due scegli conta molto meno che sceglierne una identica su entrambi i lati: entrambi i PHY devono codificare e decodificare con lo stesso schema, altrimenti il training non si completa mai, e "auto" su due famiglie di PHY diverse non è uno schema identico.
La porta dovrebbe salire non appena viene applicata anche sul secondo lato. Se più avanti aggiungi un terzo modello, impostalo esplicitamente anche lì invece di dare per scontato che il default sia lo stesso.
Un cavo che funziona tra unità identiche e muore tra modelli diversi indica che il livello fisico non riesce a mettersi d'accordo su qualcosa, e sul rame a 25G quel qualcosa è quasi sempre il FEC.
Prima di ogni altra cosa, posta che fec-state è configurato attualmente su entrambe le porte. Il default non è lo stesso tra le generazioni FortiSwitch, e i due modelli che stai collegando non sono della stessa famiglia ASIC/PHY, quindi "impostazioni di fabbrica su entrambi i lati" non vuol dire "stessa impostazione su entrambi i lati".
Se le due porte tornano con valori diversi, hai la risposta prima ancora di toccare altro.
Non è stato toccato nulla su nessuno dei due lati, quindi entrambe le porte girano con qualunque default imposti l'immagine. Il lato FS2048 è nudo:
Stessa cosa sul FS648. Anche velocità e auto-negoziazione intoccate, ho solo messo le porte nella VLAN giusta. Se i default cambiano da modello a modello, spiegherebbe perché lo stesso cavo è perfettamente felice tra due scatole identiche.
Stesso genere di problema anche ben fuori da Fortinet, per quel che vale. Avevo un DAC passivo SFP28 a 25G che si collegava benissimo tra un UniFi USW-Pro-Aggregation e un server con una scheda Intel SFP28, e non dava assolutamente nulla su sfp28-2 di un MikroTik CCR2004-1G-12S+2XS - nessun errore su nessuno dei due lati, semplicemente nessun link. Provato un Ubiquiti UACC-DAC-SFP28-3M e un Lenovo 7Z57A03558, stesso risultato. A un certo punto la porta è salita ed è ricaduta dopo circa due secondi, il che era l'indizio che qualcosa falliva il training invece che il cavo fosse morto.
Di nuovo il FEC: il lato Ubiquiti tiene il FEC sempre attivo senza un modo supportato per cambiarlo, e RouterOS ha spostato il default da fec91 a nessun FEC nella 6.49. Quello che ha funzionato qui è stato passare a RouterOS 7.4, dove le opzioni FEC sono esposte, lanciando
e poi impostando la porta su fec74 con auto-negoziazione disattivata, flow control disattivato in entrambe le direzioni, 25 Gbps full duplex, più un override del port profile sul lato UniFi che fissa 25G FDX. Questo è il mio hardware e il mio firmware, quindi prendi la ricetta esatta come punto di partenza e verifica sul tuo.
Vale la pena aggiungere che la stessa manopola ha un nome diverso a seconda di in quale CLI ti trovi, ed è questo che rende la cosa dolorosa quando un rack ospita più di un vendor. Sui link Cisco a 25G tra uno stack di Catalyst 9300 e una coppia di Catalyst 9500, fec cl108 su entrambi i lati è quello che li ha fatti salire; sul 100G tra quella coppia di 9500 e un Nexus 9000, ha funzionato fec off su entrambi i lati. Stessa decisione, parole chiave diverse.
E il FEC non è sempre qualcosa che si attiva. Su un Nexus 93180YC-EX con SFP-H25GB-SR verso un adattatore Cavium a 25G, la porta dello switch stava su FEC auto e si aspettava il FEC a causa dell'ottica, mentre la NIC non dichiarava alcuna capacità FEC, quindi i due lati non si sono mai messi d'accordo e le interfacce sono rimaste down con i moduli riconosciuti. Lì la soluzione è stata fec off sull'interfaccia dello switch, e show interface conferma il passaggio della modalità da Auto a Off.
Quindi la regola non è "usa cl91", è "decidi la modalità, poi impostala esplicitamente su entrambi i lati".
Confermato. set fec-state cl91 sulla porta FS2048 da solo non ha cambiato nulla, poi la stessa cosa sulla porta FS648 e il link è salito nel giro di un paio di secondi. Contatori che girano su entrambi i lati, e ha retto al reboot di ogni chassis.
Da ora in poi l'impostazione resta esplicita su ogni porta a 25G di questa coppia invece di fidarsi di un default. Due serate a scambiare cavi perfettamente funzionanti per una riga di configurazione.