Informationen zum vPC-Auswahlprozess

Einleitung

In diesem Dokument wird der Rollenauswahlprozess für Virtual PortChannel (vPC) auf Switches der Nexus-Serie beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• vPC auf Switches der Nexus-Serie
• Spanning Tree Protocol (STP)

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf der Switch-Plattform der Nexus Serie 9000.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Virtual PortChannel-Technologie 

Mit Virtual PortChannels (vPCs) können Verbindungen, die physisch mit zwei verschiedenen Cisco Switches verbunden sind, für ein drittes Gerät als ein PortChannel erscheinen. Beim dritten Gerät kann es sich um einen Switch, einen Server oder ein anderes Netzwerkgerät handeln, das IEEE 802.3ad PortChannels unterstützt. vPC ermöglicht auch die Erstellung von Layer-2-PortChannels, die sich über zwei Switches erstrecken. vPC wird derzeit auf Plattformen der Cisco Nexus Serien 9000, 7000, 5000 und 3000 implementiert (mit oder ohne Cisco Nexus Fabric Extender der Serie 2000).

Hinweis: Cisco NX-OS Software-vPCs und Cisco Catalyst Virtual Switching Systems (VSS) basieren auf ähnlichen Technologien. Für die Cisco EtherChannel-Technologie bezieht sich der Begriff Multi-Chassis EtherChannel (MCEC) auswechselbar auf beide Technologien.

vPC-Rolle

Obwohl beide vPC-Switches für ein Downstream-Gerät als ein einzelner Switch erscheinen, verfügen zwei vPC-Switches untereinander über klar definierte vPC-Rollen: als primärer vPC und als sekundärer vPC.

vPC-Rollen sind nicht präemptiv, d. h., ein Gerät kann als primäres vPC-Gerät konfiguriert werden, es kann jedoch als sekundäres vPC-Peer-Gerät betrieben werden. Dies kann in diesem Szenario eintreten:

1. Wenn das ursprüngliche primäre Gerät ausfällt, wird das sekundäre vPC-Gerät zum neuen primären Gerät.
2. Wenn das System sich selbst wiederherstellt, ist das zuvor primäre Gerät jetzt das sekundäre Gerät und umgekehrt. 

Die vPC-Rolle definiert, welche der beiden vPC-Peers BPDUs (Bridge Protocol Data Units) verarbeitet und auf ARP-Anfragen (Address Resolution Protocol) reagiert. Die vPC-Rolle definiert außerdem eine Reihe von Aktionen, die von primären und sekundären vPCs bei einem Ausfall der vPC-Peer-Verbindung ausgeführt werden. 

vPC-Rollenpriorität 

Sie können die Rollenpriorität im vPC-Domänenmodus auch verwenden, um den vPC-Auswahlprozess zu beeinflussen. Der Wertebereich liegt zwischen 1 und 65636, und der Standardwert ist 32667. Ein niedrigerer Wert bedeutet, dass dieser Switch eine bessere Chance hat, der primäre vPC zu werden.

Wenn Sie die Priorität der vPC-Peers ändern, kann dies dazu führen, dass die Netzwerkschnittstellen inaktiv werden. Wenn Sie die Rollenpriorität erneut konfigurieren möchten, um ein vPC-Gerät zum primären Gerät zu machen, konfigurieren Sie die Rollenpriorität sowohl auf dem primären vPC-Gerät mit einem niedrigeren Prioritätswert als auch auf dem sekundären vPC-Gerät mit dem höheren Wert. Fahren Sie anschließend den vPC-Peer-Link auf beiden Geräten herunter, und geben Sie den Befehl shutdown ein. Aktivieren Sie anschließend den Port-Channel auf beiden Geräten erneut, und geben Sie den Befehl no shutdown ein.

Hitless vPC - Rollenänderung

Die Funktion zur Änderung der vPC-Rolle bei laufendem Betrieb bietet ein Framework zum Umschalten von vPC-Rollen zwischen vPC-Peers ohne Auswirkungen auf den Datenverkehrsfluss. Der vPC-Rollenaustausch erfolgt basierend auf dem Rollenprioritätswert des Geräts in der vPC-Domäne. Ein vPC-Peer-Gerät mit niedrigerer Rollenpriorität wird als primäres vPC-Gerät ausgewählt, wenn der Befehl vpc role preempt ausgeführt wird.

