FlexPod Nexus 500 im vPC-Verhalten bei Unterbrechungen

Einführung

In diesem Dokument wird das Verhalten des Netzwerks als Reaktion auf verschiedene Unterbrechungen beschrieben, wobei der Schwerpunkt auf Virtual Port-Channel (vPC) liegt. 

Eine typische Unterbrechung wäre ein Neuladen, ein Link-Verlust oder ein Verbindungsverlust. 

Ziel dieses Dokuments ist es, Paketverluste in gängigen Szenarien aufzuzeigen. 

Topologie

Während der Tests, sofern nicht anders angegeben, wird die folgende Topologie verwendet. 

Grüne und blaue Linien weisen auf einen vPC-Port-Channel von jedem Fabric Interconnect zu beiden Nexus-Switches hin. 

Nicht aufgeführt ist das Out-of-Band-Managementnetzwerk. 

Dies ist eine vereinfachte Topologie, die in FlexPod-Bereitstellungen häufig empfohlen wird, wie z. B. in:

http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/UCS_CVDs/flexpod_esxi51_ucsm2.html

Verwendete Komponenten

Zwei Nexus 5548P-Switches

Zwei Unified Computing System (UCS) 6120 Fabric Interconnect mit 2.2(4b)-Software.

Ein 5108 UCS-Chassis. 

Zwei B200M3 Blades mit VIC 1240-Adapter und 2.2(4)-Software. 

Um Verbindungstests durchzuführen und zu überprüfen, wurden zwei Blades installiert, und das RedHat Enterprise Linux 7.1 Betriebssystem ist installiert. 

Konfiguration.  

Sowohl die vPC- als auch die Port-Channel-Konfiguration werden standardmäßig verwendet. 

feature vpc

vpc domain 75
 role priority 3000
 peer-keepalive destination 10.48.43.79 source 10.48.43.78
 delay restore 150
 peer-gateway

interface port-channel1
 description vPC Peer-Link
 switchport mode trunk
 spanning-tree port type network
 vpc peer-link

Beispiel für vPC, der zum UCS Fabric Interconnect (FI) führt, in diesem Fall bdsol-6120-05 - A

interface port-channel101
 description bdsol-6120-05-A
 switchport mode trunk
 spanning-tree port type edge trunk
 vpc 101

Tests

Der folgende Test wird durchgeführt. 

- Verlust von Datenverbindungen. 

- Disruptive Aktualisierung 

- In-Service-Software-Upgrade (ISSU) 

- Peer-Keepalive-Link - mgmt0-Schnittstelle bei dieser Topologie/Konfiguration.

- Verlust des Peer-Port-Channels - Port-Channel 1 in dieser Konfiguration. 

- Deaktivieren der vPC-Funktion

Grundlegender Datenverkehrsfluss. 

Eine einzelne iperf3-Sitzung wird verwendet, um 6,5 Gigabit pro Sekunde des Test-TCP-Datenverkehrs zu generieren, um den Frame-Verlust während Übergängen zu überprüfen.

RedHat2 ist an Fabric Interconnect B fixiert, während RedHat1 an Fabric Interconnect A fixiert ist. Dies führt zu Datenverkehr, der die Switching-Komponente passieren muss. 

Iperf3-Parameter:

• Server: iperf3 -s -i 1
• Client iperf3 -c 10.37.9.131 -t 0 -i 1 -w 1M -V

Die oben genannten Parameter wurden ausgewählt, um eine hohe Datenverkehrsrate und einen leicht erkennbaren Paketverlust zu ermöglichen. 

Das TCP-Fenster wird so gestempelt, dass Daten-Bursts vermieden werden, die iperf kennt. Wenn Iperf ungestempelt ausgeführt werden kann, kann es - abhängig von der QoS-Konfiguration - zu gelegentlichen Eintrittspuffern auf dem Pfad kommen. Die obigen Parameter ermöglichen eine kontinuierliche Übertragungsrate von 6-7 Gbit/s ohne Frame-Verlust.

Zur Überprüfung können wir die kumulierte Datenverkehrsrate an Schnittstellen überprüfen.

bdsol-n5548-07# show interface ethernet 1/1-2 | i rate
 30 seconds input rate 5612504 bits/sec, 9473 packets/sec
 30 seconds output rate 7037817832 bits/sec, 578016 packets/sec
  input rate 5.60 Mbps, 9.38 Kpps; output rate 7.01 Gbps, 576.10 Kpps
 30 seconds input rate 7037805336 bits/sec, 578001 packets/sec
 30 seconds output rate 5626064 bits/sec, 9489 packets/sec
  input rate 7.01 Gbps, 575.71 Kpps; output rate 6.56 Mbps, 9.79 Kpps

