Fehlerbehebung: ACI Intra-Fabric Forwarding - L3 Forwarding Zwei Endgeräte in verschiedenen BDs

Einleitung

In diesem Dokument werden die Schritte zum Verständnis und zur Fehlerbehebung in einem ACI L3-Weiterleitungsszenario beschrieben.

Hintergrundinformationen

Das Material aus diesem Dokument wurde aus dem Fehlerbehebung: Cisco Application Centric Infrastructure, Second Edition Buch, insbesondere das Fabric-interne Weiterleitung - L3-Weiterleitung: zwei Endpunkte in verschiedenen BDs Kapitel.

L3-Weiterleitung: zwei Endpunkte in verschiedenen BDs

In diesem Kapitel wird ein Beispiel zur Fehlerbehebung erläutert, bei dem Endpunkte in verschiedenen Bridge-Domänen nicht miteinander kommunizieren können. Dieser Datenfluss würde über die ACI-Fabric geroutet. Abbildung 1 zeigt die Topologie.

Endgeräte in verschiedenen Bridge-Domänen

Allgemeiner Workflow zur Fehlerbehebung

Im Folgenden finden Sie typische Schritte zur Fehlerbehebung und Verifizierungsbefehle:

Erste Prüfungen — Validierung der Programmierung

• Das universelle BD-Gateway muss zu Leaf-Knoten verschoben werden.
• Die Route zum BD-Ziel-Subnetz sollte an Leaf-Knoten gesendet werden.
• ARP für das Standard-Gateway der Hosts sollte aufgelöst werden.

Zweite Überprüfung - Validierung von Lern- und Tabelleneinträgen über CLI auf Leaf-Knoten

• Überprüfen Sie, ob die Quell-Leaf- und Ziel-Leaf-Knoten den Endpunkt erlernen und ob er den Ziel-Endpunkt erlernt:
  • Endpunkttabelle - 'Endpunkt anzeigen'.
  • TEP-Ziel — 'show interface tunnel <x>'.
  • Suchen des TEP-Ziels im Befehl "show ip route <TEP-Adresse> vrf overlay-1"
• Check Spine-Knoten lernen den Endpunkt:
  • 'show coop internal info'.

Dritte Prüfungen: Ergreifen eines Pakets und Analysieren der Weiterleitungsentscheidungen

• Mit ELAM (ELAM Assistant oder CLI), um den Frame zu überprüfen.
• Oder mit fTriage, um den Fluss zu verfolgen.

Fehlerbehebungs-Workflow für bekannte Endpunkte

Prüfen Sie das universelle Gateway des BD.

In diesem Beispiel werden die folgenden Quell- und Zielendpunkte verwendet:

• EP A 10.1.1.1 unter Leaf 1.
• EP B 10.1.2.1 unter VPC-Paar Leaf3 und Leaf4.

Folgende universelle Gateways sollten verwendet werden:

• 10.1.1.254/24 für BD1-Gateway auf Leaf1.
• 10.1.2.254/24 für BD2-Gateway auf Leaf3 und Leaf4.

Dies kann wie folgt überprüft werden: 'show ip interface vrf <vrf name>' auf den Leaf-Knoten.

Leaf 1:

leaf1# show ip interface vrf Prod:VRF1
IP Interface Status for VRF "Prod:VRF1"
vlan7, Interface status: protocol-up/link-up/admin-up, iod: 106, mode: pervasive
 IP address: 10.1.1.254, IP subnet: 10.1.1.0/24
 IP broadcast address: 255.255.255.255
 IP primary address route-preference: 0, tag: 0

Leaf 3 und 4:

leaf3# show ip interface  vrf Prod:VRF1
IP Interface Status for VRF "Prod:VRF1"
vlan1, Interface status: protocol-up/link-up/admin-up, iod: 159, mode: pervasive
 IP address: 10.1.2.254, IP subnet: 10.1.2.0/24
 IP broadcast address: 255.255.255.255
 IP primary address route-preference: 0, tag: 0

leaf4# show ip interface  vrf Prod:VRF1
IP Interface Status for VRF "Prod:VRF1"
vlan132, Interface status: protocol-up/link-up/admin-up, iod: 159, mode: pervasive
 IP address: 10.1.2.254, IP subnet: 10.1.2.0/24
 IP broadcast address: 255.255.255.255
 IP primary address route-preference: 0, tag: 0

