Fehlerbehebung: ACI Fabric Discovery - Multi-Pod Discovery

Einleitung

In diesem Dokument werden die Schritte zum Verständnis und zur Fehlerbehebung bei ACI Multi-Pod Discovery beschrieben.

Hintergrundinformationen

Das Material aus diesem Dokument wurde aus dem Fehlerbehebung: Cisco Application Centric Infrastructure, Second Edition Buch, insbesondere die Fabric Discovery - Multi-Pod-Erkennung Kapitel.

Multi-Pod - Überblick

ACI Multi-Pod ermöglicht die Bereitstellung eines einzelnen APIC-Clusters zur Verwaltung mehrerer miteinander verbundener ACI-Netzwerke. Diese separaten ACI-Netzwerke werden als "Pods" bezeichnet, und jeder Pod ist eine reguläre Spine-Leaf-Topologie mit zwei oder drei Ebenen. Ein einzelner APIC-Cluster kann mehrere PODs verwalten.

Ein Multi-Pod-Design ermöglicht auch die Erweiterung der ACI-Fabric-Richtlinien auf PODs, die physisch in mehreren Räumen oder sogar an entfernten Rechenzentrumsstandorten vorhanden sein können. Bei einem Multi-Pod-Design werden alle auf dem APIC-Controller-Cluster definierten Richtlinien automatisch für alle PODs verfügbar gemacht.

Schließlich erhöht ein Multi-Pod-Design die Fehlerdomänenisolierung. Jeder Pod führt seine eigene Instanz des COOP-, MP-BGP- und IS-IS-Protokolls aus, sodass Fehler und Probleme mit diesen Protokollen in diesem Pod enthalten sind und sich nicht auf andere Pods ausbreiten können.

Weitere Informationen zu Multi-Pod-Design und Best Practices finden Sie im Dokument "ACI Multi-Pod Whitepaper" unter cisco.com.

Die Hauptelemente einer Multi-Pod ACI-Fabric sind die Leaf- und Spine-Switches, die APIC-Controller und die IPN-Geräte.

In diesem Beispiel wird der Workflow zur Fehlerbehebung bei Problemen im Zusammenhang mit der Einrichtung einer ACI Multi-Pod-Fabric erläutert. Die für diesen Abschnitt verwendete Referenztopologie ist in der folgenden Abbildung dargestellt:

ACI-Multi-Pod-Referenztopologie

Problembehebungs-Workflow

Überprüfung der ACI-Richtlinien

Zugriffsrichtlinien

Multi-Pod verwendet einen L3Out, um Pod über den Infra-Tenant zu verbinden. Das bedeutet, dass die Standard-Zugriffsrichtlinien vorhanden sein müssen, um die erforderliche Multi-Pod L3Out-Kapselung (VLAN-4) an den Spine-Ports zum IPN zu aktivieren.

Zugriffsrichtlinien können über den Assistenten "Add Pod" (Pod hinzufügen) konfiguriert werden, mit dem Multi-Pod bereitgestellt werden soll. Nach der Verwendung des Assistenten kann die bereitgestellte Richtlinie über die APIC-GUI überprüft werden. Wenn die Richtlinien nicht richtig konfiguriert sind, tritt ein Fehler auf dem Infra-Tenant auf, und die Verbindung von Spines zum IPN funktioniert möglicherweise nicht wie erwartet.

Auf die folgenden Schemas kann beim Überprüfen der Zugriffsrichtliniendefinition für die IPN-zugewandten Schnittstellen auf den Spine-Knoten verwiesen werden:

Spine 201

Spine 202

Spine 401

Spine 402

Im Infra-Tenant sollte der Multi-Pod L3Out gemäß dem folgenden Schema konfiguriert werden:

Multi-Pod L3Out im Infra-Tenant

Nachfolgend finden Sie eine Referenzaufnahme der Konfiguration des logischen L3Out-Schnittstellenprofils für den Multi-Pod. Die Definitionen der Router-Subschnittstelle sollten wie in der Abbildung unten für Spine 201 aussehen.

Logisches Schnittstellenprofil in infra L3Out

Für jeden Pod sollte ein TEP-Pool wie in der Abbildung unten definiert vorhanden sein. Beachten Sie, dass der TEP-Pool vom APIC-Controller verwendet wird, um die IP-Adressen der Knoten für die Overlay-1-VRF-Instanz bereitzustellen.

Pod Fabric-Einrichtungsrichtlinie

Fabric External Connection-Richtlinie - Standard

