Troubleshooting do Guia de Multicast IP

Introdução

Este documento descreve problemas e soluções comuns para o IP Multicast.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas. 

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Quando você soluciona problemas de roteamento multicast, a principal preocupação é o endereço de origem. O multicast tem um conceito de verificação de encaminhamento de caminho reverso (RPF). Quando um pacote multicast chega a uma interface, o processo de RPF verifica se essa interface de entrada é a interface de saída usada pelo roteamento unicast para acessar a origem do pacote multicast. Esse processo de verificação de RPF impede a formação de loops. O roteamento multicast não encaminha um pacote, a menos que a origem do pacote seja aprovada em uma verificação de RPF. Depois que o pacote transmite essa verificação de RPF, o Multicast Routing encaminha o pacote com base apenas no endereço de destino.

Como o roteamento unicast, o roteamento multicast tem vários protocolos disponíveis, como modo denso do Protocol Independent Multicast (PIM-DM), modo esparso do PIM (PIM-SM), Distance Vector Multicast Routing Protocol (DVMRP), Multicast Border Gateway Protocol (MBGP) e Multicast Source Discovery Protocol (MSDP). Os estudos de caso neste documento mostram o processo de solução de vários problemas. Você pode ver quais comandos são usados para localizar rapidamente o problema e aprender como resolvê-lo. Os estudos de caso listados aqui são comuns em todos os protocolos, exceto onde indicado.

O roteador não encaminha os pacotes multicast para o host devido à falha de RPF

Esta seção oferece uma solução para o problema comum de uma falha de RPF de multicast IP. Este diagrama de rede é usado como exemplo.

Exemplo de diagrama de rede de falha de RPF de multicast

Nesta figura, os pacotes multicast entram na porta E0/0 do roteador 75a através de um servidor cujo endereço IP é 10.1.1.1, que envia para o grupo 10.224.1.1. Isso é conhecido como um (S,G) ou (10.1.1.1, 10.224.1.1).

Faça o diagnóstico do problema

Os hosts conectados diretamente ao roteador 75a recebem a alimentação multicast, mas os hosts conectados diretamente ao roteador 72a não. Primeiro, insira o show ip mroute 224.1.1.1  para verificar a atividade no roteador 75a. Esse comando examina a rota multicast (mroute) do endereço de grupo 10.224.1.1:

75a#show ip mroute 10.224.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 

(*, 10.224.1.1), 00:01:23/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:01:23/00:00:00 

(10.1.1.1, 10.224.1.1), 00:01:23/00:03:00, flags: TA 
  Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00 

Como o roteador executa o modo denso do PIM (você sabe que é o modo denso devido à flag D), ignore a entrada *,G e concentre-se na entrada S,G. Essa entrada informa que os pacotes multicast vieram de um servidor cujo endereço é 10.1.1.1, que envia para um grupo multicast 10.224.1.1. Os pacotes entram na interface Ethernet0/0 e são encaminhados fora da interface Ethernet0/1. Este é um cenário perfeito.

Digite o show ip pim neighbor para ver se o Roteador 72a mostra o roteador upstream (75a) como um vizinho PIM:

ip22-72a#show ip pim neighbor
PIM Neighbor Table 
Neighbor Address  Interface          Uptime    Expires   Ver  Mode 
10.2.1.1           Ethernet3/1        2d00h     00:01:15  v2 

Nos show ip pim neighbor , a vizinhança PIM parece boa.

Digite o show ip mroute  para ver se o Roteador 72a tem boa mroute:

ip22-72a#show ip mroute 10.224.1.1
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,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
 
(*, 10.224.1.1), 00:10:42/stopped, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet3/1, Forward/Dense, 00:10:42/00:00:00
    Ethernet3/2, Forward/Dense, 00:10:42/00:00:00
 
(10.1.1.1, 10.224.1.1), 00:01:10/00:02:48, flags: 
  Incoming interface: Ethernet2/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet3/1, Forward/Dense, 00:01:10/00:00:00
    Ethernet3/2, Forward/Dense, 00:00:16/00:00:00
 
ip22-72a#

Você pode ver no  show ip mroute 10.224.1.1  que a interface de entrada é Ethernet2/0, ao passo que Ethernet3/1 é esperado.

Digite o  show ip mroute 10.224.1.1 count  para ver se algum tráfego multicast desse grupo chega ao Roteador 72a e o que acontece em seguida:

