Inhalt

Einleitung

Hintergrundinformationen

Überblick

Topologie

GUI-Prüfung

Fehlerbehebungs-Workflow für bekannten Layer-2-Unicast-Datenverkehr

Ingress-Leaf-Quelle EP-MAC-Learning

MAC-Endpunktsuche des Eingangs-Leaf-Ziels

Eingangs-Leaf-Switch wird an Spine-Switch gesendet

Spine Forwarding

Remote-EP-MAC-Learning am Ausgangs-Leaf

MAC-Zielsuche am Ausgangs-Leaf

Validierung, dass beide Endpunkte im COOP EP-Repo des Spine-Switches richtig erkannt wurden

ELAM-Ausgabe mit ELAM Assistant

ELAM des Eingangs-Leafs mit CLI

Verwenden von fTriage, um den Fluss zu verfolgen

Fehlerbehebungs-Workflow für unbekannten Layer-2-Unicast-Datenverkehr - BD im Flood-Modus

BD GIPo suchen

ELAM — Eingangs-Leaf — Flutverkehr

Zeichnen der FTAG-Topologie

ELAM — Egress-Leaf — Flutverkehr

Workflow zur Fehlerbehebung für unbekannten Layer-2-Unicast-Datenverkehr - BD im Hardware-Proxy

Layer-2-Weiterleitungszusammenfassung

ACI Fabric Layer 2 - Weiterleitungsverhalten

Einleitung

In diesem Dokument werden die Schritte zum Verständnis und zur Fehlerbehebung von Layer-2-Weiterleitung in der ACI beschrieben.

Hintergrundinformationen

Das Material aus diesem Dokument wurde aus dem Fehlerbehebung: Cisco Application Centric Infrastructure, Second Edition Buch, insbesondere das Fabric-interne Weiterleitung - L2-Weiterleitung: zwei Endpunkte im selben BD - kein Unicast-Routing Kapitel.

Überblick

In diesem Abschnitt wird ein Beispiel für die Fehlerbehebung erläutert, bei dem Endpunkte in derselben Bridge-Domäne und demselben Subnetz nicht miteinander kommunizieren können. Die folgende Abbildung zeigt die Topologie, in der das BD keine Subnetze hat und das Unicast-Routing deaktiviert ist.

In der Regel wird bei der Fehlerbehebung von Datenverkehrsflüssen mit Endgeräteverbindungen vorgeschlagen, ein Endgerätepaar zu identifizieren. Verweisen Sie auf die Topologie unten mit den EPs A und B. Diese weisen die IP-Adressen 10.1.1.1/24 und 10.1.1.2/24 auf. Die MAC-Adressen sind 00:00:10:01:01:01 und 00:00:10:01:01:02.

Topologie

In diesem Abschnitt gibt es drei Szenarien:

1. Bekannter Layer-2-Unicast-Fluss

2. Unbekannter Layer-2-Unicast-Fluss mit BD im Flood-Modus.

3. Unbekannter Layer-2-Unicast-Fluss mit BD im Hardware-Proxy-Modus.

Die Fehlerbehebungsabläufe, die befolgt werden, können im folgenden Schema zusammengefasst werden:

- Prüfung der Stufe 1: GUI-Validierung der erfassten Konfiguration, Fehler und Endpunkte

- Prüfung der Stufe 2: CLI der Leaf-Switches:

- Überprüfen Sie, ob die Quell- und Ziel-Leaf-Switches die Endpunkte erkennen.

- Überprüft, ob Spine-Knoten den Endpunkt in COOP erkennen.

- Prüfung der Stufe 3: Paketerfassung:

- ELAM (ELAM Assistant oder CLI) zum Validieren des vorhandenen Frames

- fTriage, um den Fluss zu verfolgen.

GUI-Prüfung

Die erste Stufe der Fehlerbehebung besteht darin, über die GUI zu überprüfen, ob die Endpunkt-MAC-Adresse korrekt angegeben wurde. Dies kann über die Registerkarte "Operational" (Betrieb) der EPG erfolgen, auf der sich der Endpunkt befindet.

Registerkarte "EPG-Betrieb" > Client-Endpunkte

In diesem Szenario werden beide Endpunkte A und B in der grafischen Benutzeroberfläche angezeigt. Die GUI zeigt ihre MAC-Adressen, die Schnittstelle, über die sie mit der Fabric verbunden sind, und die Kapselung an - in diesem Fall befinden sich beide im Encap-VLAN 2501.

Es wird erwartet, dass die IP-Adresse nicht von der ACI-Fabric abgerufen wird, da das Unicast-Routing auf BD-Ebene deaktiviert wurde.

Weitere Informationen finden Sie in der Spalte mit den Lernquellen im obigen Screenshot. Wenn es "gelernt" bedeutet, hat der ACI-Leaf-Switch mindestens ein Paket vom Endpunkt empfangen.

Da in diesem Fall die Endpunkte von der ACI-Fabric übernommen werden, fahren Sie mit dem nächsten Fehlerbehebungsfall für bekannten Layer-2-Unicast-Datenverkehr fort.

Fehlerbehebungs-Workflow für bekannten Layer-2-Unicast-Datenverkehr

