Le porte combo RJ45/SFP 17-20 del FortiGate 101F si spengono dopo un upgrade di FortiOS
Gestiamo una coppia di FortiGate 101F per un ufficio da 40 persone, niente di esotico. port17 porta un uplink SFP verso lo switch core, port19 è una tratta RJ45 verso la server room, entrambe dentro il blocco condiviso RJ45/SFP (porte 17-20). Nella finestra di manutenzione del mese scorso abbiamo portato la coppia a FortiOS 7.4.4, e da allora quel blocco è morto.
- FortiGate 101F, e un FortiGate 100F nel secondo sito che si comporta allo stesso modo
- port17: modulo SFP 1G verso uno switch di accesso in stack
- port19: RJ45 verso una porta switch 1G
- FortiOS 7.4.4, aggiornato da una build 7.2
Le porte 1-16 stanno bene, solo quelle condivise sono andate giù. Quello che mi ha colpito è che le opzioni di velocità nella GUI non hanno più l'aspetto di prima dell'upgrade, e la config in esecuzione ora ha questo:
config system interface
edit "port17"
set speed 1000full
next
endQui non l'ha digitato nessuno. Prima dell'upgrade ogni porta di questo apparato era su auto.
Provato finora:
- SFP riseduto e sostituito con uno sicuramente funzionante, nessun cambiamento
- spostato il lato remoto su un'altra porta dello switch
- riavvio a freddo del firewall, la config resta come sopra
Ci si aspetta che il blocco condiviso RJ45/SFP su 100F/101F perda l'auto durante un upgrade, oppure la nostra config si è rovinata da qualche parte? E qual è il modo giusto per rimetterla a posto?
Comments 5
La tua config non l'ha rovinata nessuno in ufficio, è stato l'upgrade. Su 100F e 101F l'upgrade imprime silenziosamente un 1000full fisso sulle porte condivise RJ45/SFP dove prima c'era auto, senza chiedersi se il peer può convivere con quella velocità. A seconda del lato remoto ottieni quindi una porta che si collega alla velocità sbagliata, oppure una che non si collega affatto, ed è esattamente per questo che 17-20 sono spente mentre le porte dedicate restano intatte. Fortinet lo ha registrato come known issue 989629, documentato nelle release notes della 7.2.9; le versioni interessate sono v7.2.8 e successive, v7.4.2 e successive, e v7.6.0 e successive.
Rimetti la velocità a mano, porta per porta:
Sulla v7.2.8 e dalla v7.4.2 alla v7.4.4 il semplice auto non è nell'elenco, ed è proprio per questo che la GUI ti sembra diversa, quindi lì usa 1000auto. Su v7.2.9, v7.4.5, v7.6.0 e successive l'opzione normale è tornata e ti serve:
Ripeti per port18 fino a port20 se sono in uso. E per la prossima finestra: controlla prima che niente nel tuo percorso di gestione passi dalle porte 17-20, altrimenti l'apparato torna con la tua porta di accesso forzata a 1000full e ti tocca andare in sede a sistemarlo dalla console.
Da quale build venivi esattamente? "una build 7.2" copre un bel po' di terreno, e quello che devi digitare per sistemare la cosa cambia tra una versione e l'altra. L'altra cosa che vale la pena sapere è se i lati remoti offrono autonegoziazione o sono fissati anche loro: un peer che fa solo autonegoziazione se ne sta lì senza fare nulla contro una porta tenuta a velocità fissa.
Una cosa da chiarire prima di cambiare qualsiasi cosa: il tuo percorso di gestione passa per qualcuna delle porte 17-20? Se sì, fai il prossimo cambiamento dalla console invece che dalla rete.
Vale la pena aggiungere la parte generale per chiunque arrivi qui con una porta condivisa che si comporta male: sulla maggior parte degli apparati la coppia è davvero esclusiva. NETGEAR la chiama dual personality sul GS716T-200, dove ognuna delle due cage SFP è abbinata a una delle ultime porte in rame, e solo una metà di quella coppia può essere attiva alla volta, quindi inserire un modulo mette silenziosamente fuori servizio l'RJ-45 corrispondente. Su quel modello ogni porta è comunque gigabit, quindi l'uplink ottico ti compra una via del cavo, non banda.
Stessa idea sul blocco del FortiGate, quindi conferma quale metà di port17 stai davvero guardando. Un modulo nella cage più una bretella nella metà in rame della stessa porta è un autogol classico, e dalla CLI sembra molto un problema di velocità.
Vendor diverso, stesso sapore di sofferenza. EX4200 con un modulo uplink EX-UM-2X4SFP: xe-0/1/0 andava felicemente a 10G, xe-0/1/1 non si riusciva nemmeno ad aggiungere a una VLAN e non passava traffico. Entrambe le porte funzionavano a 1G, l'SFP+ era perfettamente visibile in show chassis hardware, ho cambiato moduli, provato un EX-UM-2X4SFP di scorta e fatto un factory reset prima che qualcuno mi dicesse cos'è davvero quel modulo.
Non c'era niente di difettoso. Quel modulo accetta un SFP+ solo in due delle sue cage, quelle numerate 0 e 2 nell'hardware; l'altra coppia porta un'ottica 1G e niente di più veloce. Quindi le interfacce 10G che ottieni sono xe-0/1/0 più xe-0/1/2, e xe-0/1/1, quella con cui avevo lottato, non sarebbe mai andata a 10G qualunque cosa ci avessi collegato. Spostata l'ottica di una cage, configurato xe-0/1/2, fatto. Con cage in modalità mista, leggi cosa supporta il blocco prima di fare RMA a qualsiasi cosa.
Attenzione con l'angolo dell'esclusività combo, qui non spiega il caso. Le porte funzionavano prima dell'upgrade, solo il blocco condiviso si è rotto dopo, e c'è una riga di velocità nella config che nessuno ha digitato. Quella è la riscrittura, non la priorità delle cage.
L'errore opposto però manda in crisi tanta gente lo stesso. Una volta ho passato una settimana su switch D-Link DES-1210-52 collegati in fibra a un OSNOVO NS-SW-8GX2G: indicazione di link sulle porte ottiche, niente LAN, nessun internet, mentre gli stessi switch funzionavano bene incatenati in rame, e un aggiornamento firmware non ha cambiato nulla. La porta combo è stata il primo sospettato per giorni. Il guasto vero era dal lato remoto: le porte OSNOVO che portavano quei moduli SFP erano morte internamente, bruciate, con le ottiche perfettamente sane infilate dentro.
Quindi, una volta sistemata la config locale, metti un modulo sicuramente funzionante in una porta sicuramente funzionante dall'altro lato prima di concludere qualsiasi cosa sul tuo apparato.