Solucione problemas do RP automático multicast no Nexus 9000 com NX-OS

Introdução

Este documento descreve como o RP automático funciona no Cisco Nexus 9000 com NX-OS e como validar e solucionar problemas de operação multicast.

Pré-requisitos

Requisitos

• Conhecimento básico de multicast IP
• Conhecimento básico de IGMP e PIM Sparse Mode
• Experiência com Cisco Nexus 9000 e NX-OS CLI
• Compreensão dos conceitos de roteamento unicast e RPF

Componentes Utilizados

• Switches Cisco Nexus 9000 Series
• Software Cisco NX-OS
• Modo escasso do PIM
• RP estático e RP automático

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

Visão geral do multicast

O multicast é um modelo de comunicação de um para muitos no qual uma origem envia um único fluxo de tráfego para vários receptores interessados. Em vez de criar uma cópia separada para cada destino, a rede replica o tráfego apenas onde o caminho de encaminhamento é ramificado. Isso torna o multicast mais eficiente do que as transmissões unicast repetidas ou de broadcast. No IPv4, o tráfego multicast usa endereços de destino do intervalo 224.0.0.0/4.

PIM Sparse Mode é o modelo de roteamento multicast suportado nos switches Cisco Nexus que executam o NX-OS. Ele encaminha o tráfego somente quando o interesse do receptor foi explicitamente aprendido. Em um projeto Multicast de qualquer origem, os receptores inicialmente se unem a uma árvore compartilhada em direção ao ponto de encontro e as origens se registram nesse RP. Depois que o tráfego começa a fluir, o roteador do último salto pode se mover da árvore compartilhada para a árvore de caminho mais curto em direção à origem.

É importante definir a terminologia usada no multicast porque a solução precisa de problemas depende da compreensão de como os eventos do plano de controle, as entradas de roteamento e as decisões de encaminhamento são representados. Uma terminologia clara ajuda a interpretar corretamente a saída do comando, a distinguir entre o comportamento da árvore compartilhada e da árvore de origem e a identificar a função de cada componente multicast no processo de encaminhamento fim-a-fim.

Termo	Definição
Endereço do grupo multicast	Um endereço destino IPv4 no intervalo 224.0.0.0/4 usado para identificar um grupo multicast.
Endereço de origem	O endereço IP unicast do remetente que transmite o tráfego para um grupo multicast.
mroute	A entrada de roteamento multicast que define como o tráfego multicast de um grupo ou combinação de grupo de origem é tratado.
IIF	Interface de entrada. A interface na qual se espera que o tráfego multicast chegue.
OIF	Interface de saída. Uma interface usada para encaminhar tráfego multicast para receptores ou vizinhos downstream.
ÓLEO	Outgoing Interface List (Lista de interface de saída). O conjunto de interfaces de saída associadas a uma entrada de roteamento multicast.
RPF	Reverse Path Forwarding (Encaminhamento de caminho reverso). Uma verificação que verifica se o tráfego multicast chegou à interface correta com base na rota unicast em direção à origem ou ao RP.
MDT	Multicast Distribution Tree (Árvore de distribuição multicast). A árvore lógica que transporta o tráfego multicast da origem para todos os receptores.
RPT	Árvore RP, também chamada de árvore compartilhada. Conecta receptores ao RP e é representado por (*,G).
SPT	Shortest Path Tree (Árvore de caminho mais curto), também chamada de árvore de origem. Conecta receptores diretamente à fonte e é representado por (S,G).
FHR	First-Hop Router (Roteador de primeiro salto). O roteador multicast conectado diretamente à origem e responsável pelo registro de origem com o RP.
LHR	Last-Hop Router (Roteador do último salto). O roteador multicast conectou-se diretamente aos receptores e é responsável por criar o estado multicast após saber o interesse do receptor através do IGMP.
RP	Ponto de encontro. O ponto de reunião lógico usado no ASM e no Modo PIM Esparso para conectar origens e destinatários inicialmente.
ASM	Multicast de qualquer origem. Um modelo multicast no qual os receptores se juntam a um grupo sem especificar a origem antecipadamente.

É importante entender os Endereços Multicast Reservados Bem Conhecidos porque a solução de problemas multicast depende da identificação rápida de qual protocolo de controle está usando um determinado grupo de destinos e de que função o tráfego serve na rede. Esses endereços ajudam a diferenciar a operação normal do protocolo do comportamento anormal e facilitam a validação de intercâmbios IGMP, PIM e AutoRP. Para o RP automático, especificamente, os grupos mais importantes a serem reconhecidos são 224.0.1.39 para RP-Announce e 224.0.1.40 para RP-Discovery, porque eles carregam as informações que permitem que os roteadores aprendam os mapeamentos RP dinâmicos.

Endereço de Multicast	Propósito
224.0.0.1	Todos os hosts na sub-rede local
224.0.0.2	Todos os roteadores na sub-rede local
224.0.0.13	Todos os roteadores PIM
224.0.0.22	Mensagens IGMPv3
224.0.1.39	Mensagens Cisco RP-Announce usadas pelo RP automático
224.0.1.40	Mensagens Cisco RP-Discovery usadas pelo RP automático

Operação de RP Automático no Modo PIM Esparso (Workflow do Plano de Controle)

O RP automático é um mecanismo da Cisco usado no modo escasso de multicast independente de protocolo para descobrir e distribuir dinamicamente as informações do ponto de encontro (RP) pelo domínio de multicast. Ele elimina a necessidade de configuração de RP estático usando mensagens de plano de controle baseadas em multicast para anunciar, selecionar e aprender mapeamentos RP para grupo. Seus principais componentes são RPs candidatos, que oferecem serviços de RP para faixas de grupos específicos, e Agentes de mapeamento, que coletam candidatos e decidem o RP ativo por grupo.

O processo começa quando cada RP candidato envia periodicamente mensagens RP-Announce para 224.0.1.39, incluindo seu endereço IP, prioridade e intervalos de grupos multicast suportados. Essas mensagens são enviadas por toda a rede usando o ouvinte de RP automático no NX-OS, garantindo que todos os agentes de mapeamento as recebam antes mesmo que a rede esteja totalmente operacional no modo escasso.

Os agentes de mapeamento ouvem esses anúncios, criam um banco de dados RP candidato e executam um processo de seleção determinístico por grupo (normalmente a prioridade mais alta e, em seguida, o endereço IP mais alto). Uma vez escolhido o melhor RP, o Agente de mapeamento gera mensagens RP-Discovery e as envia para 224.0.1.40, anunciando os mapeamentos RP-para-grupo finais para todos os roteadores no domínio.

Todos os roteadores PIM recebem as mensagens RP-Discovery e instalam os mapeamentos em suas tabelas RP locais. Com essas informações, os roteadores do último salto (conectados a receptores) enviam mensagens PIM Join para o RP selecionado para criar a árvore compartilhada (RPT), enquanto os roteadores do primeiro salto (conectados a origens) encapsulam o tráfego multicast em mensagens PIM Register para informar o RP sobre origens ativas.

À medida que o tráfego flui através do RP, os roteadores podem, opcionalmente, mudar da árvore compartilhada (RPT) para uma árvore de caminho mais curto (SPT) usando sinalização adicional de junção/remoção de PIM diretamente em direção à origem. Durante todo esse processo, o RP automático atualiza continuamente os mapeamentos por meio de mensagens de controle periódicas, garantindo a resiliência e a adaptação automática a alterações de topologia ou RP.

Operação de RP Automático no Modo PIM Esparso (Workflow do Plano de Controle)

Limitações de RP automático e restrições operacionais

