Identificar e solucionar problemas do ACI Fabric Discovery - Multi-Pod Discovery

Introduction

Este documento descreve as etapas para entender e solucionar problemas da descoberta de vários pods da ACI.

Informações de Apoio

O material deste documento foi extraído do Solução de problemas da Cisco Application Centric Infrastructure, segunda edição livro, especificamente o Fabric Discovery - Descoberta de vários pods capítulo.

Visão geral de vários pods

O ACI Multi-Pod permite a implantação de um único cluster APIC para gerenciar várias redes ACI interconectadas. Essas redes ACI separadas são chamadas de "pods" e cada pod é uma topologia spine-leaf regular de dois ou três níveis. Um único cluster do APIC pode gerenciar vários Pods.

Um projeto de vários pods também permite a extensão das políticas de estrutura da ACI em pods que podem existir fisicamente em várias salas ou até mesmo em locais remotos de data center. Em um projeto de vários pods, qualquer política definida no cluster de controladores do APIC é disponibilizada automaticamente para todos os pods.

Finalmente, um projeto de vários pods aumenta o isolamento de domínio de falha. Na verdade, cada Pod executa sua própria instância de COOP, MP-BGP e protocolo IS-IS para que as falhas e os problemas com qualquer um desses protocolos estejam contidos nesse Pod e não possam se espalhar para outros Pods.

Consulte o documento "ACI Multi-Pod White Paper" em cisco.com para obter mais informações sobre o projeto de Multi-Pod e as práticas recomendadas.

Os principais elementos de uma estrutura ACI de vários pods são os switches leaf e spine, os controladores APIC e os dispositivos IPN.

Este exemplo se aprofunda no fluxo de trabalho de solução de problemas relacionados à configuração de uma estrutura ACI Multi-Pod. A topologia de referência usada para esta seção é descrita na figura abaixo:

Topologia de referência de vários pods da ACI

Troubleshooting de fluxo de trabalho

Verificar as políticas da ACI

Políticas de acesso

Multi-Pod usa um L3Out para conectar Pods através do locatário 'infra'. Isso significa que o conjunto padrão de políticas de acesso precisa estar em vigor para ativar o encapsulamento L3Out do Multi-Pod (VLAN-4) necessário nas portas spine voltadas para o IPN.

As Políticas de Acesso podem ser configuradas através do assistente 'Adicionar Pod', que deve ser usado para implantar o Multi-Pod. Depois de usar o assistente, a política implantada pode ser verificada na GUI do APIC. Se as políticas não forem configuradas corretamente, uma falha aparecerá no locatário inferior e a conectividade das lombadas com o IPN poderá não estar funcionando conforme esperado.

Os esquemas a seguir podem ser referenciados durante a verificação da definição da política de acesso para as interfaces com IPN nos nós spine:

Spine201

Spine202

Spine401

Spine402

No locatário inferior, o Multi-Pod L3Out deve ser configurado de acordo com o seguinte esquema:

Multi-Pod L3Out em locatário inferior

Abaixo está uma captura de referência da configuração do Perfil de Interface Lógica de Saída L3do Multi-Pod. As definições de subinterface do roteador devem ser semelhantes à figura abaixo para spine 201

Perfil de Interface Lógica em infra L3Out

Para cada Pod, deve haver um pool TEP definido como na figura abaixo. Observe que o pool TEP será usado do controlador APIC para provisionar os endereços IP dos nós para o VRF de sobreposição 1.

Política de configuração do Pod Fabric

Política de Conexão Externa de Malha padrão

Verifique se, no locatário inferior, o objeto 'padrão da política de extensão de malha' está definido e configurado adequadamente. Um exemplo dessa configuração é mostrado nas figuras abaixo.

Política de Conexão Externa de Malha padrão

TEP de Dataplane

Sub-redes do Perfil de Roteamento Externo de Malha

O Perfil de roteamento externo de estrutura permite que o usuário verifique se todas as sub-redes roteadas do IPN definido estão nele.

Validação de IPN

O multipods depende de uma Inter-Pod Network (IPN) que fornecerá conectividade de POD para POD. É crucial verificar se a configuração do IPN está corretamente estabelecida. A configuração frequentemente defeituosa ou ausente é a origem de um comportamento inesperado ou queda de tráfego no caso de cenários de falha. A configuração do IPN será descrita em detalhes nesta seção.

Para a próxima seção, consulte a seguinte topologia IPN:

topologia IPN

Conectividade de subinterfaces de VLAN-4 de Spine para IPN dot1q

