FortiGate 101F: los puertos combinados RJ45/SFP 17-20 se apagan tras una actualización de FortiOS
Tenemos un par de FortiGate 101F para una oficina de 40 personas, nada exótico. port17 lleva un enlace ascendente SFP al switch core, port19 es un tramo RJ45 hacia la sala de servidores, ambos dentro del bloque combinado RJ45/SFP (puertos 17-20). En la ventana de mantenimiento del mes pasado subimos el par a FortiOS 7.4.4, y desde entonces ese bloque está muerto.
- FortiGate 101F, y un FortiGate 100F en el segundo sitio comportándose igual
- port17: módulo SFP de 1G a un switch de acceso apilado
- port19: RJ45 a un puerto de switch de 1G
- FortiOS 7.4.4, actualizado desde una build 7.2
Los puertos 1-16 están bien, solo los combinados cayeron. Lo que me llamó la atención es que las opciones de velocidad en la GUI ya no se ven como antes de la actualización, y la configuración en ejecución ahora tiene esto:
config system interface
edit "port17"
set speed 1000full
next
endAquí nadie escribió eso. Todos los puertos de esta caja estaban en auto antes de la actualización.
Probado hasta ahora:
- reasenté el SFP y lo cambié por uno confirmado bueno, sin cambios
- moví el extremo remoto a otro puerto del switch
- reinicio en frío del firewall, la configuración sobrevive tal como arriba
¿Se espera que el bloque combinado RJ45/SFP del 100F/101F pierda el auto durante una actualización, o se nos corrompió la configuración en algún sitio? ¿Y cuál es la forma correcta de devolverlo a su estado?
Comments 5
Tu configuración no la corrompió nadie en la oficina, lo hizo la actualización. En el 100F y el 101F, la actualización impone silenciosamente un 1000full fijo en los puertos combinados RJ45/SFP donde antes había auto, sin preguntar si el par puede vivir con esa tasa. Dependiendo del extremo remoto, terminas con un puerto que enlaza a la velocidad equivocada, o uno que nunca enlaza en absoluto, que es exactamente por qué 17-20 están a oscuras mientras los puertos dedicados no se tocaron. Fortinet lo tiene registrado como el problema conocido 989629, documentado en las notas de versión de 7.2.9; las ramas afectadas son v7.2.8 y posteriores, v7.4.2 y posteriores, y v7.6.0 y posteriores.
Devuelve la velocidad a mano, puerto por puerto:
En v7.2.8 y en v7.4.2 hasta v7.4.4 el auto normal no aparece en la lista, que es precisamente por qué la GUI se ve distinta para ti, así que usa 1000auto ahí. En v7.2.9, v7.4.5, v7.6.0 y posteriores la opción normal ha vuelto y quieres:
Repite para port18 hasta port20 si están en uso. Y para la próxima ventana: comprueba antes que nada en tu ruta de gestión caiga en los puertos 17-20, de lo contrario la caja vuelve con tu puerto de acceso forzado a 1000full y terminas conduciendo al sitio para arreglarlo desde la consola.
¿De qué build venías realmente? "una build 7.2" cubre mucho terreno, y lo que hay que escribir para arreglar esto difiere entre ramas. Lo otro que vale la pena saber es si los extremos remotos ofrecen autonegociación o están fijados ellos mismos: un par que solo negocia automáticamente se quedará ahí sin hacer nada frente a un puerto fijado a una tasa fija.
Una cosa que aclarar antes de cambiar nada: ¿tu ruta de gestión pasa por alguno de los puertos 17-20? Si es así, haz el próximo cambio desde la consola en vez de por la red.
Vale la pena añadir el punto general para cualquiera que llegue aquí con un puerto combinado que se comporta mal: en la mayoría de las cajas el par es realmente exclusivo. NETGEAR lo llama dual personality en el GS716T-200, donde cada una de las dos jaulas SFP está emparejada con uno de los últimos puertos de cobre, y solo la mitad de ese par puede estar activa a la vez, así que insertar un módulo saca silenciosamente de servicio el RJ-45 correspondiente. Todos los puertos de ese modelo son gigabit de todos modos, así que el enlace óptico te compra una ruta de cable, no ancho de banda.
La misma idea aplica en el bloque del FortiGate, así que confirma qué mitad de port17 estás mirando en realidad. Un módulo en la jaula más un latiguillo en la mitad de cobre del mismo puerto es un autogol clásico, y se parece mucho a un problema de velocidad visto desde la CLI.
Fabricante distinto, mismo sabor de dolor. EX4200 con un módulo de enlace ascendente EX-UM-2X4SFP: xe-0/1/0 corría 10G sin problemas, xe-0/1/1 ni siquiera se podía añadir a una VLAN y no pasaba tráfico. Ambos puertos funcionaban a 1G, el SFP+ era completamente visible en show chassis hardware, cambié módulos, probé un EX-UM-2X4SFP de repuesto e hice un reset de fábrica antes de que alguien me dijera qué es realmente ese módulo.
Nada estaba defectuoso. Ese módulo acepta un SFP+ solo en dos de sus jaulas, las numeradas 0 y 2 en el hardware; el otro par solo admite una óptica de 1G y nada más rápido. Así que las interfaces de 10G que obtienes al final son xe-0/1/0 más xe-0/1/2, y xe-0/1/1, la que había estado combatiendo, nunca iba a correr a 10G sin importar qué le conectara. Moví la óptica una jaula más allá, configuré xe-0/1/2, listo. Con jaulas de modo mixto, lee qué admite el bloque antes de devolver nada por RMA.
Cuidado con el ángulo de exclusividad de combo, no explica este caso. Los puertos funcionaban antes de la actualización, solo el bloque combinado se rompió después, y hay una línea de velocidad en la configuración que nadie escribió. Eso es la reescritura, no la prioridad de jaula.
El error contrario también quema a la gente, sin embargo. Una vez pasé una semana con switches D-Link DES-1210-52 conectados por fibra a un OSNOVO NS-SW-8GX2G: indicación de enlace en los puertos ópticos, sin LAN, sin internet en absoluto, mientras que los mismos switches funcionaban bien encadenados por cobre, y una actualización de firmware no cambió nada. El puerto combo fue el principal sospechoso durante días. El fallo real estaba en el extremo remoto: los puertos OSNOVO que llevaban esos módulos SFP estaban internamente muertos, quemados, con las ópticas dentro perfectamente sanas.
Así que una vez que la configuración local esté correcta, pon un módulo confirmado bueno en un puerto confirmado bueno del otro lado antes de concluir nada sobre tu propia caja.