ip22-72a#show ip mroute 10.224.1.1 count
IP Multicast Statistics
3 routes using 2032 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: 10.224.1.1, Source count: 1, Packets forwarded:      0, Packets received: 471
  Source:      10.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0
ip22-72a#

Você pode ver nas Outras contagens que o tráfego é descartado devido à falha de RPF: total de 471 quedas, devido à falha de RPF - 471...

Digite o show ip rpf   para ver se há um erro de RPF:

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

O Cisco IOS® calcula a interface de RPF dessa maneira. As possíveis fontes de informações de RPF são: tabela de roteamento unicast, tabela de roteamento do MBGP, tabela de roteamento do DVMRP e tabela estática mroute. Quando você calcula a interface de RPF, principalmente a distância administrativa é usada para determinar com exatidão a fonte de informações em que se baseia o cálculo de RPF. As regras específicas são:

• Todas as fontes anteriores de dados RPF são pesquisadas para uma correspondência no endereço IP de origem. Quando você usa árvores compartilhadas, o endereço RP é usado em vez do endereço de origem.

• Se mais de uma rota correspondente for encontrada, a rota com a menor distância administrativa será usada.

• Se as distâncias administrativas forem iguais, será usada esta ordem de preferência:

  1. Mroutes estáticos

  2. Rotas do DVMRP

  3. Rotas do MBGP

  4. Rotas de unicast

• Se várias entradas de uma rota ocorrerem na mesma tabela de roteamento, será usada a rota de correspondência mais longa.

O  show ip mroute 224.1.1.1 mostra que a interface RPF é E2/0, mas a interface de entrada deve ser E3/1.

Digite o  show ip mroute 224.1.1.1 para ver por que a interface RPF é diferente do que era esperado.

ip22-72a#show ip route 10.1.1.1
  Routing entry for 10.1.1.1/32
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via Ethernet2/0
   Route metric is 0, traffic share count is 1

Você pode ver nesta saída de comando show ip route 10.1.1.1 que existe uma rota estática /32, que faz com que a interface errada seja selecionada como interface de RPF.

Insira mais alguns comandos debug:

ip22-72a#debug ip mpacket 10.224.1.1 
*Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.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  e  debug ip mpacket  parece boa, o número de pacotes enviados no  show ip mroute count aumenta e o HostA recebe pacotes.

ip22-72a#show ip mroute 10.224.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 

