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.5(x)
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 9000-Serie, Version 10.4(x)
- 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 Channel (vPC) auf Switches der Cisco Nexus 7000-Serie
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 jeder Erweiterung, die Verhaltensänderung, die durch die Erweiterung eingeführt wird, und die Fehlerszenarien, die durch die Verbesserung gelöst werden, verstehen, warum und wann eine Verbesserung in einer vPC-Domäne konfiguriert werden kann, um die geschäftlichen Anforderungen am besten 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 des Spanning Tree konfiguriert, indem die Spanning Tree-Priorität auf einen niedrigen Wert, z. B. 0, festgelegt wird. Der andere vPC-Peer wird mit einer etwas höheren Spanning Tree-Priorität, z. B. 4096, konfiguriert, sodass er die Rolle einer Root-Bridge innerhalb des Spanning Tree übernehmen kann, wenn der vPC-Peer als Root-Bridge fungiert. 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 ursprünglichen Root-Bridge-System-MAC-Adresse unterscheidet. Je nachdem, wie Downstream-Brücken verbunden sind, variieren die Auswirkungen dieser Änderung und werden in diesen 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 per vPC verbundenen Geräten, die nicht auf Spanning Tree Protocol für eine schleifenfreie Topologie angewiesen sind, ineffizient und unnötig. vPCs werden aus Sicht von Spanning Tree Protocol genau wie normale Port-Channels als eine einzige logische Schnittstelle betrachtet, sodass der Verlust eines vPC-Peers dem Verlust eines einzelnen Links innerhalb eines Port-Channel-Mitglieds ähnelt. In beiden Szenarien ändert sich der Spanning Tree nicht, sodass das Leeren der dynamisch gelernten MAC-Adressen von Bridges in der Spanning Tree-Domäne (deren Zweck darin besteht, Ethernet-Flood-and-Learn-Verhalten zu ermöglichen, um MAC-Adressen auf neu weiterleitenden Schnittstellen des Spanning Tree neu zu lernen) nicht erforderlich ist.
Darüber hinaus kann das Leeren dynamisch ermittelter MAC-Adressen zu Unterbrechungen führen. 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. Aus diesem Grund wird die TFTP-Server-MAC-Adresse nach einem Leeren der dynamisch abgefragten MAC-Adressen in der Spanning Tree-Domäne einige Zeit nicht abgefragt. Das bedeutet, dass die TFTP-Client-Daten, die an den TFTP-Server gesendet werden, über das gesamte VLAN geleitet werden, da der Datenverkehr Unicast-unbekannten Ursprungs 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
Die Erweiterung des vPC-Peer-Switches weist einige Probleme auf, die Sie beachten müssen, bevor Sie ihn in einer Produktionsumgebung konfigurieren.
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.
Betrachten Sie die Konfiguration hier, bei der N9K-1 als Spanning Tree-Root-Bridge für die VLANs 1, 10 und 20 mit der Priorität 0 konfiguriert ist. N9K-2 ist die sekundäre Spanning Tree-Root-Bridge für die VLANs 1, 10 und 20 mit der Priorität 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
Vor der Aktivierung der vPC Peer Switch-Erweiterung müssen Sie die Spanning Tree-Prioritätskonfiguration für die VLANs 1, 10 und 20 auf N9K-2 ändern, um sie mit der Spanning Tree-Prioritätskonfiguration für dieselben VLANs auf N9K-1 abzustimmen. Ein Beispiel dieser Änderung wird hier dargestellt.
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 zwischen sich - Po1 und Po2. Po1 ist der vPC-Peer-Link, über den vPC-VLANs übertragen werden, während Po2 ein Layer-2-Trunk ist, über den alle Nicht-vPC-VLANs übertragen werden. 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 der Priorität 0 konfiguriert. N9K-2 ist die sekundäre Spanning Tree Root Bridge für die VLANs 1, 10 und 20 mit der Priorität 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. In dieser Ausgabe muss außerdem angegeben werden, 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 über vPC verbundene Bridge mit redundanten Verbindungen zu beiden vPC-Peers (sodass sich eine Verbindung aus Sicht des Spanning Tree Protocol im Blockierungsstatus befindet) eine Änderung der in Spanning Tree-BPDUs angekündigten Spanning Tree-Root-Bridge erkennt, kann der Root-Port der Bridge zwischen den beiden redundanten Schnittstellen wechseln. 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 Spanning Tree-Prioritätswerte so konfiguriert sind, dass sie zwischen beiden vPC-Peers übereinstimmen, kann die Spanning Tree-Root-Bridge von einem vPC-Peer zu einem anderen wechseln, 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 VLAN-übergreifendes Routing zwischen VLAN 10 und VLAN 20 durchführen. N9K-1 ist mit dem Spanning-Tree-Prioritätswert 0 für VLAN 10 und VLAN 20 konfiguriert, sodass N9K-1 die Root-Bridge für beide VLANs ist. 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 abgefragten 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 Stamm-Bridge-Spanning-Tree-BPDUs 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 vPC Peer Switched Virtual Interface (SVI) 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 gemäß der lokalen vPC-Peer-Routing-Tabelle 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. Auf diese Weise können Sie Verbindungsprobleme oder Paketverluste bei einigen Datenflüssen beobachten, die von einem Host stammen oder an einen Host gerichtet sind, und dieses nicht standardmäßige Verhalten verwenden.
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 über einen verwaisten vPC-Port verbundenen Router oder Router gebildet werden, können die Routing-Protokoll-Adjacencies nach der Aktivierung der vPC-Peer-Gateway-Erweiterung fortlaufend mit Flapping beginnen, wenn die Routing-/Layer-3-over-vPC-Erweiterung 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 Reaktion auf Pakete generiert, die den Switch erreichen, aber über eine Ziel-MAC- und IP-Adresse des Switch-vPC-Peers verfügen.
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. Für beide 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 von 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 befinden sich die VLAN 10 SVI MAC-Adresse jedes Switches und die virtuelle HSRP MAC-Adresse in der MAC-Adresstabelle jedes Switches. Die VLAN 10-SVI-MAC-Adresse jedes Switches und die virtuelle HSRP-MAC-Adresse 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 zu der auf dem vPC-Peer-Link bezogenen MAC-Adresse des jeweiligen vPC-Peers gehört, lokal weiterleiten. Hierzu wird die Gateway-Markierung für die vPC-Peer-MAC-Adresse in der MAC-Adresstabelle des Switches festgelegt.
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 diesen Unterabschnitten beschrieben. Wenn keiner dieser Unterabschnitte für Ihre Umgebung gilt, 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 über einen verwaisten vPC-Port verbundenen Router oder Router gebildet werden, können die Routing-Protokoll-Adjacencies nach der Aktivierung der vPC-Peer-Gateway-Erweiterung fortlaufend mit Flapping beginnen, wenn die Routing-/Layer-3-over-vPC-Erweiterung 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 Reaktion auf Pakete generiert, die den Switch erreichen, aber über eine Ziel-MAC- und IP-Adresse des Switch-vPC-Peers verfügen.
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. Die 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-1 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.000.0020.
N9K-1 und N9K-2 haben SVIs in VLAN 10 und VLAN 20, wobei HSRP bei jeder SVI aktiviert ist. Die VLAN 10-Schnittstelle von N9K-1 hat die IP-Adresse 192.168.10.2, und die VLAN 20-Schnittstelle von N9K-1 hat die IP-Adresse 192.168.20.2. Beide SVIs von N9K-1 haben die physische MAC-Adresse 00ee.ab 67.db47. Die VLAN 10-Schnittstelle von N9K-2 hat die IP-Adresse 1921.68.10.3, und die VLAN 20-Schnittstelle von N9K-2 hat die IP-Adresse 192.168.20.3. Beide SVIs von N9K-2 haben eine MAC-Adresse: 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.
Nehmen wir ein Szenario, in dem Host-1 ein ICMP-Echoanforderungspaket an Host-2 sendet. Nachdem Host-1 ARP für sein Standardgateway (die virtuelle HSRP-IP-Adresse) aufgelöst hat, folgt Host-1 dem Standardweiterleitungsverhalten und generiert ein ICMP-Echoanforderungspaket mit der Quell-IP-Adresse 192.168.10.10, der Ziel-IP-Adresse 192.16 8.20.10, die Quell-MAC-Adresse 0000.0000.0010 und die Ziel-MAC-Adresse 0000.0c07.ac0a. Dieses Paket geht in Richtung N9K-1 aus. Ein visuelles Beispiel hierfür ist hier dargestellt.
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 ein Umschreiben 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. Ein visuelles Beispiel hierfür ist hier dargestellt.
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 aktiviert 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 verfügbar ist. N9K-1 verwirft dieses Paket als Folge dieses Verstoßes. 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-Reply-Paket (und andere Pakete, die ähnlich adressiert sind) für N9K-1 weiterleiten, obwohl die Ziel-MAC-Adresse des Pakets N9K-1 gehört und nicht N9K-2. Daher kann N9K-2 dieses Paket von seiner vPC-Po10-Schnittstelle weiterleiten, anstatt es über den vPC-Peer-Link weiterzuleiten. 1.
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 verbinden einige Benutzer einen Router über ein vPC-VLAN mit einem einzelnen vPC-Peer und bilden Unicast-Routing-Protokoll-Nachbarschaften mit beiden vPC-Peers über das vPC-VLAN. 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 kann gegenüber der Verwendung dedizierter Routing-Verbindungen zwischen dem mit vPC verbundenen Router und beiden vPC-Peers vorzuziehen sein, um die Nutzung von IP-Adressen zu sparen (3 IP-Adressen anstelle von 4 IP-Adressen erforderlich) oder die Konfigurationskomplexität zu verringern (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. Einige Benutzer können jedoch eine Topologie implementiert haben, in der Unicast-Routing-Protokoll-Nachbarschaften über einen vPC ohne Probleme entstehen, auch wenn diese 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 wie diese zu generieren:
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. Bei diesen Syslogs handelt es sich um Warnungen an den Administrator, dass Routing-Konfiguration, Kosten und Gewichtung auf beiden vPC-Peers identisch sein müssen, wenn die Erweiterung Routing/Layer 3 über vPC aktiviert ist, um sicherzustellen, dass beide vPC-Peers den Datenverkehr identisch 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 Switch (auch "End of Row" genannt) im Chassis handelt, sowie um die aktuelle NX-OS-Softwareversion des Switches, 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 im VLAN 10, die unter dem OSPF-Prozess 1 aktiviert wird. N9K-1 und N9K-3 sind im OSPF-EXSTART/EXCHANGE-Status mit einem über vPC verbundenen OSPF-Router mit der IP-Adresse und der Nachbar-ID 192.168.10.3 fixiert.
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 deaktiviert waren, weil die Routing/Layer 3 over vPC-Erweiterung nicht aktiviert war, plötzlich aktiviert werden, weil diese Erweiterung aktiviert wurde, dann können je nach der Rolle der betroffenen Routing-Protokoll-Adjacencies, den über diese Adjacencies gemeldeten spezifischen Präfixen und dem aktuellen Status der Unicast-Routing-Tabelle bei der Aktivierung von Routing/Layer 3 über v PC-Erweiterung.
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 außerdem, den Abschnitt "Hinweise" in diesem Dokument eingehend auf Softwarefehler zu überprüfen, die sich auf Ihre NX-OS-Softwareversion auswirken und dazu führen können, dass Datenverkehr auf natürlicher Datenebene mit einem TTL von 1 in der Software anstatt in der 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 unter einem Unicast-Routing-Protokoll 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 einen vPC, bei denen die vPC-Peer-Gateway-Erweiterung nicht aktiviert ist, werden nicht unterstützt, da die ECMP-Hashing-Entscheidung des mit vPC verbundenen Routers und seine Layer-2-Port-Channel-Hashing-Entscheidung voneinander abweichen können. In dieser Topologie würden sich zwischen Router, N9K-1 und N9K-2 erfolgreich Routing-Protokoll-Nachbarschaften bilden. Berücksichtigen Sie den Datenverkehrsfluss zwischen Router und Host. Datenverkehr auf Datenebene, der den Router zum Host durchquert, kann mit einer MAC-Zieladresse neu geschrieben werden, die zur SVI-MAC-Adresse von N9K-1 gehört (aufgrund der vom Router getroffenen ECMP-Hashing-Entscheidung), jedoch ausgehend von der Schnittstelle Ethernet1/2 (aufgrund der vom Router getroffenen Layer-2-Port-Channel-Hashing-Entscheidung).
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 das Paket aus seinem Ethernet1/2 in vPC Po20 weitergeleitet werden muss. Dies verstößt gegen die vPC-Schleifenvermeidungsregel, sodass N9K-1 das Paket in der Hardware verwirft. Dadurch können Sie in dieser Topologie Verbindungsprobleme oder Paketverluste bei einigen Datenflüssen beobachten, die die vPC-Domäne durchlaufen.
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 Unterbrechungen auf ein Minimum zu reduzieren, müssen Sie beide vPC-Erweiterungen in schneller Folge aktivieren, sodass das Fehlerszenario, das in den Unicast Routing Protocol-Nachbarschaften über einen vPC mit vPC-Peer-Gateway beschrieben wird, keine Zeit hat.
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 unter einem Unicast-Routing-Protokoll 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 einen vPC mit aktivierter vPC-Peer-Gateway-Erweiterung werden nicht unterstützt, da die vPC-Peer-Gateway-Erweiterung verhindern kann, dass Unicast-Routing-Protokoll-Nachbarschaften zwischen dem mit vPC verbundenen Router und beiden vPC-Peers entstehen. In dieser Topologie kann eine Routing-Protokoll-Adjacency zwischen dem Router und N9K-1 oder N9K-2 nicht wie erwartet generiert werden, 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 vom Router stammendes Unicast-Routing-Protokollpaket, das für N9K-1 bestimmt ist, 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 TTL (Time to Live) des Pakets dekrementiert, und die TTL der meisten Unicast-Routing-Protokollpakete ist 1. Dies führt dazu, dass die TTL des Pakets auf 0 dekrementiert und von N9K-2 verworfen wird. Aus Sicht von N9K-1 empfängt N9K-1 verbindungslokale Multicast-Routing-Protokollpakete vom Router und kann Unicast-Routing-Protokollpakete senden an den Router gesendet, empfängt aber 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 unter einem Unicast-Routing-Protokoll 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 dass die vPC-Peer-Gateway-Erweiterung aktiviert ist, werden nicht unterstützt, da die ECMP-Hashing-Entscheidung des mit dem vPC-VLAN verbundenen Routers N9K-2 dazu veranlassen kann, Datenverkehr auf Datenebene zu verwerfen, weil er gegen die vPC-Schleifenvermeidungsregel verstößt. In dieser Topologie würden sich zwischen Router, N9K-1 und N9K-2 erfolgreich Routing-Protokoll-Nachbarschaften bilden. Berücksichtigen Sie den Datenverkehrsfluss zwischen Router und Host. Datenverkehr auf Datenebene, der den Router durchquert und für den Host bestimmt ist, kann mit einer MAC-Zieladresse, die zur SVI-MAC-Adresse von N9K-2 gehört (aufgrund der vom Router getroffenen ECMP-Hashing-Entscheidung), neu geschrieben werden und von der Schnittstelle Ethernet1/1 zu N9K-1 ausgehen.
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 das Paket aus seinem Ethernet1/2 in vPC Po20 weitergeleitet werden muss. Dies verstößt gegen die vPC-Schleifenvermeidungsregel, sodass N9K-2 das Paket in der Hardware verwirft. Dadurch können Sie in dieser Topologie Verbindungsprobleme oder Paketverluste bei einigen Datenflüssen beobachten, die die vPC-Domäne durchlaufen.
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 Unterbrechungen auf ein Minimum zu reduzieren, müssen Sie beide vPC-Erweiterungen in schneller Folge aktivieren, sodass das Fehlerszenario, das in den Unicast Routing Protocol-Nachbarschaften über einen vPC mit vPC-Peer-Gateway beschrieben wird, keine Zeit hat.
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 unter einem Unicast-Routing-Protokoll 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, und ein Router, der die TTL eines Pakets auf 0 herabsetzt, muss 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 vom Router stammendes Unicast-Routing-Protokollpaket, das für N9K-2 bestimmt ist, Ethernet1/1 in Richtung N9K-1 verlässt. Dieses Paket ist für die SVI-MAC-Adresse von N9K-2 bestimmt, aber 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 Sicht von N9K-2 empfängt N9K-2 verbindungslokale Multicast-Routing-Protokollpakete vom Router und kann Unicast-Routing-Protokollpakete an den Router senden. Keine Unicast-Routing-Protokollpakete vom Router empfangen. 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. Beide vPC-Domänen sind über einen Back-to-Back-vPC-Po10 miteinander verbunden. Alle vier Switches verfügen über SVI-Schnittstellen, die unter einem Unicast-Routing-Protokoll aktiviert sind, 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 an einen Router (z. B. N9K-3) gerichtet, aber basierend auf der Layer-2-Port-Channel-Hashing-Entscheidung des ursprünglichen Routers an einen anderen Router (z. B. N9K-4) weitergeleitet werden können.
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. Beide vPC-Domänen sind über einen Back-to-Back-vPC-Po10 miteinander verbunden. Alle vier Switches verfügen über SVI-Schnittstellen, die unter einem Unicast-Routing-Protokoll aktiviert sind, 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.5(x)
- Konfigurationsleitfaden für die NX-OS-Schnittstellen bei der Cisco Nexus 9000-Serie, Version 10.4(x)
- 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 Channel (vPC) auf Switches der Cisco Nexus 7000-Serie
- Unterstützte Topologien für das Routing über Virtual Port Channel auf Nexus-Plattformen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
5.0 |
05-Dec-2024 |
Feste Header und Links, maschinelle Übersetzung und SEO-Optimierung |
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)