Fehlerbehebung für ACI Fabric Port-Track

Einleitung

In diesem Dokument werden die Funktionen zur Fabric-Port-Nachverfolgung der ACI, die Schritte für die Sanierung und Szenarien für Eckfälle beschrieben. 

Überblick

Cisco ACI Fabric Port-Track, auch als Fabric Track oder Port Tracking bezeichnet, ist eine Ausfallsicherheitsfunktion, die auf ACI-Leaf-Switches verwendet wird, um den Status von Host-/Downlink-Ports basierend auf dem Betriebsstatus von Fabric-/Uplink-Ports zu steuern.

Fabric Port-Track wurde entwickelt, um Blackholing im Datenverkehr zu verhindern, wenn die Verbindung eines Leaf zur ACI-Fabric unterbrochen wird. Ohne diese Funktion kann eine Host-seitige Schnittstelle sogar dann physisch verfügbar bleiben, wenn die Fabric-Uplinks des Leaf verloren gehen. In diesem Fall können die verbundenen Endpunkte den Datenverkehr weiterhin an den Leaf weiterleiten. Der Leaf muss jedoch in der Lage sein, diesen Datenverkehr nicht in die Fabric weiterzuleiten.

Wenn Fabric Port-Track aktiviert ist, überwacht das Leaf seine aktiven Fabric-Uplinks zum Spine-Layer und vergleicht die Anzahl der operativen Fabric-Links mit dem konfigurierten Grenzwert. Wenn die Anzahl der verfügbaren Fabric-Links unter das konfigurierte Minimum fällt, werden auf dem Leaf automatisch ausgewählte Schnittstellen mit Host- bzw. Downlink-Ausrichtung deaktiviert. Auf diese Weise können angeschlossene Endgeräte, Server oder externe Geräte das Linkdown-Ereignis erkennen und ein Failover zu einem anderen verfügbaren Pfad oder Leaf durchführen, anstatt weiterhin Datenverkehr an einen Leaf zu senden, der nicht mehr über ausreichende Fabric-Verbindungen verfügt.

Sobald die erforderliche Anzahl an Fabric-Uplinks wiederhergestellt ist und die Anzahl der funktionsfähigen Fabric-Verbindungen den konfigurierten Schwellenwert überschreitet, werden die Downlink-Schnittstellen nach der konfigurierten Wiederherstellungsverzögerung wieder aktiviert.

Beispielverhalten:

• Leaf hat zwei Uplinks zu Spines.
• Fabric Port-Track ist aktiviert.
• Der minimale Schwellenwert für aktive Fabric-Links wird nicht erreicht.
• Leaf deaktiviert Host-seitige/Downlink-Schnittstellen.
• Verbundene Server oder externe Switches erkennen den Verbindungsausfall und führen ein Failover aus.
• Nach der Wiederherstellung der Fabric-Verbindung aktiviert das Leaf nach der konfigurierten Verzögerung wieder Ports auf Host-Ebene.

Topologie 

Checkliste zur Fehlerbehebung empfohlen

Verwenden Sie die Checkliste, wenn Sie Probleme mit der Cisco ACI Fabric Port-Track untersuchen. Jeder Schritt umfasst die entsprechenden Befehle zur Überprüfung oder Fehlerbehebung.

---

Bestätigen Sie das Symptom

Überprüfen Sie, ob Host-seitige/Downlink-Ports ausgefallen sind und ob sich das Ereignis auf Fabric Port-Track bezieht.

Prüfen Sie auf Fabric-Port-Track-Fehler F0532:

moquery -c faultInst -f 'fault.Inst.code=="F0532"'

Beispielanzeige:

descr    : Port is down, reason being fabricTrack(connected)
severity : critical
subject  : port-down

Wenn der Fehler F0532 auftritt, wurde die Schnittstelle aufgrund von Fabric Port-Track deaktiviert.

---

Überprüfen der Fabric-Port-Track-Richtlinie