Ingress-Leaf-Quelle EP-MAC-Learning

Im Fall einer Layer-2-Weiterleitung im selben BD erfasst die ACI nur die Quell-MAC und leitet diese basierend auf der Ziel-MAC weiter. MAC-Adressen werden im Umfang des BD erfasst.

Überprüfen Sie zunächst, ob der Endpunkt erkannt wurde:

leaf1# show endpoint  mac  0000.1001.0101

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

+-----------------------------------+---------------+-----------------+--------------+-------------+

4/Prod:VRF1                               vlan-2501    0000.1001.0101 L                      eth1/3

Die obige Ausgabe enthält die folgenden Informationen:

- Die MAC-Adresse 0000.1001.0101 wird lokal gelernt (Flag ist L für lokal) auf Port-Ethernet 1/3 mit Kapselung VLAN-2501 in vrf Prod:VRF1.

- Siehe Spalte "VLAN/Domain" in der obigen Ausgabe. Die dort aufgeführte VLAN-ID ist das interne VLAN.

MAC-Endpunktsuche des Eingangs-Leaf-Ziels

Angenommen, die Ziel-MAC-Adresse ist bekannt (bekannter Unicast).

leaf1# show endpoint mac 0000.1001.0102

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

+-----------------------------------+---------------+-----------------+--------------+-------------+

7/Prod:VRF1                          vxlan-16351141    0000.1001.0102                       tunnel4

Die obige Ausgabe enthält die folgenden Informationen:

- Die MAC-Adresse 0000.1001.0102 wird nicht lokal erfasst.

- Sie wird vom Schnittstellentunnel 4 gelernt.

- Sie wird in der Kapselung VXLAN-16351141 gelernt, die der BD_VNID (VXLAN-Netzwerk-ID) der Bridge-Domäne entspricht.

Überprüfen Sie anschließend das Ziel der Tunnelschnittstelle mit dem Befehl 'show interface tunnel <x>'.

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

Das Paket wird also in VXLAN mit der Quell-TEP-IP 10.0.88.95 (zugewiesen an loopback0) gekapselt und an die Ziel-TEP-IP 10.0.96.66 gesendet.

Quell-IP bestätigen:

leaf1# show ip interface loopback 0 vrf overlay-1

IP Interface Status for VRF "overlay-1"

lo0, Interface status: protocol-up/link-up/admin-up, iod: 4, mode: ptep

IP address: 10.0.88.95, IP subnet: 10.0.88.95/32

IP broadcast address: 255.255.255.255

IP primary address route-preference: 0, tag: 0

Die Ziel-TEP-IP-Adresse 10.0.96.66 kann eine der folgenden sein:

- PTEP-Adresse eines anderen Blattes (kann mit acidiag fnvread überprüft werden)

- VPC-VIP (siehe "GUI > Fabric > Access Policies > Policies > Switch > Virtual Port Channel default" (siehe Screenshot unten)

- Einige Loopback-IPs auf einem Spine-Switch. Verwenden Sie den Befehl "show ip interface vrf overlay-1" auf dem Spine-Switch, um dies zu überprüfen.

Explizite VPC-Schutzgruppen

Eingangs-Leaf-Switch wird an Spine-Switch gesendet

Der Eingangs-Leaf kapselt den Frame jetzt in VXLAN, wobei die äußere Ziel-IP auf 10.0.96.66 festgelegt ist. Dies ist die Tunnelziel-IP, die im vorherigen Befehl "show interface tunnel 4" aufgeführt ist. Es kapselt es in VXLAN mit der VNID der Bridge-Domäne - vxlan-16351141 - wie in der vorherigen Befehlsausgabe "show endpoint mac 0000.1001.0102" gezeigt.

Legen Sie basierend auf der IS-IS-Route in VRF-Overlay-1 fest, wohin die Nachricht gesendet werden soll:

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], 2w5d, isis-isis_infra, isis-l1-int

*via 10.0.88.94, Eth1/50.128, [115/3], 2w5d, isis-isis_infra, isis-l1-int

Daher erfolgt ECMP-Routing (Equal Cost Multipath) zum Ziel mit eth1/49 und 1/50, den Fabric-Uplinks zu den Spine-Switches.

Spine Forwarding

Die VRF-Overlay-1-Routing-Tabelle auf dem Spine zeigt, dass die Host-Route 10.0.96.66 entweder über Leaf3 oder Leaf4 erreichbar ist. Dies wird erwartet, da 10.0.96.66 die VPC-VIP der Leaf-Switches 103 und 104 ist:

spine1# 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: 2/0

*via 10.0.88.91, eth1/3.35, [115/2], 02w05d, isis-isis_infra, isis-l1-int

*via 10.0.88.90, eth1/4.39, [115/2], 02w05d, isis-isis_infra, isis-l1-int

spine1# show lldp neighbors | egrep "1\/3 |1\/4 "

leaf3             Eth1/3          120        BR          Eth1/49

leaf4             Eth1/4          120        BR          Eth1/49

Remote-EP-MAC-Learning am Ausgangs-Leaf