Die obige Ausgabe zeigt 7 Gbit/s Datenverkehr, der über Ethernet 1/2 der Schnittstelle eingeht und über Ethernet 1/1 der Schnittstelle verbleibt.

Datenverbindungsverlust

Dieser Test soll das Verhalten von Daten testen, wenn eine Verbindung, die Teil von vPC ist, geschlossen wird. 

In diesem Beispiel wird Ethernet 1/1, die Ausgabeschnittstelle für Datenverkehr, über die Befehlszeile deaktiviert. 

bdsol-n5548-07# conf t
Enter configuration commands, one per line. End with CNTL/Z.
bdsol-n5548-07(config)# int et1/1
bdsol-n5548-07(config-if)# shut

In diesem Fall ging nur ein einziges Paket verloren, bei einer Flut von 6,5 Gbit/s Stream. 

Der Datenverkehr wird fast unmittelbar auf die verbleibenden Verbindungen im Port-Channel des UCS aufgeteilt, in diesem Fall unter Verwendung des Ethernet 1/8-Ports des UCS FI B (der einzige verbleibende Port) bis zum Nexus 5548 B. Von dort wird er mithilfe von Ethernet 1/1 an UCS FI A übertragen.

bdsol-n5548-08# show interface ethernet 1/1-2 | i rate
 30 seconds input rate 5575896 bits/sec, 9413 packets/sec
 30 seconds output rate 6995947064 bits/sec, 574567 packets/sec
  input rate 2.21 Mbps, 3.70 Kpps; output rate 2.78 Gbps, 227.99 Kpps
 30 seconds input rate 6995940736 bits/sec, 574562 packets/sec
 30 seconds output rate 5581920 bits/sec, 9418 packets/sec
  input rate 2.78 Gbps, 227.99 Kpps; output rate 2.22 Mbps, 3.71 Kpps 

Disruptives Upgrade oder Neuladen 

  

Eine kombinierte Unterbrechung der Daten- und Kontrollebene kann durch eine unterbrechungsfreie Aktualisierung des bdsol-n5548-07 (primäres vPC) emuliert werden.

Datenverkehrsverluste sind zu erwarten.

Funktionell entspricht dieser Test dem erneuten Laden eines vPC-Peers.

bdsol-n5548-07# install all kickstart bootflash:n5000-uk9-kickstart.7.1.0.N1.1a.bin system bootflash:n5000-uk9.7.1.0.N1.1a.bin
(...)

Compatibility check is done:
Module bootable Impact Install-type Reason
------ -------- -------------- ------------ ------
 1 yes disruptive reset Incompatible image

(...)

Switch will be reloaded for disruptive upgrade.
Do you want to continue with the installation (y/n)? [n] y

Install is in progress, please wait.