Überprüfen Sie, ob Fabric Port-Track aktiviert ist, und überprüfen Sie die konfigurierten Parameter.

moquery -c infraPortTrackPol | egrep "adminSt|delay|includeApicPorts|minlinks"

Überprüfen Sie die angezeigten Werte:

Parameter	Zweck
AdminSt	Gibt an, ob Fabric Port-Track aktiviert oder deaktiviert ist.
verzögerung	Wiederherstellungsverzögerung, bevor Downlink-Ports wieder aktiviert werden.
includeApicPorts	Gibt an, ob Ports mit APIC-Verbindung eingeschlossen sind.
Minlinks	Mindestanzahl erforderlicher betrieblicher Fabric-Verbindungen.

Beispiel:

adminSt          : on
delay            : 300
includeApicPorts : no
minlinks         : 0

---

Fabric-Uplink-LLDP-Nachbarn validieren

Vergewissern Sie sich, dass das Leaf über Fabric-Uplinks weiterhin erwartete Spine-Nachbarn erkennt.

show lldp neighbors

Detaillierte Informationen zu einem bestimmten Fabric-Uplink finden Sie unter:

show lldp neighbors int ethernet 1/49 detail

Verwenden Sie diese Ausgabe zur Bestätigung:

• Lokale Leaf-Schnittstelle.
• Remote-Spine-Knoten.
• Remote-Spine-Schnittstelle.
• LLDP-Haltezeit.
• Ob der erwartete Nachbar noch vorhanden ist.

---

Überprüfen des Fabric-Uplink-Schnittstellenstatus und des Flap-Verlaufs

Überprüfen Sie, ob die Fabric-seitige Schnittstelle kürzlich ein Flapping durchgeführt hat.

show int eth 1/49 | egrep "flapped|state"

Beispiel:

admin state is up, Dedicated Interface
  Last link flapped 00:02:57

Eine kürzlich erfolgte Lasche am Fabric-Uplink kann erklären, warum Fabric Port-Track ausgelöst wurde.

---

Status der betroffenen Downlink-Schnittstelle überprüfen

Überprüfen Sie den Status und den Flapping-Verlauf der Host-seitigen/Downlink-Schnittstelle.

show int eth 1/17 | egrep "flapped|state|fabric-track"

Dies hilft, das Downlink-Port-Ereignis mit dem Fabric-Uplink-Fehler zu korrelieren.

---

Fabric Port-Track-Debug-Protokolle überprüfen

Überprüfen Sie das Fabric-Port-Track-Prozessprotokoll auf dem betroffenen Leaf.

cat /var/sysmgr/tmp_logs/fabric_track.py.dbg | tail -n 15

Beispiel für Protokollausgabe im Normalbetrieb:

cat /var/sysmgr/tmp_logs/fabric_track.py.dbg | tail -n 15
 Reading the port track Mo
...
 Reading the port track Mo

Beispiel-Protokolldatei während des Fehlerfensters:

cat /var/sysmgr/tmp_logs/fabric_track.py.dbg | tail -n 15
Reading Isis Mo to check for Isis Adjacency
1 Fabric links are up
Reading l1PhysIf Mos of fabric links to check number of up fabric links
Bringdown: 0 Fabric links left up
PortTrackIf Mo is not present. Creating PortTrackIf Mo for eth1/17
Committing the port track Mo

Diese Meldungen weisen darauf hin, dass das Leaf unzureichende Fabric-Verbindungen erkannt und PortTrack-Schnittstellenobjekte für die betroffenen Downlink-Ports erstellt hat.

Wichtigste Beobachtungen:

• Das Leaf hat eine Fabric-Verbindung erkannt.
• Kurz danach wurden keine Fabric-Verbindungen erkannt.
• Von Fabric Port-Track erstellter PortTrack If verwalteter Objekte für betroffene Schnittstellen.
• Die Downlink-Schnittstelle, wie eth1/17, wurde deaktiviert.

---

Transceiver-Details überprüfen