In diesem Fall ist die Ziel-TEP ein vPC-Paar, sodass das Paket entweder auf Leaf3 oder Leaf4 ankommt. Weitere Informationen finden Sie in den Befehlsausgaben unten. Leaf4 sollte eine ähnliche Ausgabe zeigen. Da sie Teil desselben VPC-Paares sind, werden alle Endpunkte zwischen den beiden Leaf-Switches synchronisiert.

Das Endpunkt-Learning für Layer-2-Datenverkehr auf dem Ausgangs-Leaf basiert auf der Quell-MAC-Adresse, die im BD entsprechend der VNID im empfangenen Paket erfasst wird. Dies kann in der Endpunkttabelle überprüft werden.

Die Quell-MAC-Adresse befindet sich hinter Tunnel 26 in VXLAN-16351141.

Tunnel 26 führt zu TEP IP 10.0.88.95, das Leaf 1 ist:

leaf3# show endpoint  mac 0000.1001.0101

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

+-----------------------------------+---------------+-----------------+--------------+-------------+

136/Prod:VRF1                        vxlan-16351141    0000.1001.0101                      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

leaf3# acidiag fnvread | egrep "10.0.88.95"

101        1                leaf1      FDO20160TPA      10.0.88.95/32    leaf         active   0

MAC-Zielsuche am Ausgangs-Leaf

Mit dem Befehl "show endpoint" wird bestätigt, dass die Ziel-MAC-Adresse hinter Port-Channel 1 gelernt wird und das Kapselungs-VLAN 2501 verwendet.

leaf3# show endpoint mac 0000.1001.0102

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

+-----------------------------------+---------------+-----------------+--------------+-------------+

135/Prod:VRF1                             vlan-2501    0000.1001.0102 LpV                       po1

Dies bedeutet, dass der Frame die ACI-Fabric auf dem Leaf 3-Schnittstellen-Port-Channel 1 mit der Encap-VLAN-ID 2501 verlässt. Die BD VNID finden Sie in der GUI auf der Registerkarte "Tenant Operational" (Tenant-Betrieb).

Validierung, dass beide Endpunkte im COOP EP-Repo des Spine-Switches richtig erkannt wurden

Das COOP EP-Repo sollte über alle Spine-Knoten hinweg synchronisiert werden. Das COOP EP-Repo kann mithilfe der BD-VNID als Schlüssel überprüft und die EP-MAC-Adresse eingegeben werden.

Die Quell-MAC-Adresse dieses Datenflusses wird vom nächsten Tunnel-Hop 10.0.88.95 abgerufen, der die TEP-IP von leaf1 darstellt. Außerdem wird in der Befehlsausgabe die VNID 16351141 angezeigt, die der richtigen Bridge-Domäne entspricht.

spine1# show coop internal info repo ep key 16351141 00:00:10:01:01:01

Repo Hdr Checksum : 24197

Repo Hdr record timestamp : 10 01 2019 10:16:50 278195866

Repo Hdr last pub timestamp : 10 01 2019 10:16:50 283699467

Repo Hdr last dampen timestamp : 01 01 1970 00:00:00 0

Repo Hdr dampen penalty : 0

Repo Hdr flags : IN_OBJ EXPORT ACTIVE

EP bd vnid : 16351141

EP mac :  00:00:10:01:01:01

flags : 0x80

repo flags : 0x122

Vrf vnid : 2097154

Epg vnid : 0

EVPN Seq no : 0

Remote publish timestamp: 01 01 1970 00:00:00 0

Snapshot timestamp: 10 01 2019 10:16:50 278195866

Tunnel nh : 10.0.88.95

MAC Tunnel  : 10.0.88.95

IPv4 Tunnel : 10.0.88.95

IPv6 Tunnel : 10.0.88.95

ETEP Tunnel : 0.0.0.0

Die Ziel-MAC dieses Flows wird anhand der VPC-VIP 10.0.96.66 von leaf3 und leaf4 ermittelt. Außerdem wird die EP BD VNID 16351141 aufgelistet, die dem richtigen BD entspricht.

spine1# show coop internal info repo ep key 15302583 00:00:10:01:01:02

Repo Hdr Checksum : 16897

Repo Hdr record timestamp : 10 01 2019 11:05:46 351360334

Repo Hdr last pub timestamp : 10 01 2019 11:05:46 352019546

Repo Hdr last dampen timestamp : 01 01 1970 00:00:00 0

Repo Hdr dampen penalty : 0

Repo Hdr flags : IN_OBJ EXPORT ACTIVE

EP bd vnid : 16351141

EP mac :  00:00:10:01:01:02

flags : 0x90

repo flags : 0x122

Vrf vnid : 2097154

Epg vnid : 0

EVPN Seq no : 0

Remote publish timestamp: 01 01 1970 00:00:00 0

Snapshot timestamp: 10 01 2019 11:05:46 351360334

Tunnel nh : 10.0.96.66

MAC Tunnel  : 10.0.96.66

IPv4 Tunnel : 10.0.96.66

IPv6 Tunnel : 10.0.96.66

ETEP Tunnel : 0.0.0.0

ELAM-Ausgabe mit ELAM Assistant

ELAM Assistant ist eine leistungsstarke ACI-Anwendung, die die Ausführung von ELAM-Erfassungen in einer ACI-Fabric vereinfachen kann.

