Wenn in einem Stack der Primary ausfällt übernimmt der bisherige Secondary die Managementaufgaben (wird primary) und ein neuer Secondary wird gewählt.
Im Zuge des wechsels ändern sich auch die MAC-Adressen des Stacks (es wird die des Secondarys übernommen).
Damit passiert folgendes:
- Die Spanning-tree BridgeID ändert sich (ist ja Priority + Mac-Adresse) – Dadurch uU STP Rekalkulationen
- LACPs brechen zusammen (das ist an die MAC-Adresse gebunden)
- Vermutlich ändern sich auch die Mac-Adressen der IP Interfaces (vielleicht hat das Default-Gateway danach eine andere Mac als vorher?!)
- Dadurch kann es auch bei Routingprotokollen zu Problemen kommen
- Kunden rufen mit Pipi in den Augen an.
- Terror und Panik bricht aus, Netzwerktechniker werden auf der Straße gelyncht.
Da ja grade die letzten 2 Punkte kritisch sind (und man die ersten Punkte auch erlegen will):
Bei Alcatel heißt das notwendige Kommando
mac-retention status enable
Dadurch bleibt die Mac-Adresse des Stacks bestehen und im besten Fall passiert (fast) garnichts.
Daher: Man sollte das Kommando auf Stacks immer aktivieren (per default ist es disabled).
Sieht dann so aus:
Stack > show mac-retention status Admin State : Enabled, Trap admin state : Disabled, EEPROM MAC address : e8:e7:32:69:2e:9c, Current MAC address : e8:e7:32:69:2c:fc, MAC address source : Retained, Topology Status : Ring Present
Die EEPROM MAC (des Switches) ist e8:e7:32:69:2e:9c, der Stack hat aber eine andere von früher. (Source = Retained)
Aber alles hat natürlich auch einen Nachteil:
Nimmt man den (ex)Primary raus und baut ihn woanders ein hat man doppelte MAC-Adressen (der ex-Primary und der Stack haben die gleiche) und man hat neue Probleme. wie z.B. verlorenen Traffic.
In einem solchen Fall: Im Wartungsfenster nach Rücksprache auf dem Stack mit „mac-retention release“ die gemerkte MAC freigeben und die des aktuellen Switches übernehmen.
STP/LACP Sachen werden dann auch auftreten, aber in einem geplanten Umfeld.
Laut einem Test eines Users im Alcatelunleashed Forum vermindert sich dadurch die Rekonvergenzzeit (unklar was er genau getestet wurde) von 3 Minuten auf 1 Sekunde.. egal: klingt gut.
Im 6900-VC ist die mac-retention (im Gegensatz zu den R6 Switchen) defaultmäßig enabled.
Bei Cisco gibt es das gleiche (Problem wie Lösung), das Kommando heißt hier
stack-mac persistent timer 0
und zum freigeben
no stack-mac persistent timer
Bei Cisco wichtig: ohne „stack-mac persistent timer 0“ kann man eine ASA-X nicht sauber an zwei Stack-Membern anschliessen, da nach einem fail des primarys die Verbindung (dauerhaft?) gestört wäre