Erfassung optischer Informationen für den betroffenen Fabric-Uplink

show interface ethernet 1/49 transceiver details | egrep "type|name|serial"

Beispiel:

type is QSFP-40/100-SRBD
name is CISCO-FINISAR
serial number is FIW2440004Z-B

Dies ist besonders bei der Fehlerbehebung wichtig:

• Optische Fehler.
• Optische BiDi-Verbindungen
• Passive TAPs
• Interaktion mit Überwachungstool.
• Unerwartete Verbindungsflaps.

---

Zuordnung der physischen Schnittstelle zum internen Port

Identifizieren Sie die interne Portnummer, die der physischen Schnittstelle zugeordnet ist.

vsh_lc -c 'show platform internal usd port info' | egrep "Eth1/49" -A 1

Beispiel:

Port  61.0 (Eth1/49)  : Admin UP  (1) Link UP   Cfg_Fec Disabled Fec Disabled Fcot Fiber retimer 0x0
                AN_knob No AN_cfg Yes   AN_operSt No In_debounce 0, Debounce-Time 0 usecs qsa: No

In diesem Beispiel ist Eth1/49 dem internen Port 61.0 zugeordnet.

---

Plattformverknüpfungs-Ereignisverlauf überprüfen

Überprüfen Sie nach der Identifizierung des internen Ports den Link-Ereignisverlauf.

vsh_lc -c 'show platform internal tah event-history linkevents' | grep Port "61.0" -A 1

Beispiel ohne Debounce:

Port 61.0: tahusd_port_handle_debounce: No debounce required!!

Beispiel mit konfiguriertem Debounce:

Port 61.0: tahusd_port_handle_debounce/9481: Started Debounce Timer for 10000 ms

Dadurch wird bestätigt, ob während des Verbindungsereignisses ein Link-Debounce angewendet wurde.

---

Bei Bedarf Link-Debouncing überprüfen und konfigurieren

Überprüfen Sie, ob das Link-Debouncing für Fabric-Schnittstellen konfiguriert ist. Das Link-Debouncing kann verhindern, dass vorübergehende Microflaps sofort das Fabric Port-Track-Verhalten auslösen.

Überprüfen Sie die Fabric-Schnittstellenrichtlinie:

moquery -c fabricFIfPol | egrep "dn|linkDebounce"

Beispiel:

dn           : uni/fabric/fintfpol-default
linkDebounce : 0

Check Debounce direkt von der Schnittstelle:

show interface eth1/49 debounce

Beispiel ohne Debounce:

------------------------------------------------------------------------------------
 Port          Debounce time  Value(ms)
------------------------------------------------------------------------------------
 Eth1/49       disable                0

Wenn Debounce deaktiviert ist und Microflaps vermutet werden, konfigurieren Sie Debounce auf der Fabric-Schnittstelle:

configure
leaf 101
interface ethernet 1/49
link debounce time 100

Wichtig:

• Der Wert ist in Millisekunden.
• 100 ist 1 Sekunde.

Überprüfen der Konfiguration:

show interface eth1/49 debounce

Erwartete Ausgabe:

------------------------------------------------------------------------------------
 Port          Debounce time  Value(ms)
------------------------------------------------------------------------------------
 Eth1/49       enable                100

Das Standard-Debouncing-Intervall ist 0 ms. Wir empfehlen einen Wert von 100 ms, Sie können jedoch einen Wert auswählen, der zu Ihrer Fabric passt.

---

Konsolidierte Befehlsreferenz

