Fehlerbehebung: ACI Intra-Fabric Forwarding - Layer 2 Forwarding
Inhalt
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:
- Bekannter Layer-2-Unicast-Fluss
- Unbekannter Layer-2-Unicast-Fluss mit BD im Flood-Modus.
- 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:
- Der Eingangs-Leaf hasht den Paket-Header, um ihn einem der FTAGs zuzuweisen (von 0 bis 15).
- Der Eingangs-Leaf kapselt den Frame in ein VXLAN-Paket mit der BD-VNID. Die äußere Ziel-IP-Adresse lautet BD GIPo + FTAG.
- 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
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
08-Aug-2022 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)