Weitere Informationen finden Sie unter Anwendungsfallszenario für Änderung der vPC-Rolle bei laufendem Betrieb.

vPC-Systemverhalten bei Ausfall eines vPC-Peer-Links

Wenn die vPC-Peer-Verbindung ausfällt und die vPC-Peer-Keepalive-Verbindung weiterhin aktiv ist, führt das sekundäre vPC-Peer-Gerät folgende Operationen durch:

1. Hält seine vPC-Member-Ports an.
2. Fährt die mit dem vPC-VLAN verbundene SVI herunter.

Durch dieses vPC-Schutzverhalten wird der gesamte Süd-Nord-Datenverkehr an das primäre vPC-Gerät umgeleitet. 

Primäres Sticky Bit für vPC

Das primäre Sticky-Bit von vPC ist ein programmierter Schutzmechanismus, der eingeführt wurde, um unnötige Rollenänderungen zu vermeiden (die möglicherweise zu Unterbrechungen im Netzwerk führen würden), wenn der primäre Switch unerwartet neu geladen wird. Das primäre Sticky-Bit von vPC ermöglicht, dass der aktive Switch seine PRIMARY-Rolle behält, wenn ein ausgefallener Switch wieder aktiv wird oder wenn ein isolierter Switch wieder in die vPC-Domäne integriert wird.

Umschalten des primären Sticky-Bits des vPC:

  1. Der Wert für das primäre Sticky Bit von vPC ist in diesem Szenario auf TRUE festgelegt:

• Der aktuelle primäre vPC-Switch wird neu gestartet, und der Switch mit aktiviertem vPC ändert seine Rolle von sekundärem vPC in primäres vPC. Das Sticky-Bit ist nicht festgelegt, wenn sich die Rolle von "vPC Operational Secondary" in "vPC Primary" ändert.
• Ein vPC-fähiger Switch ändert seine Rolle von "Kein Einrichten" in "vPC-Primär", wenn der Timer für die Wiederherstellung (standardmäßig 240 Sek.) abläuft.

  2. Der Wert für das primäre Sticky Bit von vPC ist in den folgenden Szenarien auf FALSE festgelegt:

• Ein vPC-fähiger Switch wird neu gestartet (Sticky Bit ist standardmäßig auf FALSE gesetzt).
• Die vPC-Rollenpriorität wird geändert oder neu eingegeben.

Das primäre vPC Sticky-Bit wird unter der Struktur der vPC Manager-Softwarekomponenten gemeldet und kann mit dem Befehl "NX-OS Exec-Modus" überprüft werden.

Campus_N7K2-VPC# show system internal vpcm info global | include ignore-case sticky
        Sticky Primary: TRUE
Campus_N7K2-VPC#

Verzögerung der vPC-Wiederherstellung

Nachdem ein vPC-Peer-Gerät neu geladen und wieder aktiviert wurde, benötigt das Routing-Protokoll Zeit für die Neukonvergierung. Die wiederherstellenden vPCs können einen Blackhole-Routing-Datenverkehr vom Access Switch zum Aggregation/Core bis zur Wiederherstellung der Layer-3-Uplink-Konnektivität ermöglichen.

Die Funktion "vPC Delay Restore" verzögert die Aktivierung der vPC-Komponente auf dem wiederherzustellenden vPC-Peer. Mit "vPC Delay Restore" können Layer-3-Routing-Protokolle konvergiert werden, bevor sie Datenverkehr auf der vPC-Komponente zulassen. Dies führt zu einer sanfteren Wiederherstellung und einem Paketverlust von Null während der Wiederherstellungsphase (der Datenverkehr wird weiterhin auf dem aktiven vPC-Peer-Gerät umgeleitet). Diese Funktion ist standardmäßig mit einem Standard-Timer für die vPC-Wiederherstellung von 30 Sekunden aktiviert. Der Timer kann auf eine bestimmte Layer-3-Konvergenzbasislinie von 1 bis 3600 Sekunden eingestellt werden.

VLAN für die verzögerte vPC-Wiederherstellung

Um das Hochfahren der VLAN-Schnittstellen auf dem wiederhergestellten vPC-Peer-Gerät zu verzögern, verwenden Sie die Option interfaces-vlan des Befehls delay restore. Diese Funktion ist standardmäßig mit einem Standard-Timer für die vPC-Wiederherstellung von 10 Sekunden aktiviert.