Es ist zu beachten, dass leaf3 und leaf4 die gleiche allgegenwärtige Gateway-Adresse haben, es wird aber wahrscheinlich eine andere VLAN-Kapselung für die SVI geben.

• Endknoten3 verwendet VLAN 1.
• leaf4 verwendet VLAN 132.

Dies wird erwartet, da VLAN 1 oder VLAN 132 ein lokales VLAN auf dem Leaf ist.

Wenn die IP-Adresse des universellen Gateways nicht an das Leaf übertragen wird, stellen Sie in der APIC-GUI sicher, dass keine Fehler vorliegen, die die Bereitstellung des VLAN verhindern würden.

Routing-Tabelle auf dem Leaf wird überprüft

Leaf1 hat keinen Endpunkt im Subnetz 10.1.2.0/24, es muss jedoch die Route zu diesem Subnetz aufweisen, um es zu erreichen:

leaf1# show ip route 10.1.2.0/24 vrf Prod:VRF1
IP Route Table for VRF "Prod:VRF1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.1.2.0/24, ubest/mbest: 1/0, attached, direct, pervasive
   *via 10.0.8.65%overlay-1, [1/0], 00:22:37, static, tag 4294967294
        recursive next hop: 10.0.8.65/32%overlay-1

Beachten Sie, dass die Route, die mit 'pervasive' und 'direct' markiert ist, den Next-Hop 10.0.8.65 hat. Dies ist die Anycast-v4-Loopback-Adresse, die auf allen Spines vorhanden ist.

leaf1# show isis  dteps  vrf overlay-1 | egrep 10.0.8.65
10.0.8.65          SPINE   N/A             PHYSICAL,PROXY-ACAST-V4

Entsprechend sollten leaf3 und leaf4 route für 10.1.1.0/24 haben.

leaf3# show ip route 10.1.1.1 vrf Prod:VRF1
IP Route Table for VRF "Prod:VRF1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.1.1.0/24, ubest/mbest: 1/0, attached, direct, pervasive
   *via 10.0.8.65%overlay-1, [1/0], 00:30:25, static, tag 4294967294
        recursive next hop: 10.0.8.65/32%overlay-1

Wenn diese Routen fehlen, liegt dies wahrscheinlich daran, dass es keinen Vertrag zwischen einer EPG in BD1 und einer EPG in BD2 gibt. Wenn es keinen lokalen Endpunkt in BD1 unter einem Leaf gibt, wird das universelle BD1-Gateway nicht an das Leaf übertragen. Wenn es einen lokalen Endpunkt in einer EPG gibt, der einen Vertrag mit einer anderen EPG in BD1 hat, wird das BD1-Subnetz auf dem Leaf gelernt.

ARP-Auflösung für die Standard-Gateway-IP

Da das Leaf, auf dem sich ein lokaler Endpunkt befindet, über ein universelles Gateway verfügen sollte, sollten ARP-Anfragen für das universelle Gateway immer vom lokalen Leaf gelöst werden. Dies kann auf dem lokalen Leaf mit dem folgenden Befehl überprüft werden:

leaf1# show ip arp internal event-history event  | egrep 10.1.1.1
   [116] TID 26571:arp_handle_arp_request:6135: log_collect_arp_pkt; sip = 10.1.1.1; dip = 10.1.1.254;interface = Vlan7; phy_inteface = Ethernet1/3; flood = 0; Info = Sent ARP response.
    [116] TID 26571:arp_process_receive_packet_msg:8384: log_collect_arp_pkt; sip = 10.1.1.1; dip = 10.1.1.254;interface = Vlan7; phy_interface = Ethernet1/3;Info = Received arp request

Lernen der IP- und MAC-Endpunkte des Eingangs-Leaf

Im Fall der Layer-3-Weiterleitung führt die ACI das Layer-3-Quell-IP-Learning und die Ziel-IP-Suche durch. Erlernte IP-Adressen sind auf die VRF-Instanz beschränkt.