A conectividade ponto a ponto de spine para IPN é obtida com subinterfaces em VLAN-4. A primeira validação para essa conectividade é testar a alcançabilidade de IP entre os spines e os dispositivos IPN.

Para fazer isso, determine a interface correta e verifique se ela está sendo exibida como up.

S1P1-Spine201# show ip int brief vrf overlay-1 | grep 172.16.101.2
eth1/29.29           172.16.101.2/30      protocol-up/link-up/admin-up 

S1P1-Spine201# show ip interface  eth1/29.29
IP Interface Status for VRF "overlay-1"
eth1/29.29, Interface status: protocol-up/link-up/admin-up, iod: 67, mode: external
  IP address: 172.16.101.2, IP subnet: 172.16.101.0/30
  IP broadcast address: 255.255.255.255
  IP primary address route-preference: 0, tag: 0

S1P1-Spine201# show system internal ethpm  info interface Eth1/29.29
Ethernet1/29.29 - if_index: 0x1A01C01D
Router MAC address: 00:22:bd:f8:19:ff
Admin Config Information:
  state(up), mtu(9150), delay(1), vlan(4), cfg-status(valid)
  medium(broadcast)
Operational (Runtime) Information:
  state(up), mtu(9150), Local IOD(0x43), Global IOD(0x43), vrf(enabled)
  reason(None)
  bd_id(29)
Information from SDB Query (IM call)
  admin state(up), runtime state(up), mtu(9150),
  delay(1), bandwidth(40000000), vlan(4), layer(L3),
  medium(broadcast)
  sub-interface(0x1a01c01d) from parent port(0x1a01c000)/Vlan(4)
  Operational Bits:

User config flags:  0x1
  admin_router_mac(1)

Sub-interface FSM state(3)
No errors on sub-interface
Information from GLDB Query:
Router MAC address: 00:22:bd:f8:19:ff

Depois de verificar se a interface está ativa, teste agora a conectividade IP ponto a ponto:

S1P1-Spine201# iping -V overlay-1 172.16.101.1 
PING 172.16.101.1 (172.16.101.1) from 172.16.101.2: 56 data bytes 
64 bytes from 172.16.101.1: icmp_seq=0 ttl=255 time=0.839 ms 
64 bytes from 172.16.101.1: icmp_seq=1 ttl=255 time=0.719 ms 
^C 
--- 172.16.101.1 ping statistics --- 
2 packets transmitted, 2 packets received, 0.00% packet loss 
round-trip min/avg/max = 0.719/0.779/0.839 ms 

Se houver algum problema de conectividade, verifique o cabeamento e a configuração no IPN remoto (IPN1).

IPN1# show ip interface brief | grep 172.16.101.1 
Eth1/33              172.16.101.101  protocol-up/link-up/admin-up 
Eth1/35              172.16.101.105  protocol-up/link-up/admin-up 
Eth1/53.4            172.16.101.1    protocol-up/link-up/admin-up 

IPN1# show run int Eth1/53.4 
interface Ethernet1/53.4 
description to spine 1pod1 
mtu 9150 
encapsulation dot1q 4 
ip address 172.16.101.1/30 
ip ospf cost 100 
ip ospf network point-to-point 
ip router ospf 1 area 0.0.0.0 
ip pim sparse-mode 
ip dhcp relay address 10.0.0.3 
no shutdown 

configuração de OSPF

O OSPF é usado como o protocolo de roteamento para conectar Pod1 e Pod2 dentro da 'sobreposição 1' do ACI VRF. O seguinte pode ser referenciado como um fluxo genérico para validar se o OSPF está surgindo entre o spine e o dispositivo IPN.

S1P1-Spine201# show ip ospf neighbors vrf overlay-1 
OSPF Process ID default VRF overlay-1 
Total number of neighbors: 2 
Neighbor ID     Pri State            Up Time  Address         Interface 
172.16.101.201    1 FULL/ -          08:39:35 172.16.101.1    Eth1/29.29 
172.16.101.202    1 FULL/ -          08:39:34 172.16.101.9    Eth1/30.30

S1P1-Spine201# show ip ospf  interface  vrf overlay-1 
Ethernet1/29.29 is up, line protocol is up 
   IP address 172.16.101.2/30, Process ID default VRF overlay-1, area backbone 
   Enabled by interface configuration 
   State P2P, Network type P2P, cost 1 
   Index 67, Transmit delay 1 sec 
   1 Neighbors, flooding to 1, adjacent with 1 
   Timer intervals: Hello 10, Dead 40, Wait 40, Retransmit 5 
     Hello timer due in 00:00:10 
   No authentication 
   Number of opaque link LSAs: 0, checksum sum 0 
