Recentemente comecei a trabalhar em um projeto envolvendo Cisco ACI e, durante os estudos e as atividades práticas, alguns conceitos chamaram minha atenção, principalmente em relação ao IPN, ao multicast, ao PIM-Bidir e ao Phantom RP.

A ideia deste artigo não é entrar na configuração dos componentes internos da fabric ACI, mas compartilhar um pouco do que venho estudando sobre os conceitos e mecanismos que fazem o IPN funcionar nesse tipo de arquitetura. Quero explorar principalmente a parte de rede que sustenta a comunicação entre os Pods, entender o papel do roteamento IP, do multicast e da redundância do Phantom RP, além de mostrar alguns comandos que ajudam a verificar o funcionamento desse ambiente.

Afinal, mesmo depois de muitos anos trabalhando com redes e infraestrutura, sempre existe algo novo para aprender. E uma das melhores formas de consolidar o conhecimento é estudar, colocar em prática e depois tentar explicar como tudo funciona.

Neste artigo, vamos entender o papel do IPN na arquitetura ACI Multi-Pod, como funciona o multicast nesse cenário, qual é a proposta do Phantom RP e quais comandos podemos utilizar para validar o ambiente e investigar possíveis problemas.

1. Como funciona o multicast no ACI Multi-Pod?

O Cisco ACI Multi-Pod permite expandir um fabric ACI para diferentes pods, mantendo uma arquitetura integrada e permitindo a comunicação entre eles.

Para que isso funcione corretamente, existe um componente que merece bastante atenção: o IPN (Inter-Pod Network).

O IPN fornece a conectividade de camada 3 entre os pods e também precisa suportar o tráfego multicast necessário para determinadas operações internas do ACI.

Antes de entrar na configuração, vale entender os três componentes principais envolvidos nesse processo.

PIM (Protocol Independent Multicast)

É o protocolo responsável por construir e manter os caminhos de encaminhamento multicast. No IPN, ele permite que os equipamentos participem da distribuição dos grupos multicast necessários à comunicação entre os pods.

RP (Rendezvous Point)

É a referência lógica utilizada pelo PIM para a construção da árvore multicast compartilhada. No PIM-Bidir, o RP participa da organização dessa árvore, permitindo o encaminhamento do tráfego entre origens e receptores.

IPN (Inter-Pod Network)

É a rede IP externa que interliga os pods. Além de fornecer conectividade unicast, ela precisa estar preparada para encaminhar o tráfego multicast utilizado pelo fabric.

Cada componente tem sua responsabilidade. O IPN fornece o transporte, o PIM constrói os caminhos multicast e o RP participa da lógica utilizada para organizar esses caminhos.

A topologia acima será utilizada como referência para a implementação e validação das configurações dos equipamentos IPN no ambiente Cisco ACI Multi-Pod. Ela representa a distribuição dos equipamentos, as interconexões entre os switches e a organização lógica necessária para o funcionamento da comunicação entre os Pods. Todas as configurações descritas nas próximas seções devem ser interpretadas com base nessa topologia, respeitando os endereçamentos IP, as interfaces e os relacionamentos estabelecidos no diagrama.

2. Como funciona o Phantom RP?

O Phantom RP é uma técnica utilizada para oferecer redundância ao endereço lógico do Rendezvous Point em ambientes que utilizam PIM-Bidir.

A ideia é utilizar um endereço IP que não esteja configurado como endereço de interface em um equipamento específico, mas que esteja contido em prefixos anunciados pelo protocolo de roteamento.

Dessa forma, os equipamentos utilizam o mesmo endereço lógico de RP, enquanto o roteamento determina qual caminho será utilizado para alcançá-lo.

2.1. Por que utilizar o Phantom RP?

Em um ambiente com redundância, não queremos depender de um único caminho físico para alcançar o endereço lógico do RP.

Ao utilizar prefixos com diferentes comprimentos de máscara, podemos criar uma lógica em que um caminho seja preferido enquanto estiver disponível e outro continue oferecendo alcance ao endereço em caso de falha..