(*, 10.224.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, 10.224.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 10.224.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: 10.224.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 10.224.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: 10.224.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 10.224.1.1 
*Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.1.1 (Ethernet3/2) len 60, mforward 
*Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.1.1 (Ethernet3/2) len 60, mforward 
*Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.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. Observe a saída do comando  show ip mroute  no Roteador A para ver o estado do 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 

(*, 10.224.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 10.224.0.40 na saída, pois todos os roteadores ingressam neste grupo de descoberta do Auto-RP. Mas não há origem listada para 10.224.1.1. Além de "*, 10.224.1.1" você pode ver "10.1.1.1, 10.224.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  show ip pim interface comando:

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 comando 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 10.224.1.1. Você pode verificá-lo com o comando  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 
10.224.1.1        Ethernet1/2          00:30:02  00:02:45  10.3.1.2 

10.224.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 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 

(*, 10.224.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, 10.224.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 

(*, 10.224.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, 10.224.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 10.224.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 

(*, 10.224.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, 10.224.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 10.224.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=10.224.1.1 len 60, threshold denied 
*Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied 
*Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied

O   debug As 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   ip multicast ttl-threshold  significa que qualquer pacote com um TTL inferior ao limite especificado, nesse caso, 15, não será encaminhado. 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  ip multicast ttl-threshold  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 10.224.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 

(*, 10.224.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, 10.224.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 10.224.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 

(*, 10.224.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, 10.224.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 comando show ip mroute  para ver a rota multicast (mroute) do grupo:

ip22-75a#show ip mroute 10.224.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 

(*, 10.224.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, 10.224.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 10.224.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 

(*, 10.224.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, 10.224.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 (*, 10.224.1.1) 
Join from 10.1.6.2 for invalid RP 10.1.5.4 
00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 10.224.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 

O que é o accept-rp  na configuração que deve realizar? 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 comando ip pim accept-rp . Para remover essa verificação, use a forma negativa desse comando.

Quando você remove o ip pim accept-rp  , 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  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. Então, o pim accept-rp a instrução na configuração está incorreta.

Possíveis correções

A solução é corrigir o endereço IP no  ip pim accept-rp   seguinte declaração:

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 10.224.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 10.224.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 10.224.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#

O CGMP não impede a inundação de pacotes multicast

Esta seção explica como a inundação indesejada de pacotes multicast pode ocorrer, quando o Cisco Group Management Protocol (CGMP) não está ativado em todos os roteadores em uma sub-rede específica e como esse problema pode ser evitado. Este diagrama de rede é usado como exemplo.

O Cisco Group Management Protocol (CGMP) não está ativado

Faça o diagnóstico do problema

Na figura, a tabela CAM estática no switch A Catalyst 5000 não mostra as portas corretas preenchidas. O roteador configurado com o CGMP não envia os pacotes de CGMP.

O CGMP está configurado corretamente com o comando set cgmp enable  no Switch A e no ip cgmp  na interface E0/2 do roteador 75a. No entanto, nenhum grupo multicast é visto no Switch A quando o  show multicast group  é emitido:

Console> (enable) show multicast group 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 
GMRP disabled 

VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type] 
----  ------------------    -----  ------------------------------------------- 

Total Number of Entries = 0

A saída desse comando deve mostrar cada porta que tem um roteador configurado com CGMP (porta 2/3) e cada porta que tem um receptor interessado nela (porta 2/6). Como 0 está listado, você pode supor que todas as portas estão desnecessariamente inundadas com tráfego multicast, quer queiram ou não.

Observações

Verifique se há vizinhos de Protocol Independent Multicast (PIM) no roteador 75a:

ip22-75a#show ip pim neighbor 
PIM Neighbor Table 
Neighbor Address  Interface          Uptime    Expires   Ver  Mode 
10.2.1.1           Ethernet0/2        00:07:41  00:01:34  v2 

A saída mostra que o roteador 75a pode ver o roteador 75b como um vizinho de PIM válido por meio do switch A.

Agora, verifique se você recebeu as informações corretas da rota multicast (mroute) nos roteadores:

ip22-75a#show ip mroute 10.224.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 

(*, 10.224.1.1), 00:14:55/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/2, Forward/Sparse-Dense, 00:14:55/00:00:00 

(10.1.1.1, 10.224.1.1), 00:14:56/00:02:59, flags: CTA 
  Incoming interface: Ethernet0/1, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/2, Forward/Sparse-Dense, 00:14:56/00:00:00 

A saída mostra que o roteador 75a encaminha os pacotes multicast fora da E0/2 para o switch A. Essa saída mostra que o roteador 75b recebe os pacotes multicast e os encaminha corretamente:

ip22-75b#show ip mroute 10.224.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 

(*, 10.224.1.1), 00:17:57/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet1/3, Forward/Sparse-Dense, 00:17:57/00:00:00 
    Ethernet1/4, Forward/Sparse-Dense, 00:17:57/00:00:00 

(10.1.1.1, 10.224.1.1), 00:00:35/00:02:59, flags: CTA 
  Incoming interface: Ethernet1/3, RPF nbr 10.2.1.2 
  Outgoing interface list: 
    Ethernet1/4, Forward/Sparse-Dense, 00:00:35/00:00:00 

Do ponto de vista do Switch A, você verá que ele vê o Roteador 75a fora da porta 2/3.

Console> (enable) show multicast router 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 

Port       Vlan 
---------  ---------------- 
 2/3       6 

Total Number of Entries = 1 

Tudo o que foi visto até agora parece bem. Insira alguns  debug comandos no Roteador 75a para ver o que você pode descobrir:

ip22-75a#debug ip cgmp 
CGMP debugging is on 
*Feb  8 12:45:22.206: CGMP: Sending self Join on Ethernet0/2 
*Feb  8 12:45:22.206:       GDA 0000.0000.0000, USA 00d0.ff2f.a002 
*Feb  8 12:46:22.234: CGMP: Sending self Join on Ethernet0/2 
*Feb  8 12:46:22.234:       GDA 0000.0000.0000, USA 00d0.ff2f.a002 
*Feb  8 12:47:22.262: CGMP: Sending self Join on Ethernet0/2 
*Feb  8 12:47:22.262:       GDA 0000.0000.0000, USA 00d0.ff2f.a002 

Na saída, 0000.0000.0000 é o endereço de todos os grupos e é usado quando os roteadores enviam mensagens de entrada/saída de CGMP para que os switches possam preencher as portas do roteador. GDA significa endereço de destino de grupo no formato de nível do controle de acesso à mídia (MAC) e EUA significa endereço de origem unicast. Este é o endereço do host que originou o relatório de IGMP para o qual essa mensagem de CGMP foi gerada. Nesse caso, é o endereço MAC da interface E0/2 do roteador 75a. O endereço MAC para E0/2 do roteador 75a pode ser visto com o comando  show interface  como visto aqui:

ip22-75a#show interface e0/2 
Ethernet0/2 is up, line protocol is up 
  Hardware is cxBus Ethernet, address is 00d0.ff2f.a002 (bia 00d0.ff2f.a002)

Além disso, você pode ver isso periodicamente quando o comando  debug ip igmp  está ativado:

*Feb  8 12:51:41.854: IGMP: Received v2 Report from 10.2.1.3 (Ethernet0/2) for 10.224.1.1

No entanto, você não verá posteriormente um pacote de CGMP correspondente no roteador 75a. Isso significa que o roteador 75a recebe relatórios de IGMP, mas não gera os pacotes de CGMP necessários para ajudar o switch A a identificar quais portas devem ser bloqueadas. É algo esperado para o roteador 75a, se ele for o consultante de IGMP. Esta saída do roteador 75a informa o motivo pelo qual o comportamento esperado não ocorre:

ip22-75a#show ip igmp interface e0/2 
Ethernet0/2 is up, line protocol is up 
  Internet address is 10.2.1.2/24 
  IGMP is enabled on interface 
  Current IGMP version is 2 
  CGMP is enabled 
  IGMP query interval is 60 seconds 
  IGMP querier timeout is 120 seconds 
  IGMP max query response time is 10 seconds 
  Last member query response interval is 1000 ms 
  Inbound IGMP access group is not set 
  IGMP activity: 3 joins, 1 leaves 
  Multicast routing is enabled on interface 
  Multicast TTL threshold is 0 
  Multicast designated router (DR) is 10.2.1.2 (this system) 
  IGMP querying router is 10.2.1.1 
  No multicast groups joined 

Se você tiver dois roteadores na mesma sub-rede e configurar ambos para CGMP, apenas um poderá enviar pacotes CGMP. O roteador que envia os pacotes CGMP é o IGMP que consulta o roteador. Significa o roteador com o menor endereço IP unicast dos roteadores ativados para IGMP.

Nesse caso, os roteadores 75a e o roteador 75b têm o IGMP ativado (o roteador 75b se tornou o roteador de consulta de IGMP), mas somente o roteador 75a tem o CGMP ativado. Como o roteador 75a não é o roteador de consulta de IGMP, nenhum pacote de CGMP é enviado.

Possíveis correções

Para resolver o problema, você precisa configurar o CGMP no roteador de consulta de IGMP. Nesse caso, o roteador 75b. Primeiro, ative debug comandos no roteador 75b:

ip22-75b#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
ip22-75b(config)#int e 1/3 
ip22-75b(config-if)#ip cgmp 
ip22-75b(config-if)#end 
ip22-75b#debug ip cgmp 
ip22-75b#debug ip igmp 
*Feb  8 12:58:42.422: IGMP: Received v2 Report from 10.2.1.3 (Ethernet1/3) for 10.224.1.1 
*Feb  8 12:58:42.422: CGMP: Received IGMP Report on Ethernet1/3 
*Feb  8 12:58:42.422:       from 10.2.1.3 for 10.224.1.1 
*Feb  8 12:58:42.422: CGMP: Sending Join on Ethernet1/3 
*Feb  8 12:58:42.422:       GDA 0100.5e01.0101, USA 0030.b655.a859 

O roteador 75b recebe um relatório IGMP de 10.2.1.3 para o grupo 10.224.1.1. Em seguida, ele envia um Ingresso CGMP ao Switch A do MAC equivalente a 10.224.1.1 com o MAC Address (USA) do host interessado 10.2.1.3. O Switch A sabe em que porta o host está localizado, portanto a marca como aberta e bloqueia as outras.

Agora, tudo deve funcionar no Switch A:

Console> (enable) show multicast group 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 
GMRP disabled 

VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type] 
----  ------------------    -----  ------------------------------------------- 
6     01-00-5e-00-01-28             2/3-4 
6     01-00-5e-01-01-01             2/3-4,2/6 

Total Number of Entries = 2 

Isto é muito melhor. Os pacotes 10.224.1.1 (01-00-5e-01-01-01) são enviados apenas pelas portas 2/3, 2/4 e 2/6 no switch A, como deveriam. A inundação em todas as outras portas foi interrompida. Agora o número total de entradas está listado corretamente como 2. O endereço MAC 01-00-5e-00-01-28 é mapeado a partir do endereço multicast 224.0.1.40, que é usado para autoingressos de CGMP.

O CGMP não impede a inundação de pacotes multicast devido ao posicionamento da origem/destinatário

Esta seção fornece uma solução para o problema comum de um Catalyst Switch que inunda o tráfego para cada porta, em vez de apenas para o host correto. Este diagrama de rede é usado como exemplo.

Switch Catalyst que inunda o tráfego para todas as portas

Faça o diagnóstico do problema

Na figura, os roteadores 75a e 75b e o Catalyst 5000 (Switch A) estão configurados corretamente para multicast e Cisco Group Management Protocol (CGMP). O host recebe o tráfego multicast. No entanto, todos os outros hosts estão fora do Switch A. O Switch A inunda o tráfego em todas as portas, o que significa que o CGMP não funciona.

A saída do comando  show multicast group no Switch A se parece com:

Console> (enable) show multicast group 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 
GMRP disabled 

VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type] 
----  ------------------    -----  ------------------------------------------- 
6     01-00-5e-00-01-28             2/3-4 

Total Number of Entries = 1 

Você pode ver pela saída que o único grupo é 224.0.1.40, que é usado pelo roteador quando envia autoingressos de CGMP para o grupo de auto-RP. Como não existem outros grupos?

Possíveis correções

Para entender a solução, você precisa entender como o CGMP se comporta sob certas condições. Um roteador ativado para CGMP envia os ingressos de CGMP para um switch, a fim de informar o switch sobre os hosts interessados em um grupo multicast específico. O switch procura os endereços MAC desses hosts na tabela CAM, em seguida, encaminha os pacotes multicast pelas portas com os hosts interessados e impede todas as outras portas de encaminhar pacotes multicast.

Um roteador envia os autoingressos de CGMP fora de uma interface ativada para CGMP, se receber pacotes multicast de uma origem que está na mesma interface em que ele (o roteador) ativou o CGMP.

Por exemplo, se a origem estava na mesma sub-rede (VLAN), 10.2.1.0/24 que os roteadores 75a e 75b, o CGMP funcionará perfeitamente. O roteador, quando identifica pacotes da origem, envia uma autojunção CGMP para o switch, que aprende dinamicamente em quais portas o roteador está e impede que todas as outras portas encaminhem pacotes multicast.

Um roteador envia os ingressos de CGMP fora de uma interface ativada para CGMP, se receber relatórios de IGMP de um host na mesma interface em que ele (o roteador) tem o CGMP ativado.

Outro exemplo é se você tivesse um host interessado na mesma VLAN. Nesse caso, quando um roteador ativado para CGMP recebe um relatório de IGMP (Internet Group Management Protocol) de um host interessado em um grupo multicast específico, o roteador envia um ingresso de CGMP. O ingresso indicaria o endereço MAC (controle de acesso à mídia) do host que deseja ingressar e o grupo ao qual deseja ingressar. O Catalyst 5000 verificaria sua tabela CAM quanto ao endereço MAC do host, colocaria a porta associada na lista de grupos multicast e bloquearia todas as outras portas não interessadas.

O mesmo não ocorre quando a origem e os hosts interessados estão em uma sub-rede diferente da sub-rede ativada para CGMP (VLAN). Os pacotes multicast, que vêm da origem, não acionam o roteador para enviar autoingressos CGMP ao switch. Portanto, os pacotes chegam ao switch e são inundados por toda parte na VLAN. Essa situação continua até que um host na VLAN, que sai de uma porta no switch, envie um ingresso de IGMP. Somente após receber um relatório de IGMP, o roteador envia um pacote de CGMP, o que faz com que o switch adicione a porta de host apropriada como encaminhamento e todas as outras portas são bloqueadas (além das portas do roteador).

Para que o CGMP funcione nessa topologia de tipo de trânsito, você pode adicionar um host à mesma VLAN que os roteadores 75a e 75b, como neste diagrama de rede.

Adicione um host à mesma VLAN que os roteadores 75a e 75b

Ou mova a origem na mesma sub-rede dos roteadores 72a e 75b, como neste exemplo.

Mova a origem para a mesma sub-rede dos roteadores 75a e 75b

Mova a origem para a mesma sub-rede e verifique a saída do switch A:

Console> (enable) show multicast router 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 

Port       Vlan 
---------  ---------------- 
 2/3       6 
 2/4       6 

Total Number of Entries = 2 
'*' - Configured 
Console> (enable) 

Console> (enable) show multicast group 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 
GMRP disabled 

VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type] 
----  ------------------    -----  ------------------------------------------- 
6     01-00-5e-00-01-28             2/3-4 
6     01-00-5e-01-01-01             2/3-4 

Total Number of Entries = 2 

O CGMP não impede a inundação de pacotes multicast para determinados endereços de grupo

Esta seção explica porque alguns endereços IP multicast faz com que o CGMP (Protocolo de gerenciamento do grupo Cisco) inunde o tráfego multicast de todas as portas de uma LAN (rede de área local). Quando você usa o endereço de grupo multicast 10.225.0.1, o CGMP não funciona. Isso inunda o fluxo de multicast de todas as portas de switch e desperdiça largura de banda. No entanto, se você alterar o endereço para 10.225.1.1, o CGMP funciona bem. Você pode usar 10.225.0.1 já que ele não é um endereço registrado para um protocolo de roteamento?

Possíveis correções

Primeiramente, é importante entender como os endereços multicast de Camada 3 são mapeados para endereços multicast de Camada 2. Todos os quadros IP multicast usam endereços de camada IEEE MAC, que começam com o prefixo de 24 bits de 0x0100.5e. Quando você mapeia endereços da Camada 3 para a Camada 2, os 23 bits de ordem inferior do endereço multicast da Camada 3 são mapeados nos 23 bits de ordem inferior do endereço MAC IEEE.

Outro fato importante a ser entendido é que existem 28 bits de espaço de endereço exclusivo para um endereço IP multicast (32 bits menos os primeiros 4 bits que contêm o prefixo 1110 classe D). Como só há 23 bits conectados ao endereço MAC IEEE, restarão 5 bits de sobreposição. Isto significa que diversos endereços de transmissão múltipla de camada 3 podem ser mapeados para o mesmo endereço de transmissão múltipla de camada 2.

Por exemplo:

10.244.0.1 = 1110 0000.0000 0000.0000 0000.0000 0001 in binary
low order 23 bits =    000 0000.0000 0000.0000 0001
hex equivalent    =     0    0    0    0    0    1
result of mapping = 0x0100.5e00.0001


10.244.128.0 = 1110 0000.1000 0000.0000 0000.0000 0001 in binary
low order 23 bits =      000 0000.0000 0000.0000 0001
hex equivalent    =       0    0    0     0    0    1
result of mapping = 0x0100.5e00.0001

Observe no exemplo que 10.244.0.1 e 10.244.128.0 são mapeados para o mesmo endereço multicast da Camada 2.

Agora que você sabe como os endereços multicast da Camada 3 para a Camada 2 são mapeados, continue com a solução específica para esse problema.

O switch A envia pacotes multicast para 224.0.0.x porque esses endereços são link-local e convém garantir que os endereços link-local acessem todos os dispositivos na rede local (LAN). Os Catalyst Switches também enviam pacotes multicast para outros endereços multicast ambíguos no nível de MAC com 224.0.0.x (por exemplo, 10.244.0.1 e 10.225.0.1, ambos são mapeados para 0100.5e00.0001). O switch inunda os pacotes multicast destinados a esses endereços link-local, independentemente de o CGMP estar ativado ou não.

Portanto, a aplicação de transmissão múltipla deve evitar o uso de endereços classe D que mapeiam para um endereço de transmissão múltipla de camada 2 de 0100.5e00.00xx, em que xx pode ser de 00 a FF em hexadecimal. Isso consiste nesses endereços de classe D:

224.0.0.x (x = 0 to 255)
225.0.0.x 
.
239.0.0.x


224.128.0.x (x = 0 to 255)
225.128.0.x
.
239.128.0.x

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 descargas com o comando  show interface  comando.

Switch#show interface gi 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 comando  ip igmp join-group   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 e verifique o tamanho anormal.

Switch#show buffers input-interface gi 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 comando   ip igmp static-group   em vez do comando  ip igmp join-group   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