loopback0 is up, line protocol is up 
   IP address 10.0.200.66/32, Process ID default VRF overlay-1, area backbone 
   Enabled by interface configuration 
   State LOOPBACK, Network type LOOPBACK, cost 1
 loopback14 is up, line protocol is up 
   IP address 172.16.1.4/32, Process ID default VRF overlay-1, area backbone 
   Enabled by interface configuration 
   State LOOPBACK, Network type LOOPBACK, cost 1
 Ethernet1/30.30 is up, line protocol is up 
   IP address 172.16.101.10/30, Process ID default VRF overlay-1, area backbone 
   Enabled by interface configuration 
   State P2P, Network type P2P, cost 1 
   Index 68, Transmit delay 1 sec 
   1 Neighbors, flooding to 1, adjacent with 1 
   Timer intervals: Hello 10, Dead 40, Wait 40, Retransmit 5 
     Hello timer due in 00:00:09 
   No authentication 
   Number of opaque link LSAs: 0, checksum sum 0

IPN1# show ip ospf  neighbors 
OSPF Process ID 1 VRF default 
Total number of neighbors: 5 
Neighbor ID     Pri State            Up Time  Address         Interface 
172.16.101.203    1 FULL/ -          4d12h    172.16.101.102  Eth1/33 
172.16.101.202    1 FULL/ -          4d12h    172.16.101.106  Eth1/35 
172.16.110.201    1 FULL/ -          4d12h    172.16.110.2    Eth1/48 
172.16.1.4        1 FULL/ -          08:43:39 172.16.101.2    Eth1/53.4 
172.16.1.6        1 FULL/ -          08:43:38 172.16.101.6    Eth1/54.4 

Quando o OSPF está ativo entre todos os spines e dispositivos IPN, todos os pools de TEP do Pod podem ser vistos nas tabelas de roteamento IPN.

IPN1# show ip ospf database 10.0.0.0 detail 
       OSPF Router with ID (172.16.101.201) (Process ID 1 VRF default)
                Type-5 AS External Link States
LS age: 183 
Options: 0x2 (No TOS-capability, No DC) 
LS Type: Type-5 AS-External 
Link State ID: 10.0.0.0 (Network address) 
Advertising Router: 172.16.1.4 
LS Seq Number: 0x80000026 
Checksum: 0x2da0 
Length: 36 
Network Mask: /16 
      Metric Type: 2 (Larger than any link state path) 
      TOS: 0 
      Metric: 20 
      Forward Address: 0.0.0.0 
      External Route Tag: 0
LS age: 183 
Options: 0x2 (No TOS-capability, No DC) 
LS Type: Type-5 AS-External 
Link State ID: 10.0.0.0 (Network address) 
Advertising Router: 172.16.1.6 
LS Seq Number: 0x80000026 
Checksum: 0x21aa 
Length: 36 
Network Mask: /16 
      Metric Type: 2 (Larger than any link state path) 
      TOS: 0 
      Metric: 20 
      Forward Address: 0.0.0.0 
      External Route Tag: 0

IPN1# show ip ospf database 10.1.0.0 detail 
     OSPF Router with ID (172.16.101.201) (Process ID 1 VRF default)
                Type-5 AS External Link States
LS age: 1779 
Options: 0x2 (No TOS-capability, No DC) 
LS Type: Type-5 AS-External 
Link State ID: 10.1.0.0 (Network address) 
Advertising Router: 172.16.2.4 
LS Seq Number: 0x80000022 
Checksum: 0x22ad 
Length: 36 
Network Mask: /16 
      Metric Type: 2 (Larger than any link state path) 
      TOS: 0 
      Metric: 20 
      Forward Address: 0.0.0.0 
      External Route Tag: 0
LS age: 1780 
Options: 0x2 (No TOS-capability, No DC) 
LS Type: Type-5 AS-External 
Link State ID: 10.1.0.0 (Network address) 
Advertising Router: 172.16.2.6 
LS Seq Number: 0x80000022 
Checksum: 0x16b7 
Length: 36 
Network Mask: /16 
      Metric Type: 2 (Larger than any link state path) 
      TOS: 0 
      Metric: 20 
      Forward Address: 0.0.0.0 
      External Route Tag: 0

IPN1# show ip route 10.0.0.0 
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.0.0.0/16, ubest/mbest: 2/0 
*via 172.16.101.2, Eth1/53.4, [110/20], 08:39:17, ospf-1, type-2 
*via 172.16.101.6, Eth1/54.4, [110/20], 08:39:17, ospf-1, type-2

