Troubleshooting do Guia de Multicast IP

Insira mais alguns comandos debug:

ip22-72a#debug ip mpacket 224.1.1.1 
*Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface

Os pacotes entram na E3/1, o que está correto. No entanto, eles são descartados porque essa não é a interface que a tabela de roteamento unicast usa para a verificação de RPF.

Observação: a depuração de pacotes é perigosa. A depuração de pacotes aciona o switching de processos dos pacotes multicast, o que consome muito a CPU. Além disso, a depuração de pacotes pode produzir uma saída enorme, que pode travar completamente o roteador devido à saída lenta para a porta do console. Antes de depurar pacotes, é necessário ter um cuidado especial para desativar a saída de registro no console e ativar o registro no buffer de memória. Para fazer isso, configure no logging console e logging buffered debugging. Você pode ver os resultados do debug usando o comando show logging.

Possíveis correções

Você pode alterar a tabela de roteamento unicast para atender a esse requisito ou pode adicionar um mroute estático para compelir o multicast para o RPF fora de uma interface específica, independentemente do que indica a tabela de roteamento unicast. Adicione um mroute estático:

ip22-72a(config)#ip mroute 10.1.1.1 255.255.255.255 10.2.1.1

Esse mroute estático afirma que, para chegar ao endereço 10.1.1.1 para RPF, use 10.2.1.1 como o próximo salto que está fora da interface E3/1.

ip22-72a#show ip rpf 10.1.1.1 
RPF information for ? (10.1.1.1) 
  RPF interface: Ethernet3/1 
  RPF neighbor: ? (10.2.1.1) 
  RPF route/mask: 10.1.1.1/32 
  RPF type: static mroute 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

A saída de show ip mroute debug ip mpacket and parece boa, o número de pacotes enviados no show ip mroute count aumenta e o HostA recebe pacotes.