• O RP automático opera apenas com multicast IPv4 e não é suportado para IPv6 (PIM6), portanto as implantações de IPv6 exigem um mecanismo de descoberta de RP diferente.
• O RP automático não pode coexistir com o BSR dentro do mesmo domínio PIM, pois somente um mecanismo de descoberta RP pode ser configurado para evitar conflitos de plano de controle.
• As mensagens de RP automático não são processadas ou encaminhadas por padrão em dispositivos NX-OS, portanto, é necessária uma configuração explícita para a operação adequada.
• A propagação de mensagens de controle do RP automático depende da ativação do ouvinte do RP automático; caso contrário, as informações de mapeamento de RP não alcançam todos os roteadores.
• O intervalo de anúncio RP tem um limite mínimo de 15 segundos, que limita a rapidez com que as atualizações RP podem ser anunciadas e afeta o tempo de convergência.
• A filtragem automática de mensagens RP através de mapas de rota pode afetar a operação, pois políticas incorretas podem bloquear mapeamentos RP para grupo.
• O RP automático é desabilitado por padrão em contextos VRF, portanto, deve ser habilitado explicitamente em implantações de vários VRF.

• O encaminhamento multicaminho baseado em ECMP é ativado por padrão, o que permite que o tráfego multicast use caminhos de custo igual para balanceamento de carga.

• Há suporte para autenticação de vizinho PIM usando IPsec AH-MD5.

• O rastreamento PIM não está disponível.

Benefícios do uso do RP automático

O RP automático fornece descoberta de RP dinâmico e distribuição de mapeamento de RP centralizado para ambientes multicast PIM Sparse Mode. Ele elimina a necessidade de configuração de RP estático em cada roteador multicast, reduz a complexidade operacional e melhora a escalabilidade multicast. O RP automático também suporta vários candidatos RP, permitindo failover e redundância de RP automática. Esse mecanismo ajuda a manter o comportamento consistente de encaminhamento multicast, simplifica a expansão da rede e permite que os roteadores multicast aprendam informações de RP automaticamente pelo domínio.

Agente de mapeamento de RP automático e processo de seleção de RP

O processo de seleção no RP automático é determinístico e baseia-se principalmente em endereços IP. Ao contrário de outros protocolos (como PIMv2 BSR), o RP automático não usa um valor de "prioridade" configurável; em vez disso, ele depende da hierarquia de endereços IP para resolver conflitos.

Seleção de Agente de Mapeamento (MA)

No RP automático, vários agentes de mapeamento podem coexistir na mesma rede para redundância. Não existe um processo eleitoral formal em que um se desligue e outro se desligue; todos estão tecnicamente ativos. No entanto, os switches na rede devem decidir em quais informações confiar.

• Critério de seleção: Highest IP Address (Endereço IP mais alto).
• O processo:
  1. Todos os agentes de mapeamento enviam suas mensagens RP-Discovery ao grupo multicast 224.0.1.40.
  2. Os switches clientes recebem essas mensagens.
  3. Se um switch receber mensagens de descoberta de dois agentes de mapeamento diferentes contendo informações conflitantes, ele aceitará as informações do agente de mapeamento com o maior endereço IP de origem.
  4. Comportamento do Nexus: Um Agente de Mapeamento com um endereço IP menor geralmente entra em um estado "passivo" ou "supressão" ao detectar outro MAC com um endereço IP maior para evitar tráfego de controle duplicado na rede.

Seleção do ponto de rendezvous (RP)

Esse processo é executado pelo Agente de Mapeamento após ouvir todas as mensagens RP-Announce (enviadas ao grupo 224.0.1.39) dos candidatos.

Quando o Agente de Mapeamento recebe vários candidatos para o mesmo grupo multicast, ele aplica estas regras na ordem:

Regra A: Correspondência de prefixo mais longa (máscara mais específica)

Se os candidatos anunciarem intervalos sobrepostos, o MA atribuirá o grupo ao RP que anunciou o menor intervalo (a máscara de sub-rede mais longa).

• Exemplo:
  • O candidato A anuncia o intervalo multicast inteiro 224.0.0.0/4 (the).
  • O candidato B anuncia 224.10.20.0/24.
  • Resultado: Para o grupo 224.10.20.5, o candidato B vence porque seu intervalo é mais específico.

Regra B: Endereço IP mais alto (desempate)

Se dois ou mais candidatos anunciarem exatamente o mesmo intervalo de grupo, o Agente de Mapeamento deverá escolher apenas um.

• Critério: O candidato com o maior endereço IP ganha.
• Exemplo:
  • Candidato 1: 10.2.0.1 para o intervalo 224.10.20.0/24.
  • Candidato 2: 10.2.0.4 para o intervalo 224.10.20.0/24.
  • Resultado: O Agente de Mapeamento seleciona 10.2.0.4 como o RP oficial para esse intervalo e isso é anunciado em suas mensagens de Descoberta.

Considerações sobre a camada 2: MAC Multicast e Snooping

Embora o foco deste artigo seja o multicast de Camada 3 usando PIM, o comportamento da Camada 2 desempenha um papel crítico na solução de problemas e no projeto geral. Na Camada 2, os dispositivos se comunicam usando endereços MAC, que são identificadores de 48 bits atribuídos às interfaces de rede, e o tráfego multicast requer um esquema de endereçamento MAC específico para diferenciá-lo do tráfego unicast e broadcast.

Os endereços MAC multicast IPv4 são derivados dos endereços de grupo multicast da Camada 3 usando o prefixo reservado `01:00:5E`. No entanto, apenas 23 bits do endereço IP multicast são mapeados no endereço MAC, o que cria uma sobreposição de 32:1, o que significa que até 32 grupos IP multicast diferentes podem mapear para o mesmo endereço MAC. Como resultado, os hosts que ouvem um determinado endereço MAC multicast podem receber tráfego para vários grupos multicast, mesmo que estejam interessados em apenas um. Por exemplo, 224.1.1.1, 225.1.1.1, 226.1.1.1, 227.1.1.1, 228.1.1.1 e mais.

Essa sobreposição tem implicações diretas na eficiência e na solução de problemas da rede. Como as decisões de encaminhamento de Camada 2 baseadas unicamente em endereços MAC não podem distinguir entre grupos multicast sobrepostos, os switches podem fornecer tráfego desnecessário aos hosts. Esses hosts devem, então, confiar na filtragem de camada superior (IP/IGMP) para descartar pacotes indesejados, consumindo recursos de CPU e de buffer.

No Cisco Nexus NX-OS, essa limitação é atenuada pelo comportamento de snooping IGMP. Por padrão, o snooping IGMP executa pesquisas baseadas em IP em vez de encaminhamento somente MAC, permitindo que os switches tomem decisões de encaminhamento mais precisas, mesmo quando vários grupos multicast compartilham o mesmo endereço MAC. Isso melhora significativamente a eficiência da Camada 2 e reduz a entrega de tráfego desnecessário.

Configuração de RP automático

Esta seção fornece uma explicação detalhada da configuração do RP automático, usando uma implementação simples como referência. Nessa configuração, uma origem multicast é conectada a dois switches Nexus via vPC para fornecer tráfego a um receptor. Neste projeto, tanto o N9K-1 como o N9K-2 funcionam simultaneamente como candidatos RP e agentes de mapeamento.

Fluxo de tráfego multicast

Roteador First Hop

A mesma configuração tem FHR-2.

FHR-1# show running-config pim
feature pim
ip pim auto-rp forward listen

interface Vlan1
  ip pim sparse-mode

interface Ethernet1/1
  ip pim sparse-mode

interface Ethernet1/3
  ip pim sparse-mode

