Uso do comando "ip igmp join-group" e "ip igmp static-group" do Cisco IOS

Opções de download

  • PDF     (207.1 KB)
    Ver no Adobe Reader em vários dispositivos
  • ePub     (113.3 KB)
    Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
  • Mobi (Kindle)     (109.1 KB)
    Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos
Atualizado:2 de dezembro de 2015
ID do documento:119383

Linguagem imparcial

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

Introduction

Este documento descreve como os comandos ip igmp join-group e ip igmp static-group funcionam no Cisco IOS®.

Ingressar estaticamente no grupo IGMP

Se o roteador tiver o comando ip igmp join-group em qualquer uma das interfaces, o próprio roteador se tornará um receptor para o fluxo multicast. Esse comando é usado para mover o tráfego multicast para esse roteador sem um receptor real conectado diretamente ou sem um downstream vizinho do Protocol Independent Multicast (PIM) que envia solicitações de PIM Join para o fluxo multicast. No entanto, como esse roteador ingressa no fluxo multicast, todos os pacotes multicast são direcionados para a CPU. Isso pode fazer com que a CPU esteja alta ou pode fazer com que os limitadores de taxa (se houver) ou a Proteção do plano de controle (CoPP) sejam atingidos.

Uma alternativa melhor que você pode usar para atrair o fluxo multicast para este roteador é configurar o comando de interface ip igmp static-group. Com esse comando, o roteador ainda pode atrair o fluxo multicast e encaminhá-lo para fora da interface, mas o próprio roteador não se torna um receptor para o fluxo.

Tanto o comando de interface ip igmp join-group quanto o comando ip igmp static-group fazem com que o PIM envie as solicitações Join upstream para a origem ou para o Ponto de Rendezvous (RP), mas isso só ocorre se o roteador com esse comando for o roteador designado PIM Router (DR) nessa interface. Para garantir que o comando tenha efeito e atraia o tráfego multicast, use o comando no roteador que é o DR para essa rede específica. Como alternativa, você pode tornar o roteador que usa o comando PIM DR. Para fazer isso, configure o comando ip pim dr-priority na interface e assegure-se de que ela tenha o maior valor de prioridade PIM DR de qualquer roteador PIM naquela rede.

Aqui está um exemplo:

Neste exemplo, há uma origem com o endereço IP 10.1.3.3 e um receptor para o grupo 232.1.1.1.

O receptor está ativo

Esta é a entrada de encaminhamento multicast no roteador 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 mostrado na saída, a interface Ethernet0/0 está na Lista de Interface de Saída (OIL - Outgoing Interface List) e o tráfego multicast (10.1.3.3, 232.1.1.1) é encaminhado para a interface Ethernet0/0.

Isso também pode ser observado na entrada Multicast Forwarding Information Base (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

Comando Join IGMP

Se o roteador R1 não receber uma solicitação PIM Join para o fluxo multicast do roteador R4 (por qualquer motivo), o fluxo multicast não fluirá. Uma possível razão é que o PIM não tem permissão para formar uma vizinhança entre os roteadores R1 e R4 porque os roteadores pertencem a um domínio administrativo diferente. Uma solução é encaminhar o tráfego do roteador R1 para o roteador R4 de forma estática.

O comando ip igmp join-group é usado na interface Ethernet0/0 no roteador R1. Isso permite que o roteador R1 envie uma solicitação PIM Join upstream (para a origem ou RP) e atraia o fluxo multicast (10.1.3.3, 232.1.1.1). Esse tráfego é encaminhado à interface Ethernet0/0, pois essa interface está no OIL. No entanto, o tráfego também é direcionado para a 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

O sinalizador L significa que o tráfego multicast é perfurado. A interface Ethernet0/0 está no OIL, então o tráfego é direcionado para a CPU e encaminhado para a interface Ethernet0/0.

A entrada MFIB mostra o sinalizador Cópia interna (IC). Isso significa que os pacotes para esse fluxo são direcionados para a 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

Como todo o tráfego desse fluxo multicast é perfurado, ele pode causar efeitos colaterais indesejados, como descrito anteriormente.

aviso: Não use o comando ip igmp join-group a menos que ele seja usado em um ambiente de teste.

Comando estático IGMP

O comando ip igmp static-group é usado como uma solução para encaminhar o tráfego do roteador R1 para o roteador R4 de forma estática. Nesse cenário, o roteador R1 envia uma solicitação de PIM Join upstream (para a origem ou RP) e atrai o fluxo multicast (10.1.3.3, 232.1.1.1). Esse tráfego é então encaminhado à interface Ethernet0/0, pois essa interface está no OIL, mas o tráfego não é direcionado à 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

O sinalizador L não é mais exibido. O tráfego não é direcionado para esse roteador, mas é encaminhado para as interfaces no OIL.

Da mesma forma, a entrada MFB não mostra o sinalizador 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

PIM DR Role

Nem o comando ip igmp static-group nem o comando ip igmp join-group terão efeito se o roteador R1 não for o PIM DR para a interface Ethernet0/0.

Aqui está um exemplo:

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

Note: O comando permite que uma origem seja especificada (PIM SSM) ou nenhuma fonte seja especificada (modo PIM Sparse/PIM BiDIR).

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

A interface Ethernet0/0 não está no OIL. Isso ocorre porque o roteador R1 não é o PIM DR no link com o 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

O roteador R1 também não envia uma solicitação PIM Join upstream. Isso é evidente no roteador R2, pois a entrada multicast está ausente:

R2#show ip mroute 232.1.1.1 10.1.3.3
Group 232.1.1.1 not found

Esta é a saída que pode ser observada assim que o roteador R1 for o PIM DR na interface 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 seguro do comando ip igmp join-group

Para solucionar problemas, você pode desejar executar um teste com multicast, mesmo fora do laboratório. Nesse caso, certifique-se de usar o comando ip igmp join-group de maneira segura. O motivo pelo qual você deve usar o comando ip igmp join-group sobre o comando ip igmp static-group é porque os pacotes multicast são pontuados. Como tal, se você executar um ping com um destino multicast, o roteador com o comando será um receptor para o fluxo multicast e poderá responder ao ping.

Aqui está um exemplo:

A origem 10.1.3.3 é um endereço IP no roteador R3. Se você colocar o comando na interface Ethernet0/0 no roteador R1 e efetuar ping a partir do roteador R3, o roteador R1 poderá responder ao ping. Como tal, você pode executar testes como se houvesse um receptor conectado diretamente no roteador R1. O comando ip igmp join-group é colocado na interface Ethernet0/0 no roteador R1, e a origem é especificada para garantir que o roteador R1 apenas pontua o tráfego dessa origem (e responde a ele).

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#

O comando debug ip icmp no roteador R1 indica que o ping chegou e que o roteador R1 envia uma resposta:

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

Notas importantes sobre o uso do comando

A melhor prática é não usar o comando ip igmp join-group, a menos que seja para fins de teste no laboratório ou um teste temporário em uma rede ativa. Remova o comando depois que todos os testes forem concluídos. Se o tráfego multicast tiver de ser encaminhado apenas estaticamente, use o comando ip igmp static-group em vez disso.

TAC Authored

Colaborado por engenheiros da Cisco

Este documento lhe foi útil?

FeedbackFeedback

Contate a Cisco

Este documento se refere a estes produtos