É importante entender que o Phantom RP não é um segundo RP independente. O mecanismo utiliza o roteamento para fornecer caminhos alternativos para o mesmo endereço lógico.

2.2. Entendendo a seleção do caminho

Imagine que o endereço lógico do Phantom RP seja 10.12.0.2.

Considere dois prefixos anunciados na rede:

• 10.12.0.2/30
• 10.12.0.2/29

Ambos contêm o endereço 10.12.0.2, mas o primeiro prefixo é mais específico.

Quando os dois estão disponíveis e são válidos para o destino, o roteador seleciona o prefixo mais específico, seguindo a regra de longest-prefix match.

Se o caminho associado ao prefixo mais específico deixar de existir, o prefixo menos específico poderá continuar oferecendo alcance ao endereço, desde que permaneça instalado e válido.

Esse é o princípio utilizado para construir a redundância do Phantom RP.

Os prefixos acima são apenas exemplos didáticos. No ambiente real, é necessário conferir o planejamento de endereçamento, as rotas anunciadas e a preferência efetiva de cada caminho.

2.3. Por que o endereço exato do RP não pode existir?

O endereço Phantom RP precisa ser um endereço lógico, não atribuído diretamente a uma interface. Os equipamentos anunciam as redes que contêm esse endereço, e não o endereço do RP como uma interface real.

Se o endereço exato for configurado indevidamente em um dispositivo, a lógica de redundância planejada pode deixar de funcionar como esperado.

Outro detalhe importante é que o RP, no PIM-Bidir, não precisa estar no caminho físico dos pacotes de dados. Ele é uma referência para a árvore compartilhada. O tráfego é encaminhado pelo caminho multicast construído pelos roteadores, e não precisa passar por uma interface do RP.

3. Como o multicast funciona na topologia IPN?

Na topologia de referência, temos os equipamentos IPN-1, IPN-2, IPN-3 e IPN-4, conectados aos spines dos pods.

O ambiente utiliza uma VRF chamada IPN, além de loopbacks e prefixos de roteamento associados à conectividade e ao mecanismo de Phantom RP.

Para entender o funcionamento, vale separar o processo em duas partes: plano de controle e plano de dados.

3.1. Plano de controle: construção da árvore multicast

O plano de controle é responsável por estabelecer as informações necessárias para o encaminhamento multicast.

De forma simplificada, o processo funciona assim:

1. Os equipamentos do ACI identificam a necessidade de receber determinados grupos multicast.
2. Os spines sinalizam interesse nos grupos necessários, por meio dos mecanismos aplicáveis, incluindo IGMP.
3. Os equipamentos IPN recebem as sinalizações e utilizam PIM para construir ou atualizar os caminhos multicast.
4. O PIM-Bidir utiliza a árvore compartilhada associada ao grupo multicast.
5. Os equipamentos mantêm as informações necessárias para encaminhar o tráfego aos destinos interessados.

No PIM-Bidir, uma entrada do tipo (*,G) representa o estado da árvore compartilhada para determinado grupo multicast, sem a necessidade de uma árvore específica para cada origem.

3.2. Plano de dados: transporte entre os pods

Depois que os caminhos multicast estão estabelecidos, o plano de dados realiza o encaminhamento efetivo dos pacotes.

Imagine que um endpoint do Pod 1 gere tráfego que precisa alcançar outro endpoint no Pod 2.

O tráfego entra no fabric pelo leaf, passa pelo spine e, quando necessário, é transportado pelo IPN até o outro pod. No destino, o tráfego segue pelo spine e pelo leaf até alcançar os endpoints interessados.

No ACI, esse processo envolve encapsulamento e grupos multicast utilizados internamente pelo fabric, incluindo os GIPos (Group IP Outer).

É importante não confundir o GIPo com o endereço do Phantom RP. O GIPo identifica um grupo multicast utilizado no transporte do tráfego do fabric, enquanto o Phantom RP participa da lógica de construção da árvore compartilhada.

Na prática, os pacotes podem seguir caminhos diferentes conforme a topologia, a árvore multicast e as interfaces de saída. O diagrama acima representa o conceito, não uma rota física fixa.

