- Ein Link zu einem Accessswitch ist aufgefallen:
Kein Problem, solange der Switch an beide Chassis angeschlossen ist. Entweder per Port-Channel oder STP.
INFO:
Bei einem VSS ist das Forwardingverhalten noch genauso wie bei normalen
Cat6500.
Wenn ein Paket über die SUP geroutet werden muss, wird es (per VSL) zur aktiven SUP geschickt. Wenn das Paket auf der Linecard geroutet werden kann, wird das getan. Die SUP programmiert die Linecards wie gehabt (DFCs in Cat6500)
Active SUP failed
Der Ausfall wird durch verschiedene Methoden erkannt:
– VSL Protocol (VSLP)
– GOLD failure event (Online Diagnostics)
– Komplettausfall des VSL (wenn beide Links auf der SUP liegen, z.b.)
In allen Fällen, übernimmt die Standby SUP per SSO Switchover und wird so zur Active SUP.
Während des Umschaltens kommt es zu Traffic Unterbrechungen, da die Pakete auf der Leitung und im failed Chassis bzw. der SUP verloren gehen.
Bei einem Chassis Ausfall müssen alle angebunden Geräte ihren ForwardingPath anpassen, da ein Link zum VSS ausfällt (z.B. Link-Down Event oder PAgP/LACPDUs die ausbleiben)
VSL Link Teil-Ausfall
Ein Ausfall einer Verbindung des VSL Links beeinträchtigt den VSS nicht.
Der Ausfall wird durch das VSL Protocol (VSLP) bemerkt.
Link kann einfach wiederhergestellt werden.
VSL Link Komplettausfall
Wenn der VSL Link komplett ausgefallen ist, kann ein Dual-Active Szenario vorkommen. Um das zu verhindern sollte immer eine Methode der Dual-Active Erkennung konfiguriert sein. (Fast-Hello Link, Enhanced PAgP oder BFD)
Wenn
ein Fast-Hello Link implementiert ist und der VSL Link ausfällt, passiert
folgendes:
– Bei der Erkennung des Dual-Active Szenarios schaltet das Active Chassis in den Recovery Modus und setzt
alle Ports auf SHUT, bis auf den VSL Link (oder andere Ports die so
konfiguriert wurden, z.B. Management Zugriff)
Interfaces die nicht abgeschaltet werden sollen, während Dual-Active Recovery, muss man in der Switch virtual domain angeben:
# switch virtual domain <###>
# dual-active exclude interface gi1/1/1
Wie nun Dual-Active beheben?
Der VSL Link muss wiederhergestellt werden. Mehr nicht. Sobald der VSL Link zwischen beiden Chassis wieder richtig funktioniert, rebootet das Chassis in Recovery Mode und der VSS wird wiederhergestellt.
WICHTIG!
Während sich das Chassis im Recovery Mode befindet, dürfen keine Änderungen an der Config vorgenommen werden. Am Besten nicht mal in „conf t“ Modus gehen, dann wird die Konfig als geändert markiert.
Dann würde das Chassis nicht mehr alleine booten und ihr müsst die Konfiguration von Hand wieder angleichen, damit beide Chassis wieder die identische Konfig haben und das Chassis reloaden. Danach sollte sich der VSS aber auch wieder finden. (Sofern die Konfigs auch gleich sind.)
Um den vorigen Stand wiederherzustellen und das vormals Active Chassis wieder Active zu machen, muss man einen Switchover machen:
# redundancy force-switchover
Das braucht man nicht, wenn Preemption aktiviert ist. Dann wird das Chassis mit der höheren Prio immer Active werden, sobald der Preempt-Timer abgelaufen ist. Diese Konfiguration ist durch Cisco nicht empfohlen!
Wenn ein Fehler die Höhere-Prio-SUP immer wieder zum Ausfall bringt, oder zu hohe Last auf der Höhere-Prio-SUP herrscht (oder oder oder) würde ein Switchover passieren, dadurch übernimmt die Niedrige-Prio-SUP. Schön und gut.
Aber sobald die Höhere-Prio-SUP wieder da ist, übernimmt sie wieder und läuft ggf. wieder in das gleiche Problem. Was einen erneuten Switchover verursacht. Usw. usw. usw.
Daher ist ein Preempt in diesem Fall nicht empfohlen. VSS Aufbauten sollen möglichst stabil laufen.