Dies kann in der GUI auf der Registerkarte 'Operational' einer EPG überprüft werden. Beachten Sie, dass hier sowohl die IP- als auch die MAC-Adresse erfasst werden.

EPG - Betriebliche Endgeräte

EPG - Betriebliche Endpunkte - Details

Überprüfen, ob der lokale Endpunkt auf dem lokalen Leaf gelernt wurde. Überprüfen Sie auf Leaf1, ob IP 10.1.1.1 gelernt wurde:

leaf1# show endpoint ip 10.1.1.1
Legend:
s - arp              H - vtep             V - vpc-attached     p - peer-aged
R - peer-attached-rl B - bounce           S - static           M - span
D - bounce-to-proxy  O - peer-attached    a - local-aged       m - svc-mgr
L - local            E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+
     VLAN/                           Encap           MAC Address       MAC Info/       Interface
     Domain                          VLAN            IP Address        IP Info
+-----------------------------------+---------------+-----------------+--------------+-------------+
46                                        vlan-2501    0000.1001.0101 L                      eth1/3
Prod:VRF1                                 vlan-2501          10.1.1.1 L                      eth1/3

Der Inhalt des Endgeräts ist wie oben gezeigt:

• BD (internes VLAN für BD ist 46) mit VLAN-Kapselung der EPG (vlan-2501) und der auf eth1/3 ermittelten MAC-Adresse
• VRF (Prod:VRF1) mit IP 10.1.1.1

Dies entspricht einem ARP-Eintrag in einem herkömmlichen Netzwerk. Die ACI speichert keine ARP-Informationen in einer ARP-Tabelle für Endgeräte. Endpunkte sind nur in der Endpunkttabelle sichtbar.

Die ARP-Tabelle auf einem Leaf wird nur für L3Out Next-Hops verwendet.

leaf1# show ip arp vrf Prod:VRF1    
Flags: * - Adjacencies learnt on non-active FHRP router
       + - Adjacencies synced via CFSoE
       # - Adjacencies Throttled for Glean
       D - Static Adjacencies attached to down interface    IP ARP Table for context Prod:VRF1
Total number of entries: 0
Address         Age       MAC Address     Interface    
< NO ENTRY >

IP-Zielsuche am Eingangs-Leaf - bekannter Remote-Endpunkt

Angenommen, die Ziel-IP-Adresse ist bekannt (bekanntes Unicast), unten sehen Sie die Ausgabe von "show endpoint" für die Ziel-IP 10.1.2.1. Dies ist ein Remote-Learning-Vorgang, da er sich nicht auf Leaf1 befindet und speziell auf die Tunnelschnittstelle zeigt, wo er lokal gelernt wird (Tunnel 4).

Remote-Endpunkte enthalten entweder die IP- oder die MAC-Adresse, jedoch nie beide im selben Eintrag. Die MAC- und IP-Adresse eines Endpunkts wird nur übernommen, wenn dieser lokal erfasst wird.

leaf1# show endpoint ip 10.1.2.1
Legend:
s - arp              H - vtep             V - vpc-attached     p - peer-aged
R - peer-attached-rl B - bounce           S - static           M - span
D - bounce-to-proxy  O - peer-attached    a - local-aged       m - svc-mgr
L - local            E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+
     VLAN/                           Encap           MAC Address       MAC Info/       Interface
     Domain                          VLAN            IP Address        IP Info
+-----------------------------------+---------------+-----------------+--------------+-------------+
Prod:VRF1                                                    10.1.2.1 p                     tunnel4

leaf1# show interface tunnel 4
Tunnel4 is up
   MTU 9000 bytes, BW 0 Kbit
   Transport protocol is in VRF "overlay-1"
   Tunnel protocol/transport is ivxlan
   Tunnel source 10.0.88.95/32 (lo0)
   Tunnel destination 10.0.96.66
   Last clearing of "show interface" counters never
   Tx
   0 packets output, 1 minute output rate 0 packets/sec
   Rx
   0 packets input, 1 minute input rate 0 packets/sec

Die Ziel-TEP ist die Anycast-TEP des Leaf3- und Leaf4-VPC-Paars und wird über Uplinks für Spine erfasst.

