Risoluzione dei problemi di ACI Fabric Discovery - Multi-Pod Discovery

Introduzione

In questo documento viene descritto come comprendere e risolvere i problemi relativi a ACI Multi-pod Discovery.

Premesse

Il materiale tratto da questo documento è stato Risoluzione dei problemi di Cisco Application Centric Infrastructure, Second Edition , in particolare il Fabric Discovery - Rilevamento di più pod capitolo.

Panoramica dei multipod

ACI Multi-Pod consente l'implementazione di un singolo cluster APIC per gestire più reti ACI interconnesse. Queste reti ACI separate sono chiamate 'Pod' e ogni Pod è una topologia regolare a due o tre livelli di spine-leaf. Un singolo cluster APIC può gestire diversi pod.

Un design multi-Pod consente inoltre di estendere le policy ACI per la struttura su più pod che possono essere fisicamente presenti in più stanze o anche in postazioni remote del centro dati. In una progettazione multi-pod, qualsiasi criterio definito nel cluster di controller APIC viene automaticamente reso disponibile a tutti i pod.

Infine, un design Multi-Pod aumenta l'isolamento del dominio di errore. Infatti, ogni Pod esegue la propria istanza di COOP, MP-BGP e IS-IS protocollo in modo che i guasti e i problemi con uno qualsiasi di questi protocolli sono contenuti all'interno di quel Pod e non possono diffondersi ad altri Pod.

Fare riferimento al documento "ACI Multi-Pod White Paper" su cisco.com per ulteriori informazioni sulla progettazione di multipod e le best practice.

Gli elementi principali di un fabric ACI Multi-Pod sono gli interruttori a foglia e a spina, i controller APIC e i dispositivi IPN.

In questo esempio vengono esaminati nel flusso di lavoro di risoluzione dei problemi i problemi relativi alla configurazione di un fabric ACI Multi-Pod. La topologia di riferimento utilizzata per questa sezione è illustrata nella figura seguente:

Topologia di riferimento ACI Multi-Pod

Flusso di lavoro di risoluzione dei problemi

Verifica criteri ACI

Criteri di accesso

Multi-Pod utilizza un L3Out per collegare i Pod tramite il tenant 'infra'. Ciò significa che è necessario disporre del set standard di policy di accesso per attivare l'incapsulamento Multi-Pod L3Out (VLAN-4) richiesto sulle porte della spine rivolte verso l'IPN.

È possibile configurare i criteri di accesso tramite la procedura guidata 'Aggiungi pod', che deve essere utilizzata per distribuire Multi-pod. Dopo aver utilizzato la procedura guidata, è possibile verificare i criteri distribuiti dalla GUI APIC. Se i criteri non sono configurati correttamente, verrà visualizzato un errore nell'infra tenant e la connettività dagli spine all'IPN potrebbe non funzionare come previsto.

Durante la verifica della definizione dei criteri di accesso per le interfacce con interfaccia IPN sui nodi della spine è possibile fare riferimento agli schemi seguenti:

Dorso201

Dorso202

Dorso 401

Dorso 402

Nell'infra tenant, il Multi-Pod L3Out deve essere configurato secondo lo schema seguente:

Multi-Pod L3Out nell'infra tenant

Di seguito è riportata una schermata di riferimento della configurazione del profilo di interfaccia logica Multi-Pod L3Out. Le definizioni della sottointerfaccia del router dovrebbero essere simili a quelle illustrate di seguito per Spine 201

Profilo interfaccia logica nell'infra L3Out

Per ciascun POD, dovrebbe essere presente un pool TEP definito come illustrato nella figura seguente. Notare che il pool TEP verrà utilizzato dal controller APIC per effettuare il provisioning degli indirizzi IP dei nodi per il VRF overlay-1.

Criteri di configurazione di Pod Fabric

Impostazione predefinita criterio di connessione esterna infrastruttura

Verificare che nell'infra tenant l'oggetto 'Predefinito criteri esterni infrastruttura' sia definito e configurato correttamente. Un esempio di questa configurazione è mostrato nelle figure seguenti.

Impostazione predefinita criterio di connessione esterna infrastruttura

Piano dati

Subnet del profilo di routing esterno dell'infrastruttura

Il profilo di routing esterno dell'infrastruttura consente all'utente di verificare se tutte le subnet di routing dell'IPN definito si trovano su tale rete.

Convalida IPN

Multi-Pod si basa su una rete Inter-Pod Network (IPN) che fornisce connettività POD-to-POD. È fondamentale verificare che la configurazione dell'IPN sia installata correttamente. Spesso una configurazione errata o mancante è la causa di un comportamento imprevisto o di una perdita di traffico in caso di scenari di errore. La configurazione dell'IPN è descritta in dettaglio in questa sezione.

Per la sezione successiva, fare riferimento alla topologia IPN seguente:

Topologia IPN

Connettività da dorso a IPN dot1q sottointerfacce VLAN-4

La connettività point-to-point da dorso a IPN viene ottenuta con sottointerfacce sulla VLAN-4. La prima convalida di questa connettività è la verifica della raggiungibilità IP tra gli spine e i dispositivi IPN.

