Les ports partagés RJ45/SFP 17-20 d'un FortiGate 101F s'éteignent après une mise à jour de FortiOS
On fait tourner une paire de FortiGate 101F pour un bureau de 40 personnes, rien d'exotique. port17 porte un uplink SFP vers le switch cœur, port19 est un tronçon RJ45 vers la salle serveur, tous les deux dans le bloc RJ45/SFP partagé (ports 17-20). Pendant la fenêtre de maintenance le mois dernier, on a fait passer la paire en FortiOS 7.4.4, et depuis ce bloc est mort.
- FortiGate 101F, et un FortiGate 100F sur le second site qui se comporte pareil
- port17 : module SFP 1G vers un switch d'accès empilé
- port19 : RJ45 vers un port de switch 1G
- FortiOS 7.4.4, mis à jour depuis une build 7.2
Les ports 1-16 vont bien, seuls les partagés sont tombés. Ce qui m'a interpellé, c'est que les options de vitesse dans l'interface graphique n'ont plus la même tête qu'avant la mise à jour, et la config en cours a maintenant ceci :
config system interface
edit "port17"
set speed 1000full
next
endPersonne ici n'a tapé ça. Chaque port sur ce boîtier était en auto avant la mise à jour.
Essayé jusqu'ici :
- réenfiché le SFP et remplacé par un connu bon, aucun changement
- déplacé l'autre bout vers un autre port de switch
- redémarrage à froid du firewall, la config survit comme ci-dessus
Est-ce que le bloc RJ45/SFP partagé sur le 100F/101F est censé perdre l'auto pendant une mise à jour, ou notre config s'est-elle abîmée quelque part ? Et quelle est la bonne façon de la remettre en place ?
Comments 5
Ta config n'a été abîmée par personne au bureau, c'est la mise à jour qui l'a fait. Sur le 100F et le 101F, la mise à jour tamponne discrètement un 1000full fixe sur les ports RJ45/SFP partagés là où c'était auto avant, sans se demander si le pair peut vivre avec ce débit. Selon l'autre bout, tu obtiens ensuite soit un port qui lie au mauvais débit, soit un qui ne lie jamais du tout, ce qui explique exactement pourquoi 17-20 sont éteints alors que les ports dédiés sont intacts. Fortinet l'a répertorié comme problème connu 989629, documenté dans les notes de version de la 7.2.9 ; les branches affectées sont v7.2.8 et ultérieures, v7.4.2 et ultérieures, et v7.6.0 et ultérieures.
Remets la vitesse à la main, port par port :
Sur v7.2.8 et sur v7.4.2 à v7.4.4, le simple auto n'est pas proposé dans la liste, c'est précisément pourquoi l'interface graphique te paraît différente, donc utilise 1000auto là. Sur v7.2.9, v7.4.5, v7.6.0 et ultérieures, l'option normale est de retour et tu veux :
Répète pour port18 à port20 s'ils sont utilisés. Et pour la prochaine fenêtre : vérifie d'abord que rien dans ton chemin de gestion n'atterrit sur les ports 17-20, sinon le boîtier revient avec ton port d'accès forcé en 1000full et tu te déplaces sur site pour le corriger depuis la console.
Tu venais réellement de quelle build ? « une build 7.2 » couvre beaucoup de terrain, et ce qu'il faut taper pour corriger ça diffère entre les branches. L'autre chose qui vaut la peine d'être connue, c'est si les autres bouts proposent l'auto-négociation ou sont eux-mêmes fixés : un pair qui ne fait que négocier automatiquement va rester là sans rien faire face à un port maintenu à un débit fixe.
Une chose à régler avant de changer quoi que ce soit : est-ce que ton chemin de gestion passe par l'un des ports 17-20 ? Si oui, fais le prochain changement depuis la console plutôt que par le réseau.
Ça vaut le coup d'ajouter le point général pour quiconque atterrit ici avec un port partagé qui se comporte mal : sur la plupart des boîtiers, la paire est vraiment exclusive. NETGEAR appelle ça dual personality sur le GS716T-200, où chacune des deux cages SFP est appariée avec l'un des derniers ports cuivre, et une seule moitié de cette paire peut être active à la fois, donc insérer un module retire discrètement le RJ-45 correspondant du service. Tous les ports de ce modèle sont de toute façon gigabit, donc l'uplink optique achète un chemin de câble, pas de la bande passante.
Même idée sur le bloc FortiGate, donc confirme quelle moitié de port17 tu regardes réellement. Un module dans la cage plus un cordon de brassage dans la moitié cuivre du même port est un classique but contre son camp, et ça ressemble beaucoup à un problème de vitesse depuis la CLI.
Vendeur différent, même saveur de galère. EX4200 avec un module d'uplink EX-UM-2X4SFP : xe-0/1/0 tournait joyeusement en 10G, xe-0/1/1 ne pouvait même pas être ajouté à un VLAN et ne passait aucun trafic. Les deux ports fonctionnaient en 1G, le SFP+ était pleinement visible dans show chassis hardware, j'ai échangé les modules, essayé un EX-UM-2X4SFP de rechange et fait une réinitialisation d'usine avant que quelqu'un me dise ce qu'est réellement ce module.
Rien n'était défectueux. Ce module n'accepte un SFP+ que dans deux de ses cages, celles numérotées 0 et 2 côté matériel ; l'autre paire ne porte qu'une optique 1G et rien de plus rapide. Donc les interfaces 10G dont on dispose sont xe-0/1/0 plus xe-0/1/2, et xe-0/1/1, celle avec laquelle je me battais, n'allait jamais tourner en 10G peu importe ce que j'y branchais. Déplacé l'optique d'une cage, configuré xe-0/1/2, terminé. Avec des cages en mode mixte, lis ce que le bloc supporte avant de faire un RMA de quoi que ce soit.
Attention avec l'angle de l'exclusivité combo, ça n'explique pas ce cas. Les ports fonctionnaient avant la mise à jour, seul le bloc partagé a cassé après, et il y a une ligne de vitesse dans la config que personne n'a tapée. C'est la réécriture, pas la priorité de cage.
L'erreur inverse brûle aussi les gens, cela dit. J'ai passé une semaine une fois sur des switches D-Link DES-1210-52 reliés en uplink par fibre à un OSNOVO NS-SW-8GX2G : indication de lien sur les ports optiques, pas de LAN, pas d'internet du tout, alors que les mêmes switches fonctionnaient bien chaînés en cuivre, et une mise à jour de firmware n'a rien changé. Le port combo était le suspect numéro un pendant des jours. Le vrai défaut était à l'autre bout : les ports OSNOVO portant ces modules SFP étaient morts en interne, grillés, avec les optiques dedans parfaitement saines.
Donc une fois la config locale correcte, mets un module connu bon dans un port connu bon de l'autre côté avant de conclure quoi que ce soit sur ton propre boîtier.