Überprüfen Sie, ob im Infra-Tenant das Objekt "Fabric Ext Policy default" definiert und entsprechend konfiguriert ist. Ein Beispiel dieser Konfiguration ist in den folgenden Abbildungen dargestellt.

Fabric External Connection-Richtlinie - Standard

Datenflugzeug TEP

Subnetze des externen Fabric-Routing-Profils

Mit dem externen Fabric-Routing-Profil kann der Benutzer überprüfen, ob alle Router-Subnetze des definierten IPN vorhanden sind.

IPN-Validierung

Für Multi-Pod ist ein Inter-Pod-Netzwerk (IPN) erforderlich, das die Verbindung zwischen den PODs ermöglicht. Es muss unbedingt sichergestellt werden, dass die Konfiguration für das IPN korrekt vorhanden ist. Häufig ist eine fehlerhafte oder fehlende Konfiguration die Ursache für unerwartetes Verhalten oder Datenverlust bei Ausfallszenarien. Die Konfiguration für das IPN wird in diesem Abschnitt detailliert beschrieben.

Im nächsten Abschnitt finden Sie Informationen in der folgenden IPN-Topologie:

IPN-Topologie

Verbindung zwischen Spine und IPN dot1q VLAN-4-Subschnittstellen

Die Spine-to-IPN Point-to-Point-Verbindung wird mit Subschnittstellen auf VLAN-4 erreicht. Die erste Validierung für diese Verbindung besteht darin, die IP-Erreichbarkeit zwischen den Spines und den IPN-Geräten zu testen.

Stellen Sie dazu die richtige Schnittstelle fest, und vergewissern Sie sich, dass diese als aktiv angezeigt wird.

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

Nachdem Sie überprüft haben, ob die Schnittstelle betriebsbereit ist, testen Sie jetzt die Punkt-zu-Punkt-IP-Verbindung:

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 