leaf1# show ip route 10.0.96.66 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.96.66/32, ubest/mbest: 4/0
   *via 10.0.88.65, eth1/49.10, [115/3], 02w06d, isis-isis_infra, isis-l1-int
   *via 10.0.128.64, eth1/51.8, [115/3], 02w06d, isis-isis_infra, isis-l1-int
   *via 10.0.88.64, eth1/52.126, [115/3], 02w06d, isis-isis_infra, isis-l1-int
   *via 10.0.88.94, eth1/50.128, [115/3], 02w06d, isis-isis_infra, isis-l1-int

Zusätzliche Endpunktinformationen für IP 10.1.2.1 können mit dem Befehl "show system internal epm endpoint ip <ip>" erfasst werden.

leaf1# show system internal epm endpoint ip 10.1.2.1
MAC : 0000.0000.0000 ::: Num IPs : 1
IP# 0 : 10.1.2.1 ::: IP# 0 flags :  ::: l3-sw-hit: No
Vlan id : 0 ::: Vlan vnid : 0 ::: VRF name : Prod:VRF1
BD vnid : 0 ::: VRF vnid : 2097154
Phy If : 0 ::: Tunnel If : 0x18010004
Interface : Tunnel4
Flags : 0x80004420 ::: sclass : 32771 ::: Ref count : 3
EP Create Timestamp : 10/01/2019 13:53:16.228319
EP Update Timestamp : 10/01/2019 14:04:40.757229
EP Flags : peer-aged|IP|sclass|timer|
::::

​ Ausgabeprüfung:

• Die VRF-VNID wird eingetragen - dies ist die VNID, die zur Kapselung des Frames in VXLAN in der Fabric verwendet wird.
• Die MAC-Adresse lautet 0000.0000.0000, da diese niemals in einen Remote-IP-Eintrag eingefügt wird.
• BD-VNID ist unbekannt, da für geroutete Frames das Eingangs-Leaf als Router fungiert und eine MAC-Adresse umschreibt. Das bedeutet, dass der Remote-Leaf keinen Einblick in den BD des Ziels, sondern nur in die VRF-Instanz erhält.

Der Frame wird nun in einen VXLAN-Frame gekapselt, der an die entfernte TEP 10.0.96.66 mit der VXLAN-ID 2097154 weitergeleitet wird. Dies ist die VNID der VRF-Instanz. Er wird in der Overlay-1-Routing-Tabelle (IS-IS-Route) geroutet und erreicht den Ziel-TEP. Hier erreicht er entweder leaf3 oder leaf4, da 10.0.96.66 die Anycast-TEP-Adresse des leaf3- und leaf4-VPC-Paares ist.

Quell-IP-Learning auf dem Ausgangs-Leaf

Die Ausgaben hier stammen von Leaf3, wären auf Leaf4 jedoch ähnlich. Wenn Pakete Leaf3 (Ziel-Leaf und Eigentümer der TEP) erreichen, erfährt das Leaf die Quell-IP des Pakets in der VRF-Instanz.

leaf3# show endpoint ip 10.1.1.1
Legend:
s - arp              H - vtep             V - vpc-attached     p - peer-aged
R - peer-attached-rl B - bounce           S - static           M - span
D - bounce-to-proxy  O - peer-attached    a - local-aged       m - svc-mgr
L - local            E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+
     VLAN/                           Encap           MAC Address       MAC Info/       Interface
     Domain                          VLAN            IP Address        IP Info
+-----------------------------------+---------------+-----------------+--------------+-------------+
Prod:VRF1                                                    10.1.1.1 p                    tunnel26

leaf3# show interface tunnel 26
Tunnel26 is up
   MTU 9000 bytes, BW 0 Kbit
   Transport protocol is in VRF "overlay-1"
   Tunnel protocol/transport is ivxlan
   Tunnel source 10.0.88.91/32 (lo0)
   Tunnel destination 10.0.88.95
   Last clearing of "show interface" counters never
   Tx
   0 packets output, 1 minute output rate 0 packets/sec
   Rx
   0 packets input, 1 minute input rate 0 packets/sec

Das Ziel TEP 10.0.88.95 ist die TEP-Adresse von leaf1 und wird über alle Uplinks zu Spine erfasst.

Ziel-IP-Suche auf Ausgangs-Leaf

