IP : Protocolo IP multicast

Manual de Troubleshooting de IP Multicast

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


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.

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Informações de Apoio

Ao pesquisar defeitos o roteamento de transmissão múltipla, o interesse principal é o endereço de origem. O Multicast tem um conceito da verificação do encaminhamento de caminho reverso (verificação RPF). Quando um Multicast Packet chega em uma interface, o processo RPF verifica se essa interface de entrada é a interface de saída usada pelo Unicast Routing para atingir a origem do Multicast Packet. Esse processo de verificação de RPF impede a formação de loops. O roteamento de transmissão múltipla não envia um pacote a menos que a fonte do pacote passar uma verificação do encaminhamento de caminho reverso (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 do unicast, o roteamento de transmissão múltipla tem diversos protocolos disponíveis, tais como o modo denso da transmissão múltipla independente de protocolo (PIM-DM), o modo escasso de PIM (PIM-S), o Distance Vetora Multicast Routing Protocol (DVMRP), o protocolo multicast border gateway (MBGP), e o Multicast Source Discovery Protocol (MSDP). Os Casos Práticos neste documento andam você com o processo de pesquisar defeitos vários problemas. Você verá que comandos são usados para localizar rapidamente o problema e aprender como o resolver. Os Casos Práticos alistados aqui são genéricos através dos protocolos, exceto onde indicado.

O roteador não envia pacotes de transmissão múltipla ao host devido à falha de RPF

Esta seção fornece uma solução ao problema comum de uma falha do encaminhamento de caminho reverso do Protocolo IP multicast (RPF). Este diagrama da rede é usado como um exemplo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide1a.gif

Na figura acima, os pacotes de transmissão múltipla entram o E0/0 do roteador 75a de um server cujo o endereço IP de Um ou Mais Servidores Cisco ICM NT seja 1.1.1.1 e envie para agrupar 224.1.1.1. Isso é conhecido como um (S,G) ou (1.1.1.1, 224.1.1.1).

Diagnostique o problema

Os anfitriões conectados diretamente ao roteador 75a recebem a alimentação multicast, mas os anfitriões conectados diretamente ao roteador 72a não fazem. Primeiramente, emita o comando de 224.1.1.1 do mrouter da mostra IP ver o que está acontecendo com roteador 75a. Este comando examina a rota de transmissão múltipla (mrouter) para o 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 

Desde que o roteador é modo denso de PIM running (nós sabemos que é modo denso devido à bandeira D), ignore *, entrada G e foco no S, entrada G. Esta entrada diz-lhe que os pacotes de transmissão múltipla são originado de um server cujo o endereço seja 1.1.1.1, que envia a um grupo de transmissão múltipla de 224.1.1.1. Os pacotes estão vindo na relação do Ethernet0/0 e são enviados para fora a relação Ethernet0/1. Esta é uma encenação perfeita.

Emita o comando show ip pim neighbor ver se o roteador 72a está mostrando o roteador fluxo acima (75a) como um vizinho de 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 

Da saída do comando show ip pim neighbor, o olhar do neighborship PIM bom.

Use este comando show ip mroute ver se o roteador 72a tem o bom mrouter:

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#

Você pode ver do comando de 224.1.1.1 do mrouter da mostra IP que a interface de entrada é Ethernet2/0, quando Etheret3/1 for esperado.

Emita o comando count de 224.1.1.1 do mrouter da mostra IP ver se algum tráfego multicast para este grupo chega ao roteador 72a e o que acontece em seguida:

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 das outras contagens que o tráfego obtém deixado cair devido à falha de RPF: totalize 471 gotas, devido à falha de RPF – 471…

Emita o comando show ip rpf <source> ver se há um erro 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#

Cisco IOS� calcula a relação RPF desta maneira. As possíveis fontes de informação sobre RPF são tabela de roteamento unicast, tabela de roteamento MBGP, tabela de roteamento DVMRP e tabela do mroute estática. Quando você calcula a relação RPF, primeiramente a distância administrativa está usada para determinar exatamente que o origem de informação o cálculo de RPF é baseado sobre. As regras específicas são:

  • Todas as fontes precedentes de dados RPF são procuradas por um fósforo no endereço IP de origem. Ao usar árvores compartilhadas, o endereço RP é usado em vez do endereço de origem.

  • Se mais de uma rota de harmonização é encontrada, a rota com a distância administrativa mais baixa está usada.

  • Se as distâncias administrativas são iguais, a seguir este ordem de preferência está usado:

    1. Mroutes estática

    2. Rotas DVMRP

    3. Rotas MBGP

    4. Rotas de unicast

  • Se as entradas múltiplas para uma rota ocorrem dentro da mesma tabela de rota, a rota a mais longa do fósforo está usada.

A saída do comando da mostra IP rpf 1.1.1.1 mostra a relação RPF que é E2/0, mas a interface de entrada deve ser E3/1.

Emita o comando de 1.1.1.1 da rota da mostra IP ver porque a relação RPF é diferente do que foi 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 deste comando de 1.1.1.1 da rota da mostra IP output que há uma rota estática de /32, que faça a interface errada a ser escolhida como a relação RPF.

Emita alguns comandos debug mais adicionais:

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 estão vindo dentro no E3/1, que está correto. Contudo, estão sendo deixados cair porque aquela não é a relação que a tabela de roteamento unicast se usa para a verificação RPF.

Nota: Debugar pacotes é perigoso. Os disparadores da eliminação de erros de Pakcet processam o interruptor dos pacotes de transmissão múltipla, que é utilização de CPU. Também, a eliminação de erros do pacote pode produzir a saída enorme que pode pendurar o roteador completamente devendo retardar a saída à porta de Console. Antes de depurar o pacote, o cuidado especial deve ser tomado para desabilitar saídas de registro ao console, e permite o registo ao buffer de memória. A fim conseguir isto, não configurar nenhuns console de registro e logging buffered debugging. Os resultados debugar podem ser considerados com o comando show logging.

Possíveis correções

Você pode ou mudar a tabela de roteamento unicast para satisfazer esta exigência ou você pode adicionar um mroute estática para forçar para fora o Multicast ao RPF uma interface particular, apesar do que a tabela de roteamento unicast indica. Adicionar um mroute estática:

ip22-72a(config)#ip mroute 1.1.1.1 255.255.255.255 2.1.1.1

Esse mroute estático determina que, para obter o endereço 1.1.1.1 para RPF, deve ser usado 2.1.1.1 como 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 do mrouter da mostra IP e debuga os olhares do mpacket IP bons, o número de pacotes enviados nos aumentos da contagem do mrouter da mostra IP e o HostA recebe pacotes.

ip22-72a#show ip mroute 224.1.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned 
       R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT 
       M - MSDP created entry, X - Proxy Join Timer Running 
       A - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 224.1.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00 
    Ethernet3/2, Forward/Sparse-Dense, 00:00:58/00:00:00 

(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 envia pacotes de transmissão múltipla ao host devido à Configuração TTL de Origem

Esta seção fornece uma solução para o problema comum de pacotes de transmissão múltipla de IP que não são enviados porque o valor Tempo de vida útil (TTL) é reduzido para zero. Este é um problema comum, porque há muitos aplicativos multicast. Estes aplicativos multicast são projetados primeiramente para a utilização do LAN, e ajustados assim o TTL a um valor baixo ou mesmo a um 1. Use este diagrama da rede como um exemplo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide2a.gif

Diagnostique o problema

Na figura acima, o roteador A não envia pacotes das fontes ao receptor conectado diretamente do roteador b. Olhe a saída do comando show ip mroute no roteador A ver o estado do roteamento de transmissão múltipla:

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 224.0.1.40 na saída acima desde que todo o Roteadores se junta a este grupo da descoberta Auto-RP. Mas não há nenhuma fonte alistada para 224.1.1.1. Além do que “*, 224.1.1.1” você deve ver "1.1.1.1, 224.1.1.1".

Emita o comando show ip rpf ver se é uma edição do encaminhamento de caminho reverso (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 

Da saída acima, você vê que não é uma edição RPF. A verificação RPF indica corretamente o E0/0 para obter ao endereço IP de Um ou Mais Servidores Cisco ICM NT da fonte.

Verifique se o PIM esteja configurado nas relações usando 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 olha boa, assim que este não é o problema. Verifique se o roteador reconheça algum tráfego ativo usando o comando show ip mroute ative:

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

Baseado na saída acima, o roteador não reconhece nenhum tráfego ativo.

ROUTERA#debug ip mpacket 
IP multicast packets debugging is on 

Talvez o receptor não está enviando nenhuns relatórios do Internet Group Management Protocol (IGMP) (se junta) para o grupo 224.1.1.1. Você pode verificá-lo que usa 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 foi juntado no E1/2, que é muito bem.

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

Você pode verificar para ver se é uma edição TTL com a captação do sniffer e igualmente vista com 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 acima mostra 63744 contagens de saltos ruins. Cada vez que você datilografa este comando, o contagem de saltos ruim aumenta. Esta é uma indicação forte que o remetente esteja enviando a pacotes com um TTL=1, que o roteador A decresça a zero. Isto conduz a um aumento do campo de contagem de saltos ruim.

Possíveis correções

Para resolver a edição, você precisa de 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.

Uma vez que isto é feito, o roteador A olha como este:

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 

Esta é meio a saída que você quer 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 envia os pacotes de transmissão múltipla devido ao limiar TTL de Roteador

Esta seção fornece uma solução ao problema comum do limite de TTL que está sendo ajustado demasiado baixo, de modo que o tráfego do Protocolo IP multicast não alcance o receptor. Este diagrama da rede é usado como um exemplo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide3a.gif

Diagnostique o problema

Na figura acima, o receptor não recebe pacotes de transmissão múltipla da fonte. Pode haver diverso Roteadores entre a fonte e o roteador 75a. Primeiro olhar no roteador 75a, desde que é conectado diretamente ao receptor.

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 acima mostra que o roteador 75a está enviando os pacotes para fora Ethernet0/1. Para ser roteador que absolutamente certo 75a está enviando os pacotes, gira-os debugam sobre apenas para estes fonte e grupo de transmissão múltipla:

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

O acima debugam mensagens indicam que o roteador 75a não encaminha os pacotes de transmissão múltipla porque o limite de TTL foi alcançado. Olhe a configuração de roteador para ver se você pode encontrar a razão. Esta 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 este não significa que qualquer coisa maior do que um TTL de 15 não está enviado. Na verdade, o oposto é verdadeiro. O aplicativo está sendo enviado com um TTL de 15. Antes que obtiver ao roteador 75a, os pacotes de transmissão múltipla têm um TTL menos de 15.

O comando ip multicast ttl-threshold <value> significa que todos os pacotes com um TTL abaixam do que o limiar especificado, neste caso, 15, não é enviado. Esse comando geralmente é usado para estabelecer um limite que impeça que o tráfego multicast interno seja alterado na intranet.

Possíveis correções

Qualquer um remove o comando ip multicast ttl-threshold <value> não usando nenhum formulário deste comando, que reverte ao valor de limite de TTL do padrão de 0, ou abaixa o limite de TTL de modo que o tráfego possa passar.

Diversos caminhos de custo igual resultam em um comportamento de caminho de retorno de remessa não desejado

Isto secciona mostras como os caminhos de custo igual a um origem de transmissão múltipla podem causar comportamento indesejável do Return Path Forwarding (RPF). Ele também descreve como configurar o multicast de IP para evitar tal comportamento. Este diagrama da rede é usado como um exemplo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide4a.gif

Diagnostique o problema

Na figura acima, o roteador 75b tem três caminhos de custo igual de volta à fonte (1.1.1.1), e escolhe um link que você não queira ser sua primeira escolha como o link RPF.

Quando enfrentado com caminhos de custo igual múltiplos a uma fonte, o Protocolo IP multicast escolhe a relação que tem um vizinho da transmissão múltipla independente de protocolo (PIM) com o endereço IP de Um ou Mais Servidores Cisco ICM NT o mais alto porque a interface de entrada e envia então ameixas secas aos vizinhos de PIM nos outros links.

Possíveis correções

Para mudar o Protocolo IP multicast da relação escolhe como sua interface de entrada, você pode fazer um destes:

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

  • Mude as sub-redes assim que o endereço IP de Um ou Mais Servidores Cisco ICM NT o mais alto está no link que você quer ser o link preliminar do Multicast.

  • Criam uma rota multicast (mroute) estática indicando a interface multicast preferida, o que significa que você perde a redundância multicast.

Como um exemplo, um mroute estática é criado.

Antes de instalar um mroute estática, você vê na saída abaixo daquele 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 

Após ter configurado o mroute estática, você vê no este output a relação RPF mudou ao 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 a carga do Protocolo IP multicast não equilibra através de todos os caminhos de custo igual disponíveis?

Esta seção fornece uma solução para o problema comum de configuração de transmissão múltipla de IP para balancear carga entre todos os caminhos de custo igual disponíveis. Este diagrama da rede é usado como um exemplo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide4a.gif

Na figura acima, o roteador 75b tem três caminhos de custo iguais de volta à fonte (1.1.1.1). Você quer ao balanceamento de carga o tráfego multicast através de todos os três links.

Possíveis correções

Como você viu nos caminhos de custo igual múltiplos para conduzir à seção do comportamento de caminho de retorno de remessa não desejado acima, a transmissão múltipla independente de protocolo (PIM) escolhe somente uma relação para a verificação do Return Path Forwarding (RPF) e poda a outro. Isto 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.

Estas são as configurações para o 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

Depois que você configura o túnel, use o comando show ip mroute ver a rota de transmissão múltipla (mrouter) para o grupo:

ip22-75a#show ip mroute 224.1.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned 
       R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT 
       M - MSDP created entry, X - Proxy Join Timer Running 
       A - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 224.1.1.1), 02:40:31/00:02:59, RP 0.0.0.0, flags: D 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 

(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 certificar-se dos dados de transmissão múltipla fossem a carga equilibrou ingualmente através dos três links, olha os dados da relação do roteador 75a.

A interface de entrada é 9000 bit/segundo:

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

As três interfaces enviadas bit de cada mostra 3000/segundo:

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 transmissão múltipla de IP no roteador?

Esta seção fornece soluções ao problema comum do Mensagem de Erro do Protocolo IP multicast “INVALID_RP_JOIN”.

Diagnostique o problema - Parte 1

Este os Mensagens de Erro são recebidos no ponto de reunião (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 PIM de downstream enviou um juntar mensagem para a árvore compartilhada, que este roteador não quer aceitar. Este comportamento indica que este roteador permite somente roteadores downstream se junta a um RP específico.

Suspeita-se que algum tipo da filtração está indo sobre. Você precisa de olhar a 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 

Que é instrução de aceitação de RP dentro a configuração suposta para realizar? Nos comandos ip multicast routing, este documento indica que “configurar um roteador para aceitar se junta ou as ameixas secas destinadas para um RP especificado e para uma lista específica de grupos, usa o comando ip pim accept-rp global configuration. 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 está causando o problema esteve encontrado, mas o que se você quer manter esse comando na configuração? Você pode permitir o endereço errado RP. Usando o comando show ip pim rp mapping, você pode ver o endereço correto RP:

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 as informações acima, 1.1.5.4 é o único RP aprendido por meio do RP automático ou de outro forma. Contudo, este roteador é somente o RP para os grupos 224.0.0.0/4. Portanto, a instrução pim accept-rp na configuração acima está errada.

Possíveis correções

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

Mude esta indicação:

ip pim accept-rp 10.2.2.2 8

Para o seguinte:

ip pim accept-rp 1.1.5.4 8

Você pode igualmente mudar a indicação para aceitar o que está no esconderijo auto-RP, e para assegurar que a lista de acessos (8 neste exemplo) esteja permitindo o alcance de grupo de transmissão múltipla necessário. Este é um exemplo:

ip pim accept-rp auto-rp

access-list 8 permit 224.0.0.0 0.255.255.255

Diagnostique o problema - Parte 2

Este Mensagem de Erro é considerado no roteador2.

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 para ver se o roteador2 é 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 relações do roteador2:

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#

Desde que o roteador2 não é um RP, deve não ter recebido este RP-junta-se ao pacote. Verifique porque o roteador downstream enviou a junta ao roteador2, quando não dever:

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 roteador3 configurou estaticamente a informação RP, apontando ao roteador2, que está incorreta. Isto explica porque o roteador3 está enviando RP-se junta ao roteador2.

Possíveis correções

Faça a roteador2 o RP para o grupo 224.1.1.1 ou mude a configuração no roteador3 assim que refere o endereço correto RP.

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 roteador3 é corrigida, o roteador3 refere o endereço correto RP e o Mensagem de Erro para de aparecer.

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 dos pacotes de transmissão múltipla

Esta seção explica como a inundação indesejada dos pacotes de transmissão múltipla pode ocorrer quando o Cisco Group Management Protocol (CGMP) não é permitido em todo o Roteadores em uma sub-rede particular, e como este problema pode ser evitado. Este diagrama da rede é usado como um exemplo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide7a.gif

Diagnostique o problema

Na figura acima, a tabela de CAM estática no Catalyst 5000 Switch A não mostra algumas das portas corretas que são povoadas. O roteador configurado para CGMP não envia pacotes de CGMP.

O CGMP é configurado corretamente com o comando set cgmp enable no Switch A e o comando ip cgmp na relação E0/2 do roteador 75a. Contudo os grupos do no multicast estão considerados 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 deste comando deve mostrar a cada um a porta que tem um roteador configurado para CGMP nele (porta 2/3) e a cada porta que tem um receptor interessado nela (porta 2/6). Desde que 0 estão listado, você pode supor que todas as portas estão sendo inundadas superfluamente com o tráfego multicast se o querem ou não.

Observações

Verifique para ver se há algum vizinho da transmissão múltipla independente de protocolo (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 acima mostra que o roteador 75a pode ver o roteador 75b como um vizinho PIM válido com o Switch A.

Verifique agora se você esteja recebendo a informação correta da rota de transmissão múltipla (mrouter) no 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 acima mostra que o roteador 75a está enviando os pacotes de transmissão múltipla para fora E0/2 para o Switch A. O seguinte roteador 75b das mostras da saída está obtendo os pacotes de transmissão múltipla e está enviando-os 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 

Olhando do ponto de vista do interruptor a, você vê que considera 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 visto até agora parece muito bem. Emita alguns comandos debug no roteador 75a ver o que você pode encontrar:

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 acima, 0000.0000.0000 são os todo-grupos endereço e estão usados quando o Roteadores envia o CGMP se junta/mensagem de licença assim que o Switches pode povoar portas de roteador. Suportes GDA para o endereço de destino do grupo no formato nivelado do Media Access Control (MAC) e suportes USA para o endereço de origem de unicast. Este é o endereço do host que originou o relatório IGMP para o qual esta mensagem CGMP está sendo gerada. Neste caso, é o MAC address para a relação E0/2 do roteador 75a. O MAC address para o E0/2 do roteador 75a pode ser considerado com o comando show interface como considerado 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, você pode periodicamente ver este quando o comando debug ip igmp é girado sobre:

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

Contudo, você não vê subseqüentemente um pacote de CGMP correspondente do roteador 75a. Isso significa que o Roteador 75a está recebendo relatórios IGMP, mas não está gerando os pacotes CGMP necessários para ajudar o Switch A a distinguir quais portas serão bloqueadas. Este é algo que está esperado do roteador 75a se é o IGMP mais investigado. Esta saída do roteador 75a diz-nos porque o comportamento esperado não está acontecendo:

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ê tem dois Roteadores na mesma sub-rede, e você configura ambos para o CGMP, simplesmente um enviará pacotes de CGMP. O roteador que envia os pacotes de CGMP é o roteador de consulta IGMP. Isto significa o roteador com o mais baixo endereço IP unicast do Roteadores IGMP-permitido.

Neste caso, o Roteadores 75a e o roteador 75b têm o IGMP permitido (o roteador 75b se transformou o roteador de consulta IGMP), mas somente o roteador 75a tem o CGMP permitido. Desde que o roteador 75a não é o roteador de consulta IGMP, nenhum pacote de CGMP está sendo enviado.

Possíveis correções

Para resolver o problema, você precisa de configurar o CGMP no roteador de consulta IGMP. Neste caso, roteador 75b. Primeiramente, gire sobre 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.

As coisas devem agora trabalhar 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 de 224.1.1.1 (01-00-5e-01-01-01) estão sendo somente as portas mandadas 2/3, 2/4, e 2/6 no Switch A, como devem. Inundar a todas portas restantes parou. O número total de entradas é alistado agora corretamente como 2. O MAC address 01-00-5e-00-01-28 é traçado do endereço de multicast 224.0.1.40, que é usado para o CGMP auto se junta.

O CGMP não impede as inundações do pacote de transmissão múltiplas, devido à localização de origem/receptor

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide8a.gif

Diagnostique o problema

In the figure above, Routers 75a and 75b and the Catalyst 5000 (Switch A) are properly configured for multicast and Cisco Group Management Protocol (CGMP). O host está obtendo o tráfego multicast. Contudo, é assim cada outro host fora do Switch A do interruptor A. está inundando o tráfego para fora cada porta, assim que significa que o CGMP não está trabalhando.

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 da saída acima daquele que o único grupo é 224.0.1.40, que está usado pelo roteador quando envia junções automático de CGMP para o grupo RP automático. Como vindo não há nenhum outro grupo?

Possíveis correções

Para compreender a solução, você precisa de compreender como o CGMP se comporta sob certas condições. Um roteador habilitado para CGMP envia o CGMP junta-se a um interruptor que informa o interruptor dos anfitriões interessados em um grupo de transmissão múltipla particular. O interruptor olha acima os endereços MAC para estes anfitriões em seus tabela CAM, a seguir para a frente pacotes de transmissão múltipla para fora as portas com host interessados e obstrui todas portas restantes dos pacotes de transmissão múltipla de encaminhamento.

Um roteador envia a junções automático de CGMP para fora uma interface habilitada para CGMP se recebe pacotes de transmissão múltipla de uma fonte que esteja na mesma relação em que (o roteador) tem o CGMP permitido.

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, em cima de ver pacotes da fonte, enviaria um junção automático de CGMP ao interruptor, que então aprenderia dinamicamente que portas o roteador é sobre e obstruiria todas portas restantes dos pacotes de transmissão múltipla de encaminhamento.

Um roteador envia o CGMP junta-se para fora a uma interface habilitada para CGMP se recebe relatórios IGMP de um host na mesma relação que (o roteador) tem o CGMP permitido.

Um outro exemplo é se nós tivemos um host interessado neste mesmo VLAN. Nesse caso, quando um roteador habilitado para CGMP recebeu um relatório do Internet Group Management Protocol (IGMP) de um host que estivesse interessado em um grupo de transmissão múltipla particular, o roteador enviaria um CGMP junta-se. A junta indicaria o endereço de controle de acesso de mídia (MAC) do host que quis se juntar e do grupo que quis se juntar. 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 é verdadeiro quando a fonte e o host interessado estão em uma sub-rede a não ser a sub-rede CGMP-permitida (VLAN). Os pacotes de transmissão múltipla, vindo da fonte, não provocam o roteador para enviar junções automático de CGMP ao interruptor. Consequentemente os pacotes batem o interruptor e obtêm-no inundados em toda parte dentro do VLAN. Esta encenação continua até um host no VLAN, vindo fora uma porta no interruptor, envia um IGMP junta-se. Somente com o recibo de um relatório IGMP faz o roteador enviam um pacote de CGMP, que faça com então que o interruptor adicione a porta de host apropriada enquanto portas de transmissão e todas outras são obstruídas (com exceção das portas de 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.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide8b.gif

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide8c.gif

Mova a fonte para a mesma sub-rede e verifique então 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 

224.1.1.1 (01-00-5e-01-01-01) é inundado agora somente às portas de roteador 2/3 e 2/4, e não a cada porta fora do Switch A.

O CGMP não impede os endereços de grupo das inundações do pacote de transmissão múltiplas com certeza

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 de transmissão múltipla 225.0.0.1, o Cisco Group Management Protocol (CGMP) não trabalha. Isso inunda o fluxo de multicast de todas as portas de switch e desperdiça largura de banda. Contudo, se você muda o endereço aos trabalhos de 225.1.1.1 CGMP muito bem. Que é errado com utilização de 225.0.0.1, desde que não é um endereço registrado para um protocolo de roteamento?

Possíveis correções

Primeiramente, é importante compreender como os endereços de multicast da camada 3 são traçados para mergulhar 2 endereços de multicast. Todos os quadros multicast IP usam endereços de camadas de Controle de Acesso a Mídia (MAC) IEEE que começam com o prefixo de 24 bits de 0x0100.5e. Ao mapear endereços de camada 3 para camada 2, os 23 bits de low-order do endereço de transmissão múltipla de camada 3 são mapeados para os 23 bits de low-order do endereço MAC IEEE.

Um outro fato importante a compreender é lá é 28 bit do espaço de endereços únicos para um endereço IP Multicast (bits inferiores 32 os primeiros 4 bit que contêm o prefixo de 1110 classes 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 que, no exemplo acima, 224.0.0.1 e 224.128.0.1 mapeiam para o mesmo endereço de multicast de camada 2.

Agora que você sabe a camada 3 mergulhar 2 endereços de multicast está traçada, continue à solução específica ao problema acima.

O Switch A inunda pacotes de transmissão múltipla para 224.0.0.x porque esses endereços são link-local e queremos garantir que os endereços link-local cheguem a todos os dispositivos da rede de área local (LAN). Os Catalyst Switches igualmente inundam pacotes de transmissão múltipla a outros endereços de multicast que são nível MAC ambíguo com 224.0.0.x (por exemplo, 224.0.0.1 e 225.0.0.1 ambos mapa a 0100.5e00.0001). O interruptor inunda os pacotes de transmissão múltipla destinados para estes endereços locais de link se o CGMP está permitido 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. Isto consiste nestes endereços da 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 córregos duplicados do pacote de transmissão múltipla são recebidos

Causa 1

Os pacotes de transmissão múltipla duplicados são recebidos quando dois Roteadores são configurados no modo denso. No modo denso, o dispositivo inunda periodicamente o córrego. Após a inundação, poda fora das relações onde o vapor não é querido. Os dois Roteadores igualmente atravessam o processo da afirmação e decidem quem é o remetente. Cada vez que os temporizadores se apagam, este acontece, e até que este processo esteja completo, ambo o Roteadores está enviando o córrego. Isto causa o aplicativo receber fluxos de transmissão múltipla duplicados.

Reparo possível 1

Esta edição pode ser resolved se você tem um do Roteadores configurado para o roteamento de transmissão múltipla e configurar o outro roteador para ser o RP dentro ascendente. Configurar-la a fim converter o córrego no modo escasso antes que o córrego entre o roteador. Isto pode impedir que os pacotes duplicados alcancem o aplicativo. Não é parte da responsabilidade das redes assegurar-se de que nenhum pacote duplicado alcance nunca um host final. É parte da responsabilidade do aplicativo segurar pacotes duplicados e ignorar dados unneeded.

Causa 2

Esta edição pode ocorrer nos Cisco Catalyst 6500 Switch, que são configurados para o modo da replicação multicast da saída e podem ser provocados pela remoção e pela reinserção de todo o [OIR] das placas de linha. Após o OIR, a porta da tela do [FPOE] da saída pode ser misprogrammed, que pode fazer com que os pacotes sejam dirigidos lesar o canal da saída da tela e enviados às placas de linha erradas. O resultado é que são loop à tela e as épocas múltiplas replicated em que retiram 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

Reparo possível 2

Como uma ação alternativa, mude ao modo da replicação do ingresso. Durante uma mudança da saída ao modo da ingresso-replicação, as interrupções de tráfego podem ocorrer porque os atalhos são removidos e reinstalados.

mls ip multicast replication-mode ingress

Promova o Cisco IOS Software a uma liberação não afetada pela identificação de bug Cisco CSCeg28814 (clientes registrados somente) a fim resolver permanantly a edição.

Causa 3

Esta edição pode igualmente ocorrer se o [RSS] da escamação do lado de recepção que se ajusta, nos host finais ou nos server, é desabilitado.

Reparo possível 3

O ajuste RSS facilita uma transmissão mais rápida dos dados através dos CPU múltiplos. Permita o ajuste RSS no host final ou no server. FRefer aos trabalhos em rede escaláveis do artigo Microsoft com o RSSleavingcisco.com para mais informação.

Por que os pacotes de transmissão múltipla são deixados cair?

Causa 1

É possível que você vê os resplendores e as gotas excessivos do pacote de entrada nas relações quando fluxos de tráfego multicast. Você pode verificar os resplendores 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

Reparo possível 1

Você pode ajustar o valor SPT como a infinidade para a relação onde os resplendores excessivos são considerados.

Configurar isto:

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

Causa 2

Quando você usa o comando do <group-name> do juntar-grupo do igmp IP em todas as relações, processa o interruptor. Se os pacotes de transmissão múltipla são processo ligado quaisquer relações, consome mais CPU enquanto encarrega da comutação do processo de todos os pacotes a 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

Reparo possível 2

Você pode usar o comando do <group-name> do estático-grupo do igmp IP em vez do comando do <group-name> do juntar-grupo do igmp IP.

Nota: Devido às edições precedentes, é possível que você vê o uso da alta utilização da CPU ao redor 90 por cento. O CPU vem para baixo ao normal quando você os resolve com estes reparos possíveis.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 16450