ELAM Assistant-Trigger können gleichzeitig auf mehreren Leaf-Knoten gestartet werden. Dadurch können bestimmte Pakete in Leaf1, Leaf3 und Leaf4 parallel geprüft werden.

Die konfigurierte ELAM-Erfassung wird wie unten gezeigt angezeigt. Wie beobachtet, ist das Paket auf Leaf1 (Knoten-101) und Leaf3 (Knoten-103) zu sehen.

ELAM Assistant — Parameter

Der Bericht von leaf1 (node-101) zeigt Folgendes:

- Die Ausgabe der erfassten Paketinformationen bestätigt, dass das Paket eth1/3 eingibt und über die richtigen MAC- und IP-Informationen verfügt.

- Die Paketweiterleitungsinformationen zeigen an, dass es auf eth1/49 an TEP IP 10.0.96.66 weitergeleitet wird.

ELAM Assistant — Leaf1 (Knoten-101) — erfasste Paketinformationen

ELAM Assistant — Leaf1 (Knoten-101) — Paketweiterleitungsinformationen

Auf Leaf3 (Node-103) auf dem Egress-Leaf wird Folgendes beobachtet:

In die erfassten Paketinformationen auf Leaf3 gibt es eth1/49 ein. Die äußere IP-Adresse bestätigt Folgendes:

- Quell-TEP: 10.0.88.95

- Ziel-TEP: 10.0.96.66

- VNID: 16351141 (BD VNID)

ELAM Assistant — Leaf3 (Knoten-103) — erfasste Paketinformationen

Die Paketweiterleitungsinformationen zeigen, dass der Datenverkehr auf Port-Channel 1 und insbesondere Ethernet 1/12 weitergeleitet wird.

ELAM des Eingangs-Leafs mit CLI

Es wird empfohlen, ELAM Assistant zu verwenden, da dies den Betrieb von ELAM-Erfassungen vereinfacht. Sie können jedoch auch CLI-Befehle auf ACI-Switches verwenden, um einen ELAM-Bericht zu generieren. Im Folgenden finden Sie ein Beispiel dafür, wie dies geschehen würde.

Verwenden Sie die dargestellte Trigger-Sequenz, um das Paket auf dem Eingangs-Leaf zu erfassen. Weitere Informationen zu den ELAM-Optionen finden Sie im Abschnitt "Tools".

- In diesem Beispiel ist der ASIC 'tah' als Leaf (Teilenummer endet '-EX').

- 'in-select 6' wird verwendet, um ein Paket zu erfassen, das von einem Downlink-Port ohne VXLAN-Encap stammt.

- 'out-select 1' stellt sicher, dass der Drop-Vektor ebenfalls angezeigt wird (bei Paketverlust).

- Der Befehl 'reset' wird benötigt, um sicherzustellen, dass alle vorherigen Trigger bereinigt wurden.

- Obwohl es sich um einen Bridge-Flow handelt, bietet ELAM Transparenz für den IP-Header.

- Daher können 'ipv4 src_ip' und 'dst_ip' verwendet werden, um den Trigger einzurichten.

module-1# debug platform internal tah elam asic 0

module-1(DBG-elam)# trigger init in-select ?

10  Outerl4-innerl4-ieth

13  Outer(l2|l3|l4)-inner(l2|l3|l4)-noieth

14  Outer(l2(vntag)|l3|l4)-inner(l2|l3|l4)-ieth

15  Outer(l2|l3|l4)-inner(l2|l3|l4)-ieth

6   Outerl2-outerl3-outerl4

7   Innerl2-innerl3-innerl4

8   Outerl2-innerl2-ieth

9   Outerl3-innerl3

module-1(DBG-elam)# trigger init in-select 6 out-select 1

module-1(DBG-elam-insel6)# reset

module-1(DBG-elam-insel6)# set outer ipv4 src_ip 10.1.1.1 dst_ip 10.1.1.2

module-1(DBG-elam-insel6)# start

Um festzustellen, ob das Paket empfangen wurde, überprüfen Sie den ELAM-Status. Wenn ein Trigger vorliegt, bedeutet dies, dass ein Paket, das mit den Bedingungen übereinstimmt, abgefangen wurde.

module-1(DBG-elam-insel6)# status

ELAM STATUS

===========

Asic 0 Slice 0 Status Triggered

Asic 0 Slice 1 Status Armed

Die nächste Ausgabe zeigt, dass der Bericht mit dem Befehl "report" angezeigt wird. Die Ausgabe ist sehr lang, daher wird hier nur der Anfang eingefügt. Beachten Sie jedoch, dass der vollständige Bericht zur späteren Analyse an einer Stelle im Leaf-Dateisystem gespeichert wird. Der Dateiname enthält auch die Zeitstempel, nach denen die ELAM übernommen wurde.

leaf1# ls -al /var/log/dme/log/elam_2019-09-30-03m-23h-14s.txt

-rw-rw-rw- 1 root root 699106 Sep 30 23:03 /var/log/dme/log/elam_2019-09-30-03m-23h-14s.txt

Der Bericht validiert, ob das Paket empfangen wurde und die Informationen den Erwartungen entsprechen (Quell- und Ziel-MAC-Adresse, Quell- und Ziel-IP-Adresse usw.).