Performing runtime checks.
[####################] 100% -- SUCCESS

Setting boot variables.
[####################] 100% -- SUCCESS

Performing configuration copy.
[####################] 100% -- SUCCESS

Finishing the upgrade, switch will reboot in 10 seconds.

Nach 10 Sekunden tritt der Paketverlust auf. 

Während dieser Zeit gehen nur 55 Pakete verloren (außerhalb des Streams von 6,6 Gbit/s).

Wenn das iperf3 sofort neu gestartet wurde, kann der Operator überprüfen, ob der Datenverkehr tatsächlich auf bdsol-n5548-08 umgestellt wurde. 

bdsol-n5548-08# show interface ethernet 1/1-2 | i rate
 30 seconds input rate 5601392 bits/sec, 9455 packets/sec
 30 seconds output rate 7015307760 bits/sec, 576159 packets/sec
  input rate 2.25 Mbps, 3.77 Kpps; output rate 2.81 Gbps, 231.14 Kpps
 30 seconds input rate 7015303696 bits/sec, 576152 packets/sec
 30 seconds output rate 5605280 bits/sec, 9462 packets/sec
  input rate 2.81 Gbps, 231.14 Kpps; output rate 2.25 Mbps, 3.77 Kpps

Die Datenverkehrsrate wird unter 6 Gbit/s angezeigt, da der Zähler über einen Zeitraum von 30 Sekunden gemittelt wird. 

vPC-Peer-Verbindung wird unterbrochen 

In diesem Beispiel wird die vPC-Peer-Verbindung unterbrochen, was durch eine Konfigurationsänderung ausgelöst wird. 

Zu diesem Zeitpunkt wird der Datenverkehr von bdsol-n5548-07 verarbeitet, wobei vPC sekundär betrieben wird. 

Die Abfolge von Ereignissen. 

Port-Channel 1 fällt aus. 

10. Juli 2015 15:00:25 bdsol-n5548-07 %ETHPORT-5-IF_DOWN_CFG_CHANGE: Interface port-channel1 is down (Konfigurationsänderung)

Da bdsol-n5548-07 als sekundär agiert, werden seine vPCs ausgesetzt, da keine Loopless-Topologie gewährleistet werden kann:

2015 Jul 10 15:00:28 bdsol-n5548-07 %VPC-2-VPC_SUSP_ALL_VPC: Peer-link going down, suspending all vPCs on secondary
2015 Jul 10 15:00:28 bdsol-n5548-07 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface port-channel928 is down (Initializing)
2015 Jul 10 15:00:28 bdsol-n5548-07 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface port-channel102 is down (Initializing)
2015 Jul 10 15:00:28 bdsol-n5548-07 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface port-channel101 is down (Initializing)

Während dieser Zeit verlor iperf3 einen Teil des Datenverkehrs - 90 Pakete. 

Aber konnte sich ziemlich schnell erholen. 

Da vPCs auf bdsol-n5548-07 ausgesetzt werden, wird der gesamte Datenverkehr von bdsol-n5548-08 verarbeitet 

bdsol-n5548-08# show int ethernet 1/1-2 | i rate
 30 seconds input rate 5623248 bits/sec, 9489 packets/sec
 30 seconds output rate 7036030160 bits/sec, 577861 packets/sec
  input rate 2.83 Mbps, 4.74 Kpps; output rate 3.54 Gbps, 290.64 Kpps
 30 seconds input rate 7036025712 bits/sec, 577854 packets/sec
 30 seconds output rate 5627216 bits/sec, 9498 packets/sec
  input rate 3.54 Gbps, 290.64 Kpps; output rate 2.83 Mbps, 4.75 Kpps

Auch hier zeigt die Rate nicht sofort 6,5 Gigabit pro Sekunde an, da der Lastdurchschnitt berechnet wird.

Wiederherstellung von vPC-Verbindung unterbrochen. 

Wenn die vPC-Peer-Verbindung wieder aktiv wird, kann der Datenverkehr zwischen den Verbindungen neu ausgeglichen werden, und aufgrund der Topologieänderung ist ein kurzzeitiger Paketverlust zu erwarten. 

In diesem Übungstest ist 1 Paket verloren gegangen.

In-Service-Software-Upgrade (ISSU)

Bei diesem Test wurde ein ISSU-Upgrade durchgeführt, um die Unterbrechung des Datenverkehrs zu überprüfen.

Die vPC-Rollen während dieses Tests sind wie folgt:
bdsol-n5548-07 - primär

bdsol-n5548-08 - sekundär.

Zur Durchführung eines ISSU müssen definierte Kriterien erfüllt sein.

Um Informationen zu Befehlen zu finden, die zur Überprüfung dieser Kriterien und zur Durchführung eines ISSU verwendet wurden, wurde folgender Leitfaden verwendet:

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5500/sw/upgrade/705_N1_1/n5500_upgrade_downgrade_700.html#pgfId-727913.

Nach dem ersten Ausführen eines ISSU auf dem primären und danach auf dem sekundären vPC-Peer wurden keine Pakete verloren.

Dies liegt daran, dass ISSU alle Datenebenenfunktionen unterbrechungsfrei bereitstellt und nur den Datenverkehr auf Kontrollebene beeinträchtigt.

Bekannte Probleme mit ISSU

Layer-3-Funktionen und -Lizenzen 

Während des ISSU-Tests mussten eine Reihe von Problemen behoben werden. Die Meldung "show install all impact.." gibt möglicherweise Ausgaben an, für die ISSU mit der folgenden Erklärung nicht ausgeführt werden kann: "Unterbrechungsfreie Installation wird nicht unterstützt, wenn L3 aktiviert wurde." In der Testumgebung war dies darauf zurückzuführen, dass LAN_BASE_SERVICES_PKG in der installierten Lizenzdatei verwendet wurde.

LAN_BASE_SERVICES_PKG verfügt über L3-Funktionalität. Um das ISSU auszuführen, muss dieses Paket nicht verwendet werden und die Lizenzdatei muss mithilfe des Befehls "clear license LICENSEFILE" vom Gerät gelöscht werden. Möglicherweise wird die Lizenzdatei derzeit vom Gerät verwendet. Um eine solche Lizenzdatei zu löschen, ist es wichtig zu überprüfen, welche Pakete in Gebrauch sind, indem Sie die "Lizenznutzung anzeigen" verwenden und die Funktionen dieser Pakete deaktivieren.

Nicht-Edge-STP-Ports

Während der Tests war es außerdem erforderlich, den Northbound-Port-Channel herunterzufahren, da er die Prüfung "show spanning-tree issu impact" (Spanning-Tree-Auswirkungen anzeigen), Kriterium 3, nicht bestanden hat. Dies hätte zu einem unterbrechungsfreien Upgrade geführt. Dieser Northbound-Port-Channel wurde im Befehl "show spanning-tree vlan 1" nicht als vPC-Edge aufgeführt.

Peer-Keepalive-Link fehlt

Nach dem Verlust der mgmt0-Verbindung mit dem Peer-Keepalive wurde keine Unterbrechung des Datenverkehrs aufgezeichnet. In dieser Topologie wird die Management-Schnittstelle (mgmt0) als Keepalive-Verbindung verwendet, wodurch der während des Tests generierte Datenverkehr nicht beeinträchtigt wird.

Die Geräte bemerken, dass die mgmt0-Schnittstelle ausgefallen ist und Peer-Keepalives fehlschlagen. Da die Peer-Verbindung jedoch aktiv ist, kann die Kommunikation am Datenplatz fortgesetzt werden. 

2015 Jul 14 12:11:28 bdsol-n5548-07 %IM-5-IM_INTF_STATE: mgmt0 is DOWN in vdc 1
2015 Jul 14 12:11:32 bdsol-n5548-07 %VPC-2-PEER_KEEP_ALIVE_RECV_FAIL: In domain 75, VPC peer keep-alive receive has failed
2015 Jul 14 12:12:07 bdsol-n5548-07 %IM-5-IM_INTF_STATE: mgmt0 is UP in vdc 1

Deaktivieren der vPC-Funktion

Dieser Test beschreibt, was geschieht, wenn vPC auf einem der Switches während der Live-Datenübertragung deaktiviert wird.

Die VPC-Funktion kann mit dem folgenden Befehl im globalen Konfigurationsmodus deaktiviert werden:

bdsol-n5548-07(config)# no feature vpc

Die Deaktivierung der vPC-Funktion auf dem primären oder sekundären vPC-Peer führt zu einem sofortigen Verlust der Datenverbindung. Dies liegt an der Peer-basierten Natur von vPC. Sobald die Funktion deaktiviert ist, wird die Funktion aller vPC-Funktionen auf dem Switch beendet, die Peer-Verbindung wird unterbrochen, der vPC-Keepalive-Status wird unterbrochen und der Port-Channel 101 der Testumgebung wird deaktiviert. Dies wird an der Ausgabe von show vPC des Peer-Switches deutlich, bei dem die vPC-Funktion noch aktiviert ist.

bdsol-n5548-07# show vpc
Legend:
                (*) - local vPC is down, forwarding via vPC peer-link

vPC domain id                     : 75
Peer status                       : peer link is down
vPC keep-alive status             : Suspended (Destination IP not reachable)
...

vPC status
----------------------------------------------------------------------------
id Port Status Consistency Reason Active vlans
------ ----------- ------ ----------- -------------------------- -----------
101 Po101 down success success -

Die Unterbrechung des Datenverkehrs ist wie zuvor nur von kurzer Dauer. 

Unter den oben genannten Testbedingungen gingen 50-80 Pakete aus einer einzelnen Sitzung verloren.  

Durch das Entfernen des Befehls "feature vpc" wurde auch die vPC-Konfiguration aus Port-Channels entfernt.

Diese Konfiguration muss gelesen werden. 

Schlussfolgerung

Die vPC-Funktion soll durch die Aufteilung des Datenverkehrs in einem Port-Channel auf mehrere Geräte für eine höhere Ausfallsicherheit sorgen. 

Diese einfache Idee erfordert komplizierte Kontrollebenen-Implementierungen. 

Die obigen Tests sollten Störungen sowohl auf der Kontroll- als auch der Datenebene aufzeigen, die während des Lebenszyklus der Funktion auftreten können. 

Wie erwartet wurden Unterbrechungen auf der Datenebene fast sofort erkannt und behoben - bei Tests gingen einzelne Pakete verloren. 

Die getesteten Unterbrechungen auf der Kontrollebene zeigen, dass vPC selbst bei Beeinträchtigung der Kontrollebene eine Konvergenzzeit von weniger als einer Sekunde aufrecht erhält. 

Der am häufigsten durchgeführte Test - das Herunterfahren der vPC-Peer-Verbindung - kombiniert potenziell den Ausfall auf Daten- und Kontrollebene. Dennoch wurde eine schnelle Konvergenzzeit nachgewiesen.