Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Topologie

Konfigurieren

Quelle verbunden mit dem vPC-VLAN

Quelle verbunden mit L3-Router

Quelle verbunden zwischen verschiedenen VRFs

Referenz

Bekannte Fehler

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

CSCtq49254 VPC: Multicast wird nicht weitergeleitet, wenn er von VPC von L3-Hop auf VPC Sec empfangen wurde.