module-1(DBG-elam-insel6)# ereport

Python available. Continue ELAM decode with LC Pkg

ELAM REPORT

===========================================================================================================

Trigger/Basic Information

===========================================================================================================

ELAM Report File                        : /tmp/logs/elam_2019-09-30-03m-23h-14s.txt

In-Select Trigger                       : Outerl2-outerl3-outerl4( 6 )

Out-Select Trigger                      : Pktrw-sideband-drpvec( 1 )

ELAM Captured Device                    : LEAF

Packet Direction                        : ingress

Triggered ASIC type                     : Sugarbowl

Triggered ASIC instance                 : 0

Triggered Slice                         : 0

Incoming Interface                      : 0x24( 0x24 )

( Slice Source ID(Ss) in "show plat int hal l2 port gpd" )

===========================================================================================================

Captured Packet

-----------------------------------------------------------------------------------------------------------

Outer Packet Attributes

-----------------------------------------------------------------------------------------------------------

Outer Packet Attributes       : l2uc ipv4 ip ipuc ipv4uc

Opcode                        : OPCODE_UC

-----------------------------------------------------------------------------------------------------------

Outer L2 Header

-----------------------------------------------------------------------------------------------------------

Destination MAC               : 0000.1001.0102

Source MAC                    : 0000.1001.0101

802.1Q tag is valid           : yes( 0x1 )

CoS                           : 0( 0x0 )

Access Encap VLAN             : 2501( 0x9C5 )

-----------------------------------------------------------------------------------------------------------

Outer L3 Header

-----------------------------------------------------------------------------------------------------------

L3 Type                       : IPv4

IP Version                    : 4

DSCP                          : 0

IP Packet Length              : 84 ( = IP header(28 bytes) + IP payload )

Don't Fragment Bit            : not set

TTL                           : 255

IP Protocol Number            : ICMP

IP CheckSum                   : 51097( 0xC799 )

Destination IP                : 10.1.1.2

Source IP                     : 10.1.1.1

===========================================================================================================

Forwarding Lookup ( FPB )

===========================================================================================================

-----------------------------------------------------------------------------------------------------------

Destination MAC (Lookup Key)

-----------------------------------------------------------------------------------------------------------

Dst MAC Lookup was performed            : yes

Dst MAC Lookup BD                       : 522( 0x20A )

( Hw BDID in "show plat int hal l2 bd pi" )

Dst MAC Address                         : 0000.1001.0102

-----------------------------------------------------------------------------------------------------------

Destination MAC (Lookup Result)

-----------------------------------------------------------------------------------------------------------

Dst MAC is Hit                          : yes

Dst MAC is Hit Index                    : 6443( 0x192B )

( phy_id in "show plat int hal objects ep l2 mac (MAC) extensions" )

or ( HIT IDX in "show plat int hal l3 nexthops" for L3OUT/L3 EP)

.....

Verwenden von fTriage, um den Fluss zu verfolgen

fTriage wird von einer APIC-CLI aus ausgeführt und kann verwendet werden, um die ACI-Fabric vollständig zu durchlaufen. Geben Sie mindestens das Eingangs-Leaf (Node-101), die Quell-IP und die Ziel-IP an. In diesem speziellen Fall handelt es sich um einen überbrückten Fluss (Layer 2), daher ist die Option fTriage bridge zu verwenden.

Beachten Sie, dass fTriage eine Protokolldatei im aktuellen Verzeichnis generiert. Diese Protokolldatei enthält alle gesammelten Protokolle und ELAM-Berichte. Dadurch kann das Paket an jedem Hop erfasst werden. Die Kurzversion der Ausgabe ist unten aufgeführt:

apic1# ftriage bridge -ii LEAF:101 -sip 10.1.1.1 -dip 10.1.1.2

fTriage Status: {"dbgFtriage": {"attributes": {"operState": "InProgress", "pid": "12181", "apicId": "1", "id": "0"}}}

Starting ftriage

Log file name for the current run is: ftlog_2019-10-01-18-53-24-125.txt

2019-10-01 18:53:24,129 INFO     /controller/bin/ftriage bridge -ii LEAF:101 -sip 10.1.1.1 -dip 10.1.1.2

2019-10-01 18:53:49,280 INFO     ftriage:     main:1165 Invoking ftriage with default password and default username: apic#fallback\\admin

2019-10-01 18:54:10,204 INFO     ftriage:     main:839  L2 frame Seen on leaf1 Ingress: Eth1/3 Egress: Eth1/49 Vnid: 15302583

2019-10-01 18:54:10,422 INFO     ftriage:     main:242  ingress encap string vlan-2501

2019-10-01 18:54:10,427 INFO     ftriage:     main:271  Building ingress BD(s), Ctx

2019-10-01 18:54:12,288 INFO     ftriage:     main:294  Ingress BD(s) Prod:BD1

2019-10-01 18:54:12,288 INFO     ftriage:     main:301  Ingress Ctx: Prod:VRF1

2019-10-01 18:54:12,397 INFO     ftriage:   pktrec:490  leaf1: Collecting transient losses snapshot for LC module: 1