Também é importante entender que o multicast do IPN não é simplesmente o multicast original da aplicação. O ACI utiliza mecanismos de encapsulamento e grupos multicast do fabric, incluindo os GIPos, para transportar tráfego interno entre pods.

4. Configuração aplicada

As configurações dos equipamentos IPN foram definidas com base na topologia de referência e nos requisitos de comunicação do ambiente Cisco ACI Multi-Pod. A implementação contempla os parâmetros globais necessários, a configuração das interfaces e loopbacks, o roteamento dinâmico OSPF na área 0 e a habilitação do multicast por meio do PIM Sparse Mode, com suporte ao modo Bidirectional (PIM-Bidir).

Para a distribuição do tráfego multicast, será utilizado o mecanismo Phantom RP, com endereços de RP lógicos que não serão atribuídos diretamente às interfaces dos equipamentos. A redundância será garantida por meio do anúncio de prefixos que abrangem esses endereços, com diferentes comprimentos de máscara, permitindo que o roteamento selecione o caminho preferencial e utilize uma rota alternativa em caso de falha.

As configurações serão aplicadas de forma padronizada nos quatro switches IPN, respeitando as particularidades de cada equipamento e os endereçamentos definidos na topologia. Ao final, serão realizadas validações de conectividade, adjacências OSPF, vizinhanças PIM e rotas multicast, a fim de confirmar o funcionamento esperado do ambiente.

Features e parâmetros globais

• Objetivo: habilitar os recursos necessários para o funcionamento do IPN, incluindo roteamento OSPF, multicast PIM e protocolos de camada 2 utilizados na infraestrutura.

# feature ospf
# feature pim
# feature interface-vlan
# feature lacp
# feature lldp
# system jumbomtu 9216

• feature ospf: habilita o protocolo OSPF para o roteamento entre os equipamentos IPN e os spines.
• feature pim: habilita o protocolo PIM, necessário para o encaminhamento multicast.
• feature interface-vlan: permite a utilização de interfaces VLAN (SVI).
• feature lacp: habilita a negociação de agregação de links por LACP.
• feature lldp: habilita a descoberta de dispositivos vizinhos por LLDP.
• system jumbomtu 9216: define o limite global de MTU jumbo, necessário quando o projeto exige o transporte de quadros maiores.

Configuração do OSPF

• O OSPF é responsável por divulgar as rotas entre os equipamentos IPN e manter a convergência do roteamento em caso de falha de um enlace.

A configuração utiliza a VRF IPN, separando o roteamento dessa rede dos demais contextos do equipamento.

# router ospf IPN
# vrf IPN
# log-adjacency-changes
# router-id <ROUTER_ID>

O processo OSPF é criado com o nome IPN e associado à VRF correspondente. O comando log-adjacency-changes registra alterações no estado das adjacências, facilitando o troubleshooting. O router-id identifica cada equipamento no domínio OSPF e deve ser único.

Configuração de multicast

• Esta seção prepara as interfaces e os endereços utilizados pelo roteamento multicast. A configuração inclui loopbacks para identificação dos equipamentos e para os endereços de RP, além das interfaces de transporte que interligam os IPNs e os spines.

Loopback0 – Router ID

• A Loopback0 utiliza um endereço /32 para identificar o equipamento de forma estável. Esse endereço também é anunciado pelo OSPF, permitindo que os demais dispositivos aprendam sua rota.

# interface loopback0
# vrf member IPN
# description ### ROUTER ID
# ip address <ROUTER_ID>/32
# ip router ospf IPN area 0
# no shutdown

Cada IPN deve possuir um endereço exclusivo para essa finalidade.

Loopback1 – RP

• A Loopback1 está relacionada ao endereço de RP utilizado para um determinado intervalo de grupos multicast. O PIM utiliza essa referência para organizar a árvore multicast correspondente.

# interface loopback1
# vrf member IPN
# description ### RP ###
# ip address IP ADDRESS/30
# ip router ospf IPN area 0
# ip pim sparse-mode
# no shutdown

