In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument werden verschiedene Szenarien der Multicast-Weiterleitung erläutert, wenn eine Quelle in einer vPC-Umgebung positioniert ist.
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:
Supervisor N7K-SUP2E
Linecard N7K-M348XP-25L
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Switch A und Switch B sind vPC-Peers.
Sender1 ist in VLAN 50 verbunden (10.200.255.230, 239.3.0.2)
Sender2 ist in VLAN 30 mit L3_swith/Router verbunden und für VPC-Peer über VLAN 25 bekannt (10.30.30.30, 239.3.0.2)
Receiver1 ist an einem verwaisten Port 4/1 an Switch A angeschlossen.
Receiver2 ist an einen verwaisten Port 4/1 an Switch B angeschlossen.
Switch A
Ip route 10.30.30.0/24 10.25.25.250
ip pim rp-address 10.25.25.250 group-list 224.0.0.0/4
ip pim ssm range 232.0.0.0/8
ip pim pre-build-spt
Switch B
Ip route 10.30.30.0/24 10.25.25.250
ip pim rp-address 10.25.25.250 group-list 224.0.0.0/4
ip pim ssm range 232.0.0.0/8
ip pim pre-build-spt
Receiver1 fordert fortlaufend Datenverkehr von Gruppe 239.3.0.2 an und registriert die (*,G) auf Switch A in VLAN 10.
Switch B fügt den gleichen Eintrag mithilfe von CFS hinzu. Der Receiver kann an einem verwaisten oder vPC-Member-Port im VPC-VLAN angeschlossen werden.
Da Sender1 mit VPC-VLAN-Datenverkehr verbunden ist, der an VLAN 50 gesendet wird, und beide Nexus-Geräte fügen den OIF-Eintrag (S, G) hinzu.
Beide Geräte leiten den Datenverkehr basierend auf dem internen PIM-Weiterleitungsalgorithmus weiter, da der Absender direkt mit dem vPC-VLAN verbunden ist.
Switch A# show ip pim internal vpc rpf-source
PIM vPC RPF-Source Cache for Context "default" - Chassis Role Secondary
Source: 10.200.255.230
Pref/Metric: 0/0
Ref count: 1
In MRIB: yes
Is (*,G) rpf: no
Source role: Primary
Forwarding state: Win-force (forwarding)
Switch B# show ip pim internal vpc rpf-source
PIM vPC RPF-Source Cache for Context "default" - Chassis Role Secondary
Source: 10.200.255.230
Pref/Metric: 0/0
Ref count: 1
In MRIB: yes
Is (*,G) rpf: no
Source role: secondary
Forwarding state: Win-force (forwarding)
OIF wurde auch auf beide VPC-Peers aufgefüllt.
Switch A# show ip mroute
(*, 232.0.0.0/8), uptime: 02:16:01, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
(*, 239.3.0.2/32), uptime: 01:42:35, igmp ip pim
Incoming interface: Vlan10, RPF nbr: 10.10.10.251
Outgoing interface list: (count: 1)
Vlan10, uptime: 01:42:35, igmp, (RPF)
(10.200.255.230/32, 239.3.0.2/32), uptime: 02:15:57, ip pim mrib
Incoming interface: Vlan50, RPF nbr: 10.200.255.230
Outgoing interface list: (count: 1)
Vlan10, uptime: 01:42:35, mrib
Switch B# sh ip mroute
(*, 232.0.0.0/8), uptime: 02:03:17, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
(*, 239.3.0.2/32), uptime: 01:31:59, igmp ip pim
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 1)
Vlan10, uptime: 01:31:59, igmp
(10.200.255.230/32, 239.3.0.2/32), uptime: 02:03:13, ip pim mrib
Incoming interface: Vlan50, RPF nbr: 10.200.255.230
Outgoing interface list: (count: 1)
Vlan10, uptime: 01:31:59, mrib
Receiver1 ruft den Stream ab und sobald Receiver2 eine Anfrage für dieselbe Gruppe sendet, empfängt Receiver 2 diesen ebenfalls.
Sender2 sendet den Stream an das FHRP, das L3_swith in VLAN 30 ist, das in diesem Fall auch als RP fungiert.
L3_swith leitet den Stream zum VPC-Peer im VPC VLAN 25 weiter. Dieser Datenverkehr wird als Multicast über L3 behandelt, und beide VPC-Peers erstellen den (S, G).
Receiver1- und Receiver2-Anforderung für den Multicast-Stream und (*, G), die auf beiden VPC-Peers erstellt wurden.
Da der Sender2-Stream über PIM auf SVI 25 und nicht direkt auf VPC SVI empfangen wird, leitet nur ein Gerät (DR) den Datenverkehr basierend auf dem PIM-internen Weiterleitungsalgorithmus weiter, da sich Sender 2 nicht direkt auf VPC SVI befindet.
Switch A# show ip pim internal vpc rpf-source
Source: 10.30.30.30
Pref/Metric: 1/0
Ref count: 1
In MRIB: yes
Is (*,G) rpf: no
Source role: primary
Forwarding state: Tie (forwarding)
MRIB Forwarding state: forwarding
Switch B# sh ip pim internal vpc rpf-source
Source: 10.30.30.30
Pref/Metric: 1/0
Ref count: 1
In MRIB: yes
Is (*,G) rpf: no
Source role: secondary
Forwarding state: Tie (not forwarding)
MRIB Forwarding state: not forwarding
Daher wurde OIF nur für DR verwendet.
Switch A# show ip mroute
IP Multicast Routing Table for VRF "default"
(*, 232.0.0.0/8), uptime: 02:37:29, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
(*, 239.3.0.2/32), uptime: 02:37:26, igmp ip pim
Incoming interface: Vlan25, RPF nbr: 10.25.25.250
Outgoing interface list: (count: 1)
Vlan10, uptime: 02:37:26, igmp
(10.30.30.30/32, 239.3.0.2/32), uptime: 02:37:26, ip mrib pim
Incoming interface: Vlan25, RPF nbr: 10.25.25.250
Outgoing interface list: (count: 1)
Vlan10, uptime: 02:37:26, mrib
Switch B# show ip mroute
(*, 232.0.0.0/8), uptime: 02:38:15, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
(*, 239.3.0.2/32), uptime: 02:38:15, igmp ip pim
Incoming interface: Vlan25, RPF nbr: 10.25.25.250
Outgoing interface list: (count: 1)
Vlan10, uptime: 02:38:15, igmp
(10.30.30.30/32, 239.3.0.2/32), uptime: 02:38:15, ip mrib pim
Incoming interface: Vlan25, RPF nbr: 10.25.25.250
Outgoing interface list: (count: 1) >>>>>> no OIF
In diesem Fall, da Receiver1 den Stream abruft und Receiver 2 den Stream aufgrund fehlender OIF-Dateien auf Switch B nie abruft.
Multicast-Datenverkehr wird an nur einen Empfänger in VLAN10 weitergeleitet, der mit dem primären vPC-Peer verbunden ist, während der mit dem sekundären Peer verbundene Empfänger diesen nicht empfängt.
Dies ist eine Designeinschränkung.
Auf beiden Switches kann OIF nur installiert werden, wenn der Datenverkehr direkt vom Absender im VPC-VLAN und nicht vom PIM weitergeleitet wird.
Daher wird OIF in VRF A als Absender installiert, der direkt mit VRF A verbunden ist, jedoch nicht in VRF B, da er über PIM verbunden ist.
Um das OIF auf beiden VPC-Peers abzurufen, sollte der Absender direkt mit dem VPC-VLAN verbunden sein.
Diese Funktion wird später als Teil der "L3 over VPC"-Funktion implementiert.