Der letzte Schritt besteht darin, dass das Ausgangs-Leaf die Ziel-IP sucht. Sehen Sie sich die Endpunkttabelle für 10.1.2.1 an.

Daraus ergeben sich folgende Informationen:

• Der Egress-Leaf kennt das Ziel 10.1.2.1 (ähnlich einer /32-Host-Route in der Routing-Tabelle), und die Route wird in der richtigen VRF-Instanz empfangen.
• Der Egress-Leaf kennt die MAC-Adresse 0000.1001.0201 (Endpunktinformationen).
• Der Egress-Leaf weiß, dass der an 10.1.2.1 gerichtete Datenverkehr in VLAN-2502 gekapselt und an Port-Channel 1 (po1) gesendet werden muss.

leaf3# show endpoint ip 10.1.2.1
Legend:
s - arp              H - vtep             V - vpc-attached     p - peer-aged
R - peer-attached-rl B - bounce           S - static           M - span
D - bounce-to-proxy  O - peer-attached    a - local-aged       m - svc-mgr
L - local            E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+
     VLAN/                           Encap           MAC Address       MAC Info/       Interface
     Domain                          VLAN            IP Address        IP Info
+-----------------------------------+---------------+-----------------+--------------+-------------+
2                                         vlan-2502    0000.1001.0201 LpV                       po1
Prod:VRF1                                 vlan-2502          10.1.2.1 LpV                       po1

fTriage folgt dem Datenpfad

Verwenden Sie fTriage im APIC, um den Datenpfad-Fluss zu verfolgen. Vergessen Sie nicht, fTriage verlässt sich auf ELAM und benötigt daher einen echten Datenfluss. Dies ermöglicht die Bestätigung des vollständigen Datenpfads mit der Bestätigung, dass das Paket die Fabric an Leaf3-Port 1/16 verlässt.

