Ausfall im Stack: Switchtausch mit fatalen Folgen

Es kam in einem Stack von insgesamt sieben Cisco Switches der 2960X Reihe zu einem Ausfall eines Slaves. Alle sieben Switches sind aus einer Modellreihe und so konfiguriert, dass diese vom ernannten Master Switch in dem Verbund „lernen“. Dieser wird entweder anhand der niedrigsten MAC-Adresse aller Switches im Stack vom System automatisch ausgewählt oder man kann diesen separat mit Prioritäten festlegen. So schön so gut, was ist nun das Problem? – Einfach alten Switch raus und neuen Switch rein. Das dachten wir auch.

Die Konfiguration, VLAN Database und die Softwareversion bekommt der neue Switch automatisch bespielt, sobald sich dieser über die Stackingkabel im Verbund befindet. Wenn es einen Softwareversion Mismatch gibt, wird dieser mit der aktuellen Version des Masters überschrieben. Damit das System sauber arbeiten kann, brauchen alle Switches den selben Softwarestand.

Nachdem das Austauschgerät eingebaut und die Patchkabel wieder aufgesteckt waren, startete dieser wie gewohnt mit dem Bootvorgang und dem POST. Allerdings war es das dann auch schon. Natürlich war klar, dass der Softwarestand des Austauschgerätes nicht der aktuell genutzten Version des Stackings entspricht. Dafür verweilte dieser schon zu lange im Lager. Durch eine Konsolenverbindung konnten wir einen Einblick in den Vorgang erblicken. Doch nun waren alle anderen Switches auch nicht mehr funktionstüchtig und die Konsolenverbindung war auf allen Switches absolut schleppend. Der Delay war utopisch und ganze Zeilen wurden verschluckt oder Passwortaufforderungen fielen in den Timeout.

Aufgefallen ist dann die hohe CPU Auslastung im gesamten Stack. Durch das Kopieren der richtigen Software auf den Austauschswitch ist die CPU Auslastung so in die Höhe geschossen, dass die anderen Switches nicht mehr ordnungsgemäß liefen. Das führte dann zu einem Totalausfall des Stacks. Wir brachen das Prozedere dann ab in dem wir den neuen Switch vom Strom nahmen um die CPU erstmal wieder zu beruhigen. Danach haben wir manuell den Switch auf den benötigten Softwarestand gebracht und konnten diesen dann im Stack in Betrieb nehmen.

Die Funktion, Switches automatisch auf den aktuellen Softwarestand der anderen zu bringen, mag ja ein tolles Feature sein. Bringt allerdings nichts, wenn die CPU fast auf Maximum läuft und einen Totalausfall aller anderen Switches im Stack verursacht. Die Größe der Software ist auch nicht so immens, dass das Kopieren zu viel Zeit in Anspruch nimmt. Mal davon abgesehen, dass die FlexStackPlus Module eine sehr hohe Übertragungsrate bieten. Anscheinend aber nicht für das Kopieren von Software.

Nach der Cisco Dokumentation bezüglich Stacking von 2960-X Switches steht folgendes:

„When two or more 2960-X members are stacked together, the effective stack bandwidth is 80Gpbs because each member is capable of sending and receiving 40Gbps simultaneously.“

 

Entweder muss die Übertragungsrate über die Stackingkabel so schlecht sein oder es wird absichtlich zur Ressourcen Einsparung gedrosselt. Vielleicht sollte seitens Cisco das Konzept nochmal überdacht werden.

 

over & out,

jonsch

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.