Wenn ein Verbindungsproblem auftritt, überprüfen Sie die Verkabelung und die Konfiguration auf dem Remote-IPN (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 

OSPF-Konfiguration

OSPF wird als Routing-Protokoll verwendet, um Pod1 und Pod2 innerhalb des ACI-VRF "overlay-1" miteinander zu verbinden. Auf die folgenden Daten kann als allgemeiner Fluss verwiesen werden, um zu überprüfen, ob OSPF zwischen Spine und IPN-Gerät eintritt.

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 

Wenn OSPF zwischen allen Spines und IPN-Geräten aktiv ist, sind alle Pod TEP-Pools in den IPN-Routing-Tabellen zu sehen.

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

Beachten Sie, dass auf IPN1 für den Remote-Pod (Pod2) nur die optimale Route mit dem Befehl "show ip route" angezeigt wird.

DHCP-Relay-Konfiguration

Switch-Knoten erhalten ihre Infrarot-TEP-Adresse über DHCP an die APICs. Alle APICs erhalten in der Regel die Erkennung, aber es ist der erste APIC, der die Erkennung erhält und ein Angebot für die Zuweisung der TEP-Adresse präsentiert. Um dies in einem Multi-Pod-Szenario zu berücksichtigen, konfigurieren Sie ein DHCP-Relay auf dem IPN, das diese Erkennungen empfängt, und senden sie per Unicast an die APICs. Im Allgemeinen müssen alle IPN-Spine-seitigen Schnittstellen mit IP-Helfern konfiguriert werden, die auf alle APICs verweisen. Wenn der APIC aufgrund einer Neuverkabelung verschoben wird, ein Standby-APIC ausfällt oder in anderen Szenarien auf einen neuen Pod migriert wird, ist die IPN-Konfiguration damit zukunftssicher.

In diesem Szenario bedeutet dies die Konfiguration von IPN1 Eth1/53.4 und Eth1/54.4 mit IP-Helfern, die auf alle APICs verweisen:

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

Von 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

Wenn OSPF zwischen Spine- und IPN-Gerät nicht verfügbar ist (EXCHANGE oder EXSTART), stellen Sie sicher, dass die MTU zwischen den Geräten übereinstimmt.

RP-Konfiguration

Bei PIM BiDir ist der Rendezvous Point (RP) nicht Teil des Datenpfads. Für funktionsfähiges Multicast muss jedes IPN-Gerät nur über eine Route zur RP-Adresse verfügen. Die Redundanz kann über eine Phantom-RP-Konfiguration erreicht werden. In diesem Fall ist Anycast RP keine gültige Redundanzmethode, da keine Quelle für den Austausch über das Multicast Source Discovery Protocol (MSDP) vorhanden ist.

Bei einem Phantom-RP-Design ist der RP eine nicht vorhandene Adresse in einem erreichbaren Subnetz. In der folgenden Konfiguration wird davon ausgegangen, dass der bei der Ersteinrichtung des APIC konfigurierte Multicast-Bereich der Standardwert 225.0.0.0/15 ist. Wenn er bei der Ersteinrichtung des APIC geändert wurde, müssen die IPN-Konfigurationen angepasst werden.

Der Loopback1 unten ist der Phantom-RP-Loopback. Es muss in OSPF injiziert werden; Sie kann jedoch nicht als OPSF-Router-ID verwendet werden. Hierfür muss ein separates Loopback (loopback0) verwendet werden.

IPN1-Konfiguration:

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

IPN2-Konfiguration:

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

IPN3-Konfiguration:

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

IPN4-Konfiguration:

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

Die Subnetzmaske auf dem Loopback darf nicht /32 sein. Wenn Sie IPN1 als primäres Gerät im Phantom-RP-Design verwenden möchten, verwenden Sie eine /30-Subnetzmaske, um die in der OSPF-Topologie bevorzugte Route zu nutzen. IPN3 wird das sekundäre Gerät im Phantom-RP-Design sein. Verwenden Sie daher eine /29-Subnetzmaske, um eine weniger spezifische Route festzulegen. Der Parameter "/29" wird nur verwendet, wenn etwas passiert, das den Parameter "/30" daran hindert, in der OSPF-Topologie vorhanden und anschließend vorhanden zu sein.

Fehlerbehebung beim ersten Remote Pod Spine, der mit der Fabric verbunden ist

In den folgenden Schritten wird der Prozess beschrieben, den die erste Remote Pod Spine durchläuft, um der Fabric beizutreten:

1. Der Spine führt DHCP an seiner Subschnittstelle zum IPN aus. Die DHCP-Relay-Konfiguration überträgt diese Erkennung an die APICs. Die APICs reagieren, wenn der Spine der Fabric-Mitgliedschaft hinzugefügt wurde. Die angebotene IP-Adresse ist die IP-Adresse, die für den Multi-Pod L3Out konfiguriert wurde.
2. Der Spine installiert eine Route zum DHCP-Server, der die IP-Adresse als statische Route zum anderen Ende der Point-to-Point-Schnittstelle bereitgestellt hat.
3. Der Spine lädt über die statische Route eine Bootstrap-Datei vom APIC herunter.
4. Der Spine wird basierend auf der Bootstrap-Datei konfiguriert, um VTEP, OSPF und BGP für die Verbindung mit der Fabric zu aktivieren.

Überprüfen Sie im APIC, ob die L3Out-IP-Adresse richtig konfiguriert ist, um angeboten zu werden: (unser Spine 401 hat seriellen 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

Überprüfen Sie, ob die IPN-seitige Schnittstelle die erwartete, mit der L3Out-Konfiguration übereinstimmende IP-Adresse im Infra-Tenant erhalten hat.

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 

Nun wurde die IP-Verbindung vom Spine zum APIC hergestellt, und die Verbindung über Ping kann überprüft werden:

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 

Der Spine aktiviert nun OSPF auf dem IPN und richtet ein Loopback für die Router-ID ein:

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

Der Spine erhält nun seine PTEP über 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

Die Spine wechselt von Erkennung zu Aktiv und ist vollständig erkannt:

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

Bitte wissen Sie, dass wir einen entfernten Spine nur dann entdecken können, wenn mindestens ein Leaf-Switch damit verbunden ist.

Überprüfung der verbleibenden Leaf- und Spine-Switches

Der Rest des Pod wird jetzt gemäß dem normalen Pod-Aktivierungsverfahren erkannt, wie im Abschnitt "Anfängliche Fabric-Konfiguration" beschrieben.

Remote-Pod APIC überprüfen

Zur Erkennung des dritten APIC wird folgender Prozess ausgeführt:

• Leaf301 erstellt eine statische Route zum direkt verbundenen APIC (APIC3) auf Basis von LLDP (identisch mit Single-Pod-Gehäuse)Der Remote-APIC erhält eine IP-Adresse aus dem POD1-IP-Pool. Diese Route wird als /32 erstellt.
• Leaf301 kündigt diese Route mithilfe von IS-IS zu Spine401 und Spine402 an (identisch mit dem Single-Pod-Fall)
• Spine401 und Spine402 verteilen diese Route über OSPF an IPN
• Spine201 und Spine202 verteilen diese Route von OSPF an IS-IS in Pod1
• Nun besteht eine Verbindung zwischen APIC3 und APIC1 und APIC2
• APIC3 kann jetzt zum Cluster hinzugefügt werden

Verwenden Sie zur Bestätigung folgende Prüfungen:

Leaf301 erstellt eine statische Route zum direkt verbundenen APIC (APIC3) basierend auf LLDP (identisch mit Single 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 kündigt diese Route mithilfe von IS-IS zu Spine401 und Spine402 an (identisch mit dem Single-Pod-Fall)

Spine401 und Spine402 leiten diese Route über OSPF an IPN weiter

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 

Nun besteht eine Verbindung zwischen APIC3 und APIC1 und APIC2

APIC3 kann jetzt zum Cluster hinzugefügt werden

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 

Pingen Sie vom APIC1 an ein Remote-Gerät in Pod2, um die Verbindung über den folgenden Ping zu validieren: (Stellen Sie sicher, dass die Quelle über die lokale Schnittstelle erfolgt, in APIC1, Fall 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 

Fehlerbehebungsszenarien

Spine kann IPN nicht pingen

Dies wird wahrscheinlich verursacht durch:

• Eine Fehlkonfiguration in den ACI-Zugriffsrichtlinien.
• Eine Fehlkonfiguration in der IPN-Konfiguration.

Lesen Sie den "Problembehebungs-Workflow" in diesem Kapitel, und lesen Sie:

• Überprüfen Sie die ACI-Richtlinien.
• IPN-Validierung.

Remote Spine verbindet kein Fabric

Dies wird wahrscheinlich verursacht durch:

• DHCP-Relay-Problem im IPN-Netzwerk.
• IP-Verfügbarkeit von Spine zu APIC über das IPN-Netzwerk

Lesen Sie den "Problembehebungs-Workflow" in diesem Kapitel, und lesen Sie:

• Überprüfen Sie die ACI-Richtlinien.
• IPN-Validierung.
• Fehlerbehebung bei 1. Fabric-Verbindung

Stellen Sie sicher, dass mindestens ein Leaf mit dem Remote-Spine verbunden ist und dass der Spine eine LLDP-Adjacency mit diesem Leaf hat.

APIC in Pod2 verbindet keine Struktur

Dies wird in der Regel durch einen Fehler im APIC-Dialogfeld für die Ersteinrichtung verursacht, der davon ausgeht, dass die Remote-Pod-Leaf- und Spine-Switches der Fabric richtig zugeordnet werden konnten. Bei korrekter Konfiguration ist mit der folgenden "avread"-Ausgabe zu rechnen (funktionierendes APIC3-Join-Szenario):

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 

Beachten Sie, dass der APIC3 (im Remote-Pod) mit der POD-ID 2 und der Schrittadresse von Pod1 konfiguriert ist.

Überprüfen Sie die ursprünglichen APIC3-Setup-Einstellungen mit dem folgenden Befehl:

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

Wenn ein Fehler auftritt, melden Sie sich bei APIC3 an, und führen Sie "acidiag touch setup" und "acidiag reboot" aus.

POD-zu-POD BUM-Datenverkehr funktioniert nicht

Dies wird wahrscheinlich verursacht durch:

• Das Fehlen eines RP im IP-Netzwerk
• Der RP kann von der ACI-Fabric nicht erreicht werdenAllgemeine Multicast-Fehlkonfiguration auf den IPN-Geräten

Lesen Sie den "Problembehebungs-Workflow" in diesem Kapitel, und lesen Sie:

• IPN-Validierung

Stellen Sie außerdem sicher, dass eines der IPN-RP-Geräte online ist.

Nach Ausfall von 1 IPN-Gerät wird BUM-Datenverkehr verworfen

Verwenden Sie einen Phantom-RP, um sicherzustellen, dass ein sekundärer RP verfügbar ist, wenn der primäre RP ausfällt, wie im Workflow zur Fehlerbehebung unter IPN-Validierung beschrieben. Überprüfen Sie unbedingt den Abschnitt "IPN-Validierung", und überprüfen Sie die korrekte Validierung.

Verbindung zwischen Pod-Endgeräten innerhalb derselben EPG unterbrochen

Dies wird wahrscheinlich durch eine Fehlkonfiguration in der Multi-Pod-Konfiguration verursacht. Überprüfen Sie den Workflow zur Fehlerbehebung, und überprüfen Sie den gesamten Fluss. Wenn dies in Ordnung erscheint, finden Sie weitere Informationen zur Behebung dieses Problems im Abschnitt "Multi-Pod-Weiterleitung" im Kapitel "Intra-Fabric-Weiterleitung".