Comando	Finalidade/Descrição
PIM de recurso	Habilita o processo PIM (Protocol Independent Multicast) no switch.
ip pim auto-rp forward listen	Ativa o ouvinte de RP automático. Isso permite que o switch receba e encaminhe mensagens de controle de RP automático (224.0.1.39 e 224.0.1.40), mesmo que ainda não saiba a identidade do RP.
ip pim sparse-mode	Habilita o Modo PIM Esparso em uma interface específica. Neste modo, o tráfego multicast é encaminhado somente para segmentos que o solicitaram explicitamente através de mensagens de união PIM.

Mapeando Agente e Candidato RP

N9K-1# show running-config pim
feature pim

ip pim auto-rp rp-candidate loopback0 group-list 224.10.20.0/24 interval 15
ip pim auto-rp mapping-agent loopback1

interface loopback0
  ip pim sparse-mode

interface loopback1
  ip pim sparse-mode

interface Ethernet1/3
  ip pim sparse-mode

interface Ethernet1/4
  ip pim sparse-mode

interface Ethernet1/49
  ip pim sparse-mode

Esta tabela fornece um detalhamento técnico da configuração PIM para N9K-1. Essa configuração é replicada em N9K-2. Ambos os switches são configurados com uma função dupla, atuando como um Candidato RP e um Agente de Mapeamento para o domínio multicast.

Comando	Explicação técnica detalhada
PIM de recurso	Ativação de recurso: Ativa globalmente o mecanismo Protocol Independent Multicast (PIM) no switch Nexus.
ip pim auto-rp rp-candidate loopback0 group-list 224.10.20.0/24 interval 15	Função do candidato RP: Configura esse switch como "voluntário" como o ponto de encontro (RP). Fonte: Usa o endereço IP de loopback0 Escopo: Ele se oferece para manipular o intervalo de grupo multicast 224.10.20.0/24. Intervalo: Envia mensagens de "Anúncio" ao Agente de Mapeamento a cada 15 segundos. O temporizador de espera é três vezes esse valor.
ip pim autorrp mapping-agent loopback1	Mapeando Função do Agente: Configura o switch como o "administrador" do processo de RP automático. Função: Ele ouve todos os candidatos RP, resolve conflitos (usando o endereço IP mais alto como um desempate) e envia as mensagens "Discovery" para o resto da rede para informá-los quem é o RP ativo.
interface loopback0 / loopback1	Interfaces lógicas: O PIM é habilitado nessas interfaces porque elas servem como IPs de origem para as funções Candidato RP e Agente de Mapeamento. Eles devem ser alcançáveis através da tabela de roteamento unicast de todos os roteadores PIM.
interface Ethernet1/3, 1/4, 1/49	Encaminhamento físico: Habilita o Modo PIM Esparso em portas físicas. Isso permite que o switch forme adjacências de vizinhos PIM com outros roteadores e encaminhe o tráfego multicast através desses links específicos.
ip pim sparse-mode	Modo operacional: Aplicado a todas as interfaces acima. Ele garante que o tráfego multicast seja enviado apenas para receptores que o solicitaram explicitamente através de mensagens de união PIM, evitando inundação de rede desnecessária.

Configuração de roteamento para acessibilidade IPv4

• Nessa topologia, todos os switches Nexus participam de um único processo OSPF chamado UNDERLAY, operando dentro da área 0 (0.0.0.0) para fornecer total alcance de roteamento através da rede.
• No LHR, o OSPF é ativado na VLAN 2, que serve como gateway para o receptor multicast, e nas interfaces de uplink Ethernet1/49 e Ethernet1/50, ambas configuradas como ponto-a-ponto. Isso garante uma formação de adjacência eficiente para os switches N9K de upstream sem escolhas de DR/BDR.
• A camada FHR (FHR-1 e FHR-2) compartilha uma configuração idêntica. O OSPF é ativado na VLAN 1, que atua como gateway para a origem de multicast, e nos uplinks roteados (Ethernet1/1 e Ethernet1/3) em direção à camada de agregação. Esses links também são configurados como ponto-a-ponto, otimizando a convergência e o comportamento adjacente.
• Da mesma forma, N9K-1 e N9K-2 têm configurações OSPF idênticas, com a adição do anúncio Loopback0 e Loopback1 no OSPF.
  • Esses loopbacks são críticos, pois são usados posteriormente para as funções Candidato RP PIM e Agente de Mapeamento.

Vizinhos PIM e área 0 do OSPF

N9K-1 — Configuração do OSPF

N9K-1(config)# show running-config ospf
feature ospf

router ospf UNDERLAY
  router-id 10.2.0.1

interface loopback0
  ip router ospf UNDERLAY area 0.0.0.0

interface loopback1
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/3
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/4
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/49
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

FHR-1 — Configuração do OSPF

FHR-1(config)# show running-config ospf
feature ospf

router ospf UNDERLAY

interface Vlan1
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/1
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/3
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

Configuração LHR — OSPF

LHR(config)# show running-config ospf
feature ospf

router ospf UNDERLAY

interface Vlan2
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/49
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/50
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

Verificar o estado operacional e solucionar problemas do RP automático

Passo 1: Verificar a acessibilidade básica do IP (validação unicast underlay)

Antes de analisar o comportamento de multicast, é essencial confirmar se a subjacência unicast (área 0 do OSPF) está totalmente operacional. Os protocolos de plano de controle multicast, como PIM e RP automático, dependem do alcance unicast para funcionar corretamente.

A primeira etapa de validação é confirmar se a origem e o receptor (ou seus gateways de Camada 3 mais próximos: FHR e LHR).

Na topologia:

• FHR-1 / FHR-2 → Mais próximo à origem multicast (10.150.1.37 - VLAN 1)

• LHR → Mais próximo ao receptor multicast (192.168.2.37 - VLAN 2)

Abordagem de validação

1. Executar testes de alcançabilidade ICMP entre:

• FHR ↔ LHR

• Sub-rede do receptor de ↔ FHR (gateway VLAN 2)

• Sub-rede de Origem de ↔ LHR (gateway VLAN 1)

2. Valide a acessibilidade da origem e do receptor na tabela de roteamento. Para implantações de vPC, garanta a consistência entre os dois pares do Nexus. Observe que o receptor tem um caminho ECMP, enquanto a origem pode ser alcançada através da Camada 2.

FHR-1 — Rota para a fonte

FHR-1# show ip route 10.150.1.37

10.150.1.37/32, ubest/mbest: 1/0, attached
    *via 10.150.1.37, Vlan1, [250/0], 06:57:19, am

FHR-1 — Rota para o receptor

FHR-1# show ip route 192.168.2.37

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.6, Eth1/3, [110/45], 04:11:08, ospf-UNDERLAY, intra
    *via 10.4.0.10, Eth1/1, [110/45], 04:11:08, ospf-UNDERLAY, intra

FHR-2 — Rota para a fonte

FHR-2# show ip route 10.150.1.37

10.150.1.37/32, ubest/mbest: 1/0, attached
    *via 10.150.1.37, Vlan1, [250/0], 07:03:45, am

FHR-2 — Rota para o receptor

FHR-2# show ip route 192.168.2.37

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.13, Eth1/3, [110/45], 04:16:16, ospf-UNDERLAY, intra
    *via 10.4.0.18, Eth1/4, [110/45], 04:16:16, ospf-UNDERLAY, intra

LHR — Rota até a origem

LHR(config)# show ip route 10.150.1.37

10.150.1.0/24, ubest/mbest: 2/0
    *via 10.4.0.22, Eth1/49, [110/45], 04:14:52, ospf-UNDERLAY, intra
    *via 10.4.0.26, Eth1/50, [110/45], 04:14:52, ospf-UNDERLAY, intra

LHR — Rota para o receptor

LHR(config)# show ip route 192.168.2.37

192.168.2.37/32, ubest/mbest: 1/0, attached
    *via 192.168.2.37, Vlan2, [250/0], 06:47:21, am

Considerações importantes