apic1# ftriage route -ii LEAF:101 -sip 10.1.1.1 -dip 10.1.2.1
fTriage Status: {"dbgFtriage": {"attributes": {"operState": "InProgress", "pid": "6888", "apicId": "1", "id": "0"}}}
Starting ftriage
Log file name for the current run is: ftlog_2019-10-01-21-17-54-175.txt
2019-10-01 21:17:54,179 INFO     /controller/bin/ftriage route -ii LEAF:101 -sip 10.1.1.1 -dip 10.1.2.1
2019-10-01 21:18:18,149 INFO     ftriage:     main:1165 Invoking ftriage with default password and default username: apic#fallback\\admin
2019-10-01 21:18:39,194 INFO     ftriage:     main:839  L3 packet Seen on bdsol-aci32-leaf1 Ingress: Eth1/3 Egress: Eth1/51 Vnid: 2097154
2019-10-01 21:18:39,413 INFO     ftriage:     main:242  ingress encap string vlan-2501
2019-10-01 21:18:39,419 INFO     ftriage:     main:271  Building ingress BD(s), Ctx
2019-10-01 21:18:41,240 INFO     ftriage:     main:294  Ingress BD(s) Prod:BD1
2019-10-01 21:18:41,240 INFO     ftriage:     main:301  Ingress Ctx: Prod:VRF1
2019-10-01 21:18:41,349 INFO     ftriage:   pktrec:490  bdsol-aci32-leaf1: Collecting transient losses snapshot for LC module: 1
2019-10-01 21:19:05,747 INFO     ftriage:     main:933  SIP 10.1.1.1 DIP 10.1.2.1
2019-10-01 21:19:05,749 INFO     ftriage:  unicast:973  bdsol-aci32-leaf1: <- is ingress node
2019-10-01 21:19:08,459 INFO     ftriage:  unicast:1215 bdsol-aci32-leaf1: Dst EP is remote
2019-10-01 21:19:09,984 INFO     ftriage:     misc:657  bdsol-aci32-leaf1: DMAC(00:22:BD:F8:19:FF) same as RMAC(00:22:BD:F8:19:FF)
2019-10-01 21:19:09,984 INFO     ftriage:     misc:659  bdsol-aci32-leaf1: L3 packet getting routed/bounced in SUG
2019-10-01 21:19:10,248 INFO     ftriage:     misc:657  bdsol-aci32-leaf1: Dst IP is present in SUG L3 tbl
2019-10-01 21:19:10,689 INFO     ftriage:     misc:657  bdsol-aci32-leaf1: RwDMAC DIPo(10.0.96.66) is one of dst TEPs ['10.0.96.66']
2019-10-01 21:20:56,148 INFO     ftriage:     main:622  Found peer-node bdsol-aci32-spine3 and IF: Eth2/1 in candidate list
2019-10-01 21:21:01,245 INFO     ftriage:     node:643  bdsol-aci32-spine3: Extracted Internal-port GPD Info for lc: 2
2019-10-01 21:21:01,245 INFO     ftriage:     fcls:4414 bdsol-aci32-spine3: LC trigger ELAM with IFS: Eth2/1 Asic :0 Slice: 0 Srcid: 32
2019-10-01 21:21:33,894 INFO     ftriage:     main:839  L3 packet Seen on bdsol-aci32-spine3 Ingress: Eth2/1 Egress: LC-2/0 FC-22/0 Port-1 Vnid: 2097154
2019-10-01 21:21:33,895 INFO     ftriage:   pktrec:490  bdsol-aci32-spine3: Collecting transient losses snapshot for LC module: 2
2019-10-01 21:21:54,487 INFO     ftriage:      fib:332  bdsol-aci32-spine3: Transit in spine
2019-10-01 21:22:01,568 INFO     ftriage:  unicast:1252 bdsol-aci32-spine3: Enter dbg_sub_nexthop with Transit inst: ig infra: False glbs.dipo: 10.0.96.66
2019-10-01 21:22:01,682 INFO     ftriage:  unicast:1417 bdsol-aci32-spine3: EP is known in COOP (DIPo = 10.0.96.66)
2019-10-01 21:22:05,713 INFO     ftriage:  unicast:1458 bdsol-aci32-spine3: Infra route 10.0.96.66 present in RIB
2019-10-01 21:22:05,713 INFO     ftriage:     node:1331 bdsol-aci32-spine3: Mapped LC interface: LC-2/0 FC-22/0 Port-1 to FC interface: FC-22/0 LC-2/0 Port-1
2019-10-01 21:22:10,799 INFO     ftriage:     node:460  bdsol-aci32-spine3: Extracted GPD Info for fc: 22
2019-10-01 21:22:10,799 INFO     ftriage:     fcls:5748 bdsol-aci32-spine3: FC trigger ELAM with IFS: FC-22/0 LC-2/0 Port-1 Asic :0 Slice: 2 Srcid: 24
2019-10-01 21:22:29,322 INFO     ftriage:  unicast:1774 L3 packet Seen on FC of node: bdsol-aci32-spine3  with Ingress: FC-22/0 LC-2/0 Port-1  Egress: FC-22/0 LC-2/0 Port-1 Vnid: 2097154
2019-10-01 21:22:29,322 INFO     ftriage:   pktrec:487  bdsol-aci32-spine3: Collecting transient losses snapshot for FC module: 22
2019-10-01 21:22:31,571 INFO     ftriage:     node:1339 bdsol-aci32-spine3: Mapped FC interface: FC-22/0 LC-2/0 Port-1 to LC interface: LC-2/0 FC-22/0 Port-1
2019-10-01 21:22:31,572 INFO     ftriage:  unicast:1474 bdsol-aci32-spine3: Capturing Spine  Transit pkt-type L3 packet on egress LC on Node: bdsol-aci32-spine3 IFS: LC-2/0 FC-22/0 Port-1
2019-10-01 21:22:31,991 INFO     ftriage:     fcls:4414 bdsol-aci32-spine3: LC trigger ELAM with IFS: LC-2/0 FC-22/0 Port-1 Asic :0 Slice: 1 Srcid: 0
2019-10-01 21:22:48,952 INFO     ftriage:  unicast:1510 bdsol-aci32-spine3: L3 packet Spine egress  Transit pkt Seen on bdsol-aci32-spine3 Ingress: LC-2/0 FC-22/0 Port-1 Egress: Eth2/3 Vnid: 2097154
2019-10-01 21:22:48,952 INFO     ftriage:   pktrec:490  bdsol-aci32-spine3: Collecting transient losses snapshot for LC module: 2
2019-10-01 21:23:50,748 INFO     ftriage:     main:622  Found peer-node bdsol-aci32-leaf3 and IF: Eth1/51 in candidate list
2019-10-01 21:24:05,313 INFO     ftriage:     main:839  L3 packet Seen on bdsol-aci32-leaf3 Ingress: Eth1/51 Egress: Eth1/12 (Po1) Vnid: 11365
2019-10-01 21:24:05,427 INFO     ftriage:   pktrec:490  bdsol-aci32-leaf3: Collecting transient losses snapshot for LC module: 1
2019-10-01 21:24:24,369 INFO     ftriage:     nxos:1404 bdsol-aci32-leaf3: nxos matching rule id:4326 scope:34 filter:65534
2019-10-01 21:24:25,698 INFO     ftriage:     main:522  Computed egress encap string vlan-2502
2019-10-01 21:24:25,704 INFO     ftriage:     main:313  Building egress BD(s), Ctx
2019-10-01 21:24:27,510 INFO     ftriage:     main:331  Egress Ctx Prod:VRF1
2019-10-01 21:24:27,510 INFO     ftriage:     main:332  Egress BD(s): Prod:BD2
2019-10-01 21:24:30,536 INFO     ftriage:  unicast:1252 bdsol-aci32-leaf3: Enter dbg_sub_nexthop with Local inst: eg infra: False glbs.dipo: 10.0.96.66
2019-10-01 21:24:30,537 INFO     ftriage:  unicast:1257 bdsol-aci32-leaf3: dbg_sub_nexthop invokes dbg_sub_eg for vip
2019-10-01 21:24:30,537 INFO     ftriage:  unicast:1784 bdsol-aci32-leaf3: <- is egress node
2019-10-01 21:24:30,684 INFO     ftriage:  unicast:1833 bdsol-aci32-leaf3: Dst EP is local
2019-10-01 21:24:30,685 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: EP if(Po1) same as egr if(Po1)
2019-10-01 21:24:30,943 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: Dst IP is present in SUG L3 tbl
2019-10-01 21:24:31,242 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: RW seg_id:11365 in SUG same as EP segid:11365
2019-10-01 21:24:37,631 INFO     ftriage:     main:961  Packet is Exiting fabric with peer-device: bdsol-aci32-n3k-3 and peer-port: Ethernet1/12