Aufgabe	Command
Fabric-Port-Track-Fehler überprüfen	moquery -c faultInst -f 'fault.Inst.code=="F0532"
Überprüfen der Fabric-Port-Track-Richtlinie	moquery -c infraPortTrackPol | egrep "adminSt|delay|includeApicPorts|minlinks"
LLDP-Nachbarn überprüfen	LLDP-Nachbarn anzeigen
Überprüfen eines detaillierten LLDP-Nachbarn	Zeigt LLDP-Nachbarn in Ethernet 1/49 Detail
Überprüfen des Fabric-Uplink-Zustands	show int eth 1/49 | egrep "flapped|state"
Downlink-Status überprüfen	int eth 1/17 anzeigen | egrep "flapped|state|fabric-track"
Fabric Port-Track-Debug-Protokoll überprüfen	cat /var/sysmgr/tmp_logs/fabric_track.py.dbg | Schwanz -n 15
Transceiver-Details überprüfen	Interface Ethernet 1/49 Transceiver Details anzeigen | egrep "type|name|serial"
Physische Schnittstelle dem internen Port zuordnen	vsh_lc -c 'show platform internal usd port info' | egrep "Eth1/49" -A 1
Plattformverbindungsereignisse überprüfen	vsh_lc -c 'show platform internal tah event-history linkevents' | grep Port "61.0" -A 1
Fabric-Debouncing-Richtlinie überprüfen	moquery -c FabricFIfPol | egrep "dn|linkDebounce"
Interface-Debouncing überprüfen	show interface eth1/49 debounce
Debouncing konfigurieren	Link-Debouncing-Zeit 10000

Szenario 1: Eckgehäuse Schnittstelle hat keine Markierung vorgenommen, aber Fabric-Port-Track ausgelöst

Ein mögliches Eckumfeld tritt auf, wenn die physische Fabric-Schnittstelle keine Flapping-Ereignisse aufweist, sich Fabric Port-Track jedoch weiterhin so verhält, als wären Fabric-Verbindungen nicht verfügbar.

Beispiel:

show int eth 1/49 | egrep "flapped|state"
admin state is up, Dedicated Interface
Last link flapped 1y14w

In diesem Szenario hat die Schnittstelle in letzter Zeit kein Flapping durchgeführt.

Da Fabric Port-Track auf Abfragen verwalteter Objekte basiert, überprüfen Sie, ob das Leaf die entsprechende Modeabfrage erfolgreich durchführen kann:

moquery -c l1PhysIf -x 'query-target-filter=and(anybit(l1PhysIf.usage,"fabric"),eq(l1PhysIf.switchingSt,"enabled"))'

Überprüfen Sie auch die Festplattenauslastung, z. B. problematischen Zustand:

df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 2.5G 2.5G 0 100% /bin

Wenn das Root-Dateisystem voll ist, kann das Leaf interne Funktionen wie moquery verwerfen oder versagen. Daher kann Fabric Port-Track möglicherweise nicht bestätigen, dass die Fabric-Verbindungen aktiv sind, und muss Downlink-Schnittstellen falsch deaktivieren.

Empfohlene Aktion:

• Überprüfen Sie den verfügbaren Speicherplatz.
• Löschen oder beheben Sie das Problem mit dem Dateisystem gemäß den Anweisungen von Cisco.
• Moquery-Funktionalität erneut überprüfen.
• Bestätigen Sie, dass Fabric-Uplinks richtig erkannt werden.

Szenario 2: Eckgehäuse Optische BiDi-Verbindungen und passive TAP-Interferenzen

Spezifisches Problem betrifft optische BiDi-QSFP-Verbindungen und passive optische TAPs für die Überwachung.

Passives TAP-Risiko

Wenn eine passive TAP-Infrastruktur zwischen Leaf und Spine implementiert wird und die Überwachungsausrüstung reguläre BiDi-Optiken verwendet, kann der Überwachungspfad Licht zurück in die Live-Produktionsverbindung übertragen.

Dies kann folgende Ursachen haben:

• Unerwartete optische Signaleinkopplung.
• Link-Down-Ereignisse auf beiden Seiten.
• Sowohl Leaf als auch Spine melden Remote-Fehlerzustände.
• Auslösung der Fabric-Port-Spur aufgrund eines vorübergehenden Fabric-Uplink-Verlusts.

In diesem Szenario verursachte das erneute Laden eines Überwachungsschalters unerwartete optische Signale, die zu Verbindungsausfällen sowohl auf Leaf- als auch auf Spine-Ebene führten.