IPN1# show ip route 10.1.0.0 
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.1.0.0/16, ubest/mbest: 1/0 
*via 172.16.101.102, Eth1/33, [110/20], 08:35:25, ospf-1, type-2

Observe que em IPN1 para o Pod (Pod2) remoto, somente a rota mais ótima é mostrada no comando 'show ip route'.

configuração de relé DHCP

Os nós do switch recebem seu endereço de TEP infravermelho utilizando DHCP para os APICs. Todos os APICs normalmente receberão a descoberta, mas é o primeiro APIC a receber a descoberta e apresentar uma oferta que alocará o endereço TEP. Para explicar isso em um cenário de Multi-Pod, configure a retransmissão de DHCP no IPN para receber essas descobertas e transmiti-las em unicast para os APICs. Em geral, configure todas as interfaces de spine com IP helpers apontando para todos os APICs. Isso testará a configuração do IPN no futuro se o APIC for movido devido à recabeamento, a um failover do APIC em espera ou a qualquer outro cenário que envolva a mudança de um APIC para um novo Pod.

Neste cenário, isso significa configurar IPN1 Eth1/53.4 e Eth1/54.4 com auxiliares de IP apontando para todos os APICs:

interface Ethernet1/53.4 
 description to  spine 1pod1 
 mtu 9150 
 encapsulation dot1q 4 
 ip address 172.16.101.1/30 
 ip ospf cost 100 
 ip ospf network point-to-point 
 ip router ospf 1 area 0.0.0.0 
 ip pim sparse-mode 
 ip dhcp relay address 10.0.0.1 
 ip dhcp relay address 10.0.0.2 
 ip dhcp relay address 10.0.0.3 
 no shutdown

interface Ethernet1/54.4 
 description to  spine 2pod1 
 mtu 9150 
 encapsulation dot1q 4 
 ip address 172.16.101.5/30 
 ip ospf cost 100 
 ip ospf network point-to-point 
 ip router ospf 1 area 0.0.0.0 
 ip pim sparse-mode 
 ip dhcp relay address 10.0.0.1 
 ip dhcp relay address 10.0.0.2 
 ip dhcp relay address 10.0.0.3 
 no shutdown

Do IPN3:

interface Ethernet1/53.4 
 description to  spine 1pod2 
 mtu 9150 
 encapsulation dot1q 4 
 ip address 172.16.101.17/30 
 ip ospf cost 100 
 ip ospf network point-to-point 
 ip router ospf 1 area 0.0.0.0 
 ip pim sparse-mode 
 ip dhcp relay address 10.0.0.1 
 ip dhcp relay address 10.0.0.2 
 ip dhcp relay address 10.0.0.3 
 no shutdown

interface Ethernet1/54.4 
 description to  spine 2pod2 
 mtu 9150 
 encapsulation dot1q 4 
 ip address 172.16.101.21/30 
 ip ospf cost 100 
 ip ospf network point-to-point 
 ip router ospf 1 area 0.0.0.0 
 ip pim sparse-mode 
 ip dhcp relay address 10.0.0.1 
 ip dhcp relay address 10.0.0.2 
 ip dhcp relay address 10.0.0.3 
 no shutdown

MTU

Se o OSPF não estiver sendo ativado (EXCHANGE ou EXSTART) entre o dispositivo spine e IPN, certifique-se de validar se a MTU corresponde aos dispositivos.

configuração RP

Com o PIM BiDir, o ponto de encontro (RP) não faz parte do caminho de dados. Para multicast funcional, cada dispositivo IPN precisa ter apenas uma rota para o endereço RP. A redundância pode ser obtida usando-se uma configuração Phantom RP. Nesse caso, o RP Anycast não é um método de redundância válido porque não há uma origem para troca via MSDP (Multicast Source Discovery Protocol).

Em um projeto de RP Fantasma, o RP é um endereço não existente em uma sub-rede alcançável. Na configuração abaixo, suponha que o intervalo de multicast configurado na configuração inicial do APIC seja o padrão 225.0.0.0/15. Se ele foi alterado na configuração inicial do APIC, as configurações do IPN devem ser alinhadas.

O loopback1 abaixo é o loopback fantasma-rp. Deve ser injetado no OSPF; no entanto, ele não pode ser usado como router-id do OSPF. Um loopback separado (loopback0) deve ser usado para isso.

Configuração do IPN1:

interface loopback1 
 description IPN1-RP-Loopback 
 ip address 172.16.101.221/30 
 ip ospf network point-to-point 
 ip router ospf 1 area 0.0.0.0 
 ip pim sparse-mode 