O endereço e a máscara devem seguir o planejamento do RP para cada intervalo multicast. O OSPF fornece a conectividade IP necessária, enquanto o PIM habilita a participação da interface no roteamento multicast.

Loopback2 – Phantom RP

• A Loopback2 está relacionada aos prefixos utilizados para implementar a redundância do Phantom RP. A máscara configurada influencia o prefixo anunciado e, consequentemente, a seleção do caminho até o endereço lógico do RP.

# interface loopback2
# vrf member IPN
# description ### PHANTOM RP
# ip address IP ADDRESS/29
# ip router ospf IPN area 0
# ip pim sparse-mode
# no shutdown

Os prefixos devem ser planejados para que o endereço lógico do Phantom RP seja alcançável por caminhos alternativos. A configuração precisa garantir que o endereço exato utilizado como RP não seja atribuído indevidamente a uma interface.

Interfaces físicas do IPN

• As interfaces físicas conectam os equipamentos IPN entre si e aos spines dos pods. Neste bloco, as portas são configuradas como interfaces de camada 3, com MTU adequada ao transporte do tráfego do fabric.

# interface Ethernet1/1
# description ### EQUIPAMENTO REMOTO
# no switchport
# mtu 9150
# no shutdown

description: identifica o equipamento e a porta conectada.
no switchport: configura a interface para operar em camada 3.
mtu 9150: define a MTU da interface física.
no shutdown: habilita a interface.

A MTU deve ser compatível com os equipamentos e os enlaces envolvidos no transporte do tráfego entre os pods.

Subinterfaces – VLAN de transporte e VRF IPN

• As subinterfaces permitem separar logicamente o tráfego de transporte por VLAN. Neste cenário, a VLAN 4 é utilizada para a conectividade IPN, e cada subinterface recebe um endereço IP próprio.

# interface Ethernet1/1.4
# description ### EQUIPAMENTO REMOTO - VLAN 4 - VRF IPN
# mtu 9150
# encapsulation dot1q 4
# vrf member IPN
# ip address <ENDERECO_IP>/
# ip ospf network point-to-point
# ip router ospf IPN area 0
# ip pim sparse-mode
# no shutdown

Referência Cisco – VLAN 4: Conforme a documentação de referência da Cisco para ambientes ACI Multi-Pod, a VLAN 4 é utilizada como padrão para a conectividade IPN. Por esse motivo, adotaremos essa VLAN na implementação, mantendo alinhamento com a recomendação documentada pela Cisco e padronizando a configuração do transporte entre os equipamentos da fabric ACI e a rede IPN.

A documentação oficial da Cisco confirma que o tráfego originado nas interfaces dos spines utiliza a marcação 802.1Q com VLAN 4, exigindo subinterfaces Layer 3 correspondentes nos equipamentos IPN.

Autenticação OSPF

• Nas interfaces em que a autenticação está prevista, o OSPF utiliza uma chave compartilhada para validar as mensagens do protocolo.

# ip ospf authentication message-digest
# ip ospf message-digest-key 0 md5 CISCO@LAB-CCIE

A configuração deve ser consistente nas duas extremidades do enlace. A chave apresentada no exemplo original deve ser tratada como informação sensível e substituída por um segredo adequado antes de utilizar os scripts em produção.

# vrf context IPN
# ip pim rp-address 10.12.0.2 group-list 225.0.0.0/17 bidir
# ip pim rp-address 10.12.0.10 group-list 225.0.128.0/17 bidir
# ip pim rp-address 10.12.0.18 group-list 225.1.0.0/17 bidir
# ip pim rp-address 10.12.0.26 group-list 225.1.128.0/17 bidir
# ip pim rp-address 10.12.0.2 group-list 239.255.255.240/28 bidir
# ip pim ssm range 232.0.0.0/8

Cada comando ip pim rp-address associa um endereço de RP a um intervalo de grupos multicast. A palavra-chave bidir indica que esses grupos utilizarão o modo PIM Bidirectional.