Verzögerung der vPC-Wiederherstellung bei Verwendung der SVI-Einrichtung mit Skalierung der 4000 SVI

Ein neuer Befehl delay restore interface-VLAN batch <1-4094> wird eingeführt, um den Pacer so zu konfigurieren, dass die VLAN- oder Bridge-Domain-Schnittstellen in einem Batch von jeweils 200 SVIs hochgefahren werden. Der Befehl delay restore timer des vPC-Verzögerungswiederherstellungs-Timers restore <Timeout value> kann auf einen Wert konfiguriert werden, der größer ist als die Summe aller konfigurierten Batch-Timer. Auf diese Weise wird die vPC-Komponente erst dann aktiviert, wenn alle SVIs vollständig hochgefahren sind, um ein Blackhole-Ereignis für den Datenverkehr zu vermeiden.

Beispiel: 4.000 VLANs, 200 Batches, 15 Sek. Verzögerung  

delay restore > (4000/200)x 15

vPC-Auswahlprozess

In einem vPC-System wird ein vPC-Peer-Gerät als primäres vPC-Gerät und eines als sekundäres vPC-Gerät definiert, basierend auf diesen Parametern und in dieser Reihenfolge

1. vPC Primäres Sticky-Bit auf 0 oder 1 festgelegt.
2. Benutzerdefinierte vPC-Rollenpriorität (die Cisco NX-OS-Software wählt das primäre Gerät mit dem niedrigsten numerischen Wert aus).
3. Wert der System-MAC-Adresse (die Cisco NX-OS-Software wählt das primäre Gerät anhand der niedrigsten MAC-Adresse aus).

Dieses Flussdiagramm (Bild 1) fasst die Schritte zusammen, die beide vPC-Peers während der Auswahl des primären vPC-Switches durchlaufen.

1. Der erste überprüfte Parameter zwischen zwei Geräten während des primären vPC-Auswahlprozesses ist das primäre Sticky Bit für vPC. Wenn das vPC-Peer-Gerät diesen Vergleich gewinnt, wird es unabhängig vom konfigurierten vPC-Rollenprioritätswert oder den System-MAC-Adressen, die beide Peers haben, zum primären vPC.
2. Wenn beide vPC-Peer-Switches über denselben Sticky-Bit-Wert verfügen, wird mit dem nächsten Schritt die benutzerdefinierte vPC-Rollenpriorität verglichen.  
3. Wenn beide vPC-Rollen mit dem gleichen Wert konfiguriert werden, werden die System-MAC-Adressen während des Auswahlprozesses verglichen.

Bild 1

Wie im Bild gezeigt, gewinnt die TRUE-Seite die Wahl und übernimmt die Rolle des vPC-Primäres, wenn für den vPC-Switch das primäre Sticky Bit auf 1 (TRUE-Bedingung) und für den Peer des Switches das Sticky Bit auf 0 (FALSE-Bedingung) festgelegt ist.

vPC Peer 1 Sticky Bit auf 1 gesetzt	vPC Peer 2 Sticky Bit auf 1 gesetzt	vPC Primär
Falsch (0)	Falsch (0)	Krawatte
Wahr (1)	Falsch (0)	vPC-Peer 1
Falsch (0)	Wahr (1)	vPC-Peer 2
Wahr (1)	Wahr (1)	Krawatte

vPC-Wiederherstellungsszenario

Es ist wichtig, den vPC-Auswahlprozess zu verstehen, und er kann nicht unterschätzt werden, insbesondere in vPC-Wiederherstellungsszenarien.

Abbildung 2 zeigt eine typische vPC-Konfiguration, Nexus-01 ist die primäre und Nexus-02 die sekundäre vPC. Beide haben ihre Sticky Bits standardmäßig auf FALSE zurückgesetzt.

  

 Bild 2

Wie in dieser Abbildung gezeigt, tritt beim Nexus 01 jetzt ein Stromausfall auf, und er wurde vom Netzwerk isoliert. Nexus-02 hat sich selbst zu vPC Primary hochgestuft und vPC Sticky Bit auf TRUE gesetzt. 

