Manual de Troubleshooting de IP Multicast
Contents
Introduction
Este documento descreve problemas e soluções comuns para o IP Multicast.
Prerequisites
Requirements
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.
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ê verá os comandos usados para identificar rapidamente o problema e aprenderá a 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.
Nesta figura, os pacotes multicast entram na porta E0/0 do roteador 75a através de um servidor cujo endereço IP é 1.1.1.1, que envia para o grupo 224.1.1.1. Isso é conhecido como um (S,G) ou (1.1.1.1, 224.1.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. Primeiramente, insira o comando show ip mroute 224.1.1.1 para ver o que está acontecendo com o roteador 75a. Esse comando examina a rota multicast (mroute) do endereço de grupo 224.1.1.1:
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: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
(1.1.1.1, 224.1.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 é 1.1.1.1, que envia para um grupo multicast 224.1.1.1. Os pacotes entram na interface Ethernet0/0 e são encaminhados fora da interface Ethernet0/1. Este é um cenário perfeito.
Insira o comando show ip pim neighbor para ver se o roteador 72a mostra o roteador upstream (75a) como vizinho do PIM:
ip22-72a#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 2.1.1.1 Ethernet3/1 2d00h 00:01:15 v2
Na saída do comando show ip pim neighbor, o vizinho do PIM está correto.
Insira o comando show ip mroute para ver se o mroute do o roteador 72a está correto:
ip22-72a#show ip mroute 224.1.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
(*, 224.1.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
(1.1.1.1, 224.1.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#
No comando show ip mroute 224.1.1.1, você pode ver que a interface de entrada é Ethernet2/0, enquanto se espera a Ethernet3/1.
Insira o comando show ip mroute 224.1.1.1 count para ver se o tráfego multicast deste grupo chega ao roteador 72a e o que acontece a seguir:
ip22-72a#show ip mroute 224.1.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: 224.1.1.1, Source count: 1, Packets forwarded: 0, Packets received: 471
Source: 1.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0
ip22-72a#
Você pode ver em outras contagens que o tráfego é descartado devido à falha de RPF: total de 471 quedas, devido a falha de RPF - 471...
Insira o comando show ip rpf <source> para ver se existe um erro de RPF:
ip22-72a#show ip rpf 1.1.1.1 RPF information for ? (1.1.1.1) RPF interface: Ethernet2/0 RPF neighbor: ? (0.0.0.0) RPF route/mask: 1.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 origens anteriores de dados de RPF são pesquisadas por 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, será usada a rota com a menor distância administrativa.
-
Se as distâncias administrativas forem iguais, será usada esta ordem de preferência:
-
Mroutes estáticos
-
Rotas do DVMRP
-
Rotas do MBGP
-
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.
A saída do comando show ip rpf 1.1.1.1 mostra que a interface de RPF é E2/0, mas a interface de entrada deve ser E3/1.
Insira o comando show ip route 1.1.1.1 para ver por que a interface de RPF é diferente do esperado.
ip22-72a#show ip route 1.1.1.1 Routing entry for 1.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 1.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 224.1.1.1 *Jan 14 09:45:32.972: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface *Jan 14 09:45:33.020: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface *Jan 14 09:45:33.072: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface *Jan 14 09:45:33.120: IP: s=1.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.
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 1.1.1.1 255.255.255.255 2.1.1.1
Esse mroute estático afirma que, para chegar ao endereço 1.1.1.1 para RPF, use 2.1.1.1 como o próximo salto que está fora da interface E3/1.
ip22-72a#show ip rpf 1.1.1.1 RPF information for ? (1.1.1.1) RPF interface: Ethernet3/1 RPF neighbor: ? (2.1.1.1) RPF route/mask: 1.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 está correta, o número de pacotes enviados no show ip mroute count aumenta e o HostA recebe os 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
(1.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA
Incoming interface: Ethernet3/1, RPF nbr 2.1.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: 1.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: 1.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=1.1.1.1 (Ethernet3/1)
d=224.1.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:29.999: IP: s=1.1.1.1 (Ethernet3/1)
d=224.1.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:30.051: IP: s=1.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. .
Faça o diagnóstico do problema
Na figura anterior, o roteador A não encaminha os pacotes da origem para o destinatário diretamente conectado do roteador B. Observe a saída do comando show ip mroute 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ê deve ver "1.1.1.1, 224.1.1.1".
Insira o comando show ip rpf para ver se é um problema de RPF:
ROUTERA#show ip rpf 1.1.1.1 RPF information for ? (1.1.1.1) RPF interface: Ethernet0/0 RPF neighbor: ? (0.0.0.0) - directly connected RPF route/mask: 1.1.1.0/24 RPF type: unicast (connected) RPF recursion count: 0 Doing distance-preferred lookups across tables
Na saída, você vê que não é um problema de RPF. A verificação de RPF indica a E0/0 corretamente para chegar ao endereço IP de origem.
Verifique se o PIM foi configurado nas interfaces com o comando show ip pim interface:
ROUTERA#show ip pim interface
Address Interface Version/Mode Nbr Query DR
Count Intvl
1.1.1.2 Ethernet0/0 v2/Sparse-Dense 0 30 1.1.1.2
2.1.1.1 Ethernet0/1 v2/Sparse-Dense 2 30 2.1.1.2
A saída está correta, então esse não é o problema. Verifique se o roteador reconhece tráfegos ativos com o comando show ip mroute active:
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 destinatário não esteja enviando relatórios (ingressos) de Internet Group Management Protocol (IGMP) para o grupo 224.1.1.1. Você pode verificar isso usando o comando show ip igmp group:
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 2.1.1.2 224.1.1.1 Ethernet1/2 00:30:02 00:02:45 3.1.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 usando a captura de sniffer, que também vista com o comando show ip traffic:
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
(1.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
(1.1.1.1, 224.1.1.1), 00:17:46/00:02:59, flags: CTA
Incoming interface: Ethernet1/1, RPF nbr 2.1.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.
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
(1.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 o debug apenas para essa 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 1.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=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied
As mensagens de debug 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 2.1.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 comando ip multicast ttl-threshold <value> indica que todos os pacotes com um TTL menor que o limite especificado, neste 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 comando ip multicast ttl-threshold <value> com a forma no desse comando, que reverte para o valor de limite de TTL padrão de 0 ou diminua o limite de 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.
Faça o diagnóstico do problema
Na figura, o roteador 75b tem três caminhos de custo igual que voltam à origem (1.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 1.1.1.1. As informações de RPF indicam que a interface RPF é E1/3.
ip22-75b#show ip route 1.1.1.1
Routing entry for 1.1.1.0/24
Known via "ospf 1", distance 110, metric 20, type intra area
Redistributing via ospf 1
Last update from 3.1.1.1 on Ethernet1/2, 00:26:21 ago
Routing Descriptor Blocks:
* 4.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3
Route metric is 20, traffic share count is 1
2.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1
Route metric is 20, traffic share count is 1
3.1.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 1.1.1.1
RPF information for ? (1.1.1.1)
RPF interface: Ethernet1/3
RPF neighbor: ? (4.1.1.1)
RPF route/mask: 1.1.1.0/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
(1.1.1.1, 224.1.1.1), 01:30:35/00:02:59, flags: CT
Incoming interface: Ethernet1/3, RPF nbr 4.1.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 2.1.1.1
ip22-75b(config)#end
ip22-75b#show ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
RPF interface: Ethernet1/1
RPF neighbor: ? (2.1.1.1)
RPF route/mask: 1.1.1.1/0
RPF type: static mroute
RPF recursion count: 0
Doing distance-preferred lookups across tables
ip22-75b#show ip route 1.1.1.1
Routing entry for 1.1.1.0/24
Known via "ospf 1", distance 110, metric 20, type intra area
Redistributing via ospf 1
Last update from 3.1.1.1 on Ethernet1/2, 00:26:21 ago
Routing Descriptor Blocks:
* 4.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3
Route metric is 20, traffic share count is 1
2.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1
Route metric is 20, traffic share count is 1
3.1.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
(1.1.1.1, 224.1.1.1), 01:31:30/00:02:59, flags: CT
Incoming interface: Ethernet1/1, RPF nbr 2.1.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.
Na figura, o roteador 75b tem três caminhos de custo igual de volta à origem (1.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.
| Roteador 75a |
|---|
interface Tunnel0 ip address 6.1.1.1 255.255.255.0 ip pim sparse-dense-mode tunnel source Ethernet0/0 tunnel destination 5.1.1.1 ! interface Ethernet0/0 ip address 1.1.1.2 255.255.255.0 ip pim sparse-dense-mode ! interface Ethernet0/1 ip address 2.1.1.1 255.255.255.0 ! interface Ethernet0/2 ip address 3.1.1.1 255.255.255.0 ! interface Ethernet0/3 ip address 4.1.1.1 255.255.255.0 |
| Roteador 75b |
|---|
interface Tunnel0 ip address 6.1.1.2 255.255.255.0 ip pim sparse-dense-mode tunnel source Ethernet1/4 tunnel destination 1.1.1.2 ! interface Ethernet1/1 ip address 2.1.1.2 255.255.255.0 ! interface Ethernet1/2 ip address 3.1.1.2 255.255.255.0 ! interface Ethernet1/3 ip address 4.1.1.2 255.255.255.0 ! interface Ethernet1/4 ip address 5.1.1.1 255.255.255.0 ip pim sparse-dense-mode ! ip mroute 0.0.0.0 0.0.0.0 Tunnel0 |
Após configurar o túnel, digite o comando show ip mroute para ver a rota multicast (mroute) do 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
(1.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
(1.1.1.1, 224.1.1.1), 00:22:53/00:02:59, flags: CT
Incoming interface: Tunnel0, RPF nbr 6.1.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
Por que estamos recebendo mensagens de erro "INVALID_RP_JOIN" de 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 1.1.6.2 for invalid RP 1.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 1.1.6.2 for invalid RP 1.1.5.4
As Mensagens de erro do sistema do Cisco IOS Software explicam o que causa esse erro: um roteador de PIM downstream enviou uma mensagem de entrada 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.
Acredita-se que haja algum tipo de filtragem. Você precisa dar uma olhada na configuração do roteador:
interface Ethernet0/0 ip address 1.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 a instrução accept-rp na configuração deve realizar? Nos comandos de roteamento multicast IP, este documento afirma que "para configurar um roteador para aceitar ingressos ou prunes destinados a um RP especificado e para uma lista de grupos específica, use o comando de configuração global ip pim accept-rp. Para remover essa verificação, use a forma negativa desse comando.
Quando você remove o comando 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 incorreto. Digite o comando 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 1.1.5.4 (?), v2v1
Info source: 1.1.5.4 (?), via Auto-RP
Uptime: 01:00:48, expires: 00:02:07
De acordo com a saída, 1.1.5.4 é o único RP aprendido via Auto-RP 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á incorreta.
Possíveis correções
A solução é corrigir o endereço IP na instrução ip pim accept-rp, da seguinte maneira:
Altere essa instrução:
ip pim accept-rp 10.2.2.2 8
Para esta:
ip pim accept-rp 1.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 2.1.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 1.1.1.1 (?), v2v1
Info source: 1.1.1.1 (?), elected via Auto-RP
Uptime: 00:21:26, expires: 00:02:24
router2#
O RP para 224.1.1.1 é 1.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 1.1.1.2 YES NVRAM up up Ethernet1/0 2.1.1.1 YES NVRAM up up Ethernet2/0 unassigned YES NVRAM administratively down down router2#
Como o router2 não é um RP, ele não deveria ter recebido esse pacote RP-Join. Verifique por que o roteador downstream enviou o ingresso para o router2, mas não deveria:
router3#show ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 1.1.1.1 (?), v2v1
Info source: 1.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: 2.1.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 2.1.1.1 override router3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router3(config)#no ip pim rp-address 2.1.1.1 override router3(config)#exit router3#
Depois que a configuração no router3 é for corrigida, o router3 faz referência ao endereço RP correto e a mensagem de erro deixa de ser exibida.
router3#show ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 1.1.1.1 (?), v2v1
Info source: 1.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.
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 foi configurado corretamente com o comando set cgmp enable no switch A e o comando ip cgmp na interface E0/2 do roteador 75a. No entanto, os grupos multicast não são vistos no switch A quando o comando 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 o CGMP (porta 2/3) e cada porta que tem um destinatário interessado (porta 2/6). Como 0 foi listado, você pode considerar que todas as portas estão sendo inundadas desnecessariamente com o tráfego multicast, quer elas 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 2.1.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 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: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
(1.1.1.1, 224.1.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 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: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
(1.1.1.1, 224.1.1.1), 00:00:35/00:02:59, flags: CTA
Incoming interface: Ethernet1/3, RPF nbr 2.1.1.2
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 00:00:35/00:00:00
Da perspectiva do switch A, você vê 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. Digite alguns comandos debug 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 da 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 estiver ativado:
*Feb 8 12:51:41.854: IGMP: Received v2 Report from 2.1.1.3 (Ethernet0/2) for 224.1.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 2.1.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 2.1.1.2 (this system) IGMP querying router is 2.1.1.1 No multicast groups joined
Se você tiver dois roteadores na mesma sub-rede e configurar ambos para CGMP, apenas um enviará pacotes de CGMP. O roteador que envia os pacotes de CGMP é o roteador de consulta de IGMP. 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 os comandos debug 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 2.1.1.3 (Ethernet1/3) for 224.1.1.1 *Feb 8 12:58:42.422: CGMP: Received IGMP Report on Ethernet1/3 *Feb 8 12:58:42.422: from 2.1.1.3 for 224.1.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 2.1.1.3 para o grupo 224.1.1.1. Em seguida, ele envia um Ingresso CGMP ao Switch A do MAC equivalente a 224.1.1.1 com o MAC Address (USA) do host interessado 2.1.1.3. O Switch A sabe em que porta o host está localizado, portanto a marca como aberta e bloqueia as outras.
Agora as coisas devem 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 224.1.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.
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 desativados no 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 fica assim:
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), 2.1.1.0/24 que os roteadores 75a e 75b, o CGMP funcionará perfeitamente. O roteador, ao ver os pacotes da origem, enviaria um autoingresso de CGMP para o switch, que aprenderia dinamicamente em quais portas o roteador está e impediria todas as outras portas de encaminhar 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 verifica então sua tabela CAM quanto ao endereço MAC de seu host, coloca a porta associada na lista de grupos multicast e bloqueia todas as demais 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).
Assim, para o CGMP funcionar em sua topologia de tipo de trânsito, pode-se adicionar um host à mesma VLAN como roteadores 75a e 75b, como neste diagrama de rede.
Ou mova a origem na mesma sub-rede dos roteadores 72a e 75b, como neste exemplo.
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
Agora, 224.1.1.1 (01-00-5e-01-01-01) é inundado apenas nas portas 2/3 e 2/4 do roteador, e não em todas as portas do switch A.
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 225.0.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 225.1.1.1, o CGMP funciona bem. Qual é o problema de usar 225.0.0.1, já que 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 baixa do endereço multicast da Camada 3 são mapeados nos 23 bits de ordem baixa 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:
224.0.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 224.128.0.1 = 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 224.0.0.1 e 224.128.0.1 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, 224.0.0.1 e 225.0.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 pela ID de bug da Cisco CSCeg28814 (somente clientes registrados) para resolver o problema permanentemente.
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. Consulte o artigo da Microsoft Scaling Networking with RSS para obter mais informações. 
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 os flushes com o comando show interface.
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 <group-name> em qualquer interface, ele processa o switching. 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 comando show buffers input-interface e verificar 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<group-name>, em vez do comando ip igmp join-group<group-name>.
Informações Relacionadas
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
02-Dec-2013 |
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)