ip pim rp-address 172.16.101.222 group-list 225.0.0.0/15 bidir 
ip pim rp-address 172.16.101.222 group-list 239.255.255.240/32 bidir

Configuração IPN2:

ip pim rp-address 172.16.101.222 group-list 225.0.0.0/15 bidir 
ip pim rp-address 172.16.101.222 group-list 239.255.255.240/32 bidir

Configuração do IPN3:

interface loopback1 
 description IPN3-RP-Loopback 
 ip address 172.16.101.221/29 
 ip ospf network point-to-point 
 ip router ospf 1 area 0.0.0.0 
 ip pim sparse-mode 
ip pim rp-address 172.16.101.222 group-list 225.0.0.0/15 bidir 
ip pim rp-address 172.16.101.222 group-list 239.255.255.240/32 bidir

Configuração IPN4:

ip pim rp-address 172.16.101.222 group-list 225.0.0.0/15 bidir 
ip pim rp-address 172.16.101.222 group-list 239.255.255.240/32 bidir

A máscara de sub-rede no loopback não pode ser /32. Para usar IPN1 como o dispositivo primário no design do RP Fantasma, use uma máscara de sub-rede /30 para aproveitar a rota mais específica que é preferida na topologia do OSPF. IPN3 será o dispositivo secundário no design do RP Fantasma; portanto, use uma máscara de sub-rede /29 para torná-lo uma rota menos específica. O /29 somente será usado se algo acontecer para interromper o /30 de existente e subsequentemente existente na topologia OSPF.

Solucionando problemas da 1ª coluna vertebral do Pod remoto conectada à malha

As etapas a seguir descrevem o processo que o 1º Pod Spine remoto executa para unir a estrutura:

1. O spine executará o DHCP em sua subinterface voltada para o IPN. A configuração de Retransmissão DHCP levará essa descoberta para os APICs. Os APICs responderão se o spine tiver sido adicionado à associação de estrutura. O endereço IP que é oferecido é o endereço IP configurado no Multi-Pod L3Out.
2. O spine instalará uma rota em direção ao servidor DHCP que ofereceu o endereço IP como uma rota estática em direção à outra extremidade da interface ponto a ponto.
3. O spine fará o download de um arquivo de bootstrap do APIC por meio da rota estática.
4. O spine será configurado com base no arquivo de bootstrap para ativar o VTEP, o OSPF e o BGP para ingressar na estrutura.

No APIC, valide se o IP L3Out está configurado corretamente para ser oferecido: (nosso Spine 401 tem FDO22472FCV serial)

bdsol-aci37-apic1# moquery -c dhcpExtIf

# dhcp.ExtIf 
ifId         : eth1/30 
childAction  : 
dn           : client-[FDO22472FCV]/if-[eth1/30] 
ip           : 172.16.101.26/30 
lcOwn        : local 
modTs        : 2019-10-01T09:51:29.966+00:00 
name         : 
nameAlias    : 
relayIp      : 0.0.0.0 
rn           : if-[eth1/30] 
status       : 
subIfId      : unspecified

# dhcp.ExtIf
ifId         : eth1/29 
childAction  : 
dn           : client-[FDO22472FCV]/if-[eth1/29] 
ip           : 172.16.101.18/30 
lcOwn        : local 
modTs        : 2019-10-01T09:51:29.966+00:00 
name         : 
nameAlias    : 
relayIp      : 0.0.0.0 
rn           : if-[eth1/29] 
status       : 
subIfId      : unspecified

Valide se a interface para IPN recebeu o endereço IP esperado correspondente à configuração L3Out feita em locatário inferior.

S1P2-Spine401# show ip interface brief | grep eth1/29 
eth1/29              unassigned           protocol-up/link-up/admin-up 
eth1/29.29           172.16.101.18/30     protocol-up/link-up/admin-up 

Agora a conectividade IP foi estabelecida do spine para o APIC e a conectividade através do ping pode ser verificada:

S1P2-Spine401# iping -V overlay-1 10.0.0.1 
PING 10.0.0.1 (10.0.0.1) from 172.16.101.18: 56 data bytes 
64 bytes from 10.0.0.1: icmp_seq=0 ttl=60 time=0.345 ms 
64 bytes from 10.0.0.1: icmp_seq=1 ttl=60 time=0.294 ms 
^C 
--- 10.0.0.1 ping statistics --- 
2 packets transmitted, 2 packets received, 0.00% packet loss 
round-trip min/avg/max = 0.294/0.319/0.345 ms 