A última linha define o intervalo de grupos destinado ao Source-Specific Multicast (SSM), que utiliza um modelo diferente do PIM-Bidir e não depende do RP para esses grupos.

Ponto importante: os endereços de RP precisam estar corretamente associados ao desenho de Phantom RP. No script enviado, os endereços 10.12.0.2, 10.12.0.10, 10.12.0.18 e 10.12.0.26 aparecem também atribuídos diretamente às loopbacks. Revise essa relação antes de considerar a configuração final.

4. Script completo de configuração dos equipamentos IPN

O script completo com as configurações CLI dos equipamentos IPN está disponível para consulta e utilização como referência durante a implementação. O arquivo reúne os comandos organizados conforme os parâmetros definidos neste documento e a topologia de referência, facilitando a aplicação das configurações e futuras atividades de validação, manutenção e troubleshooting.

5. Comandos para verificar o funcionamento

Após a aplicação das configurações, iniciaremos a validação do ambiente para confirmar se os equipamentos IPN estão operando conforme o esperado. A verificação será realizada por etapas, começando pela conectividade IP e pelo estado das adjacências OSPF, seguida pela análise das rotas utilizadas para alcançar os endereços lógicos do Phantom RP, das vizinhanças PIM e, por fim, das tabelas de roteamento multicast.

Todos os comandos apresentados nesta seção têm como referência equipamentos Cisco Nexus com sistema operacional NX-OS. A sintaxe e a disponibilidade de alguns comandos podem variar conforme a versão do software e os recursos habilitados no equipamento. Portanto, os exemplos devem ser utilizados como referência para a execução dos testes e a análise dos resultados durante a implementação e o troubleshooting do ambiente.

5.1. Verificando o roteamento IP

• Comece verificando as rotas e as adjacências OSPF:

# show ip route vrf IPN
# show ip ospf neighbors vrf IPN

O objetivo é confirmar que os equipamentos possuem as rotas necessárias e que as adjacências OSPF estão estabelecidas nos enlaces em que isso é esperado.

Também vale verificar se os prefixos relacionados ao Phantom RP estão presentes na tabela de roteamento.

5.2. Verificando o Phantom RP

• Para consultar o RP reconhecido pelo PIM:

# show ip pim rp vrf IPN

Depois, verifique a rota para o endereço lógico do Phantom RP:

# show ip route <ENDERECO_PHANTOM_RP> vrf IPN

Substitua o campo pelo endereço real utilizado no ambiente.

Aqui, precisamos confirmar três pontos:

• O endereço lógico de RP é o esperado para os grupos multicast.
• A rota selecionada corresponde ao caminho planejado.
• Existe um caminho alternativo válido, conforme o desenho de redundância.

A presença de uma rota para o RP, isoladamente, não comprova que a árvore multicast esteja funcionando.

5.3. Verificando os vizinhos PIM

Para verificar o estado do PIM nas interfaces e as adjacências estabelecidas:

# show ip pim neighbor vrf IPN
# show ip pim interface vrf IPN

O primeiro comando mostra os vizinhos PIM descobertos pelo equipamento. O segundo permite verificar as interfaces nas quais o protocolo está habilitado.

Se um vizinho esperado não aparecer, vale investigar a conectividade, o estado das interfaces e a configuração de PIM nos equipamentos envolvidos.

5.4. Verificando a tabela multicast

Agora chegamos a uma das verificações mais importantes:

# show ip mroute vrf IPN

A tabela multicast permite analisar as entradas de encaminhamento, as interfaces de entrada e as interfaces de saída utilizadas para distribuir o tráfego.

No PIM-Bidir, procure as entradas (*,G) correspondentes aos grupos utilizados pelo ambiente.

Também é importante observar:

• A interface de entrada e a coerência com o caminho RPF.
• As interfaces de saída instaladas para encaminhar o tráfego.
• A presença dos grupos esperados.
• A consistência das informações entre os equipamentos IPN envolvidos.

Não encontrar uma entrada (S,G) específica para cada origem não significa necessariamente que exista uma falha. No PIM-Bidir, a árvore compartilhada tem papel central no encaminhamento.

