IBM Flex System EN4093 zet SFP+ trunkpoorten in ERRDISABLE bij opstarten en tijdens bedrijf
Twee Flex System-behuizingen, elk met een EN4093R 10Gb Scalable Switch (optie 49Y4270) als netwerkmodule. Poorten komen na een stroomgebeurtenis van het chassis terug als error-disabled, en vallen minder vaak in dezelfde status terwijl alles gewoon draait. Het zijn niet steeds dezelfde poorten, en dat maakt het zo vermoeiend om na te jagen.
Opstelling:
- IBM Flex System EN4093 10Gb Scalable Switch, optie 49Y4270
- uplink-trunk van vier poorten naar de core, IBM-optics plus één DAC die later is toegevoegd
- QSFP+-poort uitgesplitst naar de tweede behuizing
- MSTP aan onze kant, de core is van een ander merk
Wat de poortenlijst laat zien na een boot:
port 5 ERRDISABLE reason: link flap detect threshold exceeded
port 17 ERRDISABLE reason: mismatched link capabilities
port 19 ERRDISABLE reason: mismatched link capabilitiesGeprobeerd:
- shutdown / no shutdown op de getroffen poorten brengt de meeste terug tot het volgende incident
- elke fiber in de trunk schoongemaakt en opnieuw ingestoken, geen verandering in het patroon
- de poortconfiguratie aan de andere kant vergeleken, snelheden komen op papier overeen
Wat duwt deze poorten nu echt in errdisable, en is er een manier om te voorkomen dat het bij elke boot weer gebeurt in plaats van het steeds handmatig op te ruimen?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
Deze switch kent zeven gedocumenteerde toestanden die een poort uitschakelen, en ze hebben onderling weinig met elkaar te maken:
Bij jou is het de vierde, en dat is degene die de meeste mensen tegenkomen, omdat je hem zelf veroorzaakt: mix module-snelheden of -types binnen één trunk en de switch maakt bezwaar. Eén DAC naast drie optische modules is al genoeg. Haal de DAC weg en vervang hem door een module die bij de andere drie past.
Voor de poort op de flap-detector is bouncen nog steeds het gedocumenteerde herstel:
Lees daarna de spanning tree-configuratie op die link terug en loop het koper en de fiber handmatig na. Laat elke configuratiewijziging volgen door een reload, anders komt de actieve status stilletjes niet meer overeen met wat je denkt te hebben ingesteld.
Twee dingen om niet te verwachten. Twee van die zeven toestanden houden de poort down nadat de timeout is verlopen en willen een handmatige ingreep op de poort. En geen enkele firmware-release lost dit op - het standpunt van de fabrikant is dat je er met configuratie omheen werkt, dus identieke modules op elk trunklid plus schone fiber is het maximum aan preventie.
Ik zou beginnen bij die twee verschillende redenen in dezelfde paste. Komt een gegeven poort altijd terug met dezelfde reden, of struikelt een poort die deze boot over capabilities viel de volgende keer over de flap-detector? Een reden die per poort vast blijft en een reden die verspringt zijn twee aparte onderzoeken, en maar één daarvan eindigt met het kopen van hardware.
Het tweede dat het uitzoeken waard is: wat draait de core voor spanning tree? Jij zit op MSTP; als de andere kant Cisco-achtige PVST-BPDU's op die uplinks zet, heeft deze switch een beschermingsmechanisme dat precies daarop reageert en de poort neerhaalt, en van buitenaf lijkt dat op de storing die je al aan het najagen bent. Kun je zien of een van de drops samenvalt met een topologiewijziging op de core in plaats van met je eigen boots?
Per poort is het consistent, over de hele box niet. De trunkleden die omvallen komen altijd terug met mismatched link capabilities, en de accesspoort op 5 trapt alleen ooit de flap-detector af, op een interval waar ik geen patroon in vind. Het lijkt dus wel degelijk op twee storingen in dezelfde jas.
Spanning tree aan de andere kant kan ik nog niet beantwoorden - de core is van een ander team en ik heb ze gevraagd wat ze daadwerkelijk op die uplinks uitzenden. Tot nu toe koppelt niets in ons log een drop aan een topologiewijziging aan die kant, maar ik las het log op linkgebeurtenissen en niet daarop, dus ik zou het nog niet uitgesloten noemen.
Ander merk, zelfde vorm. Wij hadden een FortiGate 201F aan een FortiSwitch 548D hangen op SFP+ met Fortinet's eigen DAC ertussen, en de 10Gbps-link bleef gewoon niet staan - hij viel weg wat we ook deden met speed en duplex, en beide kanten terugzetten van FortiOS 7.4 naar 7.2.5 veranderde niets.
Wat uiteindelijk hield was een kortere Fortinet-DAC met STP uitgeschakeld op die ene link, en sindsdien staat hij. Wat de moeite waard is om mee te nemen, is de redenering die daarna kwam: hoe langer het passieve kopertraject, hoe meer het signaal al is verzwakt tegen de tijd dat het aankomt, dus bij 10G hoort elke lange of grensgeval-DAC op de verdachtenlijst, ongeacht wat er op het label staat. Met drie optics en één DAC in een errdisable-trunk zou ik goed kijken naar de uitzondering in het rijtje.
Eén ding om te doen voordat je aan hardware komt: zet het exacte ritme van de flaps naast de tijdstempels in het log.
Op een compleet andere switch, een TL-SG3452X, ging elke bezette SFP+-poort elke tien tot vijftien minuten down en weer up, met STP-meldingen in het log bij elke flap, en de voor de hand liggende conclusie was slechte optics - totdat een eigen TL-SM5220-1M-DAC in precies hetzelfde ritme flapte. Dat maakte in één test een einde aan de optics-theorie en wees in plaats daarvan naar een firmware-regressie; het enige dat daar werkte was op de oudere build blijven.
Een regelmatig interval betekent dat er ergens iets op een schema timed out. Een willekeurig interval betekent iets fysieks. Goedkope test, en hij bespaart je de aankoop van modules die je niet nodig hebt. Het loont ook om het vorige firmware-image te bewaren, zodat een downgrade een optie blijft.