FortiGate 101F shared RJ45/SFP ports 17-20 go dark after a FortiOS upgrade
We run a pair of FortiGate 101F units for a 40-person office, nothing exotic. port17 carries an SFP uplink to the core switch, port19 is an RJ45 run to the server room, both of them inside the shared RJ45/SFP block (ports 17-20). In the maintenance window last month we took the pair up to FortiOS 7.4.4, and since then that block is dead.
- FortiGate 101F, and a FortiGate 100F at the second site behaving the same way
- port17: 1G SFP module to a stacked access switch
- port19: RJ45 to a 1G switch port
- FortiOS 7.4.4, upgraded from a 7.2 build
Ports 1-16 are fine, only the shared ones went down. What caught my eye is that the speed options in the GUI no longer look the way they did before the upgrade, and the running config now has this:
config system interface
edit "port17"
set speed 1000full
next
endNobody here typed that. Every port on tihs box was on auto before the upgrade.
Tried so far:
- reseated the SFP and swapped it for a known good one, no change
- moved the far end to a different switch port
- cold reboot of the firewall, config survives as above
Is the shared RJ45/SFP block on the 100F/101F expected to lose auto during an upgrade, or did our config get mangled somewhere? And what is the right way to put it back?
Comments 5
Your config was not mangled by anyone in the office, the upgrade did it. On the 100F and 101F the upgrade quietly sttampps a fixed 1000full onto the shared RJ45/SFP ports where auto used to be, without asking whether the peer can live with that rate. Depending on the far end you then get a port that links at the wrong rate, or one that never links at all, which is exactly why 17-20 are dark while the dedicated ports are untouched. Fortinet has it on the books as known issue 989629, written up in the release notes for 7.2.9; affected trains are v7.2.8 and later, v7.4.2 and later, and v7.6.0 and later.
Put the speed back by hand, per port:
On v7.2.8 and on v7.4.2 through v7.4.4 plain auto is not offered in the list, which is precisely why the GUI looks different to you, so use 1000auto there. On v7.2.9, v7.4.5, v7.6.0 and later the normal option is back and you want:
Repeat for port18 through port20 if they are in use. And for the next window: check first that nothing in your management path lands on ports 17-20, otherwise the box comes back with your access port forced to 1000full and you are driving to site to fix it from the console.
Which build did you actually come from? "a 7.2 build" covers a lot of ground, and what you have to type to fix this differs between trains. The other thing worth knowing is whether the far ends offer autonegotiation or are pinned themselves: a peer that only ever autonegotiates will sit there doing nothing against a port held at a fixed rate.
One thing to sort out before you change anything: does your management path run through any of ports 17-20? If it does, make the next change from the console rather than over the network.
Worth adding the general bit for anyone landing here with a shared port that misbehaves: on most boxes the pair really is exclusive. NETGEAR calls it dual personality on the GS716T-200, where each of the two SFP cages is paired up with one of the final copper ports, and only one half of that pair can be live at a time, so slotting in a module quietly takes the matching RJ-45 out of service. Every port on that model is gigabit anyway, so the optical uplink buys you a cable route, not bandwidth.
Same idea on the FortiGate block, so confirm wihch half of port17 you are actually looking at. A module in the cage plus a patch cord in the copper half of the same port is a classic own goal, and it looks a lot like a speed problem from the CLI.
Different vendor, same flavour of pain. EX4200 with an EX-UM-2X4SFP uplink module: xe-0/1/0 ran 10G happily, xe-0/1/1 could not even be added to a VLAN and passed no traffic. Both ports worked at 1G, the SFP+ was fully visible in show chassis hardware, I swapped modules, tried a spare EX-UM-2X4SFP and did a factory reset before someone told me what the module actually is.
Nothing was defective. That module takes an SFP+ in only two of its cages, the ones numbered 0 and 2 in hardware; the other pair will carry a 1G optic and nothing faster. So the 10G interfaces you end up with are xe-0/1/0 plus xe-0/1/2, and xe-0/1/1, the one I had been fighting, was never going to run at 10G no matter what I plugged into it. Moved the optic one cage over, configured xe-0/1/2, done. With mixed-mode cages, read what the block supports before you RMA anything.
Careful with the combo-exclusivity angle, it does not explain this case. The ports worked before the upgrade, only the shared block broke afterwards, and there is a speed line in the config that nobody typed. That is the rewrite, not cage priority.
The opposite mistake burns people too, though. I once spent a week on D-Link DES-1210-52 switches uplinked over fibre to an OSNOVO NS-SW-8GX2G: link indication on the optical ports, no LAN, no internet at all, while the same switches worked fine chained over copper, and a firmware update changed nothing. The combo port was the prime suspect for days. The real fault was at the far end: the OSNOVO ports carrying those SFP modules were internally dead, burnt out, with the optics sitting in them perfectly healthy.
So once the local config is right, put a known-good module into a known-good port on the other side before you conclude anything about your own box.