Paketerfassung auf dem Ausgangs-Leaf mithilfe der ELAM Assistant-Anwendung

Unten sehen Sie das Paket, das mit der ELAM Assistant-App auf Leaf 3 vom Spine erfasst wurde. Dies zeigt Folgendes:

• Die VNID aus den Layer-4-Informationen auf dem Äußeren (VNID: 2097154).
• Äußere L3-Header-Quelle TEP und Ziel-TEP.

ELAM Assistant - L3-Flow-Ausgangsseite (Teil 1)

ELAM Assistant - L3-Flow-Ausgangsseite (Teil 2)

Der Abschnitt "Packet Forwarding Information" (Paketweiterleitungsinformationen) belegt, dass das Gerät auf Port-Channel 1 ausgeführt wurde.

ELAM Assistant - L3-Ausgangs-Leaf - Paketweiterleitungsinformationen

Fehlerbehebungs-Workflow für unbekannte Endgeräte

Dieser Abschnitt zeigt, was sich unterscheidet, wenn der Eingangs-Leaf die Ziel-IP-Adresse nicht kennt.

IP-Zielsuche für Eingangs-Leaf

Der erste Schritt besteht darin, zu überprüfen, ob ein Endpunkt vorhanden ist, der für die Ziel-IP-Adresse gelernt wurde.

leaf1# show endpoint ip 10.1.2.1
Legend:
s - arp              H - vtep             V - vpc-attached     p - peer-aged
R - peer-attached-rl B - bounce           S - static           M - span
D - bounce-to-proxy  O - peer-attached    a - local-aged       m - svc-mgr
L - local            E - shared-service
+-----------------------------------+---------------+-----------------+--------------+------------+
     VLAN/                           Encap           MAC Address       MAC Info/       Interface
     Domain                          VLAN            IP Address        IP Info
