Este documento describe cómo funcionan los comandos ip igmp Join-group e ip igmp static-group dentro de Cisco IOS®.
Si el router tiene el comando ip igmp Join-group en cualquiera de las interfaces, el propio router se convierte en un receptor para el flujo multicast. Este comando se utiliza para mover el tráfico de multidifusión a este router sin un receptor realmente conectado directamente o sin un vecino de multidifusión independiente de protocolo (PIM) descendente que envíe solicitudes de unión PIM para el flujo de multidifusión. Sin embargo, debido a que este router se une al flujo multicast, todos los paquetes multicast son impulsados a la CPU. Esto puede provocar un uso excesivo de la CPU o puede provocar que se produzcan los limitadores de velocidad (si los hubiera) o la protección del plano de control (CoPP).
Una mejor alternativa que puede utilizar para atraer el flujo multicast para este router es configurar el comando de interfaz ip igmp static-group. Con este comando, el router todavía puede atraer el flujo multicast y reenviarlo a la interfaz, pero el router en sí no se convierte en un receptor para el flujo.
Tanto el comando de interfaz ip igmp Join-group como el comando ip igmp static-group hacen que el PIM envíe solicitudes de unión ascendente hacia el origen o hacia el punto de encuentro (RP), pero esto sólo ocurre si el router con este comando es el router designado (DR) PIM en esa interfaz. Para asegurarse de que el comando surta efecto y atraiga el tráfico multicast, utilice el comando en el router que es el DR para esa red en particular. Alternativamente, puede hacer que el router que utiliza el comando PIM DR. Para hacer esto, configure el comando ip pim dr-priority en la interfaz y asegúrese de que tenga el valor de prioridad PIM DR más alto de cualquier router PIM en esa red.
Aquí tiene un ejemplo:
En este ejemplo, hay un origen con la dirección IP 10.1.3.3 y un receptor para el grupo 232.1.1.1.
Esta es la entrada de reenvío multicast en el 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
Como se muestra en el resultado, la interfaz Ethernet0/0 se encuentra en la lista de interfaces salientes (OIL), y el tráfico de multidifusión (10.1.3.3, 232.1.1) se reenvía a la interfaz Ethernet0/0.
Esto también se puede observar en la entrada de la Base de información de reenvío multidifusión (MFIB):
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
Si el router R1 no recibe una solicitud de unión PIM para el flujo multicast del router R4 (por cualquier motivo), el flujo multicast no fluye. Una razón posible es que el PIM no puede formar una vecindad entre los routers R1 y R4 porque los routers pertenecen a un dominio administrativo diferente. Una solución es reenviar el tráfico del router R1 hacia el router R4 de una manera estática.
El comando ip igmp Join-group se utiliza en la interfaz Ethernet0/0 en el router R1. Esto permite que el router R1 envíe una solicitud de unión PIM ascendente (al origen o RP) y atraiga el flujo multicast (10.1.3.3, 232.1.1.1). Este tráfico luego se reenvía a la interfaz Ethernet0/0, ya que esta interfaz está en el OIL. Sin embargo, el tráfico también se impulsa a la CPU.
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
El indicador L significa que se impulsa el tráfico multicast. La interfaz Ethernet0/0 está en el OIL, por lo que el tráfico se envía a la CPU y se reenvía a la interfaz Ethernet0/0.
La entrada MFIB muestra el indicador Copia interna (IC). Esto significa que los paquetes para este flujo son impulsados a la CPU.
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
Debido a que todo el tráfico de esta secuencia multicast se impulsa, puede causar efectos secundarios no deseados, como se ha descrito anteriormente.
El comando ip igmp static-group se utiliza como solución para reenviar el tráfico del router R1 hacia el router R4 de una manera estática. En este escenario, el router R1 envía una solicitud de unión PIM ascendente (al origen o RP) y atrae el flujo multicast (10.1.3.3, 232.1.1.1). Este tráfico luego se reenvía a la interfaz Ethernet0/0, ya que esta interfaz está en el OIL, pero el tráfico no se impulsa a la CPU.
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
El indicador L ya no aparece. El tráfico no se impulsa en este router, pero se reenvía a las interfaces en el OIL.
De manera similar, la entrada MFB no muestra el indicador IC:
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
Ni el comando ip igmp static-group ni el comando ip igmp Join-group surten efecto si el router R1 no es el PIM DR para la interfaz Ethernet0/0.
Aquí tiene un ejemplo:
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
La interfaz Ethernet0/0 no está en el OIL. Esto se debe a que el router R1 no es el PIM DR en el link con el comando ip igmp static-group:
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
El router R1 tampoco envía una solicitud de unión PIM ascendente. Esto es evidente en el router R2, ya que falta la entrada multicast:
R2#show ip mroute 232.1.1.1 10.1.3.3
Group 232.1.1.1 not found
Este es el resultado que se puede observar en cuanto el router R1 es el PIM DR en la interfaz Ethernet0/0:
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
Para resolver problemas, es posible que desee realizar una prueba con multidifusión, incluso fuera del laboratorio. En tal caso, asegúrese de utilizar el comando ip igmp Join-group de manera segura. La razón por la que debe utilizar el comando ip igmp Join-group sobre el comando ip igmp static-group es porque los paquetes multicast son impulsados. Como tal, si realiza un ping con un destino multicast, el router con el comando es un receptor para el flujo multicast y puede responder al ping.
Aquí tiene un ejemplo:
El origen 10.1.3.3 es una dirección IP en el router R3. Si coloca el comando en la interfaz Ethernet0/0 en el router R1 y hace ping desde el router R3, entonces el router R1 puede responder al ping. Como tal, puede realizar pruebas como si hubiera un receptor conectado directamente en el router R1. El comando ip igmp Join-group se coloca en la interfaz Ethernet0/0 en el router R1, y el origen se especifica para asegurarse de que el router R1 sólo ingrese tráfico de ese origen (y responda a él).
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#
El comando debug ip icmp en el router R1 indica que el ping llegó y que el router R1 envía una respuesta:
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
La mejor práctica es no utilizar el comando ip igmp Join-group a menos que sea para propósitos de prueba en el laboratorio o una prueba temporal en una red en funcionamiento. Quite el comando después de que se hayan completado todas las pruebas. Si el tráfico multicast se debe reenviar solamente estáticamente, use el comando ip igmp static-group en su lugar.