• A falha nesse teste indica um problema de subjacência.

• O multicast não pode funcionar corretamente sem acessibilidade unicast, pois:

  • Os vizinhos PIM dependem do roteamento unicast

  • Os endereços RP (loopback) devem estar acessíveis

  • As verificações de RPF (Reverse Path Forwarding, Encaminhamento de caminho reverso) dependem da tabela de roteamento

• Um ping bem-sucedido não garante que o multicast possa funcionar, porque:

  • O ICMP pode ser permitido enquanto o multicast estiver bloqueado

  • PIM ou RP automático ainda podem ser configurados incorretamente

Passo 2: Identificar funções multicast e topologia fim-a-fim

A próxima etapa é identificar claramente a função de cada dispositivo envolvido no encaminhamento de tráfego multicast. Essa é uma etapa obrigatória, pois a solução de problemas de multicast depende inteiramente da compreensão do fluxo de tráfego e do comportamento esperado na topologia.

No mínimo, estes elementos devem ser identificados:

• Fonte Multicast (S): 10.150.1.37 (VLAN 1)

• Grupo Multicast (G): 224.10.20.10

• Receptor: 192.168.2.37 (VLAN 2)

• Roteador de primeiro salto (FHR): FHR-1 / FHR-2 (mais próximo da origem)

• Roteador de último salto (LHR): LHR (mais próximo do receptor)

Além disso, é necessário identificar as funções do plano de controle:

• Candidatos RP: N9K-1 e N9K-2 (Loopback0)

• Agentes de mapeamento: N9K-1 e N9K-2 (Loopback1)

Topologia e percepção do plano de controle

Uma topologia de rede detalhada é obrigatória para continuar com qualquer solução de problemas de multicast. Isso inclui:

• Conectividade física (interfaces usadas entre dispositivos)

• Topologia lógica (VLANs, links roteados, relações vPC)

• Protocolo de roteamento em uso (área 0 do OSPF neste design)

• Limites do domínio de roteamento (IGP único versus protocolos mistos como OSPF, EIGRP ou BGP)

• Interfaces de loopback usadas para funções de RP e Agente de mapeamento

• Interfaces ativadas por PIM e relações de vizinhança

O Que Deve Ser Claramente Entendido

• O caminho exato da origem → FHR → RP → LHR → Receiver

• Quais dispositivos são responsáveis por:

  • Enviando Registro PIM (FHR)

  • Árvores de edifício (*,G) ou (S,G) (LHR)

  • Anunciando informações de RP (Agente de Mapeamento)

• Como o roteamento (OSPF) garante acessibilidade para:

  • Sub-rede de origem

  • Sub-rede do receptor

  • endereços de loopback RP

  • Mapeando endereços de loopback do agente

Passo 3: Validar Configuração de RP Automático com Base na Função do Dispositivo

A próxima etapa é verificar se o RP automático está configurado corretamente em cada dispositivo de acordo com sua função na topologia multicast. Isso inclui confirmar que:

• Os candidatos RP (N9K-1 / N9K-2) estão configurados corretamente para anunciar seu Loopback0 como o RP para o intervalo de grupo multicast.

• Os agentes de mapeamento (N9K-1 / N9K-2) são configurados para coletar mensagens RP-Announce e gerar mensagens RP-Discovery usando Loopback1.

• O FHR e o LHR têm o modo PIM escasso ativado em todas as interfaces relevantes para participar do RP automático e receber mapeamentos RP.

É essencial garantir que todas as interfaces necessárias (incluindo loopbacks e links roteados) estejam habilitadas para o modo escasso de PIM e que não haja configurações ausentes que impeçam a troca de mensagens RP-Announce (224.0.1.39) e RP-Discovery (224.0.1.40).

Passo 4: Validar a operação de todos os candidatos RP e todos os agentes de mapeamento

Etapa 4.1 Verificar Adjacências de Vizinhos PIM

A primeira etapa de validação é confirmar se todos os vizinhos PIM esperados estão estabelecidos corretamente na topologia de multicast.

N9K-1 — Verificar vizinhos PIM

N9K-1# show ip pim neighbor

PIM Neighbor Status for VRF "default"
Neighbor        Interface            Uptime    Expires   DR       Bidir-  BFD    ECMP Redirect
                                                         Priority Capable State     Capable
10.4.0.5        Ethernet1/3          23:19:45  00:01:20  1        yes     n/a     no
10.4.0.14       Ethernet1/4          23:19:45  00:01:38  1        yes     n/a     no
10.4.0.21       Ethernet1/49         23:19:45  00:01:38  1        yes     n/a     no

N9K-2 — Verificar vizinhos PIM

N9K-2# show ip pim neighbor

PIM Neighbor Status for VRF "default"
Neighbor        Interface            Uptime    Expires   DR       Bidir-  BFD    ECMP Redirect
                                                         Priority Capable State     Capable
10.4.0.9        Ethernet1/3          23:21:18  00:01:29  1        yes     n/a     no
10.4.0.17       Ethernet1/4          23:21:18  00:01:23  1        yes     n/a     no
10.4.0.25       Ethernet1/49         23:21:18  00:01:44  1        yes     n/a     no

Pontos de validação

• Verifique se todos os vizinhos esperados aparecem em cada interface roteada.
• Verifique se o tempo de atividade do vizinho está estável e aumentando continuamente.
• Verifique se o temporizador Expira é atualizado periodicamente.
• Verifique se não ocorrem oscilações inesperadas de adjacência.
• Verifique a eleição correta do roteador designado (DR).
• Verifique se as interfaces multicast formam adjacências PIM com êxito.

Nesta topologia:

• N9K-1 estabelece três vizinhos PIM.
• O N9K-2 também estabelece três vizinhos PIM.
• Todas as adjacências permanecem estáveis por mais de 23 horas, o que indica uma operação de plano de controle de multicast estável.

---

Etapa 4.2 Verificar interfaces ativadas por PIM

A próxima etapa é confirmar se todas as interfaces que participam do RP automático estão habilitadas para PIM.

Essa validação é especialmente importante para:

• Loopbacks RP-Candidato
• Mapeando loopbacks de Agentes

N9K-1 — Verificar interfaces PIM

N9K-1# show ip pim interface brief

PIM Interface Status for VRF "default"
Interface            IP Address      PIM DR Address  Neighbor  Border
                                                     Count     Interface
Ethernet1/3          10.4.0.6        10.4.0.6        1         no
Ethernet1/4          10.4.0.13       10.4.0.14       1         no
Ethernet1/49         10.4.0.22       10.4.0.22       1         no
loopback0            10.2.0.1        10.2.0.1        0         no
loopback1            10.2.1.5        10.2.1.5        0         no

N9K-2 — Verificar interfaces PIM

N9K-2# show ip pim interface brief

PIM Interface Status for VRF "default"
Interface            IP Address      PIM DR Address  Neighbor  Border
                                                     Count     Interface
Ethernet1/3          10.4.0.10       10.4.0.10       1         no
Ethernet1/4          10.4.0.18       10.4.0.18       1         no
Ethernet1/49         10.4.0.26       10.4.0.26       1         no
loopback0            10.2.0.4        10.2.0.4        0         no
loopback1            10.2.1.4        10.2.1.4        0         no

Pontos de validação:

• Verifique se todas as interfaces multicast roteadas aparecem na saída.
• Verifique se os loopbacks RP-Candidate estão habilitados para PIM.
• Verifique se os loopbacks do Agente de Mapeamento estão habilitados para PIM.
• Verifique se as contagens de vizinhos estão corretas nas interfaces de trânsito.
• Verifique se as interfaces de loopback mostram corretamente Neighbor Count = 0.

Atribuição de função de loopback:

Dispositivo	Função	Loopback
N9K-1	RP-Candidato	10.2.0.1
N9K-1	Agente de Mapeamento	10.2.1.5
N9K-2	RP-Candidato	10.2.0.4
N9K-2	Agente de Mapeamento	10.2.1.4

Os loopbacks aparecem corretamente como interfaces PIM ativas mesmo que não formem vizinhos PIM. Esse comportamento é esperado porque as interfaces de loopback não estabelecem adjacências de multicast diretamente.

A presença desses loopbacks confirma que:

• O PIM pode originar mensagens de controle de RP automático corretamente.
• Os anúncios de RP podem ser originados com êxito.
• A funcionalidade do Agente de Mapeamento pode operar corretamente.

---

Etapa 4.3 Analisar show ip pim rp

Este comando valida:

• descoberta de RP
• Anúncios de RP automático
• Operação do Agente de Mapeamento
• Mapeamentos de grupo para RP

N9K-1 — Informações RP

N9K-1# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5*, next Discovery message in: 00:00:39
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.1*, (0),
 uptime: 22:18:44   priority: 255,
 RP-source: 10.2.0.1 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:00:37 (A)

RP: 10.2.0.4, (0),
 uptime: 23:00:32   priority: 255,
 RP-source: 10.2.0.4 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:00:44 (A)

Explicação Linha a Linha

BSR desabilitado

BSR disabled

Isto confirma que:

• O roteador de bootstrap (BSR) não é usado.
• O domínio multicast depende exclusivamente do RP automático.

Este comportamento é esperado nesta topologia.

RPA de RP automático: 10.2.1.5*

Auto-RP RPA: 10.2.1.5*

• 10.2.1.5 corresponde a loopback1 em N9K-1.
• O * indica que o switch local em si é o Agente de Mapeamento ativo.

Isto significa:

• N9K-1 origina mensagens RP-Discovery.
• O N9K-1 coleta anúncios RP de candidatos RP.
• O N9K-1 distribui informações de mapeamento RP para o domínio multicast.

Próxima mensagem de descoberta em

next Discovery message in: 00:00:39

• Verifique se o temporizador é atualizado continuamente.
• Verifique se as mensagens de Descoberta são enviadas periodicamente.

Se esse temporizador congelar ou expirar inesperadamente, os anúncios de RP automático não poderão se propagar corretamente.

Campos de política

BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

• Nenhuma política de filtragem é aplicada.
• Todos os anúncios RP e anúncios Discovery são aceitos.

Primeira entrada RP

RP: 10.2.0.1*, (0),

• Endereço RP = 10.2.0.1
• O * indica que esse RP é local para N9K-1.
• 10.2.0.1 corresponde a loopback0 em N9K-1.

Isso confirma que o N9K-1 está configurado como um candidato RP.

Tempo de atividade e prioridade

uptime: 22:18:44   priority: 255,

• Tempo de atividade estável indica operação de anúncio RP estável.
• A prioridade 255 é a prioridade mais alta padrão.

Origem RP

RP-source: 10.2.0.1 (A),

• O anúncio RP se originou diretamente do próprio RP.
• (A) indica informações aprendidas do RP automático.

Intervalo do grupo

224.10.20.0/24

• Verifique se o intervalo multicast correto é anunciado.
• Verifique se o intervalo do grupo corresponde à configuração.

Segunda entrada RP

RP: 10.2.0.4, (0),

• Existe outro RP na topologia.
• 10.2.0.4 corresponde a loopback0 em N9K-2.
• No * é exibido porque esse RP é remoto de N9K-1.

N9K-2 — Informações RP

N9K-2# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 22:19:10, expires: 00:02:28

RP: 10.2.0.4*, (0),
 uptime: 23:14:14   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:28 (A)

Principais diferenças no N9K-2

Auto-RP RPA: 10.2.1.5

• Nenhum * é exibido porque N9K-2 não é o Agente de Mapeamento.
• O N9K-2 aprende remotamente as informações do Agente de Mapeamento do N9K-1.

Diferença importante de RP

RP-source: 10.2.1.5 (A),

• N9K-2 aprende informações de RP do Agente de Mapeamento.
• O Agente de Mapeamento é 10.2.1.5.

Isto confirma que:

• As mensagens de descoberta do RP automático estão funcionando corretamente.
• Anúncios do Agente de Mapeamento propagados com êxito pelo domínio multicast.

Etapa 4.4 Validar o processo de eleição do RP automático e a seleção do RP

O RP automático usa duas funções de plano de controle de multicast diferentes:

• RP-Candidato
• Agente de Mapeamento

Entender como essas funções interagem é essencial ao validar a operação multicast em um ambiente de Modo Esparso do PIM.

Nesta topologia:

• N9K-1 e N9K-2 operam como RP-Candidatos.
• O N9K-1 opera como o Agente de Mapeamento ativo.

Operação RP-Candidate

Um candidato RP anuncia a si mesmo como um ponto de encontro válido para um ou mais intervalos de grupos multicast.

Cada candidato RP envia periodicamente mensagens de Anúncio de RP automático para:

• 224.0.1.39 — Grupo de anúncio de RP automático
  
  

Esses anúncios contêm:

• endereço RP
• Intervalo do grupo
• Prioridade
• Tempo de suspensão

Nesta topologia:

• 10.2.0.1 em N9K-1 anuncia-se como um RP.
• 10.2.0.4 em N9K-2 anuncia-se como um RP.

N9K-1 — Informações RP-Candidate

N9K-1# show ip pim rp
<snip>
RP: 10.2.0.1*, (0),
 uptime: 23:11:22 priority: 255,
 RP-source: 10.2.0.1 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:00:38 (A)

RP: 10.2.0.4, (0),
 uptime: 23:53:09 priority: 255,
 RP-source: 10.2.0.4 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:00:43 (A)

N9K-2 — Informações RP-Candidate

N9K-2# show ip pim rp
<snip>
RP: 10.2.0.4*, (0),
 uptime: 1d00h priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:02:52 (A)

Ambos os dispositivos anunciam o mesmo intervalo de grupo multicast:

• 224.10.20.0/24

Ambos os candidatos RP também usam:

• Prioridade 255

Isso é importante porque o RP automático usa prioridade e endereço RP durante a seleção RP.

Identificação do Agente de Mapeamento Ativo

O Agente de Mapeamento seleciona o RP ativo para um grupo multicast iniciando com esta lógica:

1. Maior prioridade RP ganha.
2. Se as prioridades forem iguais, o endereço IP do RP mais alto ganhará.

Nesta topologia:

• Endereço RP N9K-1 = 10.2.0.1
• Endereço RP N9K-2 = 10.2.0.4
• Ambos os candidatos RP usam a prioridade 255

Como ambos os candidatos RP têm a mesma prioridade:

• O endereço IP do RP mais alto se torna o RP selecionado.

Portanto:

• 10.2.0.4 se torna o RP ativo para 224.10.20.0/24.

Validação de RP selecionada

N9K-2 — RP Selecionado

N9K-2# show ip pim rp
<snip>
RP: 10.2.0.4*, (0),
 uptime: 23:14:14   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24

Por que o N9K-1 ainda exibe ambas as entradas RP

No N9K-1:

N9K-1# show ip pim rp
<snip>
RP: 10.2.0.1*, (0),
RP: 10.2.0.4, (0),

Este comportamento é esperado porque:

• O N9K-1 opera como o Agente de Mapeamento.
• O agente de mapeamento mantém a visibilidade de todos os candidatos RP.
• A saída exibe todos os anúncios RP aprendidos antes da distribuição da seleção RP final.

Passo 5: Verificar o acesso a candidatos RP e agentes de mapeamento

Todos os roteadores multicast que participam do domínio do modo escasso do PIM devem manter um alcance de IP estável para:

