FortiGate 101F gedeelde RJ45/SFP-poorten 17-20 vallen uit na een FortiOS-upgrade
We draaien een paar FortiGate 101F's voor een kantoor van 40 man, niets exotisch. port17 draagt een SFP-uplink naar de core-switch, port19 is een RJ45-verbinding naar de serverruimte, beide binnen het gedeelde RJ45/SFP-blok (poorten 17-20). In het onderhoudsvenster vorige maand hebben we het paar naar FortiOS 7.4.4 gebracht, en sindsdien is dat blok dood.
- FortiGate 101F, en een FortiGate 100F op de tweede locatie die zich hetzelfde gedraagt
- port17: 1G SFP-module naar een gestapelde access-switch
- port19: RJ45 naar een 1G-switchpoort
- FortiOS 7.4.4, geüpgraded vanaf een 7.2-build
Poorten 1-16 zijn in orde, alleen de gedeelde poorten gingen plat. Wat me opviel is dat de snelheidsopties in de GUI er niet meer uitzien zoals vóór de upgrade, en de running config heeft nu dit:
config system interface
edit "port17"
set speed 1000full
next
endNiemand hier heeft dat getypt. Elke poort op deze box stond vóór de upgrade op auto.
Tot nu toe geprobeerd:
- de SFP opnieuw geplaatst en verwisseld voor een bekend goede, geen verandering
- de andere kant naar een andere switchpoort verplaatst
- koude herstart van de firewall, config blijft zoals hierboven
Is het te verwachten dat het gedeelde RJ45/SFP-blok op de 100F/101F auto verliest tijdens een upgrade, of is onze config ergens verminkt geraakt? En wat is de juiste manier om het terug te zetten?
Comments 5
Jouw config is door niemand op kantoor verminkt, de upgrade heeft het gedaan. Op de 100F en 101F drukt de upgrade stilletjes een vaste 1000full op de gedeelde RJ45/SFP-poorten waar voorheen auto stond, zonder te vragen of de peer die snelheid aankan. Afhankelijk van de andere kant krijg je dan een poort die op de verkeerde snelheid linkt, of eentje die helemaal nooit linkt, en dat is precies waarom 17-20 dood zijn terwijl de dedicated poorten ongemoeid blijven. Fortinet heeft het geboekstaafd als bekend probleem 989629, beschreven in de release notes van 7.2.9; getroffen zijn de trajecten v7.2.8 en later, v7.4.2 en later, en v7.6.0 en later.
Zet de snelheid handmatig terug, per poort:
Op v7.2.8 en op v7.4.2 tot en met v7.4.4 wordt gewoon auto niet aangeboden in de lijst, en dat is precies waarom de GUI er voor jou anders uitziet, dus gebruik daar 1000auto. Op v7.2.9, v7.4.5, v7.6.0 en later is de normale optie terug en wil je:
Herhaal voor port18 tot en met port20 als die in gebruik zijn. En voor het volgende venster: check eerst dat niets in je beheerpad op poorten 17-20 landt, anders komt de box terug met je accesspoort geforceerd op 1000full en moet je naar de locatie rijden om het vanaf de console te repareren.
Van welke build kwam je nu eigenlijk? "een 7.2-build" beslaat een hoop terrein, en wat je moet typen om dit op te lossen verschilt per traject. Het andere dat de moeite van het weten waard is: bieden de andere kanten autonegotiation aan, of staan die zelf ook vast? Een peer die alleen maar autonegotieert blijft niets doen tegen een poort die op een vaste snelheid staat.
Eén ding om uit te zoeken voordat je iets verandert: loopt je beheerpad via een van de poorten 17-20? Zo ja, doe de volgende wijziging dan vanaf de console in plaats van over het netwerk.
Het algemene punt is de moeite waard voor iedereen die hier belandt met een gedeelde poort die zich misdraagt: op de meeste boxen is het paar echt exclusief. NETGEAR noemt het dual personality op de GS716T-200, waar elk van de twee SFP-cages gekoppeld is aan een van de laatste koperpoorten, en maar één helft van dat paar tegelijk actief kan zijn, dus een module erin schuiven zet stilletjes de bijbehorende RJ-45 buiten dienst. Elke poort op dat model is toch al gigabit, dus de optische uplink levert je een kabeltraject, geen bandbreedte.
Zelfde idee op het FortiGate-blok, dus check welke helft van port17 je eigenlijk aan het bekijken bent. Een module in de cage plus een patchkabel in de koperen helft van dezelfde poort is een klassieke eigen doelpunt, en het lijkt vanuit de CLI erg op een snelheidsprobleem.
Andere vendor, zelfde soort pijn. EX4200 met een EX-UM-2X4SFP-uplinkmodule: xe-0/1/0 draaide vrolijk op 10G, xe-0/1/1 kon niet eens aan een VLAN worden toegevoegd en liet geen verkeer door. Beide poorten werkten op 1G, de SFP+ was volledig zichtbaar in show chassis hardware, ik heb modules gewisseld, een reserve-EX-UM-2X4SFP geprobeerd en een fabrieksreset gedaan voordat iemand me vertelde wat die module eigenlijk is.
Er was niets defect. Die module neemt een SFP+ aan in maar twee van zijn cages, de exemplaren genummerd 0 en 2 in hardware; het andere paar draagt een 1G-optiek en niets sneller. Dus de 10G-interfaces waar je op uitkomt zijn xe-0/1/0 plus xe-0/1/2, en xe-0/1/1, degene waar ik tegen aan het vechten was, zou nooit op 10G gaan draaien, wat ik er ook in stopte. De optiek één cage opgeschoven, xe-0/1/2 geconfigureerd, klaar. Lees bij mixed-mode cages wat het blok ondersteunt voordat je iets terugstuurt voor RMA.
Wees voorzichtig met de combo-exclusiviteitshoek, die verklaart dit geval niet. De poorten werkten vóór de upgrade, alleen het gedeelde blok ging daarna kapot, en er staat een speed-regel in de config die niemand heeft getypt. Dat is de herschrijving, geen cage-prioriteit.
De omgekeerde vergissing brandt mensen ook, trouwens. Ik heb ooit een week besteed aan D-Link DES-1210-52-switches met een fiber-uplink naar een OSNOVO NS-SW-8GX2G: linkindicatie op de optische poorten, geen LAN, helemaal geen internet, terwijl dezelfde switches prima werkten wanneer ze over koper aan elkaar hingen, en een firmware-update veranderde niets. De combopoort was dagenlang de hoofdverdachte. De echte fout zat aan de andere kant: de OSNOVO-poorten die die SFP-modules droegen waren intern dood, doorgebrand, terwijl de optiek die erin zat kerngezond was.
Dus zodra de lokale config klopt: zet een bekend goede module in een bekend goede poort aan de andere kant voordat je iets concludeert over je eigen box.