Contents

Introduction

Ingressar estaticamente no grupo IGMP

O receptor está ativo

Comando Join IGMP

Comando estático IGMP

PIM DR Role

Uso seguro do comando ip igmp join-group

Notas importantes sobre o uso do comando

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.