Informationen zu Verbesserungen bei Virtual Port Channel (vPC)
Inhalt
Einleitung
In diesem Dokument werden häufige Verbesserungen für Virtual Port Channel (vPC) beschrieben, die auf Cisco Nexus-Switches in einer vPC-Domäne konfiguriert wurden.
Voraussetzungen
Anforderungen
Cisco empfiehlt Ihnen, sich mit den Grundlagen rund um Anwendungsfälle, Konfiguration und Implementierung von Virtual Port Channel (vPC) vertraut zu machen. Weitere Informationen zu dieser Funktion finden Sie in den folgenden Dokumenten:
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 9000-Serie, Version 10.3(x)
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 9000-Serie, Version 10.2(x)
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 9000-Serie, Version 10.1(x)
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 9000-Serie, Version 9.3(x)
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 9000-Serie, Version 9.2(x)
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 9000-Serie, Version 7.x
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 7000-Serie, Version 8.x
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 7000-Serie, Version 7.x
- Design- und Konfigurationsleitfaden: Best Practices für Virtual Port Channels (vPC) auf Cisco Nexus Switches der Serie 7000
Verwendete Komponenten
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.
Hintergrundinformationen
Seit der Einführung von Cisco NX-OS auf Cisco Nexus Switches für Rechenzentren hat die vPC-Funktion (Virtual Port Channel) zahlreiche Verbesserungen erfahren, die die Zuverlässigkeit von per vPC verbundenen Geräten in Ausfallszenarien verbessern und das Weiterleitungsverhalten beider vPC-Peer-Switches optimieren. Wenn Sie den Zweck der einzelnen Erweiterungen, die damit bewirkten Verhaltensänderungen und die mit der jeweiligen Erweiterung behobenen Ausfallszenarien kennen, wird besser deutlich, warum und wann eine Erweiterung innerhalb einer vPC-Domäne konfiguriert werden sollte, um die Geschäftsanforderungen bestmöglich zu erfüllen.
Relevante Hardware
Das in diesem Dokument beschriebene Verfahren gilt für alle vPC-fähigen Cisco Nexus Switches für Rechenzentren.
vPC-Peer-Switch
In diesem Abschnitt wird die vPC-Peer-Switch-Erweiterung beschrieben, die mit dem vPC-Domänenkonfigurationsbefehl peer-switch aktiviert wird.
Überblick
In vielen Umgebungen sind zwei Nexus Switches in einer vPC-Domäne Aggregations- oder Core-Switches, die als Grenze zwischen Layer-2-Ethernet-Domänen mit Switching und Layer-3-Domänen mit Routing fungieren. Beide Switches sind mit mehreren VLANs konfiguriert und für das Routing des Inter-VLAN-Ost-West-Traffics sowie des Nord-Süd-Traffics zuständig. In diesen Umgebungen fungieren die Nexus Switches aus Sicht von STP (Spanning Tree Protocol) in der Regel auch als Root-Bridges.
Normalerweise wird ein vPC-Peer als Root-Bridge für Spanning Tree konfiguriert, indem seine Spanning Tree-Priorität auf einen niedrigen Wert (z. B. 0) gesetzt wird. Der andere vPC-Peer wird mit einer etwas höheren Spanning Tree-Priorität konfiguriert (z. B. 4096), wodurch er die Rolle der Root-Bridge innerhalb von Spanning Tree übernehmen kann, wenn der vPC-Peer, der als Root-Bridge fungiert, ausfällt. Mit dieser Konfiguration generiert der vPC-Peer, der als Root-Bridge fungiert, Spanning Tree-Bridge-Protokoll-Dateneinheiten (BPDUs) mit einer Bridge-ID, die seine System-MAC-Adresse enthält.
Wenn jedoch der als Root-Bridge fungierende vPC-Peer ausfällt und den anderen vPC-Peer als Spanning Tree-Root-Bridge übernimmt, generiert der andere vPC-Peer Spanning Tree-BPDUs mit einer Bridge-ID, die seine System-MAC-Adresse enthält, die sich von der System-MAC-Adresse der ursprünglichen Root-Bridge unterscheidet. Je nachdem, wie Downstream-Brücken verbunden sind, variieren die Auswirkungen dieser Änderung und werden in den folgenden Unterabschnitten beschrieben.
Redundant verbundene Nicht-vPC-Bridges
Bridges ohne vPC-Verbindung, die mit beiden vPC-Peers über redundante Verbindungen verbunden sind (sodass sich eine Verbindung aus Sicht des Spanning Tree Protocol im Blockierungsstatus befindet), die die Änderung der BPDU (und damit die Änderung der Root-Bridge) erkennen und eine Änderung des Root-Ports beobachten. Andere designierte Weiterleitungsschnittstellen wechseln sofort in den Blockierungsstatus und durchlaufen dann den endlichen Spanning Tree Protocol-Computer (Blockieren, Lernen und Weiterleiten) mit Pausen dazwischen, die dem konfigurierten Spanning Tree Protocol Forward Delay-Timer entsprechen (standardmäßig 15 Sekunden).
Die Änderung des Root-Ports und die anschließende Durchquerung von Spanning Tree Protocol Finite State Machine können zu erheblichen Störungen im Netzwerk führen. Die vPC-Peer-Switch-Erweiterung wurde hauptsächlich eingeführt, um Netzwerkstörungen zu verhindern, die durch dieses Problem verursacht werden, wenn einer der vPC-Peers offline geht. Mit der Erweiterung für den vPC-Peer-Switch verfügt die Bridge ohne vPC-Verbindung weiterhin über eine einzelne redundante Verbindung im Blockierungsstatus, wechselt diese Schnittstelle jedoch sofort in den Weiterleitungsstatus, wenn der bestehende Root-Port aufgrund eines Verbindungsfehlers ausfällt. Derselbe Prozess findet statt, wenn der vPC-Peer offline wieder online geht: Die Schnittstelle mit den niedrigsten Kosten für die Root-Bridge übernimmt die Rolle des Root-Ports, und die redundante Verbindung wechselt sofort in den Blockierungsstatus. Der einzige zu beobachtende Effekt auf Datenebene ist der unvermeidliche Verlust übertragener Pakete, die den vPC-Peer durchlaufen haben, als dieser offline ging.
Per vPC verbundene Bridges
Mit vPC verbundene Bridges in der Spanning Tree-Domäne erkennen die Änderung in der BPDU (und damit die Änderung in der Root-Bridge) und leeren dynamisch ermittelte MAC-Adressen aus ihren lokalen MAC-Adresstabellen. Dieses Verhalten ist in Topologien mit über vPC verbundenen Geräten, die für eine schleifenfreie Topologie nicht auf das Spanning Tree Protocol angewiesen sind, ineffizient und unnötig. vPCs werden aus Sicht des Spanning Tree Protocol wie normale Port-Channels als eine einzige logische Schnittstelle betrachtet, sodass der Verlust eines vPC-Peers dem Verlust einer einzigen Verbindung innerhalb eines Port-Channel-Mitglieds ähnelt. In beiden Szenarien ändert sich am Spanning Tree nichts, sodass das Löschen von dynamisch gelernten MAC-Adressen von Bridges in der Spanning Tree-Domäne (damit Ethernet per Flood-and-Learn-Verhalten MAC-Adressen von neuerdings weiterleitenden Schnittstellen im Spanning Tree neu lernen kann) nicht erforderlich ist.
Darüber hinaus kann das Löschen von dynamisch gelernten MAC-Adressen Störungen verursachen. Stellen Sie sich ein Szenario vor, in dem zwei Hosts einen weitgehend unidirektionalen UDP-basierten Flow haben (z B. ein TFTP-Client, der Daten an einen TFTP-Server sendet). In diesem Flow fließen die Daten hauptsächlich vom TFTP-Client zum TFTP-Server. Der TFTP-Server sendet nur selten ein Paket zurück an den TFTP-Client. Daher wird die MAC-Adresse des TFTP-Servers nach einem Leeren der dynamisch abgefragten MAC-Adressen in der Spanning Tree-Domäne einige Zeit nicht abgefragt. Das bedeutet, dass die Daten des TFTP-Clients, die an den TFTP-Server gesendet werden, über das gesamte VLAN geleitet werden, da der Datenverkehr Unicast-unbekannten Datenverkehr ist. Dies kann dazu führen, dass große Datenströme an nicht dafür vorgesehene Stellen im Netzwerk gelangen, und es kann zu Leistungsproblemen kommen, wenn sie durch überlastete Abschnitte des Netzwerks fließen.
Die vPC-Peer-Switch-Erweiterung wurde eingeführt, um zu verhindern, dass dieses ineffiziente und unnötige Verhalten auftritt, wenn der vPC-Peer, der als Spanning Tree-Root-Bridge für ein oder mehrere VLANs fungiert, neu geladen oder ausgeschaltet wird.
Um die vPC-Peer-Switch-Erweiterung zu aktivieren, müssen beide vPC-Peers über identische Spanning Tree Protocol-Konfigurationen verfügen (einschließlich Spanning Tree-Prioritätswerten für alle vPC-VLANs) und als Root Bridge für alle vPC-VLANs fungieren. Sobald diese Voraussetzungen erfüllt sind, muss der vPC-Domänenkonfigurationsbefehl für den peer-switch konfiguriert werden, um die vPC-Peer-Switch-Erweiterung zu aktivieren.
Sobald die vPC-Peer-Switch-Erweiterung aktiviert ist, beginnen beide vPC-Peers, identische Spanning Tree-BPDUs mit einer Bridge-ID zu generieren, die die MAC-Adresse des vPC-Systems enthält, die von beiden vPC-Peers gemeinsam verwendet wird. Wenn ein vPC-Peer neu geladen wird, ändert sich die Spanning Tree-BPDU, die vom verbleibenden vPC-Peer stammt, nicht, sodass andere Bridges in der Spanning Tree-Domäne keine Änderung in der Root-Bridge erkennen und nicht suboptimal auf die Änderung im Netzwerk reagieren.
Hinweise
Für die vPC-Peer-Switch-Erweiterung gelten einige Einschränkungen, die Sie vor der Konfiguration in einer Produktionsumgebung beachten sollten.
Erforderliche Übereinstimmung der Spanning Tree-Prioritätswerte zwischen vPC-Peers
Bevor Sie die vPC-Peer-Switch-Erweiterung aktivieren, muss die Spanning Tree-Prioritätskonfiguration für alle vPC-VLANs so geändert werden, dass sie für beide vPC-Peers identisch ist.
Beachten Sie die Konfiguration in diesem Fall, in dem N9K-1 als Spanning Tree-Root-Bridge für die VLANs 1, 10 und 20 mit einer Priorität von 0 konfiguriert ist. N9K-2 ist die sekundäre Spanning Tree-Root-Bridge für die VLANs 1, 10 und 20 mit einer Priorität von 4096.
N9K-1# show running-config spanning-tree spanning-tree vlan 1,10,20 priority 0 interface port-channel1 spanning-tree port type network N9K-2# show running-config spanning-tree spanning-tree vlan 1,10,20 priority 4096 interface port-channel1 spanning-tree port type network
Bevor Sie die vPC-Peer-Switch-Erweiterung aktivieren, müssen Sie die Spanning Tree-Prioritätskonfiguration für die VLANs 1, 10 und 20 auf N9K-2 so ändern, dass sie mit der Spanning Tree-Prioritätskonfiguration für die gleichen VLANs auf N9K-1 übereinstimmt. Ein Beispiel für diese Änderung wird hier gezeigt.
N9K-2# configure terminal Enter configuration commands, one per line. End with CNTL/Z. N9K-2(config)# spanning-tree vlan 1,10,20 priority 0 N9K-2(config)# end N9K-2# show running-config spanning-tree spanning-tree vlan 1,10,20 priority 0 interface port-channel1 spanning-tree port type network N9K-1# show running-config spanning-tree spanning-tree vlan 1,10,20 priority 0 interface port-channel1 spanning-tree port type network
Auswirkungen von vPC-Peer-Switch auf Nicht-vPC-VLANs
Beachten Sie die folgende Topologie:
In dieser Topologie haben zwei vPC-Peers (N9K-1 und N9K-2) zwei Layer-2-Trunks: Po1 und Po2. Po1 ist der vPC-Peer-Link für die vPC-VLANs, während Po2 ein Layer-2-Trunk für alle Nicht-vPC-VLANs ist. Wenn die Spanning Tree-Prioritätswerte für Nicht-vPC-VLANs, die über Po2 übertragen werden, auf N9K-1 und N9K-2 identisch sind, stammt jeder vPC-Peer von Spanning Tree-BPDU-Frames, die von der MAC-Adresse des vPC-Systems stammen, die auf beiden Switches identisch ist. Infolgedessen scheint N9K-1 für jedes Nicht-vPC-VLAN seine eigene Spanning Tree-BPDU auf Po2 zu erhalten, obwohl N9K-2 der Switch ist, der die Spanning Tree-BPDU erstellt hat. Aus Sicht von Spanning Tree setzt N9K-1 Po2 für alle Nicht-vPC-VLANs in den Blockierungsstatus.
Dies ist ein erwartungsgemäßes Verhalten. Um dieses Verhalten zu verhindern oder dieses Problem zu umgehen, müssen beide vPC-Peers in allen Nicht-vPC-VLANs mit unterschiedlichen Spanning Tree-Prioritätswerten konfiguriert werden. Auf diese Weise kann ein vPC-Peer als Root-Bridge für das Nicht-vPC-VLAN fungieren und den Layer-2-Trunk zwischen vPC-Peers in den Status "Designated Forwarding" (Ausgewiesene Weiterleitung) versetzen. Auf ähnliche Weise überträgt der Remote-vPC-Peer den Layer-2-Trunk zwischen vPC-Peers in den Status "Designated Root". Dadurch kann Datenverkehr in Nicht-vPC-VLANs über beide vPC-Peers durch den Layer-2-Trunk fließen.
Konfiguration
Ein Beispiel für die Konfiguration der vPC-Peer-Switch-Funktion finden Sie hier.
In diesem Beispiel ist N9K-1 als Spanning Tree-Root-Bridge für die VLANs 1, 10 und 20 mit einer Priorität von 0 konfiguriert. N9K-2 ist die sekundäre Spanning Tree-Root-Bridge für die VLANs 1, 10 und 20 mit einer Priorität von 4096.
N9K-1# show running-config vpc <snip> vpc domain 1 role priority 150 peer-keepalive destination 10.122.190.196 interface port-channel1 vpc peer-link N9K-2# show running-config vpc <snip> vpc domain 1 peer-keepalive destination 10.122.190.195 interface port-channel1 vpc peer-link N9K-1# show running-config spanning-tree spanning-tree vlan 1,10,20 priority 0 interface port-channel1 spanning-tree port type network N9K-2# show running-config spanning-tree spanning-tree vlan 1,10,20 priority 4096 interface port-channel1 spanning-tree port type network
Zuerst muss die Spanning Tree-Prioritätskonfiguration von N9K-2 so geändert werden, dass sie mit der von N9K-1 identisch ist. Dies ist eine Voraussetzung, damit die vPC-Peer-Switch-Funktion wie erwartet funktioniert. Wenn die System-MAC-Adresse von N9K-2 niedriger ist als die System-MAC-Adresse von N9K-1, übernimmt N9K-2 die Rolle der Root-Bridge für die Spanning-Tree-Domäne, was dazu führt, dass andere Bridges in der Spanning-Tree-Domäne ihre lokalen MAC-Adresstabellen für alle betroffenen VLANs leeren. Ein Beispiel für dieses Phänomen wird hier gezeigt.
N9K-1# show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 1
Address 689e.0baa.dea7
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 1 (priority 0 sys-id-ext 1)
Address 689e.0baa.dea7
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Po1 Desg FWD 1 128.4096 (vPC peer-link) Network P2p
Po10 Desg FWD 1 128.4105 (vPC) P2p
Po20 Desg FWD 1 128.4115 (vPC) P2p
N9K-2# show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 1
Address 689e.0baa.dea7
Cost 1
Port 4096 (port-channel1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 4097 (priority 4096 sys-id-ext 1)
Address 689e.0baa.de07
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Po1 Root FWD 1 128.4096 (vPC peer-link) Network P2p
Po10 Desg FWD 1 128.4105 (vPC) P2p
Po20 Desg FWD 1 128.4115 (vPC) P2p
N9K-2# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
N9K-2(config)# spanning-tree vlan 1,10,20 priority 0
N9K-2(config)# end
N9K-2# show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 1
Address 689e.0baa.de07
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 1 (priority 0 sys-id-ext 1)
Address 689e.0baa.de07
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Po1 Desg FWD 1 128.4096 (vPC peer-link) Network P2p
Po10 Desg FWD 1 128.4105 (vPC) P2p
Po20 Desg FWD 1 128.4115 (vPC) P2p
Als Nächstes können Sie die vPC-Peer-Switch-Funktion mit dem vPC-Domänenkonfigurationsbefehl peer-switch aktivieren. Dadurch wird die Bridge-ID innerhalb der Spanning Tree-BPDUs geändert, die von beiden vPC-Peers generiert wurden. Dies führt dazu, dass andere Bridges in der Spanning Tree-Domäne ihre lokalen MAC-Adresstabellen für alle betroffenen VLANs leeren.
N9K-1# configure terminal N9K-1(config)# vpc domain 1 N9K-1(config-vpc-domain)# peer-switch N9K-1(config-vpc-domain)# end N9K-1# N9K-2# configure terminal N9K-2(config)# vpc domain 1 N9K-2(config-vpc-domain)# peer-switch N9K-2(config-vpc-domain)# end N9K-2#
Sie können mit dem Befehl show spanning-tree summary überprüfen, ob die vPC-Peer-Switch-Funktion wie erwartet funktioniert, indem Sie validieren, dass beide vPC-Peers die Rolle als Root-Bridge für vPC-VLANs für sich beanspruchen. Aus dieser Ausgabe sollte auch hervorgehen, dass die vPC-Peer-Switch-Funktion aktiviert und betriebsbereit ist.
N9K-1# show spanning-tree summary Switch is in rapid-pvst mode Root bridge for: VLAN0001, VLAN0010, VLAN0020 L2 Gateway STP is disabled Port Type Default is disable Edge Port [PortFast] BPDU Guard Default is disabled Edge Port [PortFast] BPDU Filter Default is disabled Bridge Assurance is enabled Loopguard Default is disabled Pathcost method used is short vPC peer-switch is enabled (operational) STP-Lite is disabled Name Blocking Listening Learning Forwarding STP Active ---------------------- -------- --------- -------- ---------- ---------- VLAN0001 0 0 0 3 3 VLAN0010 0 0 0 3 3 VLAN0020 0 0 0 3 3 ---------------------- -------- --------- -------- ---------- ---------- 3 vlans 0 0 0 9 9 N9K-2# show spanning-tree summary Switch is in rapid-pvst mode Root bridge for: VLAN0001, VLAN0010, VLAN0020 L2 Gateway STP is disabled Port Type Default is disable Edge Port [PortFast] BPDU Guard Default is disabled Edge Port [PortFast] BPDU Filter Default is disabled Bridge Assurance is enabled Loopguard Default is disabled Pathcost method used is short vPC peer-switch is enabled (operational) STP-Lite is disabled Name Blocking Listening Learning Forwarding STP Active ---------------------- -------- --------- -------- ---------- ---------- VLAN0001 0 0 0 3 3 VLAN0010 0 0 0 3 3 VLAN0020 0 0 0 3 3 ---------------------- -------- --------- -------- ---------- ---------- 3 vlans 0 0 0 9 9
Verwenden Sie den Befehl show spanning-tree vlan{x}, um detailliertere Informationen zu einem bestimmten VLAN anzuzeigen. Der Switch mit der primären oder operativen primären vPC-Rolle hat alle seine Schnittstellen im Status "Designated Forwarding". Der Switch mit der sekundären oder operativen sekundären vPC-Rolle hat alle zugehörigen Schnittstellen mit Ausnahme des vPC-Peer-Links, der sich im Root-Weiterleitungsstatus befindet, den Status "Designated Forwarding". Beachten Sie, dass die in der Ausgabe von show vpc role angezeigte MAC-Adresse des vPC-Systems mit der Root-Bridge-ID und der Bridge-ID jedes vPC-Peers identisch ist.
N9K-1# show vpc role
vPC Role status
----------------------------------------------------
vPC role : primary
Dual Active Detection Status : 0
vPC system-mac : 00:23:04:ee:be:01
vPC system-priority : 32667
vPC local system-mac : 68:9e:0b:aa:de:a7
vPC local role-priority : 150
vPC local config role-priority : 150
vPC peer system-mac : 68:9e:0b:aa:de:07
vPC peer role-priority : 32667
vPC peer config role-priority : 32667
N9K-1# show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 1
Address 0023.04ee.be01
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 1 (priority 0 sys-id-ext 1)
Address 0023.04ee.be01
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Po1 Desg FWD 1 128.4096 (vPC peer-link) Network P2p
Po10 Desg FWD 1 128.4105 (vPC) P2p
Po20 Desg FWD 1 128.4115 (vPC) P2p
N9K-2# show vpc role
vPC Role status
----------------------------------------------------
vPC role : secondary
Dual Active Detection Status : 0
vPC system-mac : 00:23:04:ee:be:01
vPC system-priority : 32667
vPC local system-mac : 68:9e:0b:aa:de:07
vPC local role-priority : 32667
vPC local config role-priority : 32667
vPC peer system-mac : 68:9e:0b:aa:de:a7
vPC peer role-priority : 150
vPC peer config role-priority : 150
N9K-2# show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 1
Address 0023.04ee.be01
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 1 (priority 0 sys-id-ext 1)
Address 0023.04ee.be01
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Po1 Root FWD 1 128.4096 (vPC peer-link) Network P2p
Po10 Desg FWD 1 128.4105 (vPC) P2p
Po20 Desg FWD 1 128.4115 (vPC) P2p
Abschließend können Sie das EthAnalyzer-Utility für die Paketerfassung auf der Kontrollebene auf jedem vPC-Peer verwenden, um zu bestätigen, dass beide vPC-Peers Spanning Tree-BPDUs mit einer Bridge-ID und einer Root-Bridge-ID veranlassen, die die vPC-System-MAC-Adresse enthalten, die von beiden vPC-Peers gemeinsam genutzt wird.
N9K-1# ethanalyzer local interface inband display-filter stp limit-captured-frames 0 <snip> Capturing on inband 2021-05-13 01:59:51.664206 68:9e:0b:aa:de:d4 -> 01:80:c2:00:00:00 STP RST. Root = 0/1/00:23:04:ee:be:01 Cost = 0 Port = 0x9000 N9K-2# ethanalyzer local interface inband display-filter stp limit-captured-frames 0 <snip> Capturing on inband 2021-05-13 01:59:51.777034 68:9e:0b:aa:de:34 -> 01:80:c2:00:00:00 STP RST. Root = 0/1/00:23:04:ee:be:01 Cost = 0 Port = 0x9000
Auswirkungen
Die Auswirkungen der Aktivierung der vPC-Peer-Switch-Erweiterung variieren je nachdem, ob andere Bridges in der Spanning Tree-Domäne über einen vPC mit beiden vPC-Peers verbunden sind oder ob diese redundant mit beiden vPC-Peers ohne vPC verbunden sind.
Redundant verbundene Nicht-vPC-Bridges
Wenn eine nicht per vPC verbundene Bridge mit redundanten Links zu beiden vPC-Peers (sodass sich eine Verbindung aus der Perspektive von STP im Blockierungsstatus befindet) eine Änderung der in Spanning Tree-BPDUs angekündigten Spanning Tree-Root-Bridge erkennt, kann sich der Root-Port der Bridge zwischen den beiden redundanten Schnittstellen ändern. Dies kann wiederum dazu führen, dass andere designierte Weiterleitungsschnittstellen sofort in einen Blockierungsstatus wechseln und dann die Spanning Tree Protocol Finite State Machine („Blocking“ [Blockieren], „Learning“ [Informationen aufnehmen] und „Forwarding“ [Weiterleiten]) durchlaufen – mit Pausen dazwischen, die dem konfigurierten Spanning Tree Protocol-Timer für die Weiterleitungsverzögerung entsprechen (standardmäßig 15 Sekunden). Die Änderung des Root-Ports und die anschließende Durchquerung von Spanning Tree Protocol Finite State Machine können zu erheblichen Störungen im Netzwerk führen.
Es sollte erwähnt werden, dass diese Auswirkungen immer dann auftreten, wenn der vPC-Peer, der derzeit die Root-Bridge für die Spanning-Tree-Domäne ist, offline geht (z. B. bei Stromausfall, Hardwareausfall oder einem Neuladen). Dieses Verhalten ist nicht allein auf die vPC-Peer-Switch-Erweiterung zurückzuführen. Vielmehr kann das Aktivieren der vPC-Peer-Switch-Erweiterung einfach zu einem ähnlichen Verhalten führen wie wenn ein vPC-Peer aus Spanning Tree-Perspektive offline geht.
Per vPC verbundene Bridges
Wenn eine über vPC verbundene Bridge eine Änderung in der Spanning Tree-Root-Bridge erkennt, die in Spanning Tree-BPDUs angekündigt wird, löscht die Bridge dynamisch ermittelte MAC-Adressen aus ihrer MAC-Adresstabelle. Beim Konfigurieren der vPC-Peer-Switch-Funktion können Sie dieses Verhalten in den folgenden beiden Szenarien beobachten:
- Wenn die Spanning Tree-Prioritätswerte so konfiguriert sind, dass sie zwischen beiden vPC-Peers übereinstimmen, kann sich die Spanning Tree-Root-Bridge von einem vPC-Peer zu einem anderen ändern, wenn der vPC-Peer, der zuvor nicht die Root-Bridge war, eine niedrigere System-MAC-Adresse hat als der vPC-Peer, der zuvor die Root-Bridge war. Ein Beispiel für dieses Szenario finden Sie in diesem Dokument im Abschnitt zur vPC-Peer-Switch-Konfiguration.
- Wenn die vPC-Peer-Switch-Funktion über den Konfigurationsbefehl für die vPC-Domäne des Peer-Switches aktiviert wird, beginnen beide vPC-Peers als Root Bridges der Spanning Tree-Domäne zu funktionieren. Beide vPC-Peers beginnen mit der Erstellung identischer Spanning Tree-BPDUs, die sich selbst als Root-Bridge der Spanning Tree-Domäne behaupten.
In den meisten Szenarien und Topologien wurden keine Auswirkungen auf die Datenebene beobachtet. Kurzfristig wird der Datenverkehr auf Datenebene jedoch innerhalb eines VLAN durch unbekanntes Unicast-Flooding geflutet, da die Ziel-MAC-Adresse von Frames auf keinem Switch-Port als direktes Ergebnis der Leerung dynamisch ermittelter MAC-Adressen erfasst wird. In einigen Topologien kann dies zu vorübergehenden Leistungsproblemen oder Paketverlusten führen, wenn ein Flooding des Datenebenen-Traffics auf überlastete Netzwerkgeräte im VLAN erfolgt. Dies kann auch zu Problemen mit bandbreitenintensiven, unidirektionalen Datenverkehrsflüssen oder stillen Hosts führen (Hosts, die primär Pakete empfangen und selten Pakete senden), da dieser Datenverkehr über einen längeren Zeitraum innerhalb des VLAN geleitet wird, anstatt wie üblich direkt zum Ziel-Host zu wechseln.
Es sollte erwähnt werden, dass diese Auswirkungen mit der Leerung dynamisch ermittelter MAC-Adressen aus der MAC-Adresstabelle der Bridges innerhalb des betroffenen VLAN zusammenhängen. Dieses Verhalten ist nicht allein auf die vPC-Peer-Switch-Erweiterung oder die Änderung der Root-Bridge zurückzuführen. Vielmehr kann es auch durch eine Topologieänderungsbenachrichtigung verursacht werden, die generiert wird, wenn im VLAN ein Nicht-Edge-Port aktiv wird.
Beispiele für Ausfallszenarien
Neustart von Finite State Machine (FSM) durch redundant verbundene Nicht-vPC-Bridges
Beachten Sie die folgende Topologie:
In dieser Topologie sind N9K-1 und N9K-2 vPC-Peers in einer vPC-Domäne. N9K-1 ist mit einem Spanning Tree-Prioritätswert von 0 für alle VLANs konfiguriert, wodurch N9K-1 zur Root-Bridge für alle VLANs wird. N9K-2 ist mit einem Spanning Tree-Prioritätswert von 4096 für alle VLANs konfiguriert, wodurch N9K-2 zur sekundären Root-Bridge für alle VLANs wird. Access-1 ist ein Switch, der über Layer-2-Switch-Ports redundant mit N9K-1 und N9K-2 verbunden ist. Diese Switch-Ports sind nicht zu einem Port-Channel gebündelt. Daher versetzt Spanning Tree Protocol den mit N9K-1 verbundenen Link in den Status als designierter Root und den mit N9K-2 verbundenen Link in einen alternativen Blockierungsstatus.
Stellen Sie sich ein Ausfallszenario vor, in dem N9K-1 offline geht, weil ein Hardwarefehler oder ein Stromausfall aufgetreten ist oder weil der Switch neu geladen wird. N9K-2 behauptet sich selbst als Root-Bridge für alle VLANs, indem es Spanning Tree-BPDUs unter Verwendung seiner System-MAC-Adresse als Bridge-ID meldet. Access-1 erkennt eine Änderung in der Root-Bridge-ID. Darüber hinaus wechselt der designierte Root-Port in einen Down/Down-Status, was bedeutet, dass der neue designierte Root-Port die Verbindung ist, die sich in einem alternativen Blockierungsstatus gegenüber N9K-2 befand.
Diese Änderung bei den designierten Root-Ports bewirkt, dass alle Nicht-Edge-Spanning-Tree-Ports den Spanning Tree Protocol Finite State Machine (Blocking, Learning und Forwarding) mit Pausen dazwischen durchlaufen, die dem konfigurierten Spanning Tree Protocol Forward Delay-Timer (standardmäßig 15 Sekunden) entsprechen. Dieser Prozess kann schwerwiegende Störungen im Netzwerk verursachen.
Im gleichen Fehlerszenario mit aktivierter vPC-Peer-Switch-Erweiterung übertragen sowohl N9K-1 als auch N9K-2 identische Spanning Tree-BPDUs, wobei die gemeinsam genutzte MAC-Adresse des vPC-Systems als Bridge-ID verwendet wird. Wenn N9k-1 ausfällt, setzt N9K-2 die Übertragung derselben Spanning-Tree-BPDU fort. Infolgedessen wechselt Access-1 sofort die Alternative Blocking-Verbindung zu N9K-2 in den Designated Root-Status und beginnt mit der Weiterleitung des Datenverkehrs über die Verbindung. Darüber hinaus verhindert die Tatsache, dass sich die Spanning Tree-Root-Bridge-ID nicht ändert, dass Nicht-Edge-Ports die Spanning Tree Protocol Finite State Machine durchlaufen, was die im Netzwerk beobachteten Störungen reduziert.
Löschung von dynamisch erlernten MAC-Adressen durch per vPC verbundene Bridges
Beachten Sie die folgende Topologie:
In dieser Topologie sind N9K-1 und N9K-2 vPC-Peers in einer vPC-Domäne, die Inter-VLAN-Routing zwischen VLAN 10 und VLAN 20 durchführen. N9K-1 ist mit einem Spanning Tree-Prioritätswert von 0 für VLAN 10 und VLAN 20 konfiguriert, wodurch N9K-1 zur Root-Bridge für beide VLANs wird. N9K-2 ist mit einem Spanning Tree-Prioritätswert von 4096 für VLAN 10 und VLAN 20 konfiguriert, wodurch N9K-2 zur sekundären Root-Bridge für beide VLANs wird. Host-1, Host-2, Host-3 und Host-4 kommunizieren kontinuierlich miteinander.
Stellen Sie sich ein Ausfallszenario vor, in dem N9K-1 offline geht, weil ein Hardwarefehler oder ein Stromausfall aufgetreten ist oder weil der Switch neu geladen wird. N9K-2 behauptet sich selbst als die Root-Bridge für VLAN 10 und VLAN 20, indem es Spanning Tree-BPDUs unter Verwendung seiner System-MAC-Adresse als Bridge-ID meldet. Access-1 und Access-2 sehen eine Änderung in der Root-Bridge-ID, und obwohl der Spanning Tree gleich bleibt (d. h. der vPC mit N9K-1 und N9K-2 bleibt ein designierter Root-Port), leeren Access-1 und Access-2 ihre MAC-Adressen aller dynamisch bezogenen MAC-Adressen in VLAN 10 und VLAN 20.
In den meisten Umgebungen hat das Löschen von dynamisch gelernten MAC-Adressen nur minimale Auswirkungen. Es gehen keine Pakete verloren (abgesehen von den Paketen, die zum Zeitpunkt des Ausfalls gerade auf dem Weg zu N9K-1 waren), aber für den Traffic erfolgt vorübergehend in jeder Broadcast-Domäne ein Flooding als unbekannter Unicast-Traffic, während alle Switches in der Broadcast-Domäne dynamische MAC-Adressen neu lernen.
Im selben Ausfallzenario mit aktivierter vPC-Peer-Switch-Erweiterung übertragen N9K-1 und N9K-2 identische Spanning Tree-BPDUs, wobei die gemeinsame MAC-Adresse des vPC-Systems als Bridge-ID verwendet wird. Wenn N9k-1 ausfällt, setzt N9K-2 die Übertragung derselben Spanning-Tree-BPDU fort. Infolgedessen ist Access-1 und Access-2 nicht bewusst, dass eine Änderung der Spanning Tree-Topologie stattgefunden hat. Aus ihrer Sicht sind die Spanning Tree-BPDUs der Root-Bridge identisch, sodass es nicht erforderlich ist, dynamisch ermittelte MAC-Adressen aus relevanten VLANs zu leeren. Dadurch wird das Flooding von unbekanntem Unicast-Traffic in jeder Broadcast-Domäne in diesem Ausfallszenario verhindert.
vPC-Peer-Gateway
In diesem Abschnitt wird die vPC-Peer-Gateway-Erweiterung beschrieben, die mit dem vPC-Domänenkonfigurationsbefehl peer-gateway aktiviert wird.
Überblick
Nexus Switches, die in einer vPC-Domäne konfiguriert sind, führen standardmäßig eine dual aktive FHRP-Weiterleitung (First Hop Redundancy Protocol) durch. Das bedeutet, dass, wenn einer der vPC-Peers ein Paket mit einer Ziel-MAC-Adresse empfängt, die zu einer auf dem Switch konfigurierten HSRP- (Hot Standby Router Protocol) oder VRRP-Gruppe (Virtual Router Redundancy Protocol) gehört, der Switch das Paket gemäß der lokalen Routing-Tabelle weiterleitet, und zwar unabhängig vom Status der HSRP- oder VRRP-Kontrollebene. Mit anderen Worten: Es ist das erwartete Verhalten für einen vPC-Peer in einem HSRP-Standby- oder VRRP-Backup-Status, Pakete an die virtuelle HSRP- oder VRRP-MAC-Adresse weiterzuleiten.
Wenn ein vPC-Peer ein Paket an eine virtuelle FHRP-MAC-Adresse weiterleitet, schreibt er das Paket mit einer neuen Quell- und Ziel-MAC-Adresse neu. Die Quell-MAC-Adresse ist die MAC-Adresse der Switched Virtual Interface (SVI) des vPC-Peers innerhalb des VLAN, in das das Paket geroutet wird. Die Ziel-MAC-Adresse ist die MAC-Adresse, die der Next-Hop-IP-Adresse für die Ziel-IP-Adresse des Pakets entsprechend der lokalen Routing-Tabelle des vPC-Peers zugeordnet ist. Bei Inter-VLAN-Routing-Szenarien ist die Ziel-MAC-Adresse des Pakets nach dem Umschreiben die MAC-Adresse des Hosts, an den das Paket letztendlich gerichtet ist.
Einige Hosts folgen nicht dem standardmäßigen Weiterleitungsverhalten als Optimierungsfunktion. Bei diesem Verhalten führt der Host beim Antworten auf ein eingehendes Paket keine Suche in der Routing-Tabelle und/oder im ARP-Cache durch. Stattdessen tauscht der Host für das Antwortpaket die Quell- gegen die Ziel-MAC-Adressen des eingehenden Pakets. Mit anderen Worten: Die Quell-MAC-Adresse des eingehenden Pakets wird zur Ziel-MAC-Adresse des Antwortpakets, und die Ziel-MAC-Adresse des eingehenden Pakets wird zur Quell-MAC-Adresse des Antwortpakets. Dieses Verhalten unterscheidet sich von einem Host, der das standardmäßige Weiterleitungsverhalten nutzt und eine Suche in der lokalen Routing-Tabelle und/oder dem ARP-Cache durchführt, um dann die virtuelle FHRP-MAC-Adresse als Ziel-MAC-Adresse des Antwortpakets festzulegen.
Dieses nicht standardmäßige Host-Verhalten kann gegen die Regel zur Vermeidung von vPC-Schleifen verstoßen, wenn das vom Host generierte Antwortpaket an einen vPC-Peer adressiert wird, den vPC jedoch in Richtung des anderen vPC-Peers verlässt. Der andere vPC-Peer empfängt das Paket, das an eine MAC-Adresse seines vPC-Peers gerichtet ist, und leitet das Paket aus dem vPC-Peer-Link an den vPC-Peer weiter, der die im MAC-Zieladressfeld des Pakets vorhandene MAC-Adresse besitzt. Der vPC-Peer, der Eigentümer der MAC-Adresse ist, versucht, das Paket lokal weiterzuleiten. Wenn das Paket einen vPC auslassen muss, verwirft der vPC-Peer dieses Paket, um gegen die vPC-Schleifenvermeidungsregel zu verstoßen. Infolgedessen können bei einigen Flows, die von einem Host mit diesem nicht standardmäßigen Verhalten stammen oder an diesen gerichtet sind, Verbindungsprobleme oder Paketverluste auftreten.
Die vPC-Peer-Gateway-Erweiterung wurde eingeführt, um den Paketverlust zu vermeiden, der durch Hosts mit diesem nicht standardmäßigen Verhalten verursacht wird. Dies wird dadurch erreicht, dass ein vPC-Peer Pakete lokal an die MAC-Adresse des anderen vPC-Peers weiterleiten kann, sodass Pakete, die an den Remote-vPC-Peer gerichtet sind, nicht den vPC-Peer-Link verlassen müssen, um weitergeleitet zu werden. Mit anderen Worten: Die vPC-Peer-Gateway-Erweiterung ermöglicht es einem vPC-Peer, Pakete im Namen des Remote-vPC-Peers weiterzuleiten. Die vPC-Peer-Gateway-Erweiterung kann mit dem vPC-Domänenkonfigurationsbefehl peer-gateway aktiviert werden.
Hinweise
Flapping von Unicast-Routing-Protokoll-Adjacencies über vPCs oder vPC-VLANs
Wenn dynamische Unicast-Routing-Protokoll-Adjacencies zwischen zwei vPC-Peers und einem per vPC verbundenen Router oder einem über einen verwaisten vPC-Port verbundenen Router gebildet werden, kann es nach dem Aktivieren der vPC-Peer-Gateway-Erweiterung zu kontinuierlichem Flapping der Routing-Protokoll-Adjacencies kommen, wenn die Erweiterung für Routing/Layer 3 über vPC nicht unmittelbar danach konfiguriert wird. Diese Ausfallzenarien werden in diesem Dokument in den Abschnitten Beispiel für ein Ausfallszenario bei Unicast-Routing-Protokoll-Adjazenzen über einen vPC mit vPC-Peer-Gateway und Unicast-Routing-Protokoll-Adjacencies über ein vPC-VLAN mit vPC-Peer-Gateway detailliert beschrieben.
Um dieses Problem zu beheben, aktivieren Sie die Erweiterung für Routing/Layer 3 über vPC mit dem vPC-Domänenkonfigurationsbefehl layer3 peer-router unmittelbar nach dem Aktivieren der vPC-Peer-Gateway-Erweiterung mit dem vPC-Domänenkonfigurationsbefehl peer-gateway.
Automatische Deaktivierung von ICMP- und ICMPv6-Umleitungen
Wenn die vPC-Peer-Gateway-Erweiterung aktiviert ist, wird die Generierung von ICMP- und ICMPv6-Weiterleitungspaketen automatisch auf allen vPC-VLAN-SVIs deaktiviert (d. h. jeder SVI, die einem VLAN zugeordnet ist, das über den vPC-Peer-Link verbunden ist). Der Switch setzt dies um, indem an allen vPC-VLAN-SVIs no ip redirects und no ipv6 redirects konfiguriert werden. Dadurch wird verhindert, dass ein Switch ICMP-Umleitungspakete als Antwort auf Pakete generiert, die zwar am Switch eintreffen, aber eine Ziel-MAC-Adresse und IP-Adresse vom vPC-Peer des Switchs haben.
Wenn in Ihrer Umgebung innerhalb eines bestimmten VLAN ICMP- oder ICMPv6-Weiterleitungspakete erforderlich sind, müssen Sie dieses VLAN mithilfe des Konfigurationsbefehls peer-gateway exclude-vlan <vlan-id> vPC-Domain von der Nutzung der vPC Peer-Gateway-Erweiterung ausschließen.
Konfiguration
Ein Beispiel für die Konfiguration der vPC-Peer-Gateway-Funktion finden Sie hier.
In diesem Beispiel sind N9K-1 und N9K-2 vPC-Peers in einer vPC-Domäne. Auf beiden vPC-Peers ist eine HSRP-Gruppe für VLAN 10 konfiguriert. N9K-1 ist der aktive HSRP-Router mit einer Priorität von 150, während N9K-2 der HSRP-Standby-Router mit der Standardpriorität 100 ist.
N9K-1# show running-config vpc
<snip>
vpc domain 1
role priority 150
peer-keepalive destination 10.82.140.43
interface port-channel1
vpc peer-link
N9K-2# show running-config vpc
<snip>
vpc domain 1
peer-keepalive destination 10.82.140.42
interface port-channel1
vpc peer-link
N9K-1# show running-config interface vlan 10
<snip>
interface Vlan10
no shutdown
ip address 192.168.10.2/24
hsrp 10
preempt
priority 150
ip 192.168.10.1
N9K-2# show running-config interface vlan 10
<snip>
interface Vlan10
no shutdown
ip address 192.168.10.3/24
hsrp 10
ip 192.168.10.1
N9K-1# show hsrp interface vlan 10 brief
*:IPv6 group #:group belongs to a bundle
P indicates configured to preempt.
|
Interface Grp Prio P State Active addr Standby addr Group addr
Vlan10 10 150 P Active local 192.168.10.3 192.168.10.1 (conf)
N9K-2# show hsrp interface vlan 10 brief
*:IPv6 group #:group belongs to a bundle
P indicates configured to preempt.
|
Interface Grp Prio P State Active addr Standby addr Group addr
Vlan10 10 100 Standby 192.168.10.2 local 192.168.10.1 (conf)
Die MAC-Adresse der VLAN 10-SVI von N9K-1 lautet 00ee.ab67.db47, und die MAC-Adresse der VLAN 10-SVI von N9K-2 lautet 00ee.abd8.747f. Die virtuelle HSRP-MAC-Adresse für VLAN 10 lautet 0000.0c07.ac0a. In diesem Zustand sind die VLAN 10-SVI-MAC-Adressen der beiden Switches und die virtuelle HSRP-MAC-Adresse in der MAC-Adresstabelle der Switches vorhanden. Die VLAN 10-SVI-MAC-Adresse und die virtuelle HSRP-MAC-Adresse jedes Switches haben das Gateway-Flag (G), das anzeigt, dass der Switch lokal Pakete weiterleitet, die an diese MAC-Adresse gerichtet sind.
Beachten Sie, dass in der MAC-Adresstabelle von N9K-1 das Gateway-Flag für die VLAN 10-SVI-MAC-Adresse von N9K-2 nicht vorhanden ist. Umgekehrt ist in der MAC-Adresstabelle von N9K-2 das Gateway-Flag für die VLAN 10-SVI-MAC-Adresse von N9K-1 nicht vorhanden.
N9K-1# show mac address-table vlan 10
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link,
(T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan
VLAN MAC Address Type age Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
G 10 0000.0c07.ac0a static - F F sup-eth1(R)
G 10 00ee.ab67.db47 static - F F sup-eth1(R)
* 10 00ee.abd8.747f static - F F vPC Peer-Link(R)
N9K-2# show mac address-table vlan 10
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link,
(T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan
VLAN MAC Address Type age Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
G 10 0000.0c07.ac0a static - F F vPC Peer-Link(R)
* 10 00ee.ab67.db47 static - F F vPC Peer-Link(R)
G 10 00ee.abd8.747f static - F F sup-eth1(R)
Die vPC-Peer-Gateway-Erweiterung kann mit dem vPC-Domänenkonfigurationsbefehl peer-gateway aktiviert werden. Auf diese Weise kann der Switch empfangene Pakete mit einer MAC-Zieladresse, die zur MAC-Adresse des vPC-Peers gehört, die er über den vPC-Peer-Link bezogen hat, lokal weiterleiten. Dazu setzen Sie das Gateway-Flag für die MAC-Adresse des vPC-Peers in der MAC-Adresstabelle des Switchs.
N9K-1# configure terminal Enter configuration commands, one per line. End with CNTL/Z. N9K-1(config)# vpc domain 1 N9K-1(config-vpc-domain)# peer-gateway N9K-1(config-vpc-domain)# end N9K-1# N9K-2# configure terminal Enter configuration commands, one per line. End with CNTL/Z. N9K-2(config)# vpc domain 1 N9K-2(config-vpc-domain)# peer-gateway N9K-2(config-vpc-domain)# end N9K-2#
Sie können überprüfen, ob die vPC-Peer-Gateway-Erweiterung wie erwartet funktioniert, indem Sie überprüfen, ob das Gateway-Flag in der MAC-Adresstabelle für die MAC des vPC Peers vorhanden ist.
N9K-1# show mac address-table vlan 10
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link,
(T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan
VLAN MAC Address Type age Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
G 10 0000.0c07.ac0a static - F F sup-eth1(R)
G 10 00ee.ab67.db47 static - F F sup-eth1(R)
G 10 00ee.abd8.747f static - F F vPC Peer-Link(R)
N9K-2# show mac address-table vlan 10
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link,
(T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan
VLAN MAC Address Type age Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
G 10 0000.0c07.ac0a static - F F vPC Peer-Link(R)
G 10 00ee.ab67.db47 static - F F vPC Peer-Link(R)
G 10 00ee.abd8.747f static - F F sup-eth1(R)
Auswirkungen
Die Auswirkungen der Aktivierung der vPC Peer Gateway-Erweiterung können je nach umgebender Topologie und dem Verhalten verbundener Hosts variieren, wie in den folgenden Unterabschnitten beschrieben. Wenn keiner der folgenden Unterabschnitte auf Ihre Umgebung zutrifft, führt die Aktivierung der vPC Peer Gateway-Erweiterung nicht zu Unterbrechungen und hat keine Auswirkungen auf Ihre Umgebung.
Flapping von Unicast-Routing-Protokoll-Adjacencies über vPCs oder vPC-VLANs
Wenn dynamische Unicast-Routing-Protokoll-Adjacencies zwischen zwei vPC-Peers und einem per vPC verbundenen Router oder einem über einen verwaisten vPC-Port verbundenen Router gebildet werden, kann es nach dem Aktivieren der vPC-Peer-Gateway-Erweiterung zu kontinuierlichem Flapping der Routing-Protokoll-Adjacencies kommen, wenn die Erweiterung für Routing/Layer 3 über vPC nicht unmittelbar danach konfiguriert wird. Diese Ausfallzenarien werden in diesem Dokument in den Abschnitten Beispiel für ein Ausfallszenario bei Unicast-Routing-Protokoll-Adjazenzen über einen vPC mit vPC-Peer-Gateway und Unicast-Routing-Protokoll-Adjacencies über ein vPC-VLAN mit vPC-Peer-Gateway detailliert beschrieben.
Um dieses Problem zu beheben, aktivieren Sie die Erweiterung für Routing/Layer 3 über vPC mit dem vPC-Domänenkonfigurationsbefehl layer3 peer-router unmittelbar nach dem Aktivieren der vPC-Peer-Gateway-Erweiterung mit dem vPC-Domänenkonfigurationsbefehl peer-gateway.
Automatische Deaktivierung von ICMP- und ICMPv6-Umleitungen
Wenn die vPC-Peer-Gateway-Erweiterung aktiviert ist, wird die Generierung von ICMP- und ICMPv6-Weiterleitungspaketen automatisch auf allen vPC-VLAN-SVIs deaktiviert (d. h. jeder SVI, die einem VLAN zugeordnet ist, das über den vPC-Peer-Link verbunden ist). Der Switch setzt dies um, indem an allen vPC-VLAN-SVIs no ip redirects und no ipv6 redirects konfiguriert werden. Dadurch wird verhindert, dass ein Switch ICMP-Umleitungspakete als Antwort auf Pakete generiert, die zwar am Switch eintreffen, aber eine Ziel-MAC-Adresse und IP-Adresse vom vPC-Peer des Switchs haben.
Wenn in Ihrer Umgebung innerhalb eines bestimmten VLAN ICMP- oder ICMPv6-Weiterleitungspakete erforderlich sind, müssen Sie dieses VLAN mithilfe des Konfigurationsbefehls peer-gateway exclude-vlan <vlan-id> vPC-Domain von der Nutzung der vPC Peer-Gateway-Erweiterung ausschließen.
Beispiele für Ausfallszenarien
Per vPC verbundene Hosts mit nicht standardmäßigem Weiterleitungsverhalten
Beachten Sie die folgende Topologie:
In dieser Topologie sind N9K-1 und N9K-2 vPC-Peers in einer vPC-Domäne, die Inter-VLAN-Routing zwischen VLAN 10 und VLAN 20 durchführen. Schnittstelle Po1 ist der vPC-Peer-Link. Ein Host mit dem Namen „Host-1“ ist über vPC Po10 mit N9K-1 und N9K-2 in VLAN 10 verbunden. Host-1 besitzt die IP-Adresse 192.168.10.10 mit der MAC-Adresse 0000.0000.0010. Ein Host mit dem Namen „Host-2“ ist über vPC Po20 mit N9K-1 und N9K-2 in VLAN 20 verbunden. Host-2 besitzt die IP-Adresse 192.168.20.10 mit der MAC-Adresse 0000.0000.0020.
N9K-1 und N9K-2 haben SVIs in VLAN 10 und VLAN 20, wobei HSRP bei jeder SVI aktiviert ist. Die IP-Adresse der VLAN 10-Schnittstelle von N9K-1 lautet 192.168.10.2. Die IP-Adresse der VLAN 20-Schnittstelle von N9K-1 lautet 192.168.20.2. Die physische MAC-Adresse beider SVIs von N9K-1 lautet 00ee.ab67.db47. Die IP-Adresse der VLAN 10-Schnittstelle von N9K-2 lautet 192.168.10.3. Die IP-Adresse der VLAN 20-Schnittstelle von N9K-2 lautet 192.168.20.3. Die physische MAC-Adresse beider SVIs von N9K-2 lautet 00ee.abd8.747f. Die virtuelle HSRP-IP-Adresse für VLAN 10 lautet 192.168.10.1. Die virtuelle HSRP-MAC-Adresse lautet 0000.0c07.ac0a. Die virtuelle HSRP-IP-Adresse für VLAN 20 lautet 192.168.20.1. Die virtuelle HSRP-MAC-Adresse lautet 0000.0c07.ac14.
Stellen Sie sich ein Szenario vor, in dem Host-1 ein ICMP-Echo-Anfragepaket an Host-2 sendet. Nachdem Host-1 ARP für sein Standardgateway (die virtuelle HSRP-IP-Adresse) aufgelöst hat, folgt Host-1 dem standardmäßigen Weiterleitungsverhalten und generiert ein ICMP-Echo-Anfragepaket mit der Quell-IP-Adresse 192.168.10.10, der Ziel-IP-Adresse 192.168.20.10, der Quell-MAC-Adresse 0000.0000.0010 und der Ziel-MAC-Adresse 0000.0c07.ac0a. Dieses Paket verlässt die Umgebung in Richtung N9K-1. Hier sehen Sie eine Visualisierung dazu.
N9K-1 empfängt dieses Paket. Da dieses Paket an die virtuelle HSRP-MAC-Adresse gerichtet ist, kann N9K-1 dieses Paket unabhängig vom HSRP-Kontrollebenenstatus gemäß seiner lokalen Routing-Tabelle weiterleiten. Dieses Paket wird von VLAN 10 in VLAN 20 geroutet. Beim Routing des Pakets führt N9K-1 eine Umschreibung des Pakets durch, indem die Quell- und Ziel-MAC-Adressfelder des Pakets neu adressiert werden. Die neue Quell-MAC-Adresse des Pakets ist die physische MAC-Adresse, die mit der VLAN 20 SVI von N9K-1 (00ee.ab67.db47) verknüpft ist, und die neue Ziel-MAC-Adresse ist die MAC-Adresse, die Host-2 (0000.000.0020) zugeordnet ist. Hier sehen Sie eine Visualisierung dazu.
Host-2 empfängt dieses Paket und generiert als Antwort auf das ICMP-Echo-Anfragepaket von Host-1 ein ICMP-Echo-Antwortpaket. Wenn Host-2 jedoch nicht das standardmäßige Weiterleitungsverhalten nutzt, sieht der Prozess anders aus. Um die Weiterleitung zu optimieren, führt Host-2 keine Suche in der Routing-Tabelle oder im ARP-Cache-Suche nach der IP-Adresse von Host-1 (192.168.10.10) durch, sondern invertiert die Einträge in den Quell-MAC-Adress- und die Ziel-MAC-Adressfeldern des ICMP-Echo-Anfragepakets, das Hosts -2 ursprünglich erhalten hat. Das von Host-2 generierte ICMP-Echo-Reply-Paket weist daher die Quell-IP-Adresse 192.168.20.10, die Ziel-IP-Adresse 192.168.10.10, die Quell-MAC-Adresse 0000.0000.0020 auf. MAC-Zieladresse: 00ee.ab67.db47.
Wenn dieses ICMP-Echoantwortpaket an N9K-1 ausgeht, wird dieses Paket problemlos an Host-1 weitergeleitet. Stellen Sie sich jedoch ein Szenario vor, in dem dieses ICMP-Echo-Antwortpaket die Umgebung wie hier gezeigt in Richtung N9K-2 verlässt.
N9K-2 empfängt dieses Paket. Da dieses Paket für die physische MAC-Adresse der VLAN 20 SVI von N9K-1 bestimmt ist, leitet N9K-2 dieses Paket über den vPC-Peer-Link an N9K-1 weiter, da N9K-2 dieses Paket nicht für N9K-1 weiterleiten kann. Hier sehen Sie eine Visualisierung dazu.
N9K-1 empfängt dieses Paket. Da dieses Paket an die physische MAC-Adresse der VLAN 20-SVI von N9K-1 gerichtet ist, kann N9K-1 dieses Paket unabhängig vom HSRP-Kontrollebenenstatus gemäß seiner lokalen Routing-Tabelle weiterleiten. Dieses Paket wird von VLAN 20 in VLAN 10 geroutet. Die Ausgangsschnittstelle für diese Route wird jedoch zu vPC-Po10 aufgelöst, der auf N9K-2 aktiv ist. Dies stellt einen Verstoß gegen die vPC-Schleifenvermeidungsregel dar: Wenn N9K-1 ein Paket über den vPC-Peer-Link empfängt, kann N9K-1 dieses Paket nicht von einer vPC-Schnittstelle weiterleiten, wenn dieselbe vPC-Schnittstelle auf N9K-2 aktiv ist. N9K-1 verwirft dieses Paket aufgrund dieser Verletzung. Hier sehen Sie eine Visualisierung dazu.
Sie können dieses Problem beheben, indem Sie die vPC-Peer-Gateway-Erweiterung mit dem vPC-Domänenkonfigurationsbefehl peer-gateway aktivieren. Dadurch kann N9K-2 das ICMP-Echo-Antwortpaket (und andere ähnlich adressierte Pakete) im Namen von N9K-1 weiterleiten, obwohl die Ziel-MAC-Adresse des Pakets N9K-1 gehört und nicht N9K-2. Infolgedessen kann N9K-2 dieses Paket über seine vPC-Schnittstelle Po10 weiterleiten, statt es über den vPC-Peer-Link weiterzuleiten.
Routing/Layer 3 über vPC (Layer-3-Peer-Router)
In diesem Abschnitt wird die Erweiterung für Routing/Layer 3 über vPC beschrieben, die mit dem vPC-Domänenkonfigurationsbefehl layer3 peer-router aktiviert wird.
Überblick
In einigen Umgebungen möchten Kunden einen Router über vPC mit zwei Nexus-Switches verbinden und mit beiden vPC-Peers Unicast-Routing-Protokoll-Adjacencies über den vPC bilden. Alternativ können Kunden einen Router über ein vPC-VLAN mit einem einzelnen vPC-Peer verbinden und Unicast-Routing-Protokoll-Adjacencies mit beiden vPC-Peers über das vPC-VLAN bilden. Infolgedessen verfügt der per vPC verbundene Router über ECMP (Equal Cost Multi-Path) für Präfixe, die von beiden Nexus-Switches angekündigt werden. Dies ist unter Umständen der Verwendung dedizierter Routing-Links zwischen dem per vPC verbundenen Router und beiden vPC-Peers vorzuziehen, um IP-Adressen zu sparen (drei statt vier IP-Adressen erforderlich) oder die Konfigurationskomplexität zu reduzieren (geroutete Schnittstellen neben SVIs, insbesondere in VRF-Lite-Umgebungen, die Subschnittstellen erfordern).
In der Vergangenheit wurde die Bildung von Unicast-Routing-Protokoll-Adjacencies über einen vPC auf Cisco Nexus-Plattformen nicht unterstützt. Kunden haben jedoch möglicherweise eine Topologie implementiert, in der sich Unicast-Routing-Protokoll-Adjacencies problemlos über einen vPC bilden, obwohl sie nicht unterstützt werden. Nach einigen Änderungen im Netzwerk (z. B. Software-Upgrade des per vPC verbundenen Routers oder der vPC-Peers selbst, Firewall-Failover usw.) funktionieren die Unicast-Routing-Protokoll-Adjacencies über einen vPC nicht mehr, was zu einem Paketverlust für Datenebenen-Traffic führt oder verhindert, dass Unicast-Routing-Protokoll-Adjacencies auf einem oder beiden vPC-Peers aktiv werden. Die technischen Details, warum diese Szenarien fehlschlagen und nicht unterstützt werden, werden in diesem Dokument im Abschnitt Beispiele für Ausfallszenarien erläutert.
Die Erweiterung für Routing/Layer 3 über vPC wurde eingeführt, um Unterstützung für die Bildung von Unicast-Routing-Protokoll-Adjacencies über einen vPC einzuführen. Zu diesem Zweck wird die Weiterleitung von Unicast-Routing-Protokollpaketen mit einer TTL von 1 über den vPC-Peer-Link zugelassen, wobei sich die TTL des Pakets nicht verringert. Infolgedessen können Unicast-Routing-Protokoll-Adjacencies problemlos über einen vPC oder ein vPC-VLAN gebildet werden. Die Erweiterung für Routing/Layer 3 über vPC kann mit dem vPC-Domänenkonfigurationsbefehl layer3 peer-router aktiviert werden, nachdem die vPC-Peer-Gateway-Erweiterung mit dem vPC-Domänenkonfigurationsbefehl peer-gateway aktiviert wurde.
Die NX-OS-Softwareversionen, mit denen die Unterstützung der Erweiterung für Routing/Layer 3 über vPC für jede Cisco Nexus-Plattform eingeführt wurde, sind im Dokument Unterstützte Topologien für das Routing über Virtual Port Channel auf Nexus-Plattformen in Tabelle 2 (Unterstützung von Routing-Protokoll-Adjacencies über vPC-VLANs) aufgeführt.
Hinweise
Gelegentliche VPC-2-L3_VPC_UNEQUAL_WEIGHT-Syslogs
Wenn die Erweiterung "Routing/Layer 3 über vPC" aktiviert ist, beginnen beide vPC-Peers einmal stündlich Syslogs zu generieren, die einem der folgenden ähneln:
2021 May 26 19:13:47.079 switch %VPC-2-L3_VPC_UNEQUAL_WEIGHT: Layer3 peer-router is enabled. Please make sure both vPC peers have the same L3 routing configuration. 2021 May 26 19:13:47.351 switch %VPC-2-L3_VPC_UNEQUAL_WEIGHT: Unequal weight routing is not supported in L3 over vPC. Please make sure both vPC peers have equal link cost configuration
Keines dieser Syslogs weist auf ein Problem mit dem Switch hin. Diese Syslogs warnen den Administrator, dass die Routingkonfiguration, die Kosten und die Gewichtung auf beiden vPC-Peers identisch sein sollten, wenn die Erweiterung für Routing/Layer 3 über vPC aktiviert ist, um sicherzustellen, dass beide vPC-Peers den Traffic gleichermaßen weiterleiten können. Dies bedeutet nicht unbedingt, dass Diskrepanzen zwischen den beiden vPC-Peers hinsichtlich Routing-Konfiguration, Kosten oder Gewichtung bestehen.
Diese Syslogs können durch die hier gezeigte Konfiguration deaktiviert werden.
switch# configure terminal switch(config)# vpc domain 1 switch(config-vpc-domain)# no layer3 peer-router syslog switch(config-vpc-domain)# end switch#
Diese Konfiguration muss auf beiden vPC-Peers durchgeführt werden, um das Syslog auf beiden vPC-Peers zu deaktivieren.
Datenverkehr auf Datenebene mit TTL von 1 Software aufgrund von Cisco Bug-ID CSCvs82183 weitergeleitet 
und Cisco Bug-ID CSCvw16965
Wenn die Erweiterung für Routing/Layer 3 über vPC auf Switches der Serie Nexus 9000 aktiviert ist, die mit einem Cloud Scale ASIC ausgestattet sind, auf dem eine NX-OS-Softwareversion vor der NX-OS-Softwareversion 9.3(6) ausgeführt wird, wird Datenverkehr auf Datenebene, der keinem Unicast-Routing-Protokoll mit einer TTL von 1 zugeordnet ist, an den Supervisor gesendet und in der Software anstatt in der Hardware weitergeleitet. Je nachdem, ob es sich bei dem Nexus-Switch um einen fest konfigurierten Switch (auch "Top of Rack" genannt) oder einen modularen Chassis-Switch (auch "End of Row" genannt) handelt und ob es sich um die aktuelle NX-OS-Softwareversion des Switches handelt, kann die Ursache für dieses Problem auf den Softwarefehler Cisco Bug-ID CSCvs82183 zurückgeführt werden. oder Softwarefehler Cisco Bug-ID CSCvw16965 . Beide Softwarefehler betreffen nur Switches der Nexus 9000-Serie, die mit einer Cloud-Scale-ASIC ausgestattet sind. Andere Cisco Nexus-Hardwareplattformen sind nicht von diesen Problemen betroffen. Weitere Informationen finden Sie bei den Hinweisen zum jeweiligen Softwarefehler.
Um diese Softwarefehler zu vermeiden, empfiehlt Cisco ein Upgrade auf die NX-OS-Softwareversion 9.3(6) oder höher. Allgemein empfiehlt Cisco, regelmäßig Upgrades auf die aktuelle empfohlene NX-OS-Softwareversion für den Switch der Nexus 9000-Serie durchzuführen. Die jeweils aktuelle Version können Sie dem Dokument zu den für Switches der Cisco Nexus 9000-Serie empfohlenen Cisco NX-OS-Versionen entnehmen.
Konfiguration
Ein Beispiel für die Konfiguration der Erweiterung für Routing/Layer 3 über vPC finden Sie hier.
In diesem Beispiel sind N9K-1 und N9K-2 vPC-Peers in einer vPC-Domäne. Bei beiden vPC-Peers ist die vPC-Peer-Gateway-Erweiterung bereits aktiviert, was erforderlich ist, um die Erweiterung für Routing/Layer 3 über vPC zu aktivieren. Beide vPC-Peers verfügen über eine SVI in VLAN 10, die in OSPF-Prozess 1 aktiviert wird. N9K-1 und N9K-3 hängen im OSPF EXSTART/EXCHANGE-Status mit einem per vPC verbundenen OSPF-Router mit der IP-Adresse und Nachbar-ID 192.168.10.3 fest.
N9K-1# show running-config vpc <snip> vpc domain 1 role priority 150 peer-keepalive destination 10.122.190.196 peer-gateway interface port-channel1 vpc peer-link N9K-2# show running-config vpc <snip> vpc domain 1 peer-keepalive destination 10.122.190.195 peer-gateway interface port-channel1 vpc peer-link N9K-1# show running-config interface Vlan10 interface Vlan10 no shutdown no ip redirects ip address 192.168.10.1/24 no ipv6 redirects ip router ospf 1 area 0.0.0.0 N9K-2# show running-config interface Vlan10 interface Vlan10 no shutdown no ip redirects ip address 192.168.10.2/24 no ipv6 redirects ip router ospf 1 area 0.0.0.0 N9K-1# show running-config ospf feature ospf router ospf 1 interface Vlan10 ip router ospf 1 area 0.0.0.0 N9K-2# show running-config ospf feature ospf router ospf 1 interface Vlan10 ip router ospf 1 area 0.0.0.0 N9K-1# show ip ospf neighbors OSPF Process ID 1 VRF default Total number of neighbors: 3 Neighbor ID Pri State Up Time Address Interface 192.168.10.2 1 TWOWAY/DROTHER 00:08:10 192.168.10.2 Vlan10 192.168.10.3 1 EXCHANGE/BDR 00:07:43 192.168.10.3 Vlan10 N9K-2# show ip ospf neighbors OSPF Process ID 1 VRF default Total number of neighbors: 3 Neighbor ID Pri State Up Time Address Interface 192.168.10.1 1 TWOWAY/DROTHER 00:08:21 192.168.10.1 Vlan10 192.168.10.3 1 EXSTART/BDR 00:07:48 192.168.10.3 Vlan10
Sie können die Erweiterung für Routing/Layer 3 über vPC mit dem vPC-Domänenkonfigurationsbefehl layer3 peer-router aktivieren. Dadurch wird verhindert, dass ein vPC-Peer die TTL von Unicast-Routing-Protokollpaketen herabsetzt, die als Folge der Aktivierung der vPC-Peer-Gateway-Erweiterung geroutet werden.
N9K-1# configure terminal Enter configuration commands, one per line. End with CNTL/Z. N9K-1(config)# vpc domain 1 N9K-1(config-vpc-domain)# layer3 peer-router N9K-1(config-vpc-domain)# end N9K-1# N9K-2# configure terminal Enter configuration commands, one per line. End with CNTL/Z. N9K-2(config)# vpc domain 1 N9K-2(config-vpc-domain)# layer3 peer-router N9K-2(config-vpc-domain)# end N9K-2#
Sie können überprüfen, ob die Erweiterung für Routing/Layer 3 über vPC wie erwartet funktioniert, indem Sie überprüfen, ob die OSPF-Adjazenz mit dem per vPC verbundenen OSPF-Nachbarn kurz nach dem Aktivieren der Erweiterung für Routing/Layer 3 über vPC in den Status FULL übergeht.
N9K-1# show ip ospf neighbors OSPF Process ID 1 VRF default Total number of neighbors: 3 Neighbor ID Pri State Up Time Address Interface 192.168.10.2 1 TWOWAY/DROTHER 00:12:17 192.168.10.2 Vlan10 192.168.10.3 1 FULL/BDR 00:00:29 192.168.10.3 Vlan10 N9K-2# show ip ospf neighbors OSPF Process ID 1 VRF default Total number of neighbors: 3 Neighbor ID Pri State Up Time Address Interface 192.168.10.1 1 TWOWAY/DROTHER 00:12:27 192.168.10.1 Vlan10 192.168.10.3 1 FULL/BDR 00:00:19 192.168.10.3 Vlan10
Auswirkungen
Die Aktivierung der Erweiterung für Routing/Layer 3 über vPC hat an sich keine Auswirkungen auf die vPC-Domäne. Wenn Sie also die Erweiterung Routing/Layer 3 über vPC aktivieren, werden vPCs weder vom vPC-Peer ausgesetzt noch der Datenverkehr auf Datenebene durch die Aktivierung dieser Erweiterung beeinträchtigt.
Wenn jedoch dynamische Routing-Protokoll-Adjacencies, die zuvor aufgrund der nicht aktivierten Erweiterung für Routing/Layer 3 über vPC inaktiv waren, als Ergebnis dieser Aktivierung plötzlich aktiv werden, kann es zu gewissen Störungen kommen. Dies hängt von der Rolle der betroffenen Routing-Protokoll-Adjacencies, den konkreten über die Adjacencies angekündigten Präfixen und dem aktuellen Status der Unicast-Routing-Tabelle ab.
Aus diesem Grund empfiehlt Cisco, dass Kunden diese Erweiterung während eines Wartungsfensters aktivieren. Dabei wird davon ausgegangen, dass es zu Unterbrechungen auf der Kontroll- und Datenebene kommen kann, es sei denn, die Kunden sind äußerst zuversichtlich, dass die betroffenen Routing-Protokoll-Nachbarschaften den Betrieb des Netzwerks nicht wesentlich beeinträchtigen.
Cisco empfiehlt auch, anhand des Abschnitts zu Einschränkungen in diesem Dokument sorgfältig zu prüfen, ob die dort aufgeführten Softwarefehler Ihre NX-OS-Softwareversion betreffen und dazu führen können, dass Datenebenen-Traffic mit einer TTL von 1 in Software statt in Hardware verarbeitet wird.
Beispiele für Ausfallszenarien
Unicast-Routing-Protokoll-Adjacencies über einen vPC ohne vPC-Peer-Gateway
Beachten Sie die hier dargestellte Topologie:
In dieser Topologie sind die Nexus Switches N9K-1 und N9K-2 vPC-Peers innerhalb einer vPC-Domäne, in der die vPC-Peer-Gateway-Erweiterung nicht aktiviert ist. Schnittstelle Po1 ist der vPC-Peer-Link. Ein Router mit dem Hostnamen „Router“ ist über vPC Po10 mit N9K-1 und N9K-2 verbunden. Ein Host ist über vPC Po20 mit N9K-1 und N9K-2 verbunden. Die Po10-Schnittstelle des Routers ist ein gerouteter Port-Channel, der im Rahmen eines Unicast-Routing-Protokolls aktiviert wird. N9K-1 und N9K-2 verfügen über SVI-Schnittstellen, die im Rahmen desselben Unicast-Routing-Protokolls aktiviert werden, und befinden sich in derselben Broadcast-Domäne wie „Router“.
Unicast-Routing-Protokoll-Adjacencies über einen vPC ohne aktivierte vPC-Peer-Gateway-Erweiterung werden nicht unterstützt, da die ECMP-Hashing-Entscheidung des per vPC verbundenen Routers und die Layer-2-Port-Channel-Hashing-Entscheidung unterschiedlich sein können. In dieser Topologie würden sich erfolgreich Routing-Protokoll-Nachbarschaften zwischen Router, N9K-1 und N9K-2 bilden. Berücksichtigen Sie den Traffic-Fluss zwischen Router und Host. Der Datenebenen-Traffic, der den für den Host bestimmten Router durchläuft, kann mit einer Ziel-MAC-Adresse umgeschrieben werden, die zur SVI-MAC-Adresse von N9K-1 gehört (aufgrund der ECMP-Hashing-Entscheidung des Routers), aber aus der Schnittstelle Ethernet1/2 austritt (aufgrund der Layer-2-Port-Channel-Hashing-Entscheidung des Routers).
N9K-2 empfängt dieses Paket und leitet es über den vPC-Peer-Link weiter, da die Ziel-MAC-Adresse zu N9K-1 gehört und die vPC-Peer-Gateway-Erweiterung (mit der N9K-2 das Paket für N9K-1 weiterleiten kann) nicht aktiviert ist. N9K-1 empfängt dieses Paket über den vPC-Peer-Link und erkennt, dass er das Paket über Ethernet1/2 in vPC Po20 weiterleiten müsste. Dies verstößt gegen die Regel zur Vermeidung von vPC-Schleifen, sodass N9K-1 das Paket in Hardware verwirft. Infolgedessen können bei einigen Flows, die die vPC-Domäne in dieser Topologie durchqueren, Verbindungsprobleme oder Paketverluste auftreten.
Sie können dieses Problem beheben, indem Sie die vPC-Peer-Gateway-Erweiterung mit dem vPC-Domänenkonfigurationsbefehl peer-gatewayaktivieren und dann die Erweiterung für Routing/Layer 3 über vPC mit dem vPC-Domänenkonfigurationsbefehl layer3 peer-router aktivieren. Um Störungen zu minimieren, sollten Sie beide vPC-Erweiterungen kurz hintereinander aktivieren, damit keine Zeit für ein Auftreten des unter „Unicast-Routing-Protokoll-Adjacencies über einen vPC mit vPC-Peer-Gateway“ beschriebenes Ausfallzenarios bleibt.
Unicast-Routing-Protokoll-Adjacencies über einen vPC mit vPC-Peer-Gateway
Beachten Sie die hier dargestellte Topologie:
In dieser Topologie sind die Nexus Switches N9K-1 und N9K-2 vPC-Peers innerhalb einer vPC-Domäne, in der die vPC-Peer-Gateway-Erweiterung aktiviert ist. Schnittstelle Po1 ist der vPC-Peer-Link. Ein Router mit dem Hostnamen „Router“ ist über vPC Po10 mit N9K-1 und N9K-2 verbunden. Die Po10-Schnittstelle des Routers ist ein gerouteter Port-Channel, der im Rahmen eines Unicast-Routing-Protokolls aktiviert wird. N9K-1 und N9K-2 verfügen über SVI-Schnittstellen, die im Rahmen desselben Unicast-Routing-Protokolls aktiviert werden, und befinden sich in derselben Broadcast-Domäne wie „Router“.
Unicast-Routing-Protokoll-Adjacencies über einen vPC mit aktivierter vPC-Peer-Gateway-Erweiterung werden nicht unterstützt, da die vPC-Peer-Gateway-Erweiterung verhindern könnte, dass Unicast-Routing-Protokoll-Adjacencies zwischen dem per vPC verbundenen Router und beiden vPC-Peers entstehen. In dieser Topologie kann es vorkommen, dass eine Routing-Protokoll-Adjacency zwischen dem Router und N9K-1 oder N9K-2 nicht wie erwartet verfügbar ist, je nachdem, wie die Unicast-Routing-Protokollpakete vom Router an den N9K-1- oder N9K-2-Hash über vPC-Po10 gesendet wurden.
Alle Router können Link-Local-Multicast-Routing-Protokollpakete (üblicherweise als „Hello“-Pakete bezeichnet) ohne Probleme senden und empfangen, da für diese Pakete erfolgreich ein Flooding in das vPC-VLAN erfolgt. Stellen Sie sich jedoch ein Szenario vor, in dem ein Unicast-Routing-Protokollpaket, das vom Router an N9K-1 gesendet wird, aufgrund der Layer-2-Port-Channel-Hashing-Entscheidung des Routers Ethernet1/2 in Richtung N9K-2 verlässt. Dieses Paket ist an die SVI-MAC-Adresse von N9K-1 gerichtet, aber an die Ethernet1/1-Schnittstelle von N9K-2. N9K-2 erkennt, dass das Paket an die SVI-MAC-Adresse von N9K-1 gerichtet ist, die in der MAC-Adresstabelle von N9K-2 mit dem Kennzeichen "G" oder "Gateway" installiert ist, da die vPC-Peer-Gateway-Erweiterung aktiviert ist. Daher versucht N9K-2, das Unicast-Routing-Protokollpaket im Auftrag von N9K-1 lokal zu routen.
Beim Routing des Pakets wird jedoch die Time to Live (TTL) des Pakets dekrementiert, und die TTL der meisten Unicast-Routing-Protokollpakete ist 1. Dadurch wird die TTL des Pakets auf 0 dekrementiert und von N9K-2 verworfen. Aus der Sicht von N9K-1 empfängt N9K-1 Link-Local-Multicast-Routing-Protokollpakete vom Router und kann Unicast-Routing-Protokollpakete an den Router senden, empfängt jedoch keine Unicast-Routing-Protokollpakete vom Router. Dadurch wird die Routing-Protokoll-Adjacency zum Router von N9K-1 entfernt, und der lokale Finite-State-Computer für das Routing-Protokoll wird neu gestartet. Entsprechend startet der Router seinen lokalen Finite-State-Computer für das Routing-Protokoll neu.
Sie können dieses Problem beheben, indem Sie die Erweiterung für Routing/Layer 3 über vPC mit dem vPC-Domänenkonfigurationsbefehl layer3 peer-router aktivieren. So können Unicast-Routing-Protokollpakete mit einer TTL von 1 über den vPC-Peer-Link weitergeleitet werden, ohne die TTL des Pakets zu verringern. Infolgedessen können Unicast-Routing-Protokoll-Adjacencies problemlos über einen vPC oder ein vPC-VLAN gebildet werden.
Unicast-Routing-Protokoll-Adjacencies über ein vPC-VLAN ohne vPC-Peer-Gateway
Beachten Sie die hier dargestellte Topologie:
In dieser Topologie sind die Nexus Switches N9K-1 und N9K-2 vPC-Peers innerhalb einer vPC-Domäne, in der die vPC-Peer-Gateway-Erweiterung nicht aktiviert ist. Schnittstelle Po1 ist der vPC-Peer-Link. Ein Router mit dem Hostnamen „Router“ ist über Ethernet1/1 mit Ethernet1/1 von N9K-1 verbunden. Die Ethernet1/1-Schnittstelle des Routers ist eine geroutete Schnittstelle, die im Rahmen eines Unicast-Routing-Protokolls aktiviert wird. N9K-1 und N9K-2 verfügen über SVI-Schnittstellen, die im Rahmen desselben Unicast-Routing-Protokolls aktiviert werden, und befinden sich in derselben Broadcast-Domäne wie „Router“.
Unicast-Routing-Protokoll-Adjacencies über ein vPC-VLAN ohne aktivierte vPC-Peer-Gateway-Erweiterung werden nicht unterstützt, da die ECMP-Hashing-Entscheidung des mit dem vPC-VLAN verbundenen Routers dazu führen kann, dass N9K-2 den Datenebenen-Traffic aufgrund eines Verstoßes gegen die Regel zur Vermeidung von vPC-Schleifen verwirft. In dieser Topologie würden sich erfolgreich Routing-Protokoll-Nachbarschaften zwischen Router, N9K-1 und N9K-2 bilden. Berücksichtigen Sie den Traffic-Fluss zwischen Router und Host. Der Datenebenen-Traffic, der den für den Host bestimmten Router durchläuft, kann mit einer Ziel-MAC-Adresse umgeschrieben werden, die zur SVI-MAC-Adresse von N9K-2 gehört (aufgrund der ECMP-Hashing-Entscheidung des Routers), und dann aus der Schnittstelle Ethernet1/1 zu N9K-1 austreten.
N9K-1 empfängt dieses Paket und leitet es über den vPC-Peer-Link weiter, da die Ziel-MAC-Adresse zu N9K-2 gehört und die vPC-Peer-Gateway-Erweiterung (die es N9K-1 ermöglicht, das Paket für N9K-2 weiterzuleiten) nicht aktiviert ist. N9K-2 empfängt dieses Paket über den vPC-Peer-Link und erkennt, dass er das Paket über Ethernet1/2 in vPC Po20 weiterleiten müsste. Dies verstößt gegen die Regel zur Vermeidung von vPC-Schleifen, sodass N9K-2 das Paket in Hardware verwirft. Infolgedessen können bei einigen Flows, die die vPC-Domäne in dieser Topologie durchqueren, Verbindungsprobleme oder Paketverluste auftreten.
Sie können dieses Problem beheben, indem Sie die vPC-Peer-Gateway-Erweiterung mit dem vPC-Domänenkonfigurationsbefehl peer-gatewayaktivieren und dann die Erweiterung für Routing/Layer 3 über vPC mit dem vPC-Domänenkonfigurationsbefehl layer3 peer-router aktivieren. Um Störungen zu minimieren, sollten Sie beide vPC-Erweiterungen kurz hintereinander aktivieren, damit keine Zeit für ein Auftreten des unter „Unicast-Routing-Protokoll-Adjacencies über einen vPC mit vPC-Peer-Gateway“ beschriebenes Ausfallzenarios bleibt.
Unicast-Routing-Protokoll-Adjacencies über ein vPC-VLAN mit vPC-Peer-Gateway
Beachten Sie die hier dargestellte Topologie:
In dieser Topologie sind die Nexus Switches N9K-1 und N9K-2 vPC-Peers innerhalb einer vPC-Domäne, in der die vPC-Peer-Gateway-Erweiterung aktiviert ist. Schnittstelle Po1 ist der vPC-Peer-Link. Ein Router mit dem Hostnamen „Router“ ist über Ethernet1/1 mit Ethernet1/1 von N9K-1 verbunden. Die Ethernet1/1-Schnittstelle des Routers ist eine geroutete Schnittstelle, die im Rahmen eines Unicast-Routing-Protokolls aktiviert wird. N9K-1 und N9K-2 verfügen über SVI-Schnittstellen, die im Rahmen desselben Unicast-Routing-Protokolls aktiviert werden, und befinden sich in derselben Broadcast-Domäne wie „Router“.
Unicast-Routing-Protokoll-Nachbarschaften über ein vPC-VLAN mit aktivierter vPC-Peer-Gateway-Erweiterung werden nicht unterstützt, da die vPC-Peer-Gateway-Erweiterung verhindert, dass sich zwischen dem mit dem vPC-VLAN verbundenen Router und dem vPC-Peer, mit dem der mit dem vPC-VLAN verbundene Router nicht direkt verbunden ist, Unicast-Routing-Protokoll-Nachbarschaften bilden. In dieser Topologie wird eine Routing-Protokoll-Adjacency zwischen Router und N9K-2 nicht wie erwartet angezeigt, da Pakete des Routing-Unicast-Routing-Protokolls vom Typ N9K-1, die an die SVI MAC-Adresse von N9K-2 gerichtet sind, aufgrund der Aktivierung der vPC-Peer-Gateway-Erweiterung nicht verfügbar sind. Da die Pakete geroutet werden, muss ihre Gültigkeitsdauer (Time to Live, TTL) verringert werden. Unicast-Routing-Protokollpakete haben in der Regel eine TTL von 1. Wenn ein Router die TTL eines Pakets auf 0 verringert, muss er dieses Paket verwerfen.
Alle Router können Link-Local-Multicast-Routing-Protokollpakete (üblicherweise als „Hello“-Pakete bezeichnet) ohne Probleme senden und empfangen, da für diese Pakete erfolgreich ein Flooding in das vPC-VLAN erfolgt. Stellen Sie sich jedoch ein Szenario vor, in dem ein Unicast-Routing-Protokollpaket, das vom Router an N9K-2 gesendet wird, Ethernet1/1 in Richtung N9K-1 verlässt. Dieses Paket ist für die SVI-MAC-Adresse von N9K-2 bestimmt, jedoch für die Ethernet1/1-Schnittstelle von N9K-1. N9K-1 erkennt, dass das Paket an die SVI-MAC-Adresse von N9K-2 gerichtet ist, die in der MAC-Adresstabelle von N9K-1 mit dem Kennzeichen "G" oder "Gateway" installiert ist, da die vPC-Peer-Gateway-Erweiterung aktiviert ist. Daher versucht N9K-1, das Unicast-Routing-Protokollpaket im Auftrag von N9K-2 lokal zu routen.
Beim Routing des Pakets wird jedoch die TTL des Pakets dekrementiert, und die TTL der meisten Unicast-Routing-Protokollpakete ist 1. Dadurch wird die TTL des Pakets auf 0 dekrementiert und von N9K-1 verworfen. Aus der Sicht von N9K-2 empfängt N9K-2 Link-Local-Multicast-Routing-Protokollpakete vom Router und kann Unicast-Routing-Protokollpakete an den Router senden, empfängt jedoch keine Unicast-Routing-Protokollpakete vom Router. Als Ergebnis trennt N9K-2 die Routing-Protokoll-Adjacency mit dem Router und startet seinen lokalen Finite-State-Computer für das Routing-Protokoll neu. Entsprechend startet der Router seinen lokalen Finite-State-Computer für das Routing-Protokoll neu.
Sie können dieses Problem beheben, indem Sie die Erweiterung für Routing/Layer 3 über vPC mit dem vPC-Domänenkonfigurationsbefehl layer3 peer-router aktivieren. So können Unicast-Routing-Protokollpakete mit einer TTL von 1 über den vPC-Peer-Link weitergeleitet werden, ohne die TTL des Pakets zu verringern. Infolgedessen können Unicast-Routing-Protokoll-Adjacencies problemlos über einen vPC oder ein vPC-VLAN gebildet werden.
Unicast-Routing-Protokoll-Adjacencies über einen Back-to-Back-vPC mit vPC-Peer-Gateway
Beachten Sie die hier dargestellte Topologie:
In dieser Topologie sind die Nexus Switches N9K-1 und N9K-2 vPC-Peers innerhalb einer vPC-Domäne, in der die vPC-Peer-Gateway-Erweiterung aktiviert ist. Die Nexus Switches N9K-3 und N9K-4 sind vPC-Peers innerhalb einer vPC-Domäne, in der die vPC-Peer-Gateway-Erweiterung aktiviert ist. Die beiden vPC-Domänen sind über eine Back-to-Back-vPC-Po10 miteinander verbunden. Alle vier Switches verfügen über SVI-Schnittstellen, die im Rahmen eines Unicast-Routing-Protokolls aktiviert werden, und befinden sich in derselben Broadcast-Domäne.
Unicast-Routing-Protokoll-Adjacencies über Back-to-Back-vPCs mit aktivierter vPC-Peer-Gateway-Erweiterung werden nicht unterstützt, da die vPC-Peer-Gateway-Erweiterung verhindern kann, dass Unicast-Routing-Protokoll-Adjacencies zwischen einer vPC-Domäne und einer anderen vPC-Domäne entstehen. In dieser Topologie kann eine Routing-Protokoll-Adjacency zwischen N9K-1 und entweder N9K-3 oder N9K-4 (oder beiden) nicht wie erwartet verfügbar sein. Ebenso kann es sein, dass eine Routing-Protokoll-Adjacency zwischen N9K-2 und entweder N9K-3 oder N9K-4 (oder beiden) nicht wie erwartet aktiv wird. Dies liegt daran, dass Unicast-Routing-Protokollpakete möglicherweise an einen Router (z. B. N9K-3) gerichtet sind, aber basierend auf der Layer-2-Port-Channel-Hashing-Entscheidung des Ursprungs-Routers an einen anderen Router (z. B. N9K-4) weitergeleitet werden.
Die Hauptursache für dieses Problem ist identisch mit der in diesem Dokument im Abschnitt Unicast-Routing-Protokoll-Adjazenzen über einen vPC mit vPC-Peer-Gateway beschriebenen Ursache. Sie können dieses Problem beheben, indem Sie die Erweiterung für Routing/Layer 3 über vPC mit dem vPC-Domänenkonfigurationsbefehl layer3 peer-router aktivieren. So können Unicast-Routing-Protokollpakete mit einer TTL von 1 über den vPC-Peer-Link weitergeleitet werden, ohne die TTL des Pakets zu verringern. Infolgedessen können Unicast-Routing-Protokoll-Adjacencies problemlos über einen Back-to-Back-vPC gebildet werden.
OSPF-Adjacencies über einen vPC mit vPC-Peer-Gateway, wenn das Präfix in der OSPF-LSDB, aber nicht in der Routing-Tabelle vorhanden ist
Beachten Sie die hier dargestellte Topologie:
In dieser Topologie sind die Nexus Switches N9K-1 und N9K-2 vPC-Peers innerhalb einer vPC-Domäne, in der die vPC-Peer-Gateway-Erweiterung aktiviert ist. Die Nexus Switches N9K-3 und N9K-4 sind vPC-Peers innerhalb einer vPC-Domäne, in der die vPC-Peer-Gateway-Erweiterung aktiviert ist. Die beiden vPC-Domänen sind über eine Back-to-Back-vPC-Po10 miteinander verbunden. Alle vier Switches verfügen über SVI-Schnittstellen, die im Rahmen eines Unicast-Routing-Protokolls aktiviert werden, und befinden sich in derselben Broadcast-Domäne. N9K-4 ist der designierte OSPF-Router (DR) für die Broadcast-Domäne, während N9K-3 der designierte OSPF-Backup-Router (BDR) für die Broadcast-Domäne ist.
In diesem Szenario geht eine OSPF-Adjacency zwischen N9K-1 und N9K-3 in einen FULL-Status über, da Unicast-OSPF-Pakete Ethernet1/1 beider Switches verlassen. Ebenso geht eine OSPF-Adjacency zwischen N9K-2 und N9K-3 in einen FULL-Status über, da Unicast-OSPF-Pakete Ethernet1/2 beider Switches verlassen.
Allerdings hängt eine OSPF-Adjacency zwischen N9K-1 und N9K-4 in einem EXSTART- oder EXCHANGE-Zustand fest, da Unicast-OSPF-Pakete Ethernet1/1 beider Switches verlassen und von N9K-2 und N9K-4 verworfen werden, wie in diesem Dokument im Abschnitt Unicast-Routing-Protokoll-Adjacencies über einen Back-to-Back-vPC mit vPC-Peer-Gateway beschrieben. Ebenso hängt eine OSPF-Adjacency zwischen N9K-2 und N9K-4 in einem EXSTART- oder EXCHANGE-Zustand fest, da Unicast-OSPF-Pakete Ethernet1/2 beider Switches verlassen und von N9K-1 und N9K-3 verworfen werden, wie in diesem Dokument im Abschnitt „Unicast-Routing-Protokoll-Adjacencies über einen Back-to-Back-vPC mit vPC-Peer-Gateway“ beschrieben.
Infolgedessen befinden sich N9K-1 und N9K-2 in einem FULL-Zustand mit dem BDR für die Broadcast-Domäne, befinden sich jedoch in einem EXSTART- oder EXCHANGE-Zustand mit dem DR für die Broadcast-Domäne. Sowohl der DR als auch der BDR einer Broadcast-Domäne behalten eine vollständige Kopie der OSPF Link State Data Base (LSDB) bei, aber OSPF DROTHER-Router müssen sich im Status FULL mit dem DR für die Broadcast-Domäne befinden, um Präfixe installieren zu können, die über OSPF entweder vom DR oder vom BDR gelernt wurden. Infolgedessen scheinen sowohl N9K-1 als auch N9K-2 Präfixe zu haben, die von N9K-3 und N9K-4 gelernt wurden, die in der OSPF-LSDB vorhanden sind. Diese Präfixe werden jedoch erst in der Unicast-Routing-Tabelle installiert, wenn N9K-1 und N9K-2 in den FULL-Zustand mit N9K-4 (der DR für die Broadcast-Domäne) übergehen.
Sie können dieses Problem beheben, indem Sie die Erweiterung für Routing/Layer 3 über vPC mit dem vPC-Domänenkonfigurationsbefehl layer3 peer-router aktivieren. So können Unicast-Routing-Protokollpakete mit einer TTL von 1 über den vPC-Peer-Link weitergeleitet werden, ohne die TTL des Pakets zu verringern. Infolgedessen können Unicast-Routing-Protokoll-Adjacencies problemlos über einen Back-to-Back-vPC gebildet werden. Infolgedessen werden N9K-1 und N9K-2 mit N9K-4 (dem DR für die Broadcast-Domäne) in den FULL-Status überführt und die von N9K-3 und N9K-4 bezogenen Präfixe über OSPF erfolgreich in die jeweiligen Unicast-Routing-Tabellen installiert.
Zugehörige Informationen
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 9000-Serie, Version 10.3(x)
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 9000-Serie, Version 10.2(x)
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 9000-Serie, Version 10.1(x)
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 9000-Serie, Version 9.3(x)
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 9000-Serie, Version 9.2(x)
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 9000-Serie, Version 7.x
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 7000-Serie, Version 8.x
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 7000-Serie, Version 7.x
- Design- und Konfigurationsleitfaden: Best Practices für Virtual Port Channels (vPC) auf Cisco Nexus Switches der Serie 7000
- Unterstützte Topologien für das Routing über Virtual Port Channel auf Nexus-Plattformen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
4.0 |
12-Dec-2022 |
Rezertifizierung |
3.0 |
29-Oct-2021 |
Tippfehler im vPC-Peer-Gateway-Fehlerszenario behoben. |
2.0 |
15-Sep-2021 |
Fügen Sie hinzu, dass der vPC-Domänenkonfigurationsbefehl "peer-gateway exclude-vlan" auf Switches der Serie Nexus 9000 nicht unterstützt wird. |
1.0 |
30-Jul-2021 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)