IBM Flex System EN4093 wirft SFP+-Trunk-Ports beim Boot und im Betrieb in ERRDISABLE
Zwei Flex-System-Enclosures, jedes mit einem EN4093R 10Gb Scalable Switch (Option 49Y4270) als Netzwerkmodul. Ports kommen nach einem Chassis-Stromereignis error-disabled zurück, und seltener fallen sie im laufenden Betrieb in denselben Status. Es sind nicht immer dieselben Ports, was die Jagd danach so mühsam macht.
Aufbau:
- IBM Flex System EN4093 10Gb Scalable Switch, Option 49Y4270
- Uplink-Trunk aus vier Ports zum Core, IBM-Optik plus ein später hinzugefügter DAC
- QSFP+-Port aufgebrochen Richtung zweitem Enclosure
- MSTP läuft auf unserer Seite, der Core ist ein anderer Hersteller
Was die Portliste nach einem Boot zeigt:
port 5 ERRDISABLE reason: link flap detect threshold exceeded
port 17 ERRDISABLE reason: mismatched link capabilities
port 19 ERRDISABLE reason: mismatched link capabilitiesVersucht:
- shutdown / no shutdown auf den betroffenen Ports bringt die meisten bis zum nächsten Ereignis zurück
- jede Faser im Trunk gereinigt und neu gesteckt, keine Änderung am Muster
- die Port-Konfiguration am Gegenende verglichen, Geschwindigkeiten stimmen auf dem Papier überein
Was drängt diese Ports tatsächlich in errdisable, und gibt es einen Weg, das bei jedem Boot zu verhindern, statt es jedes Mal von Hand aufzuräumen?
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
Dieser Switch hat sieben dokumentierte Zustände, die einen Port deaktivieren, und sie haben sehr wenig miteinander zu tun:
Deiner ist der vierte, und das ist der, dem die meisten Leute begegnen, weil man ihn sich selbst baut: Modulgeschwindigkeiten oder -typen innerhalb eines Trunks mischen, und der Switch widerspricht. Ein DAC neben drei optischen Modulen reicht schon. Nimm den DAC dort raus und fülle den Slot mit einem Modul, das zu den anderen drei passt.
Für den Port am Flap-Detektor ist das Bouncen weiterhin die dokumentierte Erholung:
Lies danach die Spanning-Tree-Konfiguration an diesem Link zurück und geh Kupfer und Faser von Hand durch. Lass jeder Konfigurationsänderung ein Reload folgen, sonst hört der laufende Status still auf, dem zu entsprechen, was du zu setzen glaubst.
Zwei Dinge, die man nicht erwarten sollte. Zwei dieser sieben Zustände halten den Port auch nach Ablauf des Timeouts unten und wollen eine Hand am Port. Und kein Firmware-Release behebt das - die Linie des Herstellers ist, dass man sich drumherum konfiguriert, identische Module über jedes Trunk-Mitglied plus saubere Faser sind also so weit, wie Prävention reicht.
Zwei verschiedene Gründe im selben Paste, da würde ich anfangen. Kommt ein gegebener Port immer aus demselben Grund disabled zurück, oder löst einer, der diesen Boot wegen Capabilities gefallen ist, beim nächsten den Flap-Detektor aus? Ein Grund, der pro Port konstant bleibt, und einer, der wandert, sind zwei getrennte Untersuchungen, und nur eine davon endet damit, dass du Hardware kaufst.
Die zweite Sache, die es zu klären lohnt, ist, was der Core für Spanning Tree fährt. Ihr seid auf MSTP; wenn die Gegenseite Cisco-artige PVST-BPDUs auf diese Uplinks legt, hat dieser Switch einen Schutzmechanismus, der genau darauf reagiert und den Port runternimmt, und von außen sieht das aus wie der Fehler, dem ihr schon hinterherjagt. Könnt ihr sagen, ob sich einer der Ausfälle mit einer Topologieänderung am Core deckt statt mit euren eigenen Boots?
Pro Port ist es konsistent, über die Box hinweg nicht. Die Trunk-Mitglieder, die fallen, kommen immer mit mismatched link capabilities zurück, und der Access-Port auf 5 löst immer nur den Flap-Detektor aus, in keinem Intervall, in dem ich ein Muster finde. Sieht also tatsächlich nach zwei Fehlern in derselben Jacke aus.
Spanning Tree auf der Gegenseite kann ich noch nicht beantworten - der Core gehört einem anderen Team, und ich habe sie gefragt, was sie auf diesen Uplinks tatsächlich aussenden. Bisher verknüpft nichts in unserem Log einen Ausfall dort mit einer Topologieänderung, aber ich habe es eher auf Link-Events gelesen als darauf, ich würde es also nicht als ausgeschlossen bezeichnen.
Anderer Hersteller, gleiche Form. Wir hatten eine FortiGate 201F, die an einer FortiSwitch 548D über SFP+ hing, mit Fortinets eigenem DAC dazwischen, und der 10-Gbps-Link wollte einfach nicht oben bleiben - er fiel, was auch immer wir an Speed und Duplex machten, und beide Enden von FortiOS 7.4 auf 7.2.5 zurückzurollen änderte nichts.
Was am Ende hielt, war ein kürzerer Fortinet-DAC mit ausgeschaltetem STP an genau diesem Link, und seitdem ist er oben. Der Teil, der sich mitzunehmen lohnt, ist die Begründung, die danach kam: Je länger die passive Kupferstrecke, desto mehr hat sich das Signal bis zur Ankunft verschlechtert, bei 10G gehört also jeder lange oder grenzwertige DAC auf die Verdachtsliste, egal welches Label draufsteht. Bei drei Optiken und einem DAC in einem errdisable Trunk würde ich mir den Ausreißer genau ansehen.
Eine Sache, bevor du irgendeine Hardware anfasst: Schreib den genauen Takt der Flaps gegen die Log-Zeitstempel auf.
An einem völlig unabhängigen Switch, einem TL-SG3452X, ging jeder bestückte SFP+-Port alle zehn bis fünfzehn Minuten runter und wieder hoch, mit STP-Meldungen im Log bei jedem Flap, und der naheliegende Schluss war schlechte Optik - bis ein herstellereigener TL-SM5220-1M-DAC im exakt selben Rhythmus flappte. Das hat die Optik-Theorie in einem einzigen Test erledigt und stattdessen auf eine Firmware-Regression gedeutet; die einzige funktionierende Antwort dort war, auf dem älteren Build zu bleiben.
Ein regelmäßiges Intervall heißt, dass etwas nach Zeitplan ein Timeout hat. Ein zufälliges heißt, dass etwas Physisches dahintersteckt. Billiger Test, und er erspart dir den Kauf von Modulen, die du nicht brauchst. Es zahlt sich auch aus, das vorherige Firmware-Image aufzuheben, damit ein Downgrade eine Option bleibt.