In vPC-Topologien wird Benutzerdatenverkehr nur für verwaisten Port-Datenverkehr oder überfluteten Datenverkehr (Unicast, Broadcast, Multicast) auf dem Peer-Link angezeigt. Bei diesem Hochwasserdatenverkehr müssen Switches sicherstellen, dass der auf einer der vPC-Bereiche empfangene Hochwasserdatenverkehr nicht auf der anderen vPC-Ebene zurückgesendet wird, sodass Pakete nicht an die Quelle zurückgesendet oder an andere vPCs dupliziert werden.
Bei Carmel-basierten Switches (Nexus 55xx) ist die Implementierung der vPC-Schleifenvermeidung anders als bei einer auf Gatos (Nexus 5010/5020) basierenden Implementierung, bei der ein separates internes MCT-VLAN für überfluteten Datenverkehr über Peer-Links verwendet wird.
Da Carmel-basierte Switches L2MP oder FabricPath unterstützen, entschieden sich die Techniker für eine L2MP-basierte Weiterleitung über den Peer-Link. Bei diesem Modell verfügt der primäre vPC-Switch über eine Switch-ID von 2748(0xabc), während der sekundäre vPC-Switch über eine Switch-ID von 2749(0xabd) verfügt. Die emulierte Switch-ID von 2750(0xabe) wird als Quell-Switch-ID für Frames verwendet, die einen vPC empfangen, aber über den Peer-Link gesendet werden. Alle Ports auf dem primären vPC-Switch sind Mitglieder von FTAG 256, während die Ports auf dem sekundären vPC Mitglieder von FTAG 257 sind. Im primären vPC-Switch sind nur verwaiste Ports FTAG 257-Mitglieder, während im sekundären vPC-Switch verwaiste Ports FTAG 256-Mitglieder sind.
Für dieses Dokument bestehen keine speziellen Anforderungen.
Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).
Für Broadcast-/unbekannte Unicast-/Multicast-Frames, die an den primären vPC-Switch gesendet werden, wird eine FTAG von 256 über die Peer-Verbindung gesendet. Wenn der sekundäre vPC-Switch diesen Frame über die vPC-Peer-Verbindung empfängt, prüft er die FTAG, und seit dem 256 sendet der sekundäre vPC-Switch diesen nur noch an FTAG 256-Mitglieder, die nur verwaiste Ports sind. Für Flutdatenverkehr vom sekundären vPC wird der FTAG 257 gesendet. Wenn der primäre vPC-Switch diesen Frame abruft, sendet er den empfangenen Flut-Frame nur an Mitglieder des FTAG 257, die nur verwaiste Ports sind. Auf diese Weise implementieren Carmel-basierte Switches die Vermeidung von vPC-Schleifen.
Um die L2MP/FTAG-basierte Weiterleitung von Flood-Frames über Peer-Link zu vertiefen, wird diese Topologie verwendet:
N5K-C5596UP-109 und N5K-C5596UP-100 sind ein vPC-Paar von Nexus 5596-Switches mit NX-OS 5.2(1)N1(2a). N5K-C5596UP-109 ist der primäre vPC-Switch und N5K-C5596UP-110 der sekundäre vPC-Switch. Port-Channel 1 ist der vPC Peer-Link. Die angegebenen IP-Adressen gehören zu Schnittstelle VLAN 1 der Switches. Host 1 und Host 2 sind Cisco Switches, die über vPC in VLAN 1 verbunden sind. Diese werden in diesem Dokument als Host 1 und Host 2 bezeichnet. In VLAN 1 ist auf beiden Switches ein verwaister Port mit Eth1/32 verbunden.
Hier einige Befehlsausgaben der Switches:
N5K-C5596UP-109# show vpc Legend: (*) - local vPC is down, forwarding via vPC peer-link vPC domain id : 2 Peer status : peer adjacency formed ok vPC keep-alive status : peer is alive Configuration consistency status : success Per-vlan consistency status : success Type-2 consistency status : success vPC role : primary Number of vPCs configured : 2 Peer Gateway : Enabled Peer gateway excluded VLANs : - Dual-active excluded VLANs : - Graceful Consistency Check : Enabled Auto-recovery status : Disabled vPC Peer-link status --------------------------------------------------------------------- id Port Status Active vlans -- ---- ------ -------------------------------------------------- 1 Po1 up 1 vPC status ---------------------------------------------------------------------------- id Port Status Consistency Reason Active vlans ------ ----------- ------ ----------- -------------------------- ----------- 111 Po111 up success success 1 200 Po200 up success success 1 N5K-C5596UP-109# show platform fwm info l2mp myswid switch id ------------------------------------------------------------------- switch id manager ------------------------------------------------------------------- vpc role: 0 my primary switch id: 2748 (0xabc) emu switch id: 2750 (0xabe) peer switch id: 2749 (0xabd) N5K-C5596UP-109# show vpc orphan-ports Note: --------::Going through port database. Please be patient.::-------- VLAN Orphan Ports ------- ------------------------- 1 Eth1/32 N5K-C5596UP-110# show vpc Legend: (*) - local vPC is down, forwarding via vPC peer-link vPC domain id : 2 Peer status : peer adjacency formed ok vPC keep-alive status : peer is alive Configuration consistency status : success Per-vlan consistency status : success Type-2 consistency status : success vPC role : secondary Number of vPCs configured : 2 Peer Gateway : Enabled Peer gateway excluded VLANs : - Dual-active excluded VLANs : - Graceful Consistency Check : Enabled Auto-recovery status : Disabled vPC Peer-link status --------------------------------------------------------------------- id Port Status Active vlans -- ---- ------ -------------------------------------------------- 1 Po1 up 1 vPC status ---------------------------------------------------------------------------- id Port Status Consistency Reason Active vlans ------ ----------- ------ ----------- -------------------------- ----------- 111 Po111 up success success 1 200 Po200 up success success 1 N5K-C5596UP-110# show platform fwm info l2mp myswid switch id ------------------------------------------------------------------- switch id manager ------------------------------------------------------------------- vpc role: 1 my primary switch id: 2749 (0xabd) emu switch id: 2750 (0xabe) peer switch id: 2748 (0xabc) N5K-C5596UP-110# show vpc orphan-ports Note: --------::Going through port database. Please be patient.::-------- VLAN Orphan Ports ------- ------------------------- 1 Eth1/32 Now lets check on default FTAGs used and its members. N5K-C5596UP-109# show platform fwm info l2mp ftag all L2MP FTAG ------------------------------------------------------------------- ftag[0x9565b1c] id: 256 (0x100) Topology ID: 0x111 Ftag flags: 0 (invalid ftag-flags) Is stale: FALSE ftag_mask[0x973eca4] ifindex array: 0x160000c7 0x1600006e 0x1a01f000 0x15010000 0x15020000 0x1600007e 0x16000000 ifmap[0x88400fc] ifmap idx 6: ref 1, lu_mcq_alloced 0, lu_mcq 15 (orig 15) 'not pruned' ifmap idx 6: prune_ifmap 0, prune ref count 0, prune_unvisited 0 ifmap_idx 6: oifls_macg_ref_cnt 0, num_oifls 0 ifmap idx 6: ifs - sup-eth1 sup-eth2 Po200 Po1 Po111 Eth1/32 Po127 rpf: (0x0) alternate: 0 intf: Po1 (0x16000000) ftag_ucast_index: 1 ftag_flood_index: 1 ftag_mcast_index: 32 ftag_alt_mcast_index: 48 ------------------------------------------------------------------- ftag[0x9565e3c] id: 257 (0x101) Topology ID: 0x111 Ftag flags: 0 (invalid ftag-flags) Is stale: FALSE ftag_mask[0x95612b4] ifindex array: 0x1a01f000 0x15010000 0x15020000 0x16000000 ifmap[0x883b81c] ifmap idx 11: ref 1, lu_mcq_alloced 0, lu_mcq 14 (orig 14) 'not pruned' ifmap idx 11: prune_ifmap 0, prune ref count 0, prune_unvisited 0 ifmap_idx 11: oifls_macg_ref_cnt 0, num_oifls 0 ifmap idx 11: ifs - sup-eth1 sup-eth2 Po1 Eth1/32 rpf: (0x0) alternate: 1 intf: Po1 (0x16000000) ftag_ucast_index: 0 ftag_flood_index: -1 ftag_mcast_index: 0 ftag_alt_mcast_index: 0 ------------------------------------------------------------------- N5K-C5596UP-109# N5K-C5596UP-110# show platform fwm info l2mp ftag all L2MP FTAG ------------------------------------------------------------------- ftag[0x956a99c] id: 256 (0x100) Topology ID: 0x111 Ftag flags: 0 (invalid ftag-flags) Is stale: FALSE ftag_mask[0x98b4764] ifindex array: 0x16000066 0x1a01f000 0x15010000 0x15020000 0x16000000 ifmap[0x9635adc] ifmap idx 4: ref 1, lu_mcq_alloced 0, lu_mcq 15 (orig 15) 'not pruned' ifmap idx 4: prune_ifmap 0, prune ref count 0, prune_unvisited 0 ifmap_idx 4: oifls_macg_ref_cnt 0, num_oifls 0 ifmap idx 4: ifs - sup-eth1 sup-eth2 Po103 Po1 Eth1/32 rpf: (0x0) alternate: 1 intf: Po1 (0x16000000) ftag_ucast_index: 1 ftag_flood_index: -1 ftag_mcast_index: 32 ftag_alt_mcast_index: 48 ------------------------------------------------------------------- ftag[0x956acbc] id: 257 (0x101) Topology ID: 0x111 Ftag flags: 0 (invalid ftag-flags) Is stale: FALSE ftag_mask[0x97359bc] ifindex array: 0x160000c7 0x16000066 0x1600006e 0x1a01f000 0x15010000 0x15020000 0x1600007e 0x16000000 ifmap[0x95c624c] ifmap idx 7: ref 1, lu_mcq_alloced 0, lu_mcq 16 (orig 16) 'not pruned' ifmap idx 7: prune_ifmap 0, prune ref count 0, prune_unvisited 0 ifmap_idx 7: oifls_macg_ref_cnt 0, num_oifls 0 ifmap idx 7: ifs - sup-eth1 sup-eth2 Po200 Po103 Po1 Po111 Eth1/32 Po127 rpf: (0x0) alternate: 0 intf: Po1 (0x16000000) ftag_ucast_index: 0 ftag_flood_index: 1 ftag_mcast_index: 32 ftag_alt_mcast_index: 48 -------------------------------------------------------------------
Test 1: Broadcast-ARP-Datenverkehr über sekundäre vPC-Verbindungen
Eine nicht vorhandene IP 192.168.1.199 wird von Host 1 gepingt (192.168.1.101). Aus diesem Grund sendet Host 1 immer wieder eine Broadcast-ARP-Anfrage mit der Frage "Wer ist 192.168.1.199". Host 1 hasht diesen Broadcast-Datenverkehr an den sekundären vPC-Switch N5K-C5596UP-110, der ihn wiederum an alle Ports in VLAN 1 weiterleitet, einschließlich Po1, dem vPC-Peer-Link.
Ein TX-SPAN von Port-Channel 1 wird erfasst, um die FabricPath-Header dieses ARP-Broadcast anzuzeigen, der ein Frame mit mehreren Zielen in FP-Terminologie ist. Sehen Sie sich den FabricPath-Header dieses Multi-Destination-Frames an.
Da der Frame über einen vPC(vPC 111) eingeht, ist die Quell-Switch-ID able.00.000.
Ziel ist ein Broadcast-MAC FF:FF:FF:FF:FF:FF
FTAG ist 257.
Wenn dieser Frame in den primären vPC-Switch eingeht, wird der FTAG 257 überprüft. Da nur verwaiste Ports Mitglieder von FTAG 257 sind, wird dieser Broadcast-ARP-Frame nur an Eth 1/32 gesendet.
Test 2: Unbekannter Unicast-Frame kommt in sekundäres vPC-System
Um unbekannten Unicast-Datenverkehr einzuführen, richtete ich auf Host 1 ein statisches ARP für 192.168.1.99 mit einer statischen MAC von 0001.0002.0003 ein und ping an 192.168.1.99. Die ICMP-Echoanfrage erreicht den Nexus 500-C5596UP-110. Da die Adresse nicht weiß, wo sich der MAC 0001.0002.0003 befindet, wird dieser Frame im VLAN inklusive Peer-Link überflutet.
Ein TX-SPAN von Port-Channel 1 wird erfasst, um die FabricPath-Header dieses unbekannten Unicast-Flood-Frames zu betrachten, der in FP-Terminologie ein Frame mit mehreren Zielen ist. Sehen Sie sich den FabricPath-Header dieses Multi-Destination-Frames an.
Da der Frame über einen vPC(vPC 11) eingeht, ist die Quell-Switch-ID abzurufen.00.000
Das Ziel ist eine Multicast-MAC-Adresse 01:bb:cc:dd:01:01
FTAG ist 257.
Wenn dieser Frame in den primären vPC-Switch eingeht, wird der FTAG 257 überprüft. Da nur verwaiste Ports Mitglieder von FTAG 257 sind, wird dieser primäre vPC-Switch diesen Frame nur an den verwaisten Port Eth 1/32 überfluten.
Aufgrund des obigen Mechanismus ist der folgende Fluss für den überfluteten Datenverkehr, der an den sekundären vPC-Switch geleitet wird.
Test 3: Übertragung von ARP-Datenverkehr über vPC Primary
Eine nicht vorhandene IP 192.168.1.200 wird von Host 2 gepingt (192.168.1.69). Aus diesem Grund sendet Host 2 immer wieder eine Broadcast-ARP-Anfrage mit der Frage "Wer ist 192.168.1.200". Host 2 hash diesen Broadcast-Datenverkehr an den vPC Primary Switch N5K-C5596UP-109, der ihn wiederum an alle Ports in VLAN 1 überflutet, einschließlich Po1, dem vPC Peer-Link.
Ein TX-SPAN von Port-Channel 1 wird erfasst, um die FabricPath-Header dieses ARP-Broadcast anzuzeigen, der ein Frame mit mehreren Zielen in FP-Terminologie ist. Sehen Sie sich den FabricPath-Header dieses Multi-Destination-Frames an.
Da der Frame über einen vPC(vPC 200) eingeht, ist die Quell-Switch-ID abrufbar.00.000
Ziel ist ein Broadcast-MAC FF:FF:FF:FF:FF:FF
FTAG ist 256.
Wenn dieser Frame in den sekundären vPC-Switch eingeht, wird der FTAG 256 überprüft. Da nur verwaiste Ports Mitglieder des FTAG 256 sind, wird dieser Broadcast-ARP-Frame nur an Eth 1/32 gesendet.
Test 4: Unbekannter Unicast-Frame kommt in vPC Primary
Um unbekannten Unicast-Datenverkehr einzuführen, wird auf Host 2 ein statisches ARP für den 192.168.1.200 mit einer statischen MAC-Adresse von 0003.0004.0005 und 192.168.1.200 eingerichtet. Die ICMP-Echoanfrage hackt auf den primären vPC N5K-C5596UP-109 und weil sie nicht weiß, wo sich MAC 0003.0004.0005 befindet, überflutet sie diesen Frame im VLAN, einschließlich Peer-Link. Ein TX-SPAN von Port-Channel 1 wird erfasst, um die FabricPath-Header dieses unbekannten Unicast-Flood-Frames zu betrachten, der in FP-Terminologie ein Frame mit mehreren Zielen ist. Sehen Sie sich den FabricPath-Header dieses Multi-Destination-Frames an.
Da der Frame über einen vPC(vPC 200) eingeht, ist die Quell-Switch-ID abrufbar.00.000
Das Ziel ist eine Multicast-MAC 01:bb:cc:dd:01:01, die für unbekannte Unicast-Flooding verwendet wird.
FTAG ist 256.
Wenn dieser Frame in den sekundären vPC-Switch eingeht, wird der FTAG 257 überprüft. Da nur verwaiste Ports Mitglieder von FTAG 256 sind, wird dieser primäre vPC-Switch diesen Frame nur an den verwaisten Port Eth 1/32 überfluten.
Aufgrund des obigen Mechanismus ist der folgende Fluss für den überfluteten Datenverkehr, der in den primären vPC-Switch eingeht.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
03-Jul-2014 |
Erstveröffentlichung |