Nexus 02 wird jetzt "Operational Primary" (Operationelles Primär) und der "Sticky Bit" (Verbindungspunkt) ist jetzt TRUE (WAHR).

                        

 Bild 3

Wie in diesem Bild gezeigt, übernimmt Nexus-01, wenn der Nexus-01 nach der Wiederherstellung des Stromausfalls wieder online geht, die Rolle "Operational PRIMARY" unabhängig von der Rollenpriorität (da er über ein WAHRES Haftbit verfügt), und Nexus-01 übernimmt die SEKUNDÄRE Rolle, wenn er online geht. Nur Nexus-01 beginnt mit der vPC-Initialisierung, während Nexus-02 PRIMÄR bleibt und Datenverkehr wie gewohnt weiterleitet. Daher treten keine Netzwerkausfälle auf.

Dem vPC-Initialisierungsprozess auf Nexus-01, dem derzeit betriebsbereiten sekundären vPC-Gerät, sind zwei Timer zugeordnet:

• delay restore SVI (standardmäßig 10 Sekunden) 
• delay restore (standardmäßig 30 Sekunden)

Daher kann auf Nexus 01 mit einer Wiederherstellungszeit von 40 Sekunden gerechnet werden, nachdem Nexus 01 wieder als sekundäres vPC-Gerät in das Netzwerk eingeführt wurde. Da Nexus-02 jedoch die primäre Rolle übernimmt, durchläuft der gesamte Datenverkehr jetzt, wie oben erwähnt, Nexus-01, und es treten keine Netzwerkausfälle auf. 

 Bild 4

Beispiel für einen Netzwerkausfall, der auf ein falsch eingestelltes Sticky Bit zurückzuführen ist

Der Netzwerkausfall wird durch ein FALSCH festgelegtes Sticky-Bit verursacht, wenn ein isolierter Switch (Nexus-02) wieder in die VPC-Domäne eingeführt wird.

Ein Netzwerkausfall kann jedoch auftreten, nachdem ein isolierter Switch wieder in die VPC-Domäne eingeführt wurde, wenn die Sticky-Bits auf beiden Nexus-Switches nicht richtig festgelegt wurden. Bevor ein isolierter Switch wieder in die VPC-Domäne eingeführt wird, muss sein Sticky Bit auf FALSE gesetzt werden. (Verfahren zum Ersetzen eines N7K-Gehäuses finden Sie unter Verfahren für den Austausch von Nexus 7000-Chassis.)

Wie in Abbildung 5 gezeigt, ist Nexus-01 mit einer höheren VPC-Rollenpriorität konfiguriert als Nexus-02, und für Nexus-02 ist das Sticky Bit auf TRUE festgelegt. Die Verbindungen E1/1 und E1/2 des Nexus-01 befinden sich im Weiterleitungsstatus, während E1/1 und E1/2 sich im Abschaltstatus befinden. 

 Bild 5

Wenn PKA und Peer-Link wiederhergestellt werden, übernimmt Nexus-02 unabhängig von seiner Rollenpriorität die PRIMARY-Rolle (da es ein TRUE-Sticky-Bit hat), zwingt Nexus-01, SECONDARY zu werden, und der VPC-Initialisierungsprozess beginnt auf Nexus-01. Aus diesem Grund werden die Verbindungen E1/1 und E1/2 des Nexus 01 von VPC unterbrochen und nach Ablauf der Timer für die Relay-Wiederherstellung (standardmäßig 40 Sekunden) online geschaltet.  In diesem Fall kommt es nach der Wiederherstellung von PKA und Peer-Link zu einem Netzwerkausfall von 40 Sekunden, wie in Abbildung 6 dargestellt.

 Bild 6

Hinweis: Wenn ein Nexus wieder in die vPC-Domäne eingeführt wird, müssen Sie sicherstellen, dass es im aktiven vPC-Gerät keine Änderung der vPC-Rolle gibt. Um eine Änderung der vPC-Rolle zu vermeiden, wenn die festen Bit beider Switches auf den gleichen Wert gesetzt werden, muss das aktive vPC-Gerät eine höhere Rollenpriorität aufweisen, damit es seine PRIMÄRE Rolle beibehalten kann. Weitere Informationen zur VPC-Rollenauswahl finden Sie in Abbildung 1 dieses Dokuments.