2019-10-01 18:54:30,079 INFO     ftriage:     main:933  SMAC 00:00:10:01:01:01 DMAC 00:00:10:01:01:02

2019-10-01 18:54:30,080 INFO     ftriage:  unicast:973  leaf1: <- is ingress node

2019-10-01 18:54:30,320 INFO     ftriage:  unicast:1215 leaf1: Dst EP is remote

2019-10-01 18:54:31,155 INFO     ftriage:     misc:659  leaf1: L2 frame getting bridged in SUG

2019-10-01 18:54:31,380 INFO     ftriage:     misc:657  leaf1: Dst MAC is present in SUG L2 tbl

2019-10-01 18:54:31,826 INFO     ftriage:     misc:657  leaf1: RwDMAC DIPo(10.0.96.66) is one of dst TEPs ['10.0.96.66']

2019-10-01 18:56:16,249 INFO     ftriage:     main:622  Found peer-node spine1 and IF: Eth1/1 in candidate list

2019-10-01 18:56:21,346 INFO     ftriage:     node:643  spine1: Extracted Internal-port GPD Info for lc: 1

2019-10-01 18:56:21,348 INFO     ftriage:     fcls:4414 spine1: LC trigger ELAM with IFS: Eth1/1 Asic :0 Slice: 0 Srcid: 32

2019-10-01 18:56:54,424 INFO     ftriage:     main:839  L2 frame Seen on spine1 Ingress: Eth1/1 Egress: LC-1/0 FC-24/0 Port-0 Vnid: 15302583

2019-10-01 18:56:54,424 INFO     ftriage:   pktrec:490  spine1: Collecting transient losses snapshot for LC module: 1

2019-10-01 18:57:15,093 INFO     ftriage:      fib:332  spine1: Transit in spine

2019-10-01 18:57:21,394 INFO     ftriage:  unicast:1252 spine1: Enter dbg_sub_nexthop with Transit inst: ig infra: False glbs.dipo: 10.0.96.66

2019-10-01 18:57:21,508 INFO     ftriage:  unicast:1417 spine1: EP is known in COOP (DIPo = 10.0.96.66)

2019-10-01 18:57:25,537 INFO     ftriage:  unicast:1458 spine1: Infra route 10.0.96.66 present in RIB

2019-10-01 18:57:25,537 INFO     ftriage:     node:1331 spine1: Mapped LC interface: LC-1/0 FC-24/0 Port-0 to FC interface: FC-24/0 LC-1/0 Port-0

2019-10-01 18:57:30,616 INFO     ftriage:     node:460  spine1: Extracted GPD Info for fc: 24

2019-10-01 18:57:30,617 INFO     ftriage:     fcls:5748 spine1: FC trigger ELAM with IFS: FC-24/0 LC-1/0 Port-0 Asic :0 Slice: 2 Srcid: 0

2019-10-01 18:57:49,611 INFO     ftriage:  unicast:1774 L2 frame Seen on FC of node: spine1  with Ingress: FC-24/0 LC-1/0 Port-0  Egress: FC-24/0 LC-1/0 Port-0 Vnid: 15302583

2019-10-01 18:57:49,611 INFO     ftriage:   pktrec:487  spine1: Collecting transient losses snapshot for FC module: 24

2019-10-01 18:57:53,110 INFO     ftriage:     node:1339 spine1: Mapped FC interface: FC-24/0 LC-1/0 Port-0 to LC interface: LC-1/0 FC-24/0 Port-0

2019-10-01 18:57:53,111 INFO     ftriage:  unicast:1474 spine1: Capturing Spine  Transit pkt-type L2 frame on egress LC on Node: spine1 IFS: LC-1/0 FC-24/0 Port-0

2019-10-01 18:57:53,530 INFO     ftriage:     fcls:4414 spine1: LC trigger ELAM with IFS: LC-1/0 FC-24/0 Port-0 Asic :0 Slice: 0 Srcid: 64

2019-10-01 18:58:26,497 INFO     ftriage:  unicast:1510 spine1: L2 frame Spine egress  Transit pkt Seen on spine1 Ingress: LC-1/0 FC-24/0 Port-0 Egress: Eth1/3 Vnid: 15302583

2019-10-01 18:58:26,498 INFO     ftriage:   pktrec:490  spine1: Collecting transient losses snapshot for LC module: 1

2019-10-01 18:59:28,634 INFO     ftriage:     main:622  Found peer-node leaf3 and IF: Eth1/49 in candidate list

2019-10-01 18:59:39,235 INFO     ftriage:     main:839  L2 frame Seen on leaf3 Ingress: Eth1/49 Egress: Eth1/12 (Po1) Vnid: 11364

2019-10-01 18:59:39,350 INFO     ftriage:   pktrec:490  leaf3: Collecting transient losses snapshot for LC module: 1

2019-10-01 18:59:54,373 INFO     ftriage:     main:522  Computed egress encap string vlan-2501

2019-10-01 18:59:54,379 INFO     ftriage:     main:313  Building egress BD(s), Ctx

2019-10-01 18:59:57,152 INFO     ftriage:     main:331  Egress Ctx Prod:VRF1

2019-10-01 18:59:57,153 INFO     ftriage:     main:332  Egress BD(s): Prod:BD1