ip22-72a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00 Ethernet3/2, Forward/Sparse-Dense, 00:00:58/00:00:00 (10.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA Incoming interface: Ethernet3/1, RPF nbr 10.2.1.1, Mroute Outgoing interface list: Ethernet3/2, Forward/Sparse-Dense, 00:00:48/00:00:00 ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2378 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.1.1.1, Source count: 1, Packets forwarded: 1019, Packets received: 1019 Source: 10.1.1.1/32, Forwarding: 1019/1/100/0, Other: 1019/0/0 ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2378 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.1.1.1, Source count: 1, Packets forwarded: 1026, Packets received: 1026 Source: 10.1.1.1/32, Forwarding: 1026/1/100/0, Other: 1026/0/0 ip22-72a# ip22-72a#debug ip mpacket 224.1.1.1 *Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward

O roteador não encaminha os pacotes multicast para o host devido à configuração de TTL da origem

Esta seção oferece ornece uma solução para o problema comum de pacotes IP multicast que não são encaminhados porque o valor de Time To Live (TTL) é reduzido a zero. Esse é um problema comum, pois existem muitas aplicações multicast. Essas aplicações multicast são criadas principalmente para o uso da LAN e, dessa forma, definem o TTL como um valor baixo ou até mesmo 1. Use este diagrama de rede como exemplo. 

Aplicativos multicast projetados principalmente para o exemplo de uso de LAN

Faça o diagnóstico do problema

Na figura anterior, o Roteador A não encaminha pacotes das fontes para o Roteador B que está diretamente conectado ao Receptor. Examine a saída   show ip mroute  do comando no Roteador A para ver o estado de roteamento multicast:

ROUTERA#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 00:00:01/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:01/00:00:00 (*, 224.1.1.1), 00:00:02/00:02:57, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:02/00:00:00 

Você pode ignorar o 224.0.1.40 na saída, pois todos os roteadores ingressam neste grupo de descoberta do Auto-RP. Mas não há origem listada para 224.1.1.1. Além de "*, 224.1.1.1", você não pode ver "10.1.1.1, 224.1.1.1".

Insira o comando show ip rpf para ver se é um problema de RPF:

ROUTERA#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet0/0 RPF neighbor: ? (0.0.0.0) - directly connected RPF route/mask: 10.1.1.1/24 RPF type: unicast (connected) RPF recursion count: 0 Doing distance-preferred lookups across tables 

Na saída, não é um problema de RPF. A verificação de RPF aponta corretamente E0/0 para chegar ao endereço IP origem.

Verifique se o PIM está configurado nas interfaces com o comandoshow ip pim interface:

ROUTERA#show ip pim interface Address Interface Version/Mode Nbr Query DR Count Intvl 10.1.1.2 Ethernet0/0 v2/Sparse-Dense 0 30 10.1.1.2 10.2.1.1 Ethernet0/1 v2/Sparse-Dense 2 30 10.2.1.2 

A saída está correta, então esse não é o problema. Verifique se o roteador reconhece qualquer tráfego ativo com o show ip mroute active comando:

ROUTERA#show ip mroute active Active IP Multicast Sources - sending >= 4 kbps 

Com base na saída, o roteador não reconhece tráfegos ativos.

ROUTERA#debug ip mpacket IP multicast packets debugging is on 

Talvez o receptor não envie nenhum relatório de Internet Group Management Protocol (IGMP) (junções) para o grupo 224.1.1.1. Você pode verificá-lo com o show ip igmp group  comando:

ROUTERB#show ip igmp group IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.0.1.40 Ethernet1/1 00:34:34 never 10.2.1.2 224.1.1.1 Ethernet1/2 00:30:02 00:02:45 10.3.1.2 

224.1.1.1 ingressou na E1/2, o que está correto.

O modo denso de PIM é um protocolo de inundação e remoção; portanto, não há junções, mas há enxertos. Como o roteador B não recebeu uma inundação do roteador A, ele não sabe para onde enviar um graft.

Você pode verificar se é um problema de TTL com a captura do farejador e também visto com o show ip traffic  comando:

ROUTERA#show ip traffic IP statistics: Rcvd: 248756 total, 1185 local destination 0 format errors, 0 checksum errors, 63744 bad hop count 0 unknown protocol, 0 not a gateway 0 security failures, 0 bad options, 0 with options 

A saída mostra 63744 contagens de saltos incorretos. Cada vez que você digita esse comando, a contagem de saltos incorretos aumenta. Essa é uma forte indicação de que o remetente envia os pacotes com um TTL = 1, que o roteador A reduz a zero. Isso resulta em um aumento no campo de contagem de saltos incorretos.

Possíveis correções

Para resolver o problema, você precisa aumentar o TTL. Isso é feito no nível do aplicativo no Remetente. Para obter mais informações, consulte o manual de instruções do aplicativo de multicast.

Quando você fizer isso, o roteador A ficará assim:

ROUTERA#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:16:32/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 01:16:32/00:00:00 (*, 224.1.1.1), 00:28:42/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:28:42/00:00:00 (10.1.1.1, 224.1.1.1), 00:19:24/00:02:59, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:19:24/00:00:00 

Esse é o tipo de saída que você deseja ver.

No roteador B, você vê:

ROUTERB#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:23:57/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:23:57/00:00:00 (*, 224.1.1.1), 01:19:26/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:19:26/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:19:26/00:00:00 (10.1.1.1, 224.1.1.1), 00:17:46/00:02:59, flags: CTA Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1 Outgoing interface list: Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00

O roteador não encaminha os pacotes multicast devido ao limite de TTL do roteador

Esta seção oferece uma solução para o problema comum em que o limite de TTL definido é muito baixo, de modo que o tráfego multicast IP não chega ao destinatário. Este diagrama de rede é usado como exemplo.

O limite de TTL é muito baixo para que o tráfego de multicast IP não alcance o receptor

Faça o diagnóstico do problema

Na figura anterior, o destinatário não recebe os pacotes multicast da origem. Pode haver vários roteadores entre a origem e o roteador 75a. Primeiro, observe o roteador 75a, pois ele está diretamente conectado ao destinatário.

ip22-75a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:32:05/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:08:17/00:00:00 (10.1.1.1, 224.1.1.1), 00:01:02/00:01:57, flags: CTA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:01:02/00:00:00 

A saída mostra que o roteador 75a encaminha os pacotes fora da Ethernet0/1. Para ter certeza absoluta de que o Roteador 75a encaminha os pacotes, ative debug apenas para esta origem e grupo multicast:

ip22-75a#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75a(config)#access-list 101 permit udp host 10.1.1.1 host 224.1.1.1 ip22-75a(config)#end ip22-75a#debug ip mpacket 101 IP multicast packets debugging is on for access list 101 ip22-75a# *Jan 17 09:04:08.714: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied

As debug mensagens indicam que o Roteador 75a não encaminha os pacotes multicast porque o limite de TTL foi atingido. Examine a configuração do roteador para ver se consegue encontrar o motivo. Essa saída mostra o culpado:

interface Ethernet0/1 ip address 10.2.1.1 255.255.255.0 ip pim sparse-dense-mode ip multicast ttl-threshold 15 

O roteador tem um limite de TTL de 15, mas isso não significa que algo maior que um TTL de 15 não seja enviado. Na verdade, o oposto é verdadeiro. A aplicação é enviada com um TTL de 15. Quando chega ao roteador 75a, os pacotes multicast têm um TTL menor que 15.

O comandoip multicast ttl-threshold <value> significa que todos os pacotes com um TTL inferior ao limite especificado, nesse caso, 15, não são encaminhados. Geralmente, esse comando é usado para fornecer uma barreira que impede que o tráfego multicast interno saia da intranet.

Possíveis correções

Remova o comandoip multicast ttl-threshold <value> com a forma no desse comando, que reverte para o valor de limite TTL padrão de 0, ou diminua o limite TTL para que o tráfego possa passar.

Vários caminhos de custo igual resultam em um comportamento indesejado do RPF

Esta seção mostra como caminhos de custo igual para uma origem multicast podem causar o comportamento indesejado de RPF. Também descreve como configurar o multicast IP para evitar esse comportamento. Este diagrama de rede é usado como exemplo.

Caminhos de Custo Igual para uma Origem Multicast Causa Comportamento de RPF Indesejado

Faça o diagnóstico do problema

Na figura, o roteador 75b tem três caminhos de custo igual que voltam à origem (10.1.1.1) e seleciona um link que você não deseja que seja a primeira escolha como o link de RPF.

Quando se depara com vários caminhos de custo igual para uma origem, o multicast IP seleciona a interface que tem um vizinho de Protocol Independent Multicast (PIM) com o maior endereço IP como interface de entrada e, em seguida, envia os prunes para os vizinhos de PIM nos outros links.

Possíveis correções

Para alterar a interface que o multicast IP seleciona como interface de entrada, você pode fazer um dos seguintes procedimentos:

• Configure o PIM apenas nas interfaces que deseja que sejam atravessadas pela transmissão, o que significa que você perde a redundância de transmissão.

• Altere as sub-redes para que o maior endereço IP esteja no link que você deseja que seja o link multicast primário.

• Crie uma rota multicast estática (mroute) que indique a interface multicast preferencial, o que significa que você perderá a redundância multicast.

Como exemplo, um mroute estático é criado.

Antes de instalar um mroute estático, você vê nesta saída que a tabela de roteamento tem três rotas de custo igual para o endereço de origem 10.1.1.1. As informações de RPF indicam que a interface RPF é E1/3.

ip22-75b#show ip route 10.1.1.1 Routing entry for 10.1.1.1/24 Known via "ospf 1", distance 110, metric 20, type intra area Redistributing via ospf 1 Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago Routing Descriptor Blocks: * 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 Route metric is 20, traffic share count is 1 10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 Route metric is 20, traffic share count is 1 10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 Route metric is 20, traffic share count is 1 ip22-75b#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet1/3 RPF neighbor: ? (10.4.1.1) RPF route/mask: 10.1.1.1/24 RPF type: unicast (ospf 1) RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 01:30:34/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:30:34/00:00:00 Ethernet1/1, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/3, Forward/Sparse-Dense, 00:24:22/00:00:00 (10.1.1.1, 224.1.1.1), 01:30:35/00:02:59, flags: CT Incoming interface: Ethernet1/3, RPF nbr 10.4.1.1 Outgoing interface list: Ethernet1/1, Prune/Sparse-Dense, 01:30:35/00:02:32 Ethernet1/4, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/2, Prune/Sparse-Dense, 00:24:22/00:02:42 

Depois de configurar o mroute estático, você verá nesta saída que a interface de RPF mudou para E1/1:

ip22-75b#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75b(config)#ip mroute 0.0.0.0 0.0.0.0 10.2.1.1 ip22-75b(config)#end ip22-75b#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet1/1 RPF neighbor: ? (10.2.1.1) RPF route/mask: 10.1.1.1/0 RPF type: static mroute RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-75b#show ip route 10.1.1.1 Routing entry for 10.1.1.1/24 Known via "ospf 1", distance 110, metric 20, type intra area Redistributing via ospf 1 Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago Routing Descriptor Blocks: * 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 Route metric is 20, traffic share count is 1 10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 Route metric is 20, traffic share count is 1 10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 Route metric is 20, traffic share count is 1 ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 01:31:29/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:31:29/00:00:00 Ethernet1/1, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/3, Forward/Sparse-Dense, 00:25:17/00:00:00 (10.1.1.1, 224.1.1.1), 01:31:30/00:02:59, flags: CT Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1, Mroute Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/2, Prune/Sparse-Dense, 00:25:17/00:01:47 Ethernet1/3, Prune/Sparse-Dense, 00:00:31/00:02:28

Por que o multicast IP não faz o balanceamento de carga em todos os caminhos de custo igual disponíveis?

Esta seção oferece uma solução para o problema comum no modo de configuração do multicast IP para fazer o balanceamento de carga em todos os caminhos de custo igual disponíveis. Este diagrama de rede é usado como exemplo.

Observação: antes de carregar o tráfego multicast IP dividido em caminhos de mesmo custo em um túnel, configure o balanceamento de carga por pacote CEF ou os pacotes GRE não podem ter a carga balanceada por pacote. Para obter outros métodos de compartilhamento de carga em ambientes multicast, consulte Carregar tráfego multicast de IP dividido sobre ECMP.

Configurar Multicast IP para Balancear Carga em Todos os Caminhos de Custo Igual Disponíveis

Na figura, o roteador 75b tem três caminhos de custo igual de volta à origem (10.1.1.1). Você deseja fazer o balanceamento de carga do tráfego multicast em todos os três links.

Possíveis correções

Como você viu na seção Vários caminhos de custo igual resultam em um comportamento indesejado do RPF, o Protocol Independent Multicast (PIM) seleciona apenas uma interface para a verificação de RPF e remove as outras. Isso significa que o balanceamento de carga não ocorre. Para fazer o balanceamento de carga, você precisa remover o PIM dos links redundantes e criar um túnel entre o Roteador 75a e o Roteador 75b. Depois, você pode fazer o balanceamento de carga no nível do link e o IP será executado pelo túnel.

Essas são as configurações do túnel.

interface Tunnel0 
 ip address 10.6.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
 tunnel source Ethernet0/0 
 tunnel destination 10.5.1.1 
! 
interface Ethernet0/0 
 ip address 10.1.1.2 255.255.255.0 
 ip pim sparse-dense-mode 
! 
interface Ethernet0/1 
 ip address 10.2.1.1 255.255.255.0 
! 
interface Ethernet0/2 
 ip address 10.3.1.1 255.255.255.0 
! 
interface Ethernet0/3 
 ip address 10.4.1.1 255.255.255.0

interface Tunnel0 
 ip address 10.6.1.2 255.255.255.0 
 ip pim sparse-dense-mode 
 tunnel source Ethernet1/4 
 tunnel destination 10.1.1.2 
! 
interface Ethernet1/1 
 ip address 10.2.1.2 255.255.255.0 
! 
interface Ethernet1/2 
 ip address 10.3.1.2 255.255.255.0 
! 
interface Ethernet1/3 
 ip address 10.4.1.2 255.255.255.0 
! 
interface Ethernet1/4 
 ip address 10.5.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
! 
ip mroute 0.0.0.0 0.0.0.0 Tunnel0

Depois de configurar o túnel, insira o comandoshow ip mroute para ver a rota multicast (mroute) para o grupo:

ip22-75a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 02:40:31/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 (10.1.1.1, 224.1.1.1), 02:40:32/00:03:29, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 02:42:20/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:22:53/00:00:00 Ethernet1/4, Forward/Sparse-Dense, 02:42:20/00:00:00 (10.1.1.1, 224.1.1.1), 00:22:53/00:02:59, flags: CT Incoming interface: Tunnel0, RPF nbr 10.6.1.1, Mroute Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 00:22:53/00:00:00 

Para verificar se o balanceamento de carga dos dados multicast foi realizado igualmente nos três links, observe os dados da interface do roteador 75a.

A interface de entrada é 9000 bits/seg:

ip22-75a#show interface e0/0 . . 5 minute input rate 9000 bits/sec, 20 packets/sec 

As três interfaces de saída mostram 3000 bits/seg, cada:

ip22-75a#show interface e0/1 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/2 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/3 . . 5 minute output rate 3000 bits/sec, 7 packets/sec

Quando você recebe mensagens de erro "INVALID_RP_JOIN" do Multicast IP no roteador

Esta seção oferece soluções para o problema comum da mensagem de erro "INVALID_RP_JOIN" do multicast de IP.

Faça o diagnóstico do problema – Parte 1

Estas mensagens de erro são recebidas no ponto de rendezvous (RP):

00:55:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 

O documento Mensagens de Erro do Sistema do Software Cisco IOS explica o que causa esse erro: um roteador PIM downstream enviou uma mensagem de junção para a árvore compartilhada, que este roteador não deseja aceitar. Esse comportamento indica que esse roteador permite que apenas os roteadores downstream ingressem em um RP específico.

Suspeita-se que esteja filtrando. Você precisa dar uma olhada na configuração do roteador:

interface Ethernet0/0 ip address 10.1.5.4 255.255.255.0 ip pim sparse-dense-mode ! ip pim accept-rp 10.2.2.2 8 ip pim send-rp-announce Ethernet0/0 scope 15 ip pim send-rp-discovery scope 15 ! access-list 8 permit 224.0.0.0 0.255.255.255 

Qual é a accept-rp  instrução na configuração que deve ser realizada? Em IP Multicast Routing Commands, ele afirma que "para configurar um roteador para aceitar Joins ou Prunes destinados a um RP especificado e a uma lista específica de grupos, use o ip pim accept-rp comando de configuração global. Para remover essa verificação, use a forma negativa desse comando.

Quando você remove o ip pim accept-rp comando, as mensagens desaparecem. O comando que causa o problema foi encontrado, mas e se você quiser manter esse comando na configuração? Você pode permitir o endereço RP errado. Digite o show ip pim rp mapping  comando para ver o endereço RP correto:

ip22-75a#show ip pim rp mapping PIM Group-to-RP Mappings This system is an RP (Auto-RP) This system is an RP-mapping agent Group(s) 224.0.0.0/4 RP 10.1.5.4 (?), v2v1 Info source: 10.1.5.4 (?), via Auto-RP Uptime: 01:00:48, expires: 00:02:07

Com base na saída , 10.1.5.4 é o único RP aprendido por RP automático ou de outra forma. No entanto, esse roteador é apenas o RP para os grupos 224.0.0.0/4. Portanto, a instrução pim accept-rp na configuração está errada.

Possíveis correções

A solução é corrigir o endereço IP na ip pim accept-rp instrução da seguinte maneira:

Altere essa instrução:

ip pim accept-rp 10.2.2.2 8

Para esta:

ip pim accept-rp 10.1.5.4 8

Você também pode alterar a instrução para aceitar o que está no cache auto-rp e garantir que a lista de acesso (8 neste exemplo) permita o intervalo de grupo multicast necessário. Este é um exemplo:

ip pim accept-rp auto-rp access-list 8 permit 224.0.0.0 0.255.255.255

Faça o diagnóstico do problema – Parte 2

Esta mensagem de erro é vista no router2.

router2# *Aug 12 15:18:17.891: %PIM-6-INVALID_RP_JOIN: Received (*, 224.0.1.40) Join from 0.0.0.0 for invalid RP 10.2.1.1

Verifique se o router2 é o RP para o grupo 224.1.1.1:

router2#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:21:26, expires: 00:02:24 router2#

O RP para 224.1.1.1 é 10.1.1.1.

Verifique se esta é uma das interfaces do router2:

router2#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0/0 10.1.1.2 YES NVRAM up up Ethernet1/0 10.2.1.1 YES NVRAM up up Ethernet2/0 unassigned YES NVRAM administratively down down router2#

Como o roteador 2 não é um RP, ele não deve ter recebido esse pacote RP-Join. Verifique por que o roteador downstream enviou Join para o roteador 2, embora ele não deva:

router3#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:24:30, expires: 00:02:16 Group(s): 224.0.0.0/4, Static-Override RP: 10.2.1.1 (?) router3#

Como você vê, o router3 configurou estaticamente as informações de RP e aponta para o router2, o que está incorreto. Isso explica por que o router3 envia o RP-Join para o router2.

Possíveis correções

Faça com que o router2 seja o RP para o grupo 224.1.1.1 ou altere a configuração no router3 para que faça referência ao endereço RP correto.

router3#show run | i rp ip pim rp-address 10.2.1.1 override router3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router3(config)#no ip pim rp-address 10.2.1.1 override router3(config)#exit router3#

Após a correção da configuração no roteador 3, o roteador 3 refere-se ao endereço RP correto e a mensagem de erro pára.

router3#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:30:45, expires: 00:02:02 router3#

Os fluxos de pacotes multicast duplicados são recebidos

Causa 1

Pacotes multicast duplicados são recebidos quando dois roteadores são configurados no modo denso. No modo denso, o dispositivo inunda o fluxo periodicamente. Após a inundação, ele remove as interfaces em que o fluxo não é desejado. Os dois roteadores também passam pelo processo de asserção e decidem quem é o encaminhador. Toda vez que os temporizadores são desligados, isso acontece e, até que esse processo seja concluído, os dois roteadores encaminham o fluxo. Isso faz com que a aplicação receba os fluxos multicast duplicados.

Possível correção 1

Esse problema pode ser resolvido, se você configurar um dos roteadores para roteamento multicast e o outro roteador para ser o RP no upstream. Configure-o para converter o fluxo no modo esparso, antes que o fluxo entre no roteador. Isso pode impedir que pacotes duplicados acessem a aplicação. Não faz parte da responsabilidade das redes garantir que os pacotes duplicados não cheguem a um host final. Faz parte da responsabilidade da aplicação lidar com pacotes duplicados e ignorar dados desnecessários.

Causa 2

Esse problema pode ocorrer nos switches Cisco Catalyst 6500, que são configurados para o modo de replicação multicast de saída e podem ser acionados pela remoção e reinserção de qualquer placa de linha [OIR]. Após o OIR, a porta de saída da malha [FPOE] pode ser programada incorretamente, o que pode fazer com que os pacotes sejam direcionados para o canal de saída de malha errado e enviados para as placas de linha erradas. O resultado é que eles retornam à malha e são replicados várias vezes, quando saem na placa de linha correta.

C6509#show mls ip multicast capability Current mode of replication is Egress Auto replication mode detection is ON Slot Multicast replication capability 1 Egress 2 Egress 3 Egress 4 Egress 5 Egress 6 Egress 7 Egress

Possível correção 2

Como solução alternativa, mude para o modo de replicação de entrada. Durante uma alteração do modo de replicação de saída para entrada, podem ocorrer interrupções de tráfego porque os atalhos são eliminados e reinstalados.

mls ip multicast replication-mode ingress 

Atualize o software Cisco IOS para uma versão não afetada pelo bug da Cisco ID CSCeg28814 para resolver permanentemente o problema.

Observação: somente usuários registrados da Cisco têm acesso a ferramentas internas da Cisco e informações sobre bugs.

Causa 3

Esse problema também pode ocorrer, se a configuração de RSS (Receive Side Scaling) estiver desativada nos hosts finais ou servidores.

Possível correção 3

A configuração de RSS facilita a transmissão mais rápida de dados em várias CPUs. Ative a configuração de RSS no host final ou no servidor.

Por que os pacotes multicast são descartados?

Causa 1

É possível que você veja descargas excessivas e descartes de pacotes de entrada nas interfaces, quando o tráfego de multicast flui. Você pode verificar as liberações com o comandoshow interface .

Switch#show interface gigabitethernet 1/0 !--- Output suppressed MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is SX input flow-control is off, output flow-control is on Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 2/75/0/13370328 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 195000 bits/sec, 85 packets/sec 30 second output rate 1000 bits/sec, 1 packets/sec L2 Switched: ucast: 53056 pkt, 4728434 bytes - mcast: 235759386 pkt, 66914376970 bytes L3 in Switched: ucast: 8714263 pkt, 1815426423 bytes - mcast: 1081138213 pkt,
 438000092206 bytes mcast L3 out Switched: ucast: 4939256 pkt, 790351689 bytes mcast: 0 pkt, 0 bytes 1326976857 packets input, 506833655045 bytes, 0 no buffer Received 1318209538 broadcasts, 0 runts, 0 giants, 1 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 input packets with dribble condition detected 31643944 packets output, 3124494549 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out

Possível correção 1

Você pode definir o valor de SPT como infinito para a interface em que as descargas excessivas são vistas.

Configure isto:

Switch(config-if)#ip pim spt-threshold infinity 

Causa 2

Quando você usa o comandoip igmp join-group <group-name> em qualquer interface, ele processa a comutação. Se pacotes multicast forem comutados por processo em qualquer interface, isso consumirá mais CPU, pois exige o switching de processo de todos os pacotes para esse grupo. Você pode executar o show buffers input-interface comando e verificar o tamanho anormal.

Switch#show buffers input-interface gigabitethernet 1/0 Header DataArea Pool Rcnt Size Link Enc Flags Input Output 437C6EAC 8096AE4 Middl 1 434 7 1 280 Gi1/1 None 437C74B4 8097864 Middl 1 298 7 1 280 Gi1/1 None 437C98E4 809C964 Middl 1 434 7 1 280 Gi1/1 None 437CAAFC 809F1E4 Middl 1 349 7 1 280 Gi1/1 None 437CAE00 809F8A4 Middl 1 519 7 1 280 Gi1/1 None !--- Output suppressed 

Possível correção 2

Você pode usar o ip igmp static-group <group-name> comando em vez do ip igmp join-group <group-name> comando.

Observação: devido a problemas anteriores, é possível que você veja um alto uso da CPU em torno de 90%. A CPU fica normal quando você resolve os problemas com essas correções possíveis.

Informações Relacionadas

• Solucione problemas de redes multicast com ferramentas CLI
• Manual de configuração de Multicast Quick Start

• Ativando a divisão de carga multicast ECMP 

• Suporte à tecnologia IP multicast
• Suporte aos protocolos de roteamento IP
• Suporte técnico e downloads da Cisco