A tale scopo, determinare l'interfaccia corretta e verificare che venga visualizzata come visualizzata.

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

Dopo aver verificato che l'interfaccia sia attiva, verificare la connettività IP point-to-point:

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 

In caso di problemi di connettività, verificare il cablaggio e la configurazione sull'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 

Configurazione OSPF

OSPF è utilizzato come protocollo di routing per collegare i Pod1 e Pod2 all'interno di ACI VRF "overlay-1". Di seguito è possibile fare riferimento a un flusso generico per verificare se OSPF è in arrivo tra spine e 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 OSPF è attivo tra tutti gli spine e i dispositivi IPN, tutti i pool POD TEP possono essere visualizzati nelle tabelle di routing 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

Nota su IPN1 per il pod remoto (Pod2), nel comando "show ip route" viene visualizzata solo la route ottimale.

Configurazione inoltro DHCP

I nodi dello switch ricevono l'indirizzo TEP a infrarossi utilizzando DHCP per gli APIC. Tutti gli APIC riceveranno generalmente il discover, ma è il primo APIC a ricevere il discover e a presentare un'offerta che assegnerà l'indirizzo TEP. Per risolvere questo problema in uno scenario con più dispositivi, configurare l'inoltro DHCP sull'IPN in modo che riceva tali rilevamenti e li esegua in unicast verso gli APIC. In genere, configurare tutte le interfacce IPN con riquadri laterali con helper IP che puntano a tutti gli APIC. In questo modo, la configurazione IPN sarà a prova di futuro se l'APIC viene spostato a causa della riattivazione, di un failover dell'APIC in standby o di altri scenari che implicano lo spostamento dell'APIC su un nuovo Pod.

In questo scenario, ciò significa configurare IPN1 Eth1/53.4 e Eth1/54.4 con helper IP che puntano a tutti gli APIC:

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

Da 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 il protocollo OSPF (EXCHANGE o EXSTART) tra il dorso e il dispositivo IPN non è attivo, verificare che l'MTU corrisponda tra i dispositivi.

Configurazione RP

Con PIM BiDir, il punto di rendering (RP) non fa parte del percorso dati. Per il multicast funzionale, ogni dispositivo IPN deve disporre solo di una route all'indirizzo RP. La ridondanza può essere ottenuta utilizzando una configurazione Phantom RP. In questo caso, l'RP Anycast non è un metodo di ridondanza valido perché non dispone di un'origine da scambiare tramite il protocollo MSDP (Multicast Source Discovery Protocol).

In una progettazione RP fantasma, l'RP è un indirizzo inesistente in una subnet raggiungibile. Nella configurazione seguente, si supponga che l'intervallo multicast configurato nella configurazione iniziale di APIC sia il valore predefinito 225.0.0.0/15. Se è stato modificato nella configurazione iniziale di APIC, le configurazioni IPN devono essere allineate.

Il loopback1 riportato di seguito è il loopback phantom-rp. deve essere iniettato in OSPF; non può tuttavia essere utilizzato come ID router OPSF. A tale scopo, è necessario utilizzare un loopback separato (loopback0).

Configurazione 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

Configurazione 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

Configurazione 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

Configurazione 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

La subnet mask sul loopback non può essere /32. Per utilizzare IPN1 come dispositivo primario nella progettazione dell'RP fantasma, utilizzare una subnet mask /30 per sfruttare la route più specifica preferita nella topologia OSPF. Poiché IPN3 sarà il dispositivo secondario nella progettazione di Phantom RP, utilizzare una subnet mask /29 per renderlo meno specifico. L'opzione /29 verrà utilizzata solo se si verifica un problema che blocca l'opzione /30 da esistente e successivamente esistente nella topologia OSPF.

Risoluzione dei problemi relativi alla prima spina dorsale del POD remoto che si unisce al fabric

La procedura seguente descrive il processo di collegamento del primo Remote Pod Spine al fabric:

1. Il dorso eseguirà il comando DHCP sulla sua sottointerfaccia rivolta verso l'IPN. La configurazione dell'inoltro DHCP includerà il rilevamento agli APIC. Gli APIC risponderanno se il dorso è stato aggiunto nell'appartenenza del fabric. L'indirizzo IP offerto è quello configurato sul Multi-Pod L3Out.
2. Il dorso installa un percorso verso il server DHCP che ha offerto l'indirizzo IP come percorso statico verso l'altra estremità dell'interfaccia point-to-point.
3. Il dorso scaricherà un file bootstrap dall'APIC attraverso la route statica.
4. La spine verrà configurata in base al file di bootstrap per connettere VTEP, OSPF e BGP al fabric.

Dall'APIC, verificare se l'IP L3Out è configurato correttamente per essere offerto: (la nostra Spine 401 ha la porta seriale FDO22472FCV)

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

Convalida se l'interfaccia con interfaccia IPN ha ricevuto la configurazione L3Out prevista dell'indirizzo IP corrispondente eseguita nel tenant infra.

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 

Ora la connettività IP è stata stabilita dal dorso all'APIC ed è possibile verificare la connettività tramite ping:

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 

