FortiGate 101F: gemeinsame RJ45/SFP-Ports 17-20 gehen nach einem FortiOS-Upgrade dunkel
Wir betreiben ein Paar FortiGate 101F für ein Büro mit 40 Leuten, nichts Exotisches. port17 trägt einen SFP-Uplink zum Core-Switch, port19 ist eine RJ45-Strecke zum Serverraum, beide innerhalb des gemeinsamen RJ45/SFP-Blocks (Ports 17-20). Im Wartungsfenster letzten Monat haben wir das Paar auf FortiOS 7.4.4 gehoben, seitdem ist dieser Block tot.
- FortiGate 101F, und eine FortiGate 100F am zweiten Standort verhält sich genauso
- port17: 1G-SFP-Modul zu einem gestackten Access-Switch
- port19: RJ45 zu einem 1G-Switch-Port
- FortiOS 7.4.4, hochgezogen von einem 7.2-Build
Ports 1-16 sind in Ordnung, nur die gemeinsamen sind ausgefallen. Aufgefallen ist mir, dass die Geschwindigkeitsoptionen in der GUI nicht mehr so aussehen wie vor dem Upgrade, und die laufende Konfiguration enthält jetzt das hier:
config system interface
edit "port17"
set speed 1000full
next
endDas hat hier niemand eingetippt. Vor dem Upgrade stand jeder Port auf dieser Box auf auto.
Bisher versucht:
- das SFP neu gesteckt und gegen ein bekanntermaßen gutes getauscht, keine Änderung
- das Gegenende an einen anderen Switch-Port gelegt
- Kaltstart der Firewall, die Konfiguration bleibt wie oben
Ist zu erwarten, dass der gemeinsame RJ45/SFP-Block bei 100F/101F während eines Upgrades auto verliert, oder ist uns irgendwo die Konfiguration zerschossen worden? Und wie stelle ich das richtig wieder her?
Comments 5
Eure Konfiguration wurde von niemandem im Büro zerschossen, das war das Upgrade. Auf 100F und 101F stempelt das Upgrade den gemeinsamen RJ45/SFP-Ports stillschweigend ein festes 1000full auf, wo vorher auto stand, ohne zu fragen, ob die Gegenseite mit dieser Rate leben kann. Je nach Gegenende bekommt man dann einen Port, der mit der falschen Rate linkt, oder einen, der überhaupt nie linkt, genau deshalb sind 17-20 dunkel, während die dedizierten Ports unangetastet bleiben. Fortinet führt das als bekanntes Problem 989629, dokumentiert in den Release Notes zu 7.2.9; betroffen sind die Zweige v7.2.8 und später, v7.4.2 und später sowie v7.6.0 und später.
Die Geschwindigkeit von Hand zurücksetzen, pro Port:
Auf v7.2.8 sowie v7.4.2 bis v7.4.4 wird das einfache auto nicht in der Liste angeboten, genau deshalb sieht die GUI bei dir anders aus, dort also 1000auto verwenden. Auf v7.2.9, v7.4.5, v7.6.0 und später ist die normale Option wieder da, dort willst du:
Für port18 bis port20 wiederholen, falls sie in Benutzung sind. Und fürs nächste Fenster: vorher prüfen, dass nichts in eurem Management-Pfad auf den Ports 17-20 landet, sonst kommt die Box mit eurem Access-Port fest auf 1000full zurück, und ihr fahrt zum Standort, um es von der Konsole aus zu reparieren.
Von welchem Build kommt ihr eigentlich? "ein 7.2-Build" deckt eine Menge Boden ab, und was man zum Beheben eintippen muss, unterscheidet sich zwischen den Zweigen. Das andere, was man wissen sollte: Bieten die Gegenenden Autonegotiation an, oder sind sie selbst fest eingestellt? Eine Gegenseite, die nur autonegotiation macht, sitzt untätig gegen einen auf fester Rate gehaltenen Port.
Eins vorab klären, bevor ihr irgendetwas ändert: Läuft euer Management-Pfad über einen der Ports 17-20? Falls ja, macht die nächste Änderung von der Konsole aus, nicht über das Netz.
Lohnt sich, für alle, die hier mit einem fehlverhaltenden gemeinsamen Port landen, den allgemeinen Punkt zu ergänzen: Auf den meisten Boxen ist das Paar wirklich exklusiv. NETGEAR nennt das dual personality auf dem GS716T-200, wo jeder der beiden SFP-Käfige mit einem der letzten Kupferports gepaart ist, und nur eine Hälfte dieses Paars kann gleichzeitig aktiv sein, ein eingestecktes Modul nimmt also stillschweigend den passenden RJ-45 außer Betrieb. Jeder Port auf diesem Modell ist ohnehin Gigabit, der optische Uplink kauft einem also eine Kabelroute, keine Bandbreite.
Dieselbe Idee gilt beim FortiGate-Block, also bestätige, welche Hälfte von port17 du dir eigentlich ansiehst. Ein Modul im Käfig plus ein Patchkabel in der Kupferhälfte desselben Ports ist ein klassisches Eigentor, und es sieht von der CLI aus sehr nach einem Geschwindigkeitsproblem aus.
Anderer Hersteller, gleiche Art von Ärger. EX4200 mit einem EX-UM-2X4SFP-Uplink-Modul: xe-0/1/0 lief problemlos mit 10G, xe-0/1/1 ließ sich nicht einmal einem VLAN hinzufügen und beförderte keinen Traffic. Beide Ports funktionierten mit 1G, das SFP+ war in show chassis hardware voll sichtbar, ich habe Module getauscht, ein Ersatz-EX-UM-2X4SFP probiert und einen Werksreset gemacht, bevor mir jemand sagte, was das Modul eigentlich ist.
Nichts war defekt. Dieses Modul nimmt ein SFP+ nur in zwei seiner Käfige, den hardwareseitig mit 0 und 2 nummerierten; das andere Paar trägt eine 1G-Optik und nichts Schnelleres. Die 10G-Interfaces, die dabei herauskommen, sind also xe-0/1/0 plus xe-0/1/2, und xe-0/1/1, mit dem ich gekämpft hatte, sollte nie mit 10G laufen, egal was ich hineinsteckte. Die Optik einen Käfig weitergesetzt, xe-0/1/2 konfiguriert, fertig. Bei Cages mit gemischtem Modus vorher nachlesen, was der Block unterstützt, bevor man irgendetwas per RMA zurückschickt.
Vorsicht mit dem Combo-Exklusivitäts-Ansatz, er erklärt diesen Fall nicht. Die Ports funktionierten vor dem Upgrade, erst danach ist der gemeinsame Block ausgefallen, und in der Konfiguration steht eine Speed-Zeile, die niemand eingetippt hat. Das ist der Rewrite, nicht Käfig-Priorität.
Der umgekehrte Fehler bringt aber auch Leute zu Fall. Ich habe einmal eine Woche mit D-Link-DES-1210-52-Switches verbracht, die per Faser zu einem OSNOVO NS-SW-8GX2G hochgebunden waren: Link-Anzeige an den optischen Ports, kein LAN, überhaupt kein Internet, während dieselben Switches über Kupfer verkettet einwandfrei liefen, und ein Firmware-Update änderte nichts. Der Combo-Port war tagelang der Hauptverdächtige. Der eigentliche Fehler saß am Gegenende: Die OSNOVO-Ports, an denen diese SFP-Module hingen, waren intern tot, durchgebrannt, während die Optiken darin völlig gesund waren.
Sobald die lokale Konfiguration also stimmt: ein bekanntermaßen gutes Modul in einen bekanntermaßen guten Port auf der anderen Seite stecken, bevor man irgendetwas über die eigene Box schlussfolgert.