2019-10-01 18:59:59,230 INFO     ftriage:  unicast:1252 leaf3: Enter dbg_sub_nexthop with Local inst: eg infra: False glbs.dipo: 10.0.96.66

2019-10-01 18:59:59,231 INFO     ftriage:  unicast:1257 leaf3: dbg_sub_nexthop invokes dbg_sub_eg for vip

2019-10-01 18:59:59,231 INFO     ftriage:  unicast:1784 leaf3: <- is egress node

2019-10-01 18:59:59,377 INFO     ftriage:  unicast:1833 leaf3: Dst EP is local

2019-10-01 18:59:59,378 INFO     ftriage:     misc:657  leaf3: EP if(Po1) same as egr if(Po1)

2019-10-01 18:59:59,378 INFO     ftriage:     misc:659  leaf3: L2 frame getting bridged in SUG

2019-10-01 18:59:59,613 INFO     ftriage:     misc:657  leaf3: Dst MAC is present in SUG L2 tbl

2019-10-01 19:00:06,122 INFO     ftriage:     main:961  Packet is Exiting fabric with peer-device: n3k-3 and peer-port: Ethernet1/16

Fehlerbehebungs-Workflow für unbekannten Layer-2-Unicast-Datenverkehr - BD im Flood-Modus

In diesem Beispiel ist die Ziel-MAC-Adresse unbekannt. Die Ziel-MAC-Suche auf dem Eingangs-Leaf zeigt keine Ausgabe an.

leaf1# show endpoint mac 0000.1001.0102

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

+-----------------------------------+---------------+-----------------+--------------+-------------+

Da BD für L2 Unknown Unicast auf "Flood" festgelegt ist, geschieht Folgendes auf hoher Ebene:

1. Der Eingangs-Leaf hasht den Paket-Header, um ihn einem der FTAGs zuzuweisen (von 0 bis 15).

2. Der Eingangs-Leaf kapselt den Frame in ein VXLAN-Paket mit der BD-VNID. Die äußere Ziel-IP-Adresse lautet BD GIPo + FTAG.

3. Er wird in der Fabric nach einer Baumtopologie geflutet und sollte jeden Leaf-Knoten erreichen, für den das BD bereitgestellt ist.

In diesem Abschnitt wird hervorgehoben, welche Optionen aktiviert werden können.

BD GIPo suchen

Die GUI identifiziert die vom BD für Datenverkehr mit mehreren Zielen verwendete Multicast-Gruppe 225.1.5.48.

BD-GIPo

ELAM — Eingangs-Leaf — Flutverkehr

Mit ELAM Assistant wird der ELAM-Bericht auf dem Eingangs-Leaf überprüft. Dies zeigt, dass der Frame im BD geflutet wurde und an allen Fabric-Uplinks ausfällt (hier eth1/49, 1/50,1/51 und 1/52).

ELAM Assistant - Eingangs-Leaf - Paketweiterleitungsinformationen

Den vom Eingangs-Leaf ausgewählten FTAG-Wert finden Sie im Rohbericht des ELAM-Assistenten.

sug_lu2ba_sb_info.mc_info.mc_info_nopad.ftag: 0xC

Wenn der Hexadezimalwert von 0xC in Dezimalzahl konvertiert wird, ergibt dies FTAG 12.

Zeichnen der FTAG-Topologie

Die FTAG-Topologie wird von IS-IS berechnet. Für jeden FTAG-Wert wird eine Baumtopologie mit einer Liste von Root- und Ausgabeschnittstellen erstellt, die eine optimale Lastverteilung ermöglicht.

Zeigen Sie die lokale FTAG-Topologie mit dem folgenden Befehl an. Im folgenden Beispiel wird die FTAG-ID 12-Topologie für Spine1 verwendet.

spine1# show isis internal mcast routes ftag

IS-IS process: isis_infra

VRF : default

FTAG Routes

====================================

FTAG ID:  12  [Enabled] Cost:(   2/  11/   0)

----------------------------------

Root port: Ethernet1/4.39

OIF List:

Ethernet1/11.11

Ethernet1/12.12

