Uso dei comandi Cisco IOS "ip igmp join-group" e "ip igmp static-group"
Sommario
Introduzione
In questo documento viene descritto il funzionamento dei comandi ip igmp join-group e ip igmp static-group in Cisco IOS®.
Partecipa staticamente al gruppo IGMP
se il router ha il comando ip igmp join-group su una delle interfacce, il router stesso diventa un ricevitore per il flusso multicast. Questo comando è usato per spostare il traffico multicast su questo router senza un ricevitore connesso direttamente reale o senza un vicino PIM (Protocol Independent Multicast) a valle che invia le richieste di unione PIM per il flusso multicast. Tuttavia, poiché il router si unisce al flusso multicast, tutti i pacchetti multicast vengono indirizzati alla CPU. Ciò può causare un elevato utilizzo della CPU o l'impatto di eventuali limitatori di velocità o della protezione del piano di controllo (CoPP).
Un'alternativa migliore per attirare il flusso multicast del router è configurare il comando ip igmp static-group interface. Con questo comando, il router può ancora attrarre il flusso multicast e inoltrarlo sull'interfaccia, ma il router non diventa un ricevitore per il flusso.
Sia il comando ip igmp join-group interface che il comando ip igmp static-group fanno in modo che il PIM invii richieste di join a monte verso l'origine o verso il punto di rendering (RP), ma questo si verifica solo se il router con questo comando è il router designato come PIM (DR) su quell'interfaccia. Per verificare che il comando abbia effetto e attragga il traffico multicast, usare il comando sul router che corrisponde al DR per la rete in questione. In alternativa, è possibile impostare il router che utilizza il comando PIM DR. A tale scopo, configurare il comando ip pim dr-priority sull'interfaccia e verificare che abbia il valore di priorità DR PIM più alto di qualsiasi router PIM della rete.
Di seguito è riportato un esempio:
Nell'esempio, è presente un'origine con indirizzo IP 10.1.3.3 e un ricevitore per il gruppo 232.1.1.1.
Il ricevitore è attivo
Ecco la voce di inoltro multicast sul 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
Come mostrato nell'output, l'interfaccia Ethernet0/0 è nell'elenco delle interfacce in uscita (OIL) e il traffico multicast (10.1.3.3, 232.1.1.1) viene inoltrato all'interfaccia Ethernet0/0.
È possibile osservare questa condizione anche nella voce MFIB (Multicast Forwarding Information Base):
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
Comando IGMP Join
Se il router R1 non riceve una richiesta di unione PIM per il flusso multicast dal router R4 (per qualsiasi motivo), il flusso multicast non viene trasmesso. Una delle ragioni possibili è che al PIM non è consentito formare un collegamento tra i router R1 e R4 perché i router appartengono a un dominio amministrativo diverso. La soluzione è inoltrare il traffico tra il router R1 e il router R4 in modo statico.
Il comando ip igmp join-group viene usato sull'interfaccia Ethernet0/0 sul router R1. In questo modo, il router R1 può inviare una richiesta di unione PIM a monte (alla sorgente o all'RP) e attirare il flusso multicast (10.1.3.3, 232.1.1.1). Il traffico viene quindi inoltrato all'interfaccia Ethernet0/0, poiché questa interfaccia si trova nell'interfaccia OIL. Tuttavia, il traffico viene punito anche alla 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
Il flag L indica che il traffico multicast è puntato. L'interfaccia Ethernet0/0 si trova nell'OIL, quindi il traffico viene indirizzato alla CPU e inoltrato all'interfaccia Ethernet0/0.
La voce MFIB visualizza il flag Internal Copy (IC). Ciò significa che i pacchetti per questo flusso vengono indirizzati alla 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
Poiché tutto il traffico relativo a questo flusso multicast è puntato, può causare effetti collaterali indesiderati, come descritto in precedenza.
Comando IGMP Static
il comando ip igmp static-group viene usato come soluzione per inoltrare il traffico dal router R1 verso il router R4 in modo statico. In questo scenario, il router R1 invia una richiesta di unione PIM a monte (alla sorgente o all'RP) e attrae il flusso multicast (10.1.3.3, 232.1.1.1). Il traffico viene quindi inoltrato all'interfaccia Ethernet0/0, poiché questa interfaccia si trova nell'OIL, ma il traffico non viene indirizzato alla 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
Il flag L non viene più visualizzato. Il traffico non viene puntato su questo router, ma viene inoltrato alle interfacce nell'OIL.
Analogamente, la voce MFB non mostra il flag 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
Ruolo DR PIM
Se il router R1 non è il DR PIM dell'interfaccia Ethernet0/0, non è possibile usare né il comando ip igmp static-group né il comando ip igmp join-group.
Di seguito è riportato un esempio:
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
L'interfaccia Ethernet0/0 non è presente nel campo OIL. Infatti, il router R1 non è il PIM DR sul collegamento con il 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
Inoltre, il router R1 non invia una richiesta di unione PIM a monte. Ciò è evidente sul router R2, poiché la voce multicast è mancante:
R2#show ip mroute 232.1.1.1 10.1.3.3
Group 232.1.1.1 not found
Di seguito è riportato l'output che può essere osservato non appena il router R1 è il PIM DR sull'interfaccia 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
Uso sicuro del comando ip igmp join-group
Per risolvere i problemi, potrebbe essere utile eseguire un test con multicast, anche all'esterno dell'ambiente di emulazione. In tal caso, verificare di utilizzare il comando ip igmp join-group in modo sicuro. Il motivo per cui si consiglia di utilizzare il comando ip igmp join-group sul comando ip igmp static-group è che i pacchetti multicast sono puntati. Di conseguenza, se si esegue un ping con una destinazione multicast, il router con il comando è un ricevitore per il flusso multicast e può rispondere al ping.
Di seguito è riportato un esempio:
L'origine 10.1.3.3 è un indirizzo IP sul router R3. Se si inserisce il comando sull'interfaccia Ethernet0/0 sul router R1 e si esegue il ping dal router R3, il router R1 può rispondere al ping. Per questo motivo, è possibile eseguire i test come se ci fosse un ricevitore collegato direttamente sul router R1. Il comando ip igmp join-group viene posizionato sull'interfaccia Ethernet0/0 sul router R1 e l'origine viene specificata in modo che il router R1 indirizzi solo il traffico proveniente da tale origine (e risponda ad essa).
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#
Il comando debug ip icmp sul router R1 indica che il ping è arrivato e che il router R1 invia una risposta:
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
Note importanti sull'uso dei comandi
La procedura ottimale è di non utilizzare il comando ip igmp join-group a meno che non sia per scopi di test in laboratorio o per un test temporaneo su una rete attiva. Rimuovere il comando al termine di tutti i test. Se il traffico multicast deve essere inoltrato solo in modo statico, utilizzare il comando ip igmp static-group.
Feedback