Multicast-Weiterleitung in vPC basierend auf dem Standort der Quelle

Einführung

In diesem Dokument werden verschiedene Szenarien der Multicast-Weiterleitung erläutert, wenn eine Quelle in einer vPC-Umgebung positioniert ist.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• Routing und Multilcast-Weiterleitung
• Nexus-Plattformen
• Virtueller Port-Channel

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

• Nexus 7000 mit Software 8.1(1)

• 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.

Topologie

Konfigurieren

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

Quelle verbunden mit dem vPC-VLAN

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.

Quelle verbunden mit L3-Router

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. 

Quelle verbunden zwischen verschiedenen VRFs

                                                                                                                                                                                                                         

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.

1. Multicast wird an FEX auf VLAN 50 (VPC-VLAN) gesendet. In diesem Fall verfügen Switch A und Switch B über OIF für VRF B, da die Quelle direkt mit ihm verbunden ist und sich in VPC-VLAN befindet.
2. Dieser Datenverkehr wird an VLAN 51 in Richtung VRF A in einem anderen VDC weitergeleitet und an RP gesendet. 
3. Dieser VDC verfügt über VLAN 11 in VRF A und VLAN 51 in Standard-VRF.
4. Der Datenverkehr wird jetzt an Switch A VLAN 11 gesendet, der sich in VRF A befindet.
5. Nur einer von Switch A/Switch B verfügt aufgrund der gleichen Einschränkung, die im Fall mit dem L3-Router verbunden ist, über OIF für VRF A.
6. Der Receiver1, der mit OIF mit dem Switch A verbunden ist, ruft den Multicast-Stream ab.

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.

Referenz

Bekannte Fehler