• Todos os candidatos RP
• Todos os Agentes de Mapeamento

Esta validação é crítica porque o Modo PIM Esparso depende do roteamento unicast para:

• Alcance o ponto de encontro (RP)
• Construir a árvore multicast compartilhada (RPT)
• Entregar mensagens PIM Register do First Hop Router (FHR)
• Receber anúncios de descoberta de RP automático
• Executar validação de Encaminhamento de Caminho Reverso (RPF)

Se a acessibilidade em relação ao RP ou ao Agente de Mapeamento falhar:

• As origens de multicast podem falhar no registro com êxito.
• Os receptores podem falhar ao ingressar em grupos multicast.
• Anúncios de RP automático não puderam se propagar corretamente.
• Podem ocorrer falhas de RPF.
• O encaminhamento de tráfego multicast pode se tornar instável ou intermitente.

---

Verificar Entradas de Roteamento Estáveis

A tabela de roteamento deve conter rotas unicast estáveis para:

• Todos os loopbacks RP
• Todos os loopbacks de agentes de mapeamento
• Todas as interfaces de trânsito multicast

As rotas devem permanecer instaladas continuamente sem oscilação de rota ou eventos de reconvergência excessivos.

Verifique:

• Corrigir seleção do próximo salto
• Corrija a interface de saída
• Tempo de atividade de rota estável
• Origem esperada do protocolo de roteamento
• Alcance unicast consistente no domínio multicast

---

FHR-1 — Rota para RP-candidato 10.2.0.1

FHR-1# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.6, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1 — Rota para RP-candidato 10.2.0.4

FHR-1# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1 — Rota para o agente de mapeamento 10.2.1.5

FHR-1# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.6, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1 — Rota para o agente de mapeamento 10.2.1.4

FHR-1# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra

---

FHR-2 — Rota para RP-candidato 10.2.0.1

FHR-2# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.13, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2 — Rota para RP-candidato 10.2.0.4

FHR-2# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2 — Rota para o agente de mapeamento 10.2.1.5

FHR-2# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.13, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2 — Rota para o agente de mapeamento 10.2.1.4

FHR-2# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra

---

LHR — Rota para RP-candidato 10.2.0.1

LHR# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.22, Eth1/49, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR — Rota para RP-candidato 10.2.0.4

LHR# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR — Rota para o agente de mapeamento 10.2.1.5

LHR# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.22, Eth1/49, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR — Rota para o agente de mapeamento 10.2.1.4

LHR# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra

---

Verifique a acessibilidade do ping a partir de interfaces PIM

Após validar a tabela de roteamento, verifique a alcançabilidade de IP fim-a-fim em relação a:

• Todos os candidatos RP
• Todos os Agentes de Mapeamento

O ping deve ser originado de:

• Interfaces ativadas por PIM
• Interfaces de loopback participando do roteamento multicast

Essa validação é importante porque os roteadores multicast usam esses endereços de origem durante:

• estabelecimento de vizinho PIM
• Cálculos de RPF
• Encapsulamento PIM Register
• Comunicação de RP automático

Resumo de validação de ping

Dispositivo	IP origem	Destino	Função	Resultado
FHR-1	10.4.0.5	10.2.0.1	RP-Candidato	Bem-sucedido
FHR-1	10.4.0.5	10.2.0.4	RP-Candidato	Bem-sucedido
FHR-1	10.4.0.5	10.2.1.5	Agente de Mapeamento	Bem-sucedido
FHR-1	10.4.0.5	10.2.1.4	Agente de Mapeamento	Bem-sucedido
FHR-2	10.4.0.9	10.2.0.1	RP-Candidato	Bem-sucedido
FHR-2	10.4.0.9	10.2.0.4	RP-Candidato	Bem-sucedido
FHR-2	10.4.0.9	10.2.1.5	Agente de Mapeamento	Bem-sucedido
FHR-2	10.4.0.9	10.2.1.4	Agente de Mapeamento	Bem-sucedido
LHR	10.4.0.5	10.2.0.1	RP-Candidato	Bem-sucedido
LHR	10.4.0.5	10.2.0.4	RP-Candidato	Bem-sucedido
LHR	10.4.0.5	10.2.1.5	Agente de Mapeamento	Bem-sucedido
LHR	10.4.0.5	10.2.1.4	Agente de Mapeamento	Bem-sucedido

Verifique o estado operacional e o encaminhamento de tráfego multicast no FHR e no LHR

A próxima etapa de validação é verificar se:

• O FHR e o LHR aprenderam o RP esperado com êxito.
• A tabela de roteamento multicast contém os estados de multicast esperados.
• O plano de controle multicast opera corretamente antes do início da transmissão de tráfego multicast.
• O Modo PIM Esparso cria o estado de árvore compartilhado esperado.

---

Etapa 1 Verificar o aprendizado do RP no FHR e no LHR

Antes de validar o estado de encaminhamento multicast, verifique se todos os roteadores multicast aprenderam o RP esperado para o grupo multicast em validação.

Esta etapa é crítica porque:

• O FHR deve saber para onde enviar as mensagens do PIM Register.
• O LHR deve saber qual RP usar ao construir a árvore compartilhada.
• O domínio multicast deve manter um mapeamento RP consistente.

Nesta topologia:

• O RP selecionado é 10.2.0.4.
• O Agente de Mapeamento é 10.2.1.5.
• O intervalo do grupo multicast é 224.10.20.0/24.

---

FHR-1 — Verificar RP aprendido

FHR-1# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:30
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:30 (A)

FHR-2 — Verificar RP aprendido

FHR-2# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:15
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:15 (A)

LHR — Verificar RP aprendido

LHR# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:07
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:07 (A)

---

Análise de aprendizagem RP

As saídas confirmam que:

• Todos os roteadores multicast aprenderam o mesmo RP consistentemente.
• O RP selecionado é 10.2.0.4.
• O mapeamento RP foi aprendido por meio do RP automático.
• O Agente de mapeamento que distribui as informações do RP é 10.2.1.5.
• O mapeamento RP permanece estável por mais de um dia.
• Os temporizadores de expiração de Descoberta são atualizados corretamente.

Este comportamento é esperado porque:

• 10.2.0.4 foi selecionado como o RP ativo durante o processo de eleição do RP automático.
• 10.2.1.5 opera como o Agente de Mapeamento.
• Todos os roteadores multicast recebem com êxito anúncios de Descoberta de RP Automático.

Nesse estágio, o plano de controle multicast está operando corretamente e todos os roteadores têm um mapeamento RP consistente para 224.10.20.0/24

---

Etapa 2 Verificar o estado do roteamento multicast antes do tráfego multicast ativo

A próxima etapa é validar a tabela de roteamento multicast antes que a transmissão de tráfego multicast comece.

Neste cenário:

• O receptor multicast já ingressou no grupo multicast.
• Nenhum tráfego de origem multicast ativo está fluindo ainda.

Este estado é importante porque valida:

• operação de associação de IGMP
• criação de árvore compartilhada PIM
• Estado multicast inicial (*,G)
• Propagação de juros do receptor

FHR-1 — Tabela de roteamento multicast

FHR-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 23:07:34, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-2 — Tabela de roteamento multicast

FHR-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 23:07:37, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

---

Análise de Estado Multicast FHR

Os FHRs ainda não contêm:

• (* ,G) estado para 224.10.20.10
• Estado (S,G) para a origem de multicast

Este comportamento é esperado porque:

• Nenhum tráfego de origem de transmissão múltipla está ativo ainda.
• Nenhuma mensagem de registro PIM foi gerada.
• O FHR não iniciou o encaminhamento multicast.

A única entrada multicast presente é:

• 232.0.0.0/8

Isso corresponde ao intervalo padrão do SSM e é instalado automaticamente pelo sistema.