Die Erstellung der vollständigen FTAG-Topologie in einer großen ACI-Fabric kann sich als langwierige und komplexe Aufgabe erweisen. Das Python-Skript "aci-ftag-viewer" (https://github.com/agccie/aci-ftag-viewer) kann auf einen APIC kopiert werden. Es generiert die vollständige FTAG-Topologie des Fabric in einem Durchgang.

Die folgende Ausgabe zeigt den FTAG 12-Tree in Pod1 einer Multi-Pod-Struktur und enthält die FTAG-Topologie für die IPN-Geräte.

Dies zeigt, dass der Datenverkehr, der von Leaf101 in die ACI-Fabric eingeht, die folgenden Pfade durchläuft, wie in der unten stehenden Skriptausgabe aufgeführt.

admin@apic1:tmp> python aci_ftag_viewer.py --ftag 12 --pod 1

################################################################################

#  Pod 1 FTAG 12

#  Root spine-204

#  active nodes: 8, inactive nodes: 1

################################################################################

spine-204

+- 1/1 -------- 1/52 leaf-101

+- 1/2 -------- 1/52 leaf-102

+- 1/3 -------- 1/52 leaf-103

+- 1/4 -------- 1/52 leaf-104

+- 1/49 -------- 1/4 spine-201

|                      +- 1/11 ...... (EXT) Eth2/13 n7706-01-Multipod-A1

|                      +- 1/12 ...... (EXT) Eth2/9 n7706-01-Multipod-A2

|

+- 1/50 -------- 1/4 spine-202

|                      +- 1/11 ...... (EXT) Eth2/14 n7706-01-Multipod-A1

|                      +- 1/12 ...... (EXT) Eth2/10 n7706-01-Multipod-A2

|

+- 1/51 -------- 2/4 spine-203

+- 2/11 ...... (EXT) Eth2/15 n7706-01-Multipod-A1

+- 2/12 ...... (EXT) Eth2/11 n7706-01-Multipod-A2

+- 1/11 ...... (EXT) Eth2/16 n7706-01-Multipod-A1

+- 1/12 ...... (EXT) Eth2/12 n7706-01-Multipod-A2

ELAM — Egress-Leaf — Flutverkehr

In diesem Fall erreicht der Datenverkehr alle Leafs der ACI-Fabric. Er erreicht also sowohl Leaf 3 als auch Leaf 4, die das vPC-Paar darstellen. Beide Leaf-Knoten verfügen über eine vPC zum Ziel. Um doppelte Pakete zu vermeiden, wählt das vPC-Paar nur einen Leaf für die Weiterleitung des Datenverkehrs an das Ziel aus. Das gewählte Leaf wird als VPC DF-Leaf (VPC-designierter Forwarder-Leaf) bezeichnet.

Dies kann in ELAM mithilfe des folgenden Triggers auf beiden Leaf-Knoten überprüft werden.

module-1# debug platform internal tah elam asic 0

module-1(DBG-elam)# trigger reset

module-1(DBG-elam)# trigger init in-select 14 out-select 1

module-1(DBG-elam-insel14)# set inner ipv4 src_ip 10.1.1.1 dst_ip 10.1.1.2

module-1(DBG-elam-insel14)# start

Leaf3-Ausgabe:

module-1(DBG-elam-insel14)# ereport | egrep vpc.*df

sug_lub_latch_results_vec.lub4_1.vpc_df: 0x1

Leaf4-Ausgabe:

module-1(DBG-elam-insel14)# ereport | egrep vpc.*df

sug_lub_latch_results_vec.lub4_1.vpc_df: 0x0

In der obigen Ausgabe hat leaf3 den Wert '0x1' für das 'vpc_df'-Feld, wohingegen leaf4 den Wert '0x0' für das 'vpc_df'-Feld hat. Daher ist Leaf3 der designierte Forwarder. leaf3 leitet das geflutete Paket über seine VPC-Verbindung an das Ziel-EP weiter.

Workflow zur Fehlerbehebung für unbekannten Layer-2-Unicast-Datenverkehr - BD im Hardware-Proxy

Das aktuell aufgeführte Szenario gilt für unbekannten Unicast-Datenverkehr auf Layer 2 mit dem BD im Hardware-Proxymodus. In diesem Szenario wird das Paket an die Anycast-Proxy-MAC-Adresse des Spine weitergeleitet, wenn das Eingangs-Leaf die Ziel-MAC-Adresse nicht kennt. Der Spine führt eine COOP-Suche für die Ziel-MAC durch.

Wenn die Suche wie unten gezeigt erfolgreich ist, schreibt der Spine die äußere Ziel-IP in das Tunnelziel (hier 10.0.96.66) um und sendet sie an das leaf3-leaf4-VPC-Paar.

spine1# show coop internal info repo ep key 15302583 00:00:10:01:01:02

Repo Hdr Checksum : 16897

Repo Hdr record timestamp : 10 01 2019 11:05:46 351360334

Repo Hdr last pub timestamp : 10 01 2019 11:05:46 352019546

Repo Hdr last dampen timestamp : 01 01 1970 00:00:00 0

Repo Hdr dampen penalty : 0

Repo Hdr flags : IN_OBJ EXPORT ACTIVE

EP bd vnid : 16351141

EP mac :  00:00:10:01:01:02

flags : 0x90

repo flags : 0x122

Vrf vnid : 2097154

Epg vnid : 0

EVPN Seq no : 0

Remote publish timestamp: 01 01 1970 00:00:00 0

Snapshot timestamp: 10 01 2019 11:05:46 351360334

Tunnel nh : 10.0.96.66

MAC Tunnel  : 10.0.96.66

IPv4 Tunnel : 10.0.96.66

IPv6 Tunnel : 10.0.96.66

ETEP Tunnel : 0.0.0.0

Wenn die Suche fehlschlägt (der Endpunkt ist in der ACI-Fabric unbekannt), verwirft der Spine das unbekannte Unicast.

spine1# show coop internal info repo ep key 15302583 00:00:10:01:01:02

Key not found in repo

Layer-2-Weiterleitungszusammenfassung

Im folgenden Diagramm wird das mögliche Weiterleitungsverhalten für Layer-2-Datenverkehr in der ACI-Fabric zusammengefasst.

ACI Fabric Layer 2 - Weiterleitungsverhalten