Dépannage de la détection de fabric ACI - Détection multipod

Introduction

Ce document décrit les étapes à suivre pour comprendre et dépanner l'ACI Multi-pod Discovery.

Informations générales

Le matériel de ce document a été extrait de la Dépannage de l'infrastructure axée sur les applications Cisco, deuxième édition , en particulier la découverte du fabric - Découverte multipod chapitre.

Présentation de Multi-Pod

L'ACI Multi-Pod permet le déploiement d'un cluster APIC unique pour gérer plusieurs réseaux ACI interconnectés. Ces réseaux ACI distincts sont appelés « pods » et chaque pod est une topologie spine-leaf à deux ou trois niveaux. Un seul cluster APIC peut gérer plusieurs pods.

Une conception à plusieurs pods permet également d'étendre les politiques de fabric ACI sur des pods qui peuvent exister physiquement dans plusieurs salles ou même sur des sites de data center distants. Dans une conception à plusieurs pods, toute stratégie définie sur le cluster de contrôleurs APIC est automatiquement mise à la disposition de tous les pods.

Enfin, une conception multipod augmente l'isolation du domaine de défaillance. En fait, chaque pod exécute sa propre instance des protocoles COOP, MP-BGP et IS-IS, de sorte que les pannes et les problèmes avec l'un de ces protocoles sont contenus dans ce pod et ne peuvent pas se propager à d'autres pods.

Reportez-vous au document « ACI Multi-Pod White Paper » sur cisco.com pour plus d'informations sur la conception et les meilleures pratiques multipod.

Les principaux éléments d'un fabric ACI multipod sont les commutateurs Leaf et Spine, les contrôleurs APIC et les périphériques IPN.

Cet exemple est axé sur le workflow de dépannage pour les problèmes liés à la configuration d'un fabric multipod ACI. La topologie de référence utilisée pour cette section est illustrée dans l'image ci-dessous :

Topologie de référence ACI multipod

Workflow de dépannage

Vérifier les politiques ACI

Politiques d'accès

Multi-Pod utilise une L3Out afin de connecter des Pods via le locataire « infra ». Cela signifie que l'ensemble standard de politiques d'accès doit être en place pour activer l'encapsulation L3Out multipod (VLAN-4) requise sur les ports spine orientés vers le réseau IP.

Les stratégies d'accès peuvent être configurées via l'assistant « Ajouter un pod » qui doit être utilisé pour déployer Multi-Pod. Une fois l'assistant utilisé, la stratégie déployée peut être vérifiée à partir de l'interface utilisateur graphique du contrôleur APIC. Si les stratégies ne sont pas correctement configurées, une défaillance apparaîtra sur le locataire infra et la connectivité des spines au réseau IP risque de ne pas fonctionner comme prévu.

Les schémas suivants peuvent être référencés lors de la vérification de la définition de la politique d'accès pour les interfaces orientées IPN sur les noeuds spine :

Spine201

Spine202

Spine401

Spine402

Dans le locataire infra, le L3Out multipod doit être configuré selon le schéma suivant :

L3Out multipod dans le locataire infra

Vous trouverez ci-dessous une capture de référence de la configuration du profil d'interface logique L3Out multipod. Les définitions de sous-interface de routeur doivent ressembler à l'image ci-dessous pour la spine 201

Profil d'interface logique dans l'interface L3Out

Pour chaque module, un pool TEP doit être défini comme dans l'image ci-dessous. Notez que le pool TEP sera utilisé à partir du contrôleur APIC pour provisionner les adresses IP des noeuds pour le VRF de superposition 1.

Stratégie de configuration de fabric Pod

Stratégie de connexion externe du fabric par défaut

Vérifiez que l'objet « Fabric Ext Policy default » est défini et configuré correctement dans le locataire infra. Un exemple de cette configuration est illustré dans les figures ci-dessous.

Stratégie de connexion externe du fabric par défaut

TEP plan de données

Sous-réseaux du profil de routage externe du fabric

Le profil de routage externe du fabric permet à l'utilisateur de vérifier si tous les sous-réseaux routés du réseau IP défini s'y trouvent.

Validation IPN

Multi-Pod repose sur un réseau inter-pods (IPN) qui fournit une connectivité POD à POD. Il est essentiel de vérifier que la configuration du réseau IP est correctement en place. Souvent, une configuration défectueuse ou manquante est la source d'un comportement inattendu ou d'une perte de trafic en cas de scénarios de panne. La configuration du numéro d'identification de produit est décrite en détail dans cette section.

Pour la section suivante, reportez-vous à la topologie IPN suivante :

Topologie IPN

Connectivité des sous-interfaces VLAN-4 entre Spine et IPN dot1q

La connectivité point à point entre les spines et l’IPN est réalisée avec des sous-interfaces sur VLAN-4. La première validation de cette connectivité consiste à tester l’accessibilité IP entre les spines et les périphériques IPN.

Pour ce faire, déterminez l’interface appropriée et vérifiez qu’elle s’affiche.

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

Après avoir vérifié que l'interface est active, testez la connectivité IP point à 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 