O spine agora ativará o OSPF para o IPN e configurará um loopback para o ID do roteador:

S1P2-Spine401# show ip ospf neighbors vrf overlay-1
OSPF Process ID default VRF overlay-1 
Total number of neighbors: 2 
Neighbor ID     Pri State            Up Time  Address         Interface 
172.16.101.204    1 FULL/ -          00:04:16 172.16.101.25   Eth1/30.30 
172.16.101.203    1 FULL/ -          00:04:16 172.16.101.17   Eth1/29.29

S1P2-Spine401# show ip ospf  interface  vrf overlay-1 
loopback8 is up, line protocol is up 
   IP address 172.16.2.4/32, Process ID default VRF overlay-1, area backbone 
   Enabled by interface configuration 
   State LOOPBACK, Network type LOOPBACK, cost 1
 Ethernet1/30.30 is up, line protocol is up 
   IP address 172.16.101.26/30, Process ID default VRF overlay-1, area backbone 
   Enabled by interface configuration 
   State P2P, Network type P2P, cost 1 
   Index 68, Transmit delay 1 sec 
   1 Neighbors, flooding to 1, adjacent with 1 
   Timer intervals: Hello 10, Dead 40, Wait 40, Retransmit 5 
     Hello timer due in 00:00:07 
   No authentication 
   Number of opaque link LSAs: 0, checksum sum 0 
Ethernet1/29.29 is up, line protocol is up 
   IP address 172.16.101.18/30, Process ID default VRF overlay-1, area backbone 
   Enabled by interface configuration 
   State P2P, Network type P2P, cost 1 
   Index 67, Transmit delay 1 sec 
   1 Neighbors, flooding to 1, adjacent with 1 
   Timer intervals: Hello 10, Dead 40, Wait 40, Retransmit 5 
     Hello timer due in 00:00:04 
   No authentication 
   Number of opaque link LSAs: 0, checksum sum 0

O spine agora receberá seu PTEP através do DHCP:

S1P2-Spine401# show ip interface vrf overlay-1 | egrep -A 1 status 
lo0, Interface status: protocol-up/link-up/admin-up, iod: 4, mode: ptep 
IP address: 10.1.88.67, IP subnet: 10.1.88.67/32

A coluna será movida de Detecção para Ativa e será totalmente descoberta:

bdsol-aci37-apic1# acidiag fnvread 
     ID   Pod ID                 Name    Serial Number         IP Address    Role        State   LastUpdMsgId 
-------------------------------------------------------------------------------------------------------------- 
    101        1         S1P1-Leaf101      FDO224702JA     10.0.160.64/32    leaf         active   0 
    102        1         S1P1-Leaf102      FDO223007G7     10.0.160.67/32    leaf         active   0 
    201        1        S1P1-Spine201      FDO22491705     10.0.160.65/32   spine         active   0 
    202        1        S1P1-Spine202      FDO224926Q9     10.0.160.66/32   spine         active   0 
    401        2        S1P2-Spine401      FDO22472FCV      10.1.88.67/32   spine         active   0

Saiba que só é possível descobrir uma coluna remota quando há pelo menos um switch folha conectado a ela.

Verificar os switches leaf e spine restantes

O restante do Pod é agora descoberto de acordo com o procedimento normal de ativação do Pod, conforme discutido na seção "Configuração inicial da estrutura".

Verificar APIC de Pod remoto

Para descobrir o 3º APIC, siga o seguinte processo:

• O leaf301 cria uma rota estática para o APIC (APIC3) diretamente conectado com base no LLDP (o mesmo que um único caso de Pod)O APIC remoto receberá um endereço IP do pool de IP do POD1. Criaremos essa rota como um /32.
• O Leaf301 anuncia essa rota usando IS-IS para Spine401 e Spine402 (o mesmo que um único pod case)
• Spine401 e Spine402 redistribuem essa rota no OSPF em direção ao IPN
• Spine201 e Spine202 redistribuem essa rota do OSPF para IS-IS no Pod1
• Agora a conectividade é estabelecida entre APIC3 e APIC1 e APIC2
• O APIC3 agora pode ingressar no cluster

Para confirmar, use as seguintes verificações:

O Leaf301 cria uma rota estática para o APIC (APIC3) diretamente conectado com base no LLDP (o mesmo que o caso de um único pod)

S1P2-Leaf301# show ip route 10.0.0.3 vrf overlay-1 
IP Route Table for VRF "overlay-1" 
'*' denotes best ucast next-hop 
'**' denotes best mcast next-hop 
'[x/y]' denotes [preference/metric] 
'%<string>' in via output denotes VRF <string>