Estes valores são esperados:

• Interface de entrada: Nulo
• Vizinho de RPF: 0.0.0.0
• Contagem de interface de saída: 0

Essa entrada não indica encaminhamento multicast ativo.

---

LHR — Tabela de roteamento multicast

LHR# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 23:07:39, igmp ip pim
  Incoming interface: Ethernet1/50, RPF nbr: 10.4.0.26
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 23:07:39, igmp

(*, 232.0.0.0/8), uptime: 23:07:39, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Análise de Estado Multicast LHR

Ao contrário dos FHRs, o LHR contém uma entrada ativa (*,G) para:

• 224.10.20.10

Este comportamento é esperado porque:

• O receptor multicast já ingressou no grupo.
• As informações de associação IGMP foram aprendidas na Vlan2.
• O LHR iniciou a junção da árvore compartilhada em direção ao RP.

A tabela de roteamento multicast confirma:

• A Interface de Entrada (IIF) é Ethernet1/50.
• O vizinho RPF é 10.4.0.26.
• A Outgoing Interface List (OIL) contém Vlan2.

Isso indica que:

• O LHR construiu corretamente a árvore compartilhada em direção ao RP.
• O interesse do receptor multicast se propagou com êxito no upstream.
• As mensagens PIM Join foram transmitidas corretamente.

Nesta fase:

• Nenhum tráfego de origem de transmissão múltipla está ativo ainda.
• Ainda não existe um estado (S,G).
• Existe somente o estado da árvore compartilhada.

---

N9K-1 — Mapeando a tabela de roteamento multicast do agente

N9K-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 1d03h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Mapeando Análise de Estado Multicast do Agente

O N9K-1 opera apenas como o Agente de Mapeamento e não participa do encaminhamento multicast para 224.10.20.10

Portanto, é esperada a ausência de entradas (*, G) e entradas (S, G).

O Agente de Mapeamento distribui apenas informações de mapeamento RP e não necessariamente participa do encaminhamento de dados multicast, a menos que o tráfego multicast atravesse o dispositivo diretamente.

---

N9K-2 — Tabela de Roteamento Multicast RP

N9K-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d01h, pim ip
  Incoming interface: loopback0, RPF nbr: 10.2.0.4
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 1d01h, pim

(*, 232.0.0.0/8), uptime: 1d03h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Análise do estado de multicast RP

O N9K-2 opera como RP ativo para:

• 224.10.20.0/24

Portanto, o RP contém o estado da árvore compartilhada (*,G) para 224.10.20.10

Estes valores são esperados:

• Interface de entrada = loopback0
• Vizinho RPF = 10.2.0.4
• Interface de saída = Ethernet1/49

Isso indica que:

• O RP instalou o estado da árvore compartilhada com êxito.
• O RP recebeu mensagens PIM Join dos roteadores downstream.
• A árvore multicast compartilhada em direção aos receptores foi criada corretamente.

Nesta fase:

• O RP contém apenas o estado da árvore compartilhada.
• Nenhum tráfego de origem de transmissão múltipla está ativo ainda.
• Ainda não existem entradas (S,G).

---

Etapa 3 Verificar O Estado De Roteamento Multicast Com O Tráfego Multicast Ativo

Uma vez iniciada a transmissão de tráfego multicast, a tabela de roteamento multicast faz a transição do estado da árvore compartilhada para o estado de encaminhamento ativo específico da origem.

Neste cenário:

• A origem multicast é 10.150.1.37.
• O grupo multicast é 224.10.20.10.
• O RP ativo é 10.2.0.4 em N9K-2.
• A origem multicast se conecta através do canal de porta 78 do vPC.

---

Considerações importantes sobre multicast vPC

A origem multicast se conecta por meio de um domínio vPC formado por FHR-1 e FHR-2.

Como a origem se conecta por meio de um canal de porta membro do vPC:

• O hashing de tráfego pode encaminhar pacotes multicast para qualquer switch Nexus.
• Ambos os FHRs exigem configuração de multicast idêntica.
• Ambos os FHRs exigem informações de roteamento unicast consistentes.
• Ambos os FHRs devem manter mapeamentos RP idênticos.
• Ambos os FHRs devem manter adjacências de PIM estáveis.

Neste cenário específico:

• Os hashes de fluxo multicast para FHR-2.
• FHR-2 se torna o FHR de encaminhamento ativo para a origem de multicast.

FHR-1 — Tabela de roteamento multicast

FHR-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:03:58, ip pim
  Incoming interface: Vlan1, RPF nbr: 10.150.1.37
  Outgoing interface list: (count: 0)

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-1 — Função vPC

FHR-1# show vpc role

vPC Role status
----------------------------------------------------
vPC role                        : primary <<<
Dual Active Detection Status    : 0
vPC system-mac                  : 00:23:04:ee:be:01
vPC system-priority             : 32667
vPC local system-mac            : 00:6b:f1:84:02:97
vPC local role-priority         : 32667
vPC local config role-priority  : 32667
vPC peer system-mac             : 6c:b2:ae:ee:5a:97
vPC peer role-priority          : 32667
vPC peer config role-priority   : 32667

Análise de Estado Multicast FHR-1

FHR-1 contém uma entrada ativa (S,G) para:

• Origem = 10.150.1.37
• Grupo = 224.10.20.10

A entrada de roteamento multicast confirma:

• A origem foi aprendida na Vlan1.
• O vizinho RPF é a fonte multicast diretamente conectada.
• Não existem interfaces de saída no OIL.

Esse comportamento é esperado porque o fluxo de multicast não gerou hash em direção a FHR-1 para encaminhamento de saída.

Como resultado:

• O FHR-1 instala somente o estado de origem local.
• FHR-1 não encaminha o tráfego multicast upstream através do PIM.

FHR-2 — Tabela de roteamento multicast

FHR-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:16:35, ip pim
  Incoming interface: Vlan1, RPF nbr: 10.150.1.37
  Outgoing interface list: (count: 1)
    Ethernet1/3, uptime: 00:16:35, pim

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-2 — Função vPC

FHR-2# show vpc role

vPC Role status
----------------------------------------------------
vPC role                        : secondary <<<
Dual Active Detection Status    : 0
vPC system-mac                  : 00:23:04:ee:be:01
vPC system-priority             : 32667
vPC local system-mac            : 6c:b2:ae:ee:5a:97
vPC local role-priority         : 32667
vPC local config role-priority  : 32667
vPC peer system-mac             : 00:6b:f1:84:02:97
vPC peer role-priority          : 32667
vPC peer config role-priority   : 32667

Análise de Estado Multicast FHR-2

Ao contrário da FHR-1, a FHR-2 contém:

• Uma lista ativa de interfaces de saída
• Um caminho de encaminhamento PIM ativo

Isso indica que:

• O FHR-2 tornou-se o FHR de encaminhamento operacional para o fluxo multicast.
• Os pacotes multicast têm hash em direção a FHR-2 através do canal de porta membro do vPC.
• O FHR-2 encapsulou o tráfego multicast em mensagens PIM Register.
• FHR-2 encaminhou o tráfego multicast upstream em direção ao RP.

Comportamento de encaminhamento ECMP e multicast

A interface de saída Ethernet1/3 corresponde à tabela de roteamento unicast em direção ao receptor 192.168.2.37

FHR-2 — Rota para receptor multicast

FHR-2# show ip route 192.168.2.37

IP Route Table for VRF "default"

'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.13, Eth1/3, [110/45], 1d02h, ospf-UNDERLAY, intra
    *via 10.4.0.18, Eth1/4, [110/45], 1d02h, ospf-UNDERLAY, intra

O FHR-2 contém duas rotas de custo igual para a sub-rede do receptor multicast:

• 10.4.0.13 através de Ethernet1/3
• 10.4.0.18 através de Ethernet1/4

Isto confirma que:

• O roteamento ECMP está ativo na topologia de transporte multicast.
• Existem vários caminhos válidos de encaminhamento unicast para a rede do receptor.
• O PIM pode usar o caminho RPF selecionado pelo MRIB para decisões de encaminhamento multicast.
• A duplicação de pacotes em caminhos ECMP paralelos não ocorre.

Embora existam duas rotas de custo igual, o encaminhamento multicast usa um único caminho RPF para cada fluxo multicast.

Nessa topologia, o fluxo multicast usa:

• Ethernet1/3 para 10.4.0.13

Esse comportamento corresponde à tabela de roteamento multicast observada anteriormente:

(10.150.1.37/32, 224.10.20.10/32)
  Outgoing interface list:
    Ethernet1/3

---

Comportamento operacional primário e secundário do vPC

As funções operacionais do vPC influenciam o comportamento de encaminhamento multicast de forma diferente para:

• tráfego PIM
• processamento IGMP

Nesta topologia:

• FHR-1 é o vPC operacional principal.
• FHR-2 é o vPC secundário operacional.

Os dois switches Nexus podem:

• Processar tráfego de plano de controle PIM
• Criar estado de roteamento multicast
• Encaminhar tráfego multicast através do PIM

No entanto:

• Somente o vPC operacional principal processa o tráfego do receptor IGMP em direção à camada de acesso.

Esta distinção é importante porque:

• O encaminhamento PIM em direção à rede roteada permanece ativo em ambos os pares.
• O encaminhamento de IGMP para segmentos de receptor de Camada 2 permanece centralizado no principal operacional.

Portanto:

• O tráfego multicast da origem para o domínio multicast roteado pode sair por qualquer par do vPC.
• O tráfego multicast para os receptores IGMP depende do comportamento primário operacional.

---

LHR — Tabela de roteamento multicast

LHR# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d00h, igmp ip pim
  Incoming interface: Ethernet1/50, RPF nbr: 10.4.0.26
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 1d00h, igmp

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:31, ip mrib pim
  Incoming interface: Ethernet1/49, RPF nbr: 10.4.0.22
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 00:06:31, mrib

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Análise de Estado Multicast LHR

O LHR agora contém ambos:

• (* ,G) estado da árvore compartilhada
• (S,G) estado da árvore de origem

Isso confirma:

• O receptor multicast ingressou com êxito.
• A origem de multicast se tornou ativa.
• O LHR fez a transição do encaminhamento de árvore compartilhada para o encaminhamento de árvore de origem.

A entrada (S,G) confirma:

• O caminho de origem de multicast foi aprendido com êxito.
• O vizinho RPF é 10.4.0.22.
• O tráfego multicast chega pela Ethernet1/49.
• O tráfego multicast é encaminhado para os receptores Vlan2.

Este comportamento confirma o êxito:

• encaminhamento PIM
• validação de RPF
• Construção de árvore de origem
• Entrega de tráfego multicast

---

N9K-1 — Tabela de Roteamento Multicast de Trânsito

N9K-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:42, pim ip
  Incoming interface: Ethernet1/4, RPF nbr: 10.4.0.14
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 00:06:42, pim

(*, 232.0.0.0/8), uptime: 1d04h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Análise do estado de trânsito N9K-1

O N9K-1 opera como um roteador multicast de trânsito para o fluxo multicast ativo.

A entrada de roteamento multicast confirma:

• O tráfego multicast chega da Ethernet1/4.
• O tráfego multicast é encaminhado para a Ethernet1/49.
• O caminho de encaminhamento multicast em direção ao LHR está operacional.

Isso confirma o sucesso:

• operação de vizinho de PIM
• validação de RPF
• Encaminhamento multicast através da rede de trânsito

---

N9K-2 — Tabela de Roteamento Multicast RP

N9K-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d02h, pim ip
  Incoming interface: loopback0, RPF nbr: 10.2.0.4
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 1d02h, pim

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:50, ip pim mrib
  Incoming interface: Ethernet1/4, RPF nbr: 10.4.0.17, internal
  Outgoing interface list: (count: 0)

(*, 232.0.0.0/8), uptime: 1d04h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Análise do estado de multicast RP

O N9K-2 opera como o RP ativo para o grupo multicast.

O RP contém ambos:

• (* ,G) estado da árvore compartilhada
• (S,G) estado da árvore de origem

A ausência de interfaces de saída na entrada (S,G) é esperada porque:

• O RP já comutou receptores em direção à árvore de caminho mais curto.
• O caminho de encaminhamento de árvore compartilhada não é mais necessário para o encaminhamento multicast ativo.

Informações mínimas de multicast necessárias para RCA e diagnósticos de integridade

A lista de comandos fornece a coleta de dados multicast mínima recomendada necessária para executar uma análise de causa raiz (RCA) ou um diagnóstico de integridade multicast nos switches Cisco Nexus 9000 Series que executam o NX-OS. Essas saídas capturam o estado do plano de controle de multicast, programação MRIB, informações de encaminhamento, estado operacional vPC e detalhes de encaminhamento de hardware. No entanto, ainda podem ser necessárias informações adicionais, dependendo do cenário de falha. Por exemplo, perda de pacotes multicast, quedas intermitentes de tráfego, problemas de replicação de pacotes, inconsistências de encaminhamento de hardware ou encaminhamento multicast fora de ordem frequentemente exigem capturas diretas de pacotes no switch Nexus usando o Ethanalyzer, o SPAN ou capturas no nível de hardware. Da mesma forma, podem ocorrer inconsistências transitórias de RPF, alterações de encaminhamento de ECMP, falhas de programação de ASIC ou eventos de supressão de IGMP sem a geração de log persistente.

Como resultado, a combinação de saídas show tech com capturas de pacotes e validação de encaminhamento melhora significativamente a precisão do diagnóstico e a qualidade da RCA. Embora essas informações forneçam uma base operacional sólida para a solução de problemas de multicast, elas não garantem que uma RCA sempre possa ser identificada exclusivamente a partir dessas saídas. Determinadas falhas de multicast exigem Troubleshooting adicional, análise de tráfego ao vivo, validação em nível de hardware, correlação de topologia ou capturas de pacotes estendidos para isolar a causa raiz exata.

Comandos mínimos de coleta de dados multicast

N9K-1# show tech-support multicast >> bootflash:$(SWITCHNAME)-sh-tech-multicast.txt

N9K-1# show tech-support details >> bootflash:$(SWITCHNAME)-sh-tech-det.txt

N9K-1# show tech-support vpc >> bootflash:$(SWITCHNAME)-sh-tech-vpc.txt

N9K-1# show tech-support forwarding multicast >> bootflash:$(SWITCHNAME)-sh-tech-fwd-multicast.txt

N9K-1# show tech-support forwarding l3 multicast detail vdc-all >> bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-multicast.txt

N9K-1# show tech-support forwarding l3 unicast detail vdc-all >> bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-unicast-det.txt

Criar um arquivo TAR para exportação

Depois de gerar os arquivos show tech, consolide-os em um único arquivo TAR para exportação e análise. O comando é uma única linha.

N9K-1# tar create bootflash:$(SWITCHNAME)-multicast-logs
bootflash:$(SWITCHNAME)-sh-tech-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-det.txt
bootflash:$(SWITCHNAME)-sh-tech-vpc.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-unicast-det.txt

A exportação de um único arquivo TAR simplifica:

• Carregamentos de caso do TAC
• Fluxos de trabalho RCA
• Análise de registro centralizada
• Correlação de encaminhamento multicast
• Preservação de falhas históricas

Histórico de revisões

Revisão	Data de publicação	Comentários
1.0	13-May-2026	Versão inicial