En cas de problème de connectivité, vérifiez le câblage et la configuration du réseau IP distant (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 

Configuration OSPF

Le protocole OSPF est utilisé comme protocole de routage pour connecter Pod1 et Pod2 au sein du VRF ACI « overlay-1 ». Les éléments suivants peuvent être référencés en tant que flux générique pour valider si OSPF intervient entre le spine et le périphérique 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 

Lorsque le protocole OSPF est activé entre tous les spines et les périphériques IPN, tous les pools TEP de pod sont visibles dans les tables de routage 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

Notez que sur IPN1 pour le Pod distant (Pod2), seule la route la plus optimale est affichée dans la commande « show ip route ».

Configuration du relais DHCP

Les noeuds de commutation reçoivent leur adresse infra-TEP en utilisant DHCP vers les APIC. Tous les APIC reçoivent généralement la détection, mais c'est le premier APIC à recevoir la détection et à présenter une offre qui allouera l'adresse TEP. Pour tenir compte de cela dans un scénario à plusieurs pods, configurez le relais DHCP sur le réseau IP pour recevoir ces découvertes et les monodiffuser vers les cartes APIC. En général, configurez toutes les interfaces IPN orientées spine avec des assistants IP pointant vers tous les APIC. Cette opération résistera à la configuration IPN si le contrôleur APIC est déplacé en raison d'un recâblage, d'une panne d'un contrôleur APIC en veille ou de tout autre scénario impliquant le déplacement d'un contrôleur APIC vers un nouveau pod.

Dans ce scénario, cela signifie configurer les interfaces Eth1/53.4 et Eth1/54.4 IPN1 avec des assistants IP pointant vers tous les 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

Depuis 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

Si le protocole OSPF ne s'active pas (EXCHANGE ou EXSTART) entre le périphérique Spine et le périphérique IPN, assurez-vous de valider que la MTU correspond entre les périphériques.

Configuration RP

Avec PIM BiDir, le point de rendez-vous (RP) ne fait pas partie du chemin de données. Pour la multidiffusion fonctionnelle, chaque périphérique IPN doit seulement avoir une route vers l'adresse RP. La redondance peut être obtenue à l'aide d'une configuration Phantom RP. Dans ce cas, Anycast RP n'est pas une méthode de redondance valide en raison de l'absence d'une source à échanger via le protocole MSDP (Multicast Source Discovery Protocol).

Dans une conception de RP fantôme, le RP est une adresse inexistante dans un sous-réseau accessible. Dans la configuration ci-dessous, supposons que la plage de multidiffusion configurée dans la configuration initiale du contrôleur APIC est 225.0.0.0/15 par défaut. Si elle a été modifiée dans la configuration initiale du contrôleur APIC, les configurations IPN doivent être alignées.

Le bouclage 1 ci-dessous est le bouclage phantom-rp. Il doit être injecté dans OSPF ; cependant, il ne peut pas être utilisé comme ID de routeur OPSF. Un bouclage distinct (loopback0) doit être utilisé pour cela.

Configuration 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

Configuration 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

Configuration 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

Configuration 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

Le masque de sous-réseau sur le bouclage ne peut pas être /32. Pour utiliser IPN1 comme périphérique principal dans la conception du RP fantôme, utilisez un masque de sous-réseau /30 pour tirer parti de la route la plus spécifique privilégiée dans la topologie OSPF. IPN3 sera le périphérique secondaire dans la conception du RP fantôme, donc utilisez un masque de sous-réseau /29 pour en faire une route moins spécifique. /29 ne sera utilisé que si quelque chose empêche /30 d'exister et d'exister par la suite dans la topologie OSPF.

Dépannage de la première colonne vertébrale du pod distant reliant le fabric

Les étapes suivantes décrivent le processus suivi par le 1er noeud Spine de pod distant pour joindre le fabric :

1. La colonne vertébrale exécutera DHCP sur sa sous-interface faisant face au réseau IP. La configuration du relais DHCP transporte cette détection vers les cartes APIC. Les APIC répondront si la colonne vertébrale a été ajoutée à l'appartenance au fabric. L'adresse IP qui est offerte est l'adresse IP configurée sur le Multi-Pod L3Out.
2. Le spine installe une route vers le serveur DHCP qui a offert l'adresse IP comme route statique vers l'autre extrémité de l'interface point à point.
3. La colonne vertébrale téléchargera un fichier de démarrage à partir du contrôleur APIC via la route statique.
4. La colonne vertébrale sera configurée en fonction du fichier de bootstrap pour activer les protocoles VTEP, OSPF et BGP pour joindre le fabric.

À partir du contrôleur APIC, vérifiez si l’adresse IP L3Out est correctement configurée pour être offerte : (notre Spine 401 a la série 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

Vérifiez si l'interface orientée IPN a reçu l'adresse IP attendue correspondant à la configuration L3Out effectuée dans le locataire 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 

Maintenant, la connectivité IP a été établie de la colonne vertébrale au contrôleur APIC et la connectivité par ping peut être vérifiée :

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 colonne vertébrale affiche alors le protocole OSPF sur le réseau IP et configure un bouclage pour l’ID de routeur :

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

La colonne vertébrale reçoit désormais son PTEP via 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 colonne vertébrale passe de Découverte à Active et est entièrement découverte :

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

Sachez que nous ne pouvons détecter une colonne vertébrale distante que si au moins un commutateur leaf y est connecté.

Vérification des commutateurs leaf et spine restants

Le reste du module Pod est maintenant détecté selon la procédure normale d'affichage du module Pod, comme indiqué dans la section « Configuration initiale du fabric ».

Vérifier le Pod APIC distant

Pour détecter le troisième contrôleur APIC, procédez comme suit :

• Le leaf301 crée une route statique vers le contrôleur APIC connecté directement (APIC3) sur la base du protocole LLDP (identique au cas d'un seul POD)Le contrôleur APIC distant reçoit une adresse IP du pool IP POD1. Nous allons créer cette route en tant que /32.
• Leaf301 annonce cette route en utilisant IS-IS vers Spine401 et Spine402 (comme dans le cas d'un seul POD)
• Spine401 et Spine402 redistribuent cette route dans OSPF vers IPN
• Spine201 et Spine202 redistribuent cette route d'OSPF vers IS-IS dans Pod1
• La connectivité est désormais établie entre APIC3, APIC1 et APIC2
• APIC3 peut désormais rejoindre le cluster

Afin de confirmer, utilisez les vérifications suivantes :

Le Leaf301 crée une route statique vers le contrôleur APIC connecté directement (APIC3) basé sur LLDP (identique au cas d'un seul 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 annonce cette route en utilisant IS-IS vers Spine401 et Spine402 (comme dans le cas d'un seul POD)

Spine401 et Spine402 laissent passer cette route dans OSPF vers 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 

La connectivité est désormais établie entre APIC3, APIC1 et APIC2

APIC3 peut désormais rejoindre le 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 

Envoyez une requête ping à partir du contrôleur APIC1 vers un périphérique distant dans le Pod2 pour valider la connectivité via la requête ping suivante : (assurez-vous d'utiliser la source de l'interface locale, dans le cas APIC1 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 

Scénarios de dépannage

Spine ne peut pas envoyer de requête ping

Ceci est probablement dû à :

• Erreur de configuration dans les politiques d'accès ACI.
• Erreur de configuration dans la configuration IPN.

Reportez-vous au « Workflow de dépannage » de ce chapitre et passez en revue :

• Vérifiez les politiques ACI.
• Validation IPN.

La colonne vertébrale distante ne joint pas le fabric

Ceci est probablement dû à :

• Problème de relais DHCP sur le réseau IPN.
• Accessibilité IP de la colonne vertébrale au contrôleur APIC sur le réseau IPN.

Reportez-vous au « Workflow de dépannage » de ce chapitre et passez en revue :

• Vérifiez les politiques ACI.
• Validation IPN.
• Dépannez la 1ère connexion de fabric.

Assurez-vous de valider qu'au moins 1 noeud leaf est connecté au noeud spine distant et que le noeud spine a une contiguïté LLDP avec ce noeud leaf.

Le contrôleur APIC de Pod2 ne joint pas le fabric

Cela est généralement dû à une erreur dans le dialogue de configuration initiale du contrôleur APIC, en supposant que les commutateurs Leaf et Spine du Pod distant ont pu joindre correctement le fabric. Dans une configuration correcte, attendez-vous à la sortie « avread » suivante (scénario de jonction APIC3 opérationnel) :

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 

Notez que l'APIC3 (dans le Pod distant) est configuré avec podId 2 et l'adresse d'étape du Pod1.

Vérifiez les paramètres de configuration APIC3 d'origine à l'aide de la commande suivante :

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

En cas d'erreur, connectez-vous au contrôleur APIC3 et exécutez les commandes « acidiag touch setup » et « acidiag reboot ».

Le trafic POD-à-POD BUM ne fonctionne pas

Ceci est probablement dû à :

• Absence de RP dans le réseau IP
• Le RP n'est pas accessible par le fabric ACIerreur de configuration de multidiffusion générale sur les périphériques IPN

Reportez-vous au « Workflow de dépannage » de ce chapitre et passez en revue :

• Validation IPN

Assurez-vous également que l'un des périphériques RP IPN est en ligne.

Après la défaillance d'un périphérique IPN, le trafic BUM est abandonné

Comme décrit dans la Validation IPN dans le workflow de dépannage, utilisez un RP fantôme pour garantir qu'un RP secondaire est disponible lorsque le RP principal tombe en panne. Assurez-vous de consulter la section « Validation IPN » et de vérifier la validation correcte.

La connectivité entre les terminaux Pod est interrompue dans le même EPG

Ceci est probablement dû à une mauvaise configuration dans la configuration Multi-Pod, assurez-vous de valider le workflow de dépannage et vérifiez le flux entier. Si cela semble correct, reportez-vous à la section « Transfert multipod » du chapitre « Transfert intra-fabric » pour résoudre ce problème.