In diesem Dokument wird beschrieben, wie die Befehle ip igmp join-group und ip igmp static-group innerhalb von Cisco IOS® funktionieren.
Wenn der Router den Befehl ip igmp join-group auf einer der Schnittstellen hat, wird der Router selbst zum Empfänger für den Multicast-Stream. Dieser Befehl wird verwendet, um Multicast-Datenverkehr an diesen Router ohne einen direkt angeschlossenen Empfänger oder ohne einen nachgeschalteten Protocol Independent Multicast (PIM)-Nachbar zu übertragen, der PIM-Join-Anfragen für den Multicast-Fluss sendet. Da dieser Router jedoch dem Multicast-Stream beitritt, werden alle Multicast-Pakete an die CPU geleitet. Dies kann zu einer hohen CPU führen oder dazu führen, dass die Durchsatzbegrenzer (falls vorhanden) oder der Control Plane Protection (CoPP) getroffen werden.
Eine bessere Alternative, die Sie verwenden können, um den Multicast-Stream für diesen Router anzuziehen, ist die Konfiguration des Schnittstellenbefehls ip igmp static-group. Mit diesem Befehl kann der Router den Multicast-Stream weiterhin anziehen und an der Schnittstelle weiterleiten, der Router selbst wird jedoch nicht zum Empfänger für den Stream.
Der Befehl ip igmp join-group interface und der Befehl ip igmp static-group veranlassen den PIM, Join-Anfragen an die Quelle oder an den Rendezvous Point (RP) zu senden. Dies geschieht jedoch nur, wenn der Router mit diesem Befehl der PIM Designated Router (DR) an dieser Schnittstelle ist. Um sicherzustellen, dass der Befehl wirksam wird und den Multicast-Datenverkehr anzieht, verwenden Sie den Befehl auf dem Router, der der DR für das jeweilige Netzwerk ist. Alternativ können Sie den Router, der den Befehl verwendet, als PIM DR festlegen. Hierzu müssen Sie den Befehl ip pim dr-priority auf der Schnittstelle konfigurieren und sicherstellen, dass dieser den höchsten PIM DR-Prioritätswert eines PIM-Routers in diesem Netzwerk aufweist.
Hier ein Beispiel:
In diesem Beispiel gibt es eine Quelle mit der IP-Adresse 10.1.3.3 und einen Empfänger für die Gruppe 232.1.1.1.
Dies ist der Multicast-Weiterleitungseintrag auf dem Router R1:
R1#show ip mroute 232.1.1.1 10.1.3.3
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(10.1.3.3, 232.1.1.1), 01:54:48/00:02:54, flags: sT
Incoming interface: Ethernet1/0, RPF nbr 10.1.2.2
Outgoing interface list:
Ethernet0/0, Forward/Sparse-Dense, 01:54:48/00:02:54
Wie in der Ausgabe gezeigt, befindet sich die Schnittstelle Ethernet0/0 in der OIL-Liste (Outgoing Interface List), und der (10.1.3.3, 232.1.1.1) Multicast-Datenverkehr wird an die Schnittstelle Ethernet0/0 weitergeleitet.
Dies ist auch im MFIB-Eintrag (Multicast Forwarding Information Base) zu beobachten:
R1#show ip mfib 232.1.1.1 10.1.3.3
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
ET - Data Rate Exceeds Threshold, K - Keepalive
DDE - Data Driven Event, HW - Hardware Installed
I/O Item Flags: IC - Internal Copy, NP - Not platform switched,
NS - Negate Signalling, SP - Signal Present,
A - Accept, F - Forward, RA - MRIB Accept, RF - MRIB Forward,
MA - MFIB Accept
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts: Total/RPF failed/Other drops
I/O Item Counts: FS Pkt Count/PS Pkt Count
Default
(10.1.3.3,232.1.1.1) Flags:
SW Forwarding: 0/0/0/0, Other: 0/0/0
Ethernet1/0 Flags: A
Ethernet0/0 Flags: F NS
Pkts: 0/0
Wenn der Router R1 (aus irgendeinem Grund) keine PIM-Join-Anfrage für den Multicast-Stream vom Router R4 empfängt, fließt der Multicast-Stream nicht. Ein möglicher Grund ist, dass das PIM keine Nachbarschaft zwischen den Routern R1 und R4 bilden darf, da die Router einer anderen administrativen Domäne angehören. Eine Lösung besteht darin, den Datenverkehr vom Router R1 statisch an den Router R4 weiterzuleiten.
Der Befehl ip igmp join-group wird auf der Schnittstelle Ethernet0/0 des Routers R1 verwendet. Dadurch kann der Router R1 eine PIM-Join-Anfrage an den Upstream (an die Quelle oder den RP) senden und den Multicast-Stream anziehen (10.1.3.3, 232.1.1.1). Dieser Datenverkehr wird dann an die Schnittstelle Ethernet0/0 weitergeleitet, da sich diese Schnittstelle im OIL befindet. Der Datenverkehr wird jedoch auch an die CPU geleitet.
R1#show running-config interface Ethernet 0/0
!
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip pim sparse-dense-mode
ip igmp join-group 232.1.1.1 source 10.1.3.3
end
R1#show ip mroute 232.1.1.1 10.1.3.3
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(10.1.3.3, 232.1.1.1), 00:09:30/00:02:19, flags: sLTI
Incoming interface: Ethernet1/0, RPF nbr 10.1.2.2
Outgoing interface list:
Ethernet0/0, Forward/Sparse-Dense, 00:00:40/00:02:19
Das L-Flag bedeutet, dass der Multicast-Datenverkehr gestrafft wird. Die Schnittstelle Ethernet0/0 befindet sich im OIL, sodass der Datenverkehr an die CPU geleitet und an die Schnittstelle Ethernet0/0 weitergeleitet wird.
Der MFIB-Eintrag zeigt das Internal Copy (IC)-Flag. Das bedeutet, dass die Pakete für diesen Datenfluss an die CPU geleitet werden.
R1#show ip mfib 232.1.1.1 10.1.3.3
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
ET - Data Rate Exceeds Threshold, K - Keepalive
DDE - Data Driven Event, HW - Hardware Installed
I/O Item Flags: IC - Internal Copy, NP - Not platform switched,
NS - Negate Signalling, SP - Signal Present,
A - Accept, F - Forward, RA - MRIB Accept, RF - MRIB Forward,
MA - MFIB Accept
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts: Total/RPF failed/Other drops
I/O Item Counts: FS Pkt Count/PS Pkt Count
Default
(10.1.3.3,232.1.1.1) Flags:
SW Forwarding: 0/0/0/0, Other: 0/0/0
Ethernet1/0 Flags: A
Ethernet0/0 Flags: F IC NS
Pkts: 0/0
Da der gesamte Datenverkehr für diesen Multicast-Stream gestrafft wird, kann er, wie bereits beschrieben, unerwünschte Nebenwirkungen verursachen.
Der Befehl ip igmp static-group wird als Lösung verwendet, um den Datenverkehr vom Router R1 statisch an den Router R4 weiterzuleiten. In diesem Szenario sendet der Router R1 eine PIM-Join-Anfrage an den Upstream (an die Quelle oder den RP) und zieht den Multicast-Stream an (10.1.3.3, 232.1.1.1). Dieser Datenverkehr wird dann an die Schnittstelle Ethernet0/0 weitergeleitet, da sich diese Schnittstelle im OIL befindet, der Datenverkehr jedoch nicht an die CPU geleitet wird.
R1#show running-config interface Ethernet 0/0
!
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip pim sparse-dense-mode
ip igmp static-group 232.1.1.1 source 10.1.3.3
end
R1#show ip mroute 232.1.1.1 10.1.3.3
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(10.1.3.3, 232.1.1.1), 00:07:41/stopped, flags: sTI
Incoming interface: Ethernet1/0, RPF nbr 10.1.2.2
Outgoing interface list:
Ethernet0/0, Forward/Sparse-Dense, 00:05:06/00:00:53
Das L-Flag wird nicht mehr angezeigt. Der Datenverkehr wird auf diesem Router nicht gestrafft, sondern an die Schnittstellen in der OIL weitergeleitet.
Entsprechend zeigt der MFB-Eintrag nicht das IC-Flag:
R1#show ip mfib 232.1.1.1 10.1.3.3
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
ET - Data Rate Exceeds Threshold, K - Keepalive
DDE - Data Driven Event, HW - Hardware Installed
I/O Item Flags: IC - Internal Copy, NP - Not platform switched,
NS - Negate Signalling, SP - Signal Present,
A - Accept, F - Forward, RA - MRIB Accept, RF - MRIB Forward,
MA - MFIB Accept
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts: Total/RPF failed/Other drops
I/O Item Counts: FS Pkt Count/PS Pkt Count
Default
(10.1.3.3,232.1.1.1) Flags:
SW Forwarding: 0/0/0/0, Other: 0/0/0
Ethernet1/0 Flags: A
Ethernet0/0 Flags: F NS
Pkts: 0/0
Der Befehl ip igmp static-group und der Befehl ip igmp join-group werden weder wirksam, wenn der Router R1 nicht der PIM DR für die Schnittstelle Etherent0/0 ist.
Hier ein Beispiel:
R1#show running-config interface Ethernet 0/0
!
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip pim sparse-dense-mode
ip igmp static-group 232.1.1.1 source 10.1.3.3
end
R1#show ip mroute 232.1.1.1 10.1.3.3
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(10.1.3.3, 232.1.1.1), 00:00:30/00:02:29, flags: sPT
Incoming interface: Ethernet1/0, RPF nbr 10.1.2.2
Outgoing interface list: Null
Die Schnittstelle Ethernet0/0 befindet sich nicht im OIL. Der Grund hierfür ist, dass der Router R1 nicht der PIM DR auf der Verbindung mit dem Befehl ip igmp static-group ist:
R1#show ip pim interface ethernet 0/0
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
10.1.1.1 Ethernet0/0 v2/SD 1 30 1 10.1.1.4
Der Router R1 sendet außerdem keine PIM-Join-Anfrage an Upstream. Dies ist auf dem Router R2 offensichtlich, da der Multicast-Eintrag fehlt:
R2#show ip mroute 232.1.1.1 10.1.3.3
Group 232.1.1.1 not found
Dies ist die Ausgabe, die beobachtet werden kann, sobald der Router R1 der PIM DR auf der Schnittstelle Ethernet0/0 ist:
R1#show ip pim interface ethernet 0/0
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
10.1.1.1 Ethernet0/0 v2/SD 1 30 1 10.1.1.1
R1#show ip mroute 232.1.1.1 10.1.3.3
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(10.1.3.3, 232.1.1.1), 00:02:39/00:02:55, flags: sTI
Incoming interface: Ethernet1/0, RPF nbr 10.1.2.2
Outgoing interface list:
Ethernet0/0, Forward/Sparse-Dense, 00:00:04/00:02:55
Um Probleme zu beheben, empfiehlt es sich, einen Multicast-Test auch außerhalb der Übung durchzuführen. Stellen Sie in diesem Fall sicher, dass Sie den Befehl ip igmp join-group auf sichere Weise verwenden. Der Grund, warum Sie den Befehl ip igmp join-group über den Befehl ip igmp static-group verwenden sollten, ist, dass die Multicast-Pakete gestrafft werden. Wenn Sie also einen Ping mit einem Multicast-Ziel ausführen, ist der Router mit dem Befehl ein Empfänger für den Multicast-Fluss und kann auf den Ping antworten.
Hier ein Beispiel:
Die Quelle 10.1.3.3 ist eine IP-Adresse auf dem Router R3. Wenn Sie den Befehl auf der Ethernet0/0-Schnittstelle des Routers R1 platzieren und vom Router R3 pingen, kann der Router R1 auf den Ping antworten. Daher können Sie Tests durchführen, als ob ein direkt verbundener Empfänger auf dem Router R1 vorhanden wäre. Der Befehl ip igmp join-group wird auf der Ethernet0/0-Schnittstelle des Routers R1 platziert, und die Quelle wird angegeben, um sicherzustellen, dass der Router R1 nur Datenverkehr von dieser Quelle abtastet (und darauf reagiert).
R1#show running-config interface Ethernet 0/0
!
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip pim sparse-dense-mode
ip igmp join-group 232.1.1.1 source 10.1.3.3
end
R3#ping 232.1.1.1 source 10.1.3.3
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.3.3
Reply to request 0 from 10.1.1.1, 2 ms
R3#
Der Befehl debug ip icmp auf dem Router R1 gibt an, dass der Ping angekommen ist und dass der Router R1 eine Antwort sendet:
R1#debug ip icmp
ICMP packet debugging is on
R1#
*Oct 30 11:35:41.133: ICMP: echo reply sent, src 10.1.1.1, dst 10.1.3.3,
topology BASE, dscp 0 topoid 0
Die Best Practice besteht darin, den Befehl ip igmp join-group nur dann zu verwenden, wenn er zu Testzwecken im Labor oder für einen temporären Test in einem Live-Netzwerk verwendet wird. Entfernen Sie den Befehl, nachdem alle Tests abgeschlossen sind. Wenn der Multicast-Datenverkehr nur statisch weitergeleitet werden muss, verwenden Sie stattdessen den Befehl ip igmp static-group.