5.5. Verificando os grupos IGMP

O IGMP ajuda a entender se existe interesse pelos grupos multicast nos pontos esperados.

# show ip igmp groups vrf IPN

A interpretação depende do papel do equipamento e da configuração do ambiente. Nem todo IPN precisa apresentar exatamente os mesmos grupos IGMP em todas as interfaces.

O importante é comparar as informações com a topologia e verificar se os grupos necessários estão presentes nos pontos apropriados.

5.6. Verificando um GIPo específico

Para investigar um Bridge Domain, identifique no APIC o GIPo correspondente ao contexto que deseja analisar.

Com o endereço em mãos, consulte a tabela multicast:

# show ip mroute <GIPO_REAL> vrf IPN

Substitua <GIPO_REAL> pelo endereço encontrado no ambiente.

Essa consulta ajuda a relacionar as informações do APIC com as entradas multicast presentes no IPN.

6. Como testar a redundância do Phantom RP?

Uma configuração pode parecer correta enquanto todos os enlaces estão operacionais. O verdadeiro teste acontece quando um dos caminhos deixa de existir.

Em uma janela controlada de manutenção, podemos validar o comportamento da redundância seguindo alguns passos:

1. Registrar as rotas para o Phantom RP antes do teste.
2. Conferir os vizinhos PIM e as entradas multicast.
3. Identificar o caminho primário e o caminho alternativo.
4. Simular a indisponibilidade do caminho primário de forma planejada.
5. Acompanhar a convergência do OSPF e a seleção da nova rota.
6. Verificar novamente o RP e as entradas multicast.
7. Confirmar que o tráfego entre os pods continua funcionando.

Não devemos assumir que a mudança de rota garante, automaticamente, a continuidade de todos os fluxos multicast. O resultado depende da convergência, do estado das árvores e das condições da topologia.

Esse tipo de teste precisa de planejamento, avaliação de impacto e uma estratégia de retorno, principalmente em ambientes de produção.

7. Boas práticas para o IPN

Alguns cuidados fazem bastante diferença na operação do ACI Multi-Pod:

• Manter o planejamento de endereçamento e das loopbacks bem documentado.
• Conferir os prefixos utilizados pelo Phantom RP e a forma como são anunciados.
• Garantir que o PIM esteja habilitado nas interfaces corretas.
• Validar o roteamento multicast, e não apenas a conectividade unicast.
• Documentar os grupos GIPo dos Bridge Domains relevantes para o troubleshooting.
• Testar a redundância antes de depender dela em uma situação real de falha.
• Comparar os resultados dos comandos entre os equipamentos envolvidos.

Uma boa documentação do IPN facilita muito o troubleshooting, principalmente em ambientes com vários pods e múltiplos caminhos de redundância.

Conclusão

Começar a trabalhar com uma tecnologia ou arquitetura diferente é sempre uma boa oportunidade para revisar conceitos e aprender algo novo.

No caso do Cisco ACI Multi-Pod, entender o papel do IPN, do multicast, do PIM-Bidir e do Phantom RP ajuda a compreender como os diferentes pods se comunicam e como podemos investigar problemas nesse tipo de ambiente.

Resolvi registrar esses pontos aqui tanto para compartilhar conhecimento quanto para manter minhas próprias referências técnicas organizadas. É uma forma de consolidar o que venho estudando e, ao mesmo tempo, contribuir com quem também está trabalhando com ACI ou começando a explorar essa arquitetura.

No final, documentação e compartilhamento fazem parte do aprendizado. Quanto melhor entendemos a arquitetura, mais preparados estamos para analisar cenários reais, identificar problemas e tomar decisões com segurança.

E esse é justamente o objetivo do Tech Study Jedi: estudar, compartilhar conhecimento e manter a base técnica sempre em evolução.

Que a Força esteja com você!

Referência técnica

Cisco – Troubleshoot Multi-Pod Issues in an ACI Network
Cisco – Cisco Application Centric Infrastructure Multi-Pod