La spine ora porterà l'OSPF sull'IPN e configurerà un loopback per l'ID router:

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

Il dorso riceverà ora il PTEP tramite 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

La colonna vertebrale passerà da Individuazione ad Attiva e viene completamente individuata:

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

Si tenga presente che è possibile individuare un dorso remoto solo quando è collegato ad almeno uno switch foglia.

Verificare gli interruttori foglia e dorso rimanenti

Il resto del Pod viene ora individuato secondo la normale procedura di sollevamento del Pod, come descritto nella sezione "Configurazione iniziale del tessuto".

Controllare il POD APIC remoto

Per individuare il terzo APIC, procedere come segue:

• Leaf301 crea un percorso statico verso l'APIC (APIC3) collegato direttamente basato su LLDP (come una singola custodia per il POD)L'APIC remoto riceverà un indirizzo IP dal POD1 IP Pool. La route verrà creata come /32.
• Leaf301 pubblicizza questo percorso utilizzando IS-IS per Spine401 e Spine402 (come una singola custodia per POD)
• Spine401 e Spine402 ridistribuiscono questa route in OSPF verso IPN
• Spine201 e Spine202 ridistribuiscono questa route da OSPF a IS-IS in Pod1
• Ora la connettività è stabilita tra APIC3 e APIC1 e APIC2
• È ora possibile aggiungere APIC3 al cluster

Per confermare, utilizzare i seguenti controlli:

Leaf301 crea un percorso statico verso l'APIC (APIC3) direttamente collegato basato su LLDP (come la custodia per un unico 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

Leaf301 pubblicizza questo percorso utilizzando IS-IS per Spine401 e Spine402 (come una singola custodia per POD)

Spine401 e Spine402 perdono questa route in OSPF verso 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 

Ora la connettività è stabilita tra APIC3 e APIC1 e APIC2

È ora possibile aggiungere APIC3 al 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 

Eseguire il ping da APIC1 a un dispositivo remoto nel Pod2 per convalidare la connettività tramite il ping seguente: (accertarsi di eseguire l'origine dall'interfaccia locale, nel caso APIC1 versione 10.0.0.1)

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 

Risoluzione dei problemi

Il dorso non può eseguire il ping dell'IPN

Ciò è dovuto molto probabilmente a:

• Configurazione errata nei criteri di accesso ACI.
• Configurazione errata nella configurazione IPN.

Consultare il "Flusso di lavoro per la risoluzione dei problemi" in questo capitolo ed esaminare:

• Verificare i criteri ACI.
• Convalida IPN.

Il dorso remoto non unisce il fabric

Ciò è dovuto molto probabilmente a:

• Problema di inoltro DHCP sulla rete IPN.
• Raggiungibilità IP da spine ad APIC sulla rete IPN.

Consultare il "Flusso di lavoro per la risoluzione dei problemi" in questo capitolo ed esaminare:

• Verificare i criteri ACI.
• Convalida IPN.
• Risoluzione dei problemi relativi al primo join di infrastruttura.

Accertarsi che vi sia almeno una foglia collegata al dorso remoto e che il dorso abbia un'adiacenza LLDP con questa foglia.

APIC nel Pod2 non unisce il fabric

Ciò è in genere causato da un errore nella finestra di dialogo di configurazione iniziale dell'APIC presupponendo che gli interruttori a forma di pod remoto e di dorso siano stati in grado di collegarsi correttamente al fabric. In una configurazione corretta, attendersi il seguente output 'avread' (scenario di join APIC3 funzionante):

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 

Si noti che APIC3 (nel POD remoto) è configurato con podId 2 e l'indirizzo del passaggio di Pod1.

Verificate le impostazioni di configurazione originali di APIC3 utilizzando il seguente 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

In caso di errore, accedere ad APIC3 ed eseguire i comandi 'acidiag touch setup' e 'acidiag reboot'.

Traffico BUM POD-to-POD non funzionante

Ciò è dovuto molto probabilmente a:

• Mancanza di RP nella rete IP
• RP non raggiungibile dalla configurazione errata di ACI fabricGeneral Multicast sui dispositivi IPN

Consultare il "Flusso di lavoro per la risoluzione dei problemi" in questo capitolo ed esaminare:

• Convalida IPN

Verificare inoltre che uno dei dispositivi IPN RP sia online.

Dopo un errore in un dispositivo IPN, il traffico BUM verrà interrotto

Come descritto in Convalida IPN (IPN Validation) nel flusso di lavoro di risoluzione dei problemi, utilizzare un RP fantasma per garantire la disponibilità di un RP secondario quando l'RP principale diventa inattivo. Esaminare la sezione "Convalida IPN" e verificare la convalida corretta.

La connettività dell'endpoint tra-Pod è interrotta nello stesso EPG

Questo problema è probabilmente causato da una configurazione errata nella configurazione di Multi-Pod. Assicurarsi di convalidare il flusso di lavoro di risoluzione dei problemi e verificare l'intero flusso. Se il problema persiste, consultare la sezione "Inoltro su più pod" nel capitolo "Inoltro all'interno della struttura" per risolvere ulteriormente il problema.