+-----------------------------------+---------------+-----------------+--------------+------------+   
<NO ENTRY>

Die Endpunkttabelle enthält für das Ziel nichts. Der nächste Schritt besteht daher darin, die Routing-Tabelle auf der Suche nach der Route mit der längsten Präfixübereinstimmung zum Ziel zu überprüfen:

leaf1# show ip route 10.1.2.1 vrf Prod:VRF1
IP Route Table for VRF "Prod:VRF1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.1.2.0/24, ubest/mbest: 1/0, attached, direct, pervasive
   *via 10.0.8.65%overlay-1, [1/0], 01:40:18, static, tag 4294967294
        recursive next hop: 10.0.8.65/32%overlay-1

Wenn der Frame in das /24-BD-Subnetz 10.1.2.0/24 fällt, kapselt das Leaf den Frame in VXLAN mit dem Ziel TEP 10.0.8.65 (Anycast-v4 auf Spine). Der Frame verwendet eine VXLAN-ID, die der VRF-VNID entspricht.

COOP-Suche auf Spine - Ziel-IP ist bekannt

Das Paket erreicht einen der Spines, der die COOP-Suche in der IP-Datenbank durchführt. Die Quelle muss überprüft werden, und die Ziel-IP-Adresse muss korrekt aus der COOP-Datenbank abgerufen werden.

Um eine IP-Adresse in der COOP-Datenbank zu finden, ist der Schlüssel die VRF-VNID (in diesem Beispiel 2097154).

Aus der unten stehenden Ausgabe wird bestätigt, dass die COOP-Datenbank den Eintrag für die Quell-IP aus TEP 10.0.88.95 (leaf1) korrekt enthält.

spine1# show coop internal info ip-db key 2097154 10.1.1.1
IP address : 10.1.1.1
Vrf : 2097154
Flags : 0
EP bd vnid : 15302583
EP mac :  00:00:10:01:01:01
Publisher Id : 10.0.88.95
Record timestamp : 10 01 2019 14:16:50 522482647
Publish timestamp : 10 01 2019 14:16:50 532239332
Seq No: 0
Remote publish timestamp: 01 01 1970 00:00:00 0
URIB Tunnel Info
Num tunnels : 1
       Tunnel address : 10.0.88.95
       Tunnel ref count : 1

Die folgende Ausgabe zeigt, dass die COOP-Datenbank den Eintrag für die Ziel-IP-Adresse aus TEP 10.0.96.66 (Anycast TEP des Leaf3- und 4-VPC-Paares) korrekt enthält

spine1# show coop internal info ip-db key 2097154 10.1.2.1
IP address : 10.1.2.1
Vrf : 2097154
Flags : 0
EP bd vnid : 15957974
EP mac :  00:00:10:01:02:01
Publisher Id : 10.0.88.90
Record timestamp : 10 01 2019 14:52:52 558812544
Publish timestamp : 10 01 2019 14:52:52 559479076
Seq No: 0
Remote publish timestamp: 01 01 1970 00:00:00 0
URIB Tunnel Info
Num tunnels : 1
       Tunnel address : 10.0.96.66
       Tunnel ref count : 1

In diesem Szenario kennt COOP die Ziel-IP-Adresse, sodass die Ziel-IP-Adresse des äußeren IP-Headers im VXLAN-Paket in 10.0.96.66 umgeschrieben und dann an Leaf3 oder Leaf4 gesendet wird (je nach ECMP-Hashing). Beachten Sie, dass die Quell-IP-Adresse des VXLAN-Frames nicht geändert wird und es sich daher weiterhin um die Leaf1-PTEP handelt.

COOP-Suche für Spine - Ziel-IP ist unbekannt

Wenn der COOP-Eintrag für die Ziel-IP-Adresse nicht ausgefüllt wird (stummer Endpunkt oder veraltet), generiert der Spine einen ARP-Glean, um ihn aufzulösen. Weitere Informationen finden Sie im Abschnitt "Multi-Pod Forwarding".

ACI-Weiterleitungszusammenfassung

In der folgenden Zeichnung ist die ACI-Weiterleitung für den Anwendungsfall "Layer 2" und "Layer 3" zusammengefasst.