10.0.0.3/32, ubest/mbest: 2/0 
   *via 10.1.88.64, eth1/50.14, [115/12], 00:07:21, isis-isis_infra, isis-l1-ext 
   *via 10.1.88.67, eth1/49.13, [115/12], 00:07:15, isis-isis_infra, isis-l1-ext 
    via 10.0.0.3, vlan9, [225/0], 07:31:04, static

O Leaf301 anuncia essa rota usando IS-IS para Spine401 e Spine402 (o mesmo que um único pod case)

Spine401 e Spine402 vazam essa rota no OSPF em direção ao IPN

S1P2-Spine401# show ip route 10.0.0.3 vrf overlay-1 
IP Route Table for VRF "overlay-1" 
'*' denotes best ucast next-hop 
'**' denotes best mcast next-hop 
'[x/y]' denotes [preference/metric] 
'%<string>' in via output denotes VRF <string>

10.0.0.3/32, ubest/mbest: 1/0 
    *via 10.1.88.65, eth1/2.35, [115/11], 00:17:38, isis-isis_infra, isis-l1-ext  S1P2-Spine401#

IPN3# show ip route 10.0.0.3 
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.0.0.3/32, ubest/mbest: 2/0 
    *via 172.16.101.18, Eth1/53.4, [110/20], 00:08:05, ospf-1, type-2 
    *via 172.16.101.22, Eth1/54.4, [110/20], 00:08:05, ospf-1, type-2

S1P1-Spine201# show ip route vrf overlay-1 10.0.0.3 
IP Route Table for VRF "overlay-1" 
'*' denotes best ucast next-hop 
'**' denotes best mcast next-hop 
'[x/y]' denotes [preference/metric] 
'%<string>' in via output denotes VRF <string>

10.0.0.3/32, ubest/mbest: 2/0 
    *via 172.16.101.1, eth1/29.29, [110/20], 00:08:59, ospf-default, type-2 
    *via 172.16.101.9, eth1/30.30, [110/20], 00:08:59, ospf-default, type-2 
    via 10.0.160.64, eth1/1.36, [115/12], 00:18:19, isis-isis_infra, isis-l1-ext 
    via 10.0.160.67, eth1/2.35, [115/12], 00:18:19, isis-isis_infra, isis-l1-ext 

Agora a conectividade é estabelecida entre APIC3 e APIC1 e APIC2

O APIC3 agora pode ingressar no cluster

apic1# show controller 
Fabric Name          : POD37 
Operational Size     : 3 
Cluster Size         : 3 
Time Difference      : 133 
Fabric Security Mode : PERMISSIVE
 ID    Pod   Address          In-Band IPv4     In-Band IPv6               OOB IPv4         OOB IPv6                        Version             Flags  Serial Number     Health 
----  ----  ---------------  ---------------  -------------------------  ---------------  ------------------------------  ------------------  -----  ----------------  ------------------ 
1*    1     10.0.0.1         0.0.0.0          fc00::1                    10.48.176.57     fe80::d6c9:3cff:fe51:cb82       4.2(1i)             crva-  WZP22450H82       fully-fit 
2     1     10.0.0.2         0.0.0.0          fc00::1                    10.48.176.58     fe80::d6c9:3cff:fe51:ae22       4.2(1i)             crva-  WZP22441AZ2       fully-fit 
3     2     10.0.0.3         0.0.0.0          fc00::1                    10.48.176.59     fe80::d6c9:3cff:fe51:a30a       4.2(1i)             crva-  WZP22441B0T       fully-fit
Flags - c:Commissioned | r:Registered | v:Valid Certificate | a:Approved | f/s:Failover fail/success 
(*)Current (~)Standby (+)AS 

Faça ping do APIC1 para um dispositivo remoto no Pod2 para validar a conectividade através do seguinte ping: (certifique-se de obter a origem da interface local, no caso 10.0.0.1 do APIC1)

apic1# ping 10.0.0.3 -I 10.0.0.1 
PING 10.0.0.3 (10.0.0.3) from 10.0.0.1 : 56(84) bytes of data. 
64 bytes from 10.0.0.3: icmp_seq=1 ttl=58 time=0.132 ms 
64 bytes from 10.0.0.3: icmp_seq=2 ttl=58 time=0.236 ms 
64 bytes from 10.0.0.3: icmp_seq=3 ttl=58 time=0.183 ms 
^C 
--- 10.0.0.3 ping statistics --- 
3 packets transmitted, 3 received, 0% packet loss, time 2048ms 
rtt min/avg/max/mdev = 0.132/0.183/0.236/0.045 ms 

Cenários de Troubleshooting

Spine não pode fazer ping no IPN

Isso é provavelmente causado por:

• Um erro de configuração nas políticas de acesso da ACI.
• Um erro de configuração na configuração do IPN.

Consulte o "Fluxo de trabalho de solução de problemas" neste capítulo e revise:

• Verifique as políticas da ACI.
• Validação de IPN.

A coluna remota não está ingressando na malha

Isso é provavelmente causado por:

• Problema de retransmissão de DHCP na rede IPN.
• Alcance IP de spine para APIC na rede IP.

Consulte o "Fluxo de trabalho de solução de problemas" neste capítulo e revise:

• Verifique as políticas da ACI.
• Validação de IPN.
• Solucionar problemas da 1ª junção de estrutura.

Certifique-se de validar que há pelo menos uma folha conectada à coluna remota e que a coluna tem uma adjacência LLDP com essa folha.

O APIC no Pod2 não está ingressando na malha

Isso é normalmente causado por um erro no diálogo de configuração inicial do APIC, supondo que os switches remotos de folha e coluna pod pudessem se unir corretamente à estrutura. Em uma configuração correta, espere a seguinte saída 'avread' (cenário de junção APIC3 em funcionamento):

apic1# avread 
Cluster: 
------------------------------------------------------------------------- 
fabricDomainName        POD37 
discoveryMode           PERMISSIVE 
clusterSize             3 
version                 4.2(1i) 
drrMode                 OFF 
operSize                3
APICs: 
------------------------------------------------------------------------- 
                   APIC 1                  APIC 2                  APIC 3 
version           4.2(1i)                 4.2(1i)                 4.2(1i) 
address           10.0.0.1                10.0.0.2                10.0.0.3 
oobAddress        10.48.176.57/24         10.48.176.58/24         10.48.176.59/24 
routableAddress   0.0.0.0                 0.0.0.0                 0.0.0.0 
tepAddress        10.0.0.0/16             10.0.0.0/16             10.0.0.0/16 
podId             1                       1                       2 
chassisId         7e34872e-.-d3052cda     84debc98-.-e207df70     89b73e48-.-f6948b98 
cntrlSbst_serial  (APPROVED,WZP22450H82)  (APPROVED,WZP22441AZ2)  (APPROVED,WZP22441B0T) 
active            YES                     YES                     YES 
flags             cra-                    cra-                    cra- 
health            255                     255                     255 

Observe que APIC3 (no Pod remoto) está configurado com podId 2 e o tepAddress de Pod1.

Verifique as configurações originais do APIC3 usando o seguinte comando:

apic3# cat /data/data_admin/sam_exported.config 
Setup for Active and Standby APIC
fabricDomain = POD37 
fabricID = 1 
systemName =bdsol-aci37-apic3 
controllerID = 3 
tepPool = 10.0.0.0/16 
infraVlan = 3937 
clusterSize = 3 
standbyApic = NO 
enableIPv4 = Y 
enableIPv6 = N 
firmwareVersion = 4.2(1i) 
ifcIpAddr = 10.0.0.3 
apicX = NO 
podId = 2 
oobIpAddr = 10.48.176.59/24

Se ocorrer um erro, faça login no APIC3 e execute 'acidiag touch setup' e 'acidiag reboot'.

O tráfego BUM de POD para POD não está funcionando

Isso é provavelmente causado por:

• A falta de um RP na rede IP
• O RP não alcançável pela estrutura da ACIerro de configuração de multicast geral nos dispositivos IPN

Consulte o "Fluxo de trabalho de solução de problemas" neste capítulo e revise:

• Validação de IPN

Verifique também se um dos dispositivos IPN RP está on-line.

Após a falha de 1 dispositivo IPN, o tráfego BUM será descartado

Conforme descrito na Validação de IPN no fluxo de trabalho de solução de problemas, use um RP Fantasma para garantir que um RP secundário esteja disponível quando o RP principal for desativado. Certifique-se de revisar a seção "Validação do IPN" e verificar a validação correta.

A conectividade de endpoint entre pods é interrompida no mesmo EPG

Isso é provavelmente causado por um erro de configuração na configuração do Multi-Pod, certifique-se de validar o fluxo de trabalho de solução de problemas e verificar todo o fluxo. Se isso parecer correto, consulte a seção "Encaminhamento de vários pods" no capítulo "Encaminhamento de malha interna" para solucionar esse problema.