Standardmäßige optische SR-Verbindungen - QSFP-40/100-SRBD

Bei standardmäßigen optischen SR-Verbindungen sind die Übertragungs- und Empfangspfade getrennt:

Tx -> Rx
Rx <- Tx

Der Datenverkehr erfolgt unidirektional pro Glasfaser.

Empfohlene Eindämmung

Verwenden Sie für BiDi-Überwachungsszenarien geeignete BiDi-Optiken, die nur empfangen und nicht in den Produktionspfad übertragen.

Optische BiDi-Verbindungen - QSFP-40G-BD-RX

Bei optischen BiDi-Verbindungen sind Übertragung und Empfang auf jeder Faser gleich:

Tx/Rx <-> Tx/Rx

Dies wird als spezielle TAP/Monitor-BiDi-Optik beschrieben, bei der der Monitorpfad nur ein Signal empfängt.

Überlegungen zu vPC

Bei Downlink-Ports mit vPC-Verbindung kann das Wiederherstellungsverhalten sowohl durch den Fabric Port Track-Verzögerungs-Timer als auch durch den vPC-Verzögerungs-Timer beeinflusst werden.

Bei vPC-Konfigurationen kann ein Leaf-Knoten nicht mit seinem vPC-Peer kommunizieren, wenn alle Fabric-Ports und damit die ISIS-Adjacencies verloren gehen. In diesem Fall werden Downlink-Ports reaktiviert, nachdem der vPC-Verzögerungs-Timer oder der Port-Verfolgungs-Verzögerungs-Timer länger geworden ist.

Betriebliche Auswirkungen:

• Nicht-vPC-Downlink-Ports müssen der Fabric Port-Track-Wiederherstellungsverzögerung entsprechen.
• vPC-Downlink-Ports können länger ausfallen, wenn der vPC-Verzögerungs-Timer größer als die Fabric-Port-Track-Verzögerung ist.
  
  

Beispiel:

• Fabric-Port-Track-Verzögerung: 300 Sekunden
• vPC-Verzögerungszeitgeber: 600 Sekunden
• vPC-Downlink-Ports müssen nach 600 Sekunden wiederhergestellt werden.

Wichtiger Hinweis für APIC-verbundene Ports

Die Cisco Bug-ID CSCva9547, die sich auf die mit dem APIC verbundenen Ports und das Fabric Port-Track-Verhalten bezieht.

Ein wichtiger betrieblicher Gesichtspunkt ist, dass Ports mit APIC-Anbindung bei vorübergehenden Uplink-Ausfällen im Allgemeinen nicht durch Fabric Port-Track deaktiviert werden dürfen, da dies die Management- und Controller-Konnektivität beeinträchtigen könnte.

Mit der Option include ApicPorts wird gesteuert, ob mit dem APIC verbundene Schnittstellen in das Verhalten einbezogen werden.

Dies weist darauf hin, dass Ports, die mit dem APIC verbunden sind, von der Deaktivierung durch Fabric Port-Track ausgeschlossen sind.

Referenzen

Cisco APIC Basic Konfigurationsleitfaden > Kapitel: Provisioning Core ACI Fabric Services > Link Debounce-Intervall

Konfigurationsleitfaden für Cisco APIC Layer-2-Netzwerke > Kapitel: Fabric-Port-Nachverfolgung

Cisco Application Centric Infrastructure (ACI) - Designleitfaden > Port-Nachverfolgung

Cisco Application Centric Infrastructure - Grundlagen > Kapitel: Fabric-Bereitstellung > Port-Nachverfolgungsrichtlinie für Fabric Port-Ausfallerkennung

Referenzfehler:

Cisco Bug-ID CSCva95547: Anfrage für Port-Tracking-Funktion: Regler zum Deaktivieren der Leaf-Switch-Ports, die zum APIC gehen

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
1.0	17-Jun-2026	Erstveröffentlichung