Fehlerbehebung bei Punt-Keepalive-Fehlern in Cisco IOS XE
Einleitung
In diesem Dokument wird beschrieben, wie Sie Fehler beim Aufrechterhalten des aktiven Punts beheben.
Voraussetzungen
Anforderungen
Grundkenntnisse von Cisco IOS® XE
Verwendete Komponenten
Dieses Dokument basiert auf Cisco IOS XE-Routern wie den Serien CSR8000v, ASR1000 und ISR4000.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hintergrundinformationen
Bei Cisco IOS XE-basierten Systemen ist der Pfad für jeden Eintrag ein interner Datenpfad. Hierbei handelt es sich um den Pfad, über den die Kommunikation zwischen der Kontroll- und Datenebene stattfindet.
Dieser interne Pfad wird zur Übertragung von Paketen auf der Kontrollebene für die Router-Nutzung verwendet.
Wenn dieser Pfad fehlschlägt, können Sie diese Art von Fehler im Protokoll sehen.
%IOSXE_INFRA-4-NO_PUNT_KEEPALIVE: Keepalive not received for 60 secondsBei den Keep-Alive-Nachrichten handelt es sich um Nachrichten, die den Zustand des Pfads zwischen dem QFP und dem RP überwachen.
Dieser Pfad ist für den Betrieb des Systems von entscheidender Bedeutung.
Wenn diese Keepalives nicht innerhalb von 5 Minuten empfangen werden, können Sie ein kritisches Protokoll wie dieses sehen:
%IOSXE_INFRA-2-FATAL_NO_PUNT_KEEPALIVE: Keepalive not received for 300 seconds resetting
Das System wird zurückgesetzt, um sich von diesem Zustand zu erholen.
Die Punt-Debug-Protokolldatei
Im Falle von Punt-Keep-Alive-Fehlern und daraus resultierenden Rücksetzvorgängen erstellt das System eine Datei mit dem Namen punt_debug.log, die relevante Daten sammelt, um das Verhalten zur Problemzeit zu verstehen.
Anmerkung: Stellen Sie sicher, dass das System mit der neuesten Cisco IOS XE-Softwareversion auf dem neuesten Stand ist, damit die Datei punt_debug.log generiert werden kann.
Diese Datei enthält diese Befehle, die mehrmals ausgeführt werden, um verschiedene Zähler zu verstehen.
show plattform software infra punt-keepalive
show plattform software infra lsmpi
show platform software infrastructure lsmpi driver
show plattform software infra lsmpi bufusage
show platform software punt-policer
show platform software status control-prozessor brief
show prozess cpu plattform sortiert
show platform software infrastructure punt
show plattform hardware qfp aktive statistik drop
show plattform hardware qfp active infra punt statistik typ pro ursache
show plattform hardware qfp aktive infrastruktur bqs warteschlange ausgabe standard all
Anmerkung: In der Datei punt_debug.log konzentrieren Sie sich auf Fehleranzeigen und große Paketmengen, die das Problem verursachen können.
Die Linux Shared Memory Punt-Schnittstelle (LSMPI)
Diese Komponente dient zum Übertragen von Paketen und Nachrichten vom Weiterleitungsprozessor an den Routing-Prozessor.
Die Punt-Überwachung
Die Point Policer-Funktion ist ein Schutzmechanismus auf Kontrollebene, mit dem das System Pakete auf Kontrollebene schützen und überwachen kann.
Mit dem Befehl show platform software punt-policer können Sie die konformen Pakete und die aufgrund dieses Policers verworfenen Pakete anzeigen.
----------------- show platform software punt-policer ------------------
Per Punt-Cause Policer Configuration and Packet Counters
Punt Config Rate(pps) Conform Packets Dropped Packets Config Burst(pkts) Config Alert
Cause Description Normal High Normal High Normal High Normal High Normal High
-------------------------------------------------------------------------------------------------------------------------------------------------------------
2 IPv4 Options 874 655 0 0 0 0 874 655 Off Off
3 Layer2 control and legacy 8738 2185 0 0 0 0 8738 2185 Off Off
4 PPP Control 437 1000 0 0 0 0 437 1000 Off Off
—— snip : output omitted for brevity —— Der Befehl show platform software infrastructure punt zeigt Zählerdaten zu punt-Ursachen an.
------------------ show platform software infrastructure punt ------------------
LSMPI interface internal stats:
enabled=0, disabled=0, throttled=0, unthrottled=0, state is ready
Input Buffers = 51181083
Output Buffers = 51150283
—— snip : output omitted for brevity ——
EPC CP RX Pkt cleansed 0
Punt cause out of range 0
IOSXE-RP Punt packet causes:
3504959 ARP request or response packets
27 Incomplete adjacency packets
—— snip : output omitted for brevity ——
FOR_US Control IPv4 protcol stats:
2369262 TCP packets
FOR_US Control IPv6 protcol stats:
6057 ICMPV6 packets
Packet histogram(500 bytes/bin), avg size in 119, out 95:
Pak-Size In-Count Out-Count
0+: 51108211 51144723
500+: 22069 2632
1000+: 2172 0
1500+: 3170 0Diese Daten sind relevant, um zu verstehen, was sich auf den Punt-Keep-Alive-Pfad auswirken kann.
Embedded Event Manager (EEM) für die Datensammlung
Falls die Datei punt_debug.log nicht genügend Daten zur Diagnose des Problems liefert, kann EEM-Scripting verwendet werden, um mehr Datenpunkte zur Problemzeit zu erhalten.
event manager applet punt_script authorization bypass
event syslog pattern "IOSXE_INFRA-4-NO_PUNT_KEEPALIVE" maxrun 1000
action 0.0 cli command "enable"
action 0.1 set i "0"
action 0.2 cli command "test platform software punt-keepalive ignore-fault"
action 0.3 while $i lt 10
action 0.4 syslog msg "iteration $i"
action 0.9 cli command "show clock | append bootflash:qfp_lsmpi.txt"
action 1.0 cli command "show platform software infrastructure lsmpi | append bootflash:qfp_lsmpi.txt"
action 1.1 cli command "show platform software infrastructure lsmpi driver | append bootflash:qfp_lsmpi.txt"
action 1.2 cli command "show platform software infrastructure lsmpi driver 0 | append bootflash:qfp_lsmpi.txt"
action 1.3 cli command "show platform software infrastructure lsmpi bufusage | append bootflash:qfp_lsmpi.txt"
action 1.4 cli command "show platform software infrastructure lsmpi bufusage 0 | append bootflash:qfp_lsmpi.txt"
action 1.5 cli command "show platform software infrastructure punt-keepalive | append bootflash:qfp_lsmpi.txt"
action 1.6 cli command "show platform software infrastructure punt | append bootflash:qfp_lsmpi.txt"
action 1.7 cli command "show platform software punt-policer | append bootflash:qfp_lsmpi.txt"
action 1.8 cli command "show platform hardware qfp active infrastructure punt stat type per-cause | append bootflash:qfp_lsmpi.txt"
action 1.9 cli command "show platform hardware qfp active infrastructure punt statistics type punt-drop | append bootflash:qfp_lsmpi.txt"
action 1.a cli command "show platform hardware qfp active infrastructure punt statistics type inject-drop | append bootflash:qfp_lsmpi.txt"
action 1.b cli command "show platform hardware qfp active infrastructure bqs queue output default interface-string internal0/0/rp:0 hier detail | append bootflash:qfp_lsmpi.txt"
action 1.c cli command "show platform hardware qfp active statistics drop | append bootflash:qfp_lsmpi.txt"
action 1.d cli command "show platform hardware qfp active datapath utilization | append bootflash:qfp_lsmpi.txt"
action 1.e cli command "show platform hardware qfp active datapath infrastructure sw-hqf | append bootflash:qfp_lsmpi.txt"
action 1.f cli command "show platform hardware qfp active datapath infrastructure sw-distrib | append bootflash:qfp_lsmpi.txt"
action 1.g cli command "show platform hardware qfp active datapath infrastructure sw-pktmem | append bootflash:qfp_lsmpi.txt"
action 1.h cli command "show platform software status control-processor brief | append bootflash:qfp_lsmpi.txt"
action 2.0 increment i
action 2.1 wait 3
action 2.4 end
action 3.0 syslog msg "End of data collection. Please transfer the file at bootflash:qfp_lsmpi.txt"
action 5.0 cli command "debug platform hardware qfp active datapath crashdump"
Anmerkung: Die im Skript enthaltenen Befehle variieren je nach Plattform, auf der es konfiguriert ist.
Mit diesem Skript können Sie den LSMPI-, Ressourcen- und Punt-Status während der Problemzeit verstehen.
Das EEM-Skript enthält den Befehl debug platform hardware qfp active datapath crashdump, der das vom Entwicklerteam und TAC benötigte QFP-Core-Dump generiert.
Anmerkung: Wenn Sie beim Cisco TAC einen Fall einreichen, geben Sie die vom Skript generierte Kerndatei an.
Wenn eine Paketverfolgung erforderlich ist, kann diese Änderung dem Skript hinzugefügt werden:
Richten Sie zunächst die Paketablaufverfolgungskonfiguration ein, die über das EEM-Skript ausgeführt werden kann:
debug plattform packet-trace paket 8192 fia-trace zirkular
Debug-Plattformbedingung
debug plattform packet-trace copy paket beide L2
Starten und stoppen Sie es anschließend mit den folgenden Aktionen im EEM-Skript:
action 6.2 cli-Befehl "debug platform condition start"
Aktion 6.3 warten 8
action 6.4 cli-Befehl "debug platform condition stop"
Speichern Sie die Daten mit diesen Befehlen in einer separaten Datei:
action 6.5 cli-Befehl "show platform packet trace statistics" | append bootflash:traceAll.txt"
action 6.6 cli-Befehl "show platform packet-trace summary | append bootflash:traceAll.txt"
action 6.7 cli-Befehl "show platform packet-trace packet all decode | append bootflash:traceAll.txt"
Diese Paketablaufverfolgungsaktionen werden direkt nach der end-Anweisung des while-Zyklus innerhalb des EEM-Skripts hinzugefügt.
Mit diesem Skript können Sie ermitteln, welche Art von Paketen das Problem verursachen können.
Die Paketverfolgung ist eine Funktion, die bei der Fehlerbehebung mit der IOS XE DataPath Packet Trace-Funktion dokumentiert ist.
Ein praktisches Beispiel
Ein CSR8000v wird ständig neu gestartet.
Nachdem Sie den Systembericht extrahiert haben, können Sie einen Crashdump und eine IoSD-Kerndatei beobachten, die darauf hinweist, dass die entsprechenden Funktionen im Stapelverlauf beibehalten werden.
Anmerkung: Für die Stack-Trace-Decodierung ist die Unterstützung des TAC erforderlich.
Die crashinfo-Datei ist jedoch in Klartext, und Sie können die folgenden Symptome sehen:
Jan 15 14:29:41.756 AWST: %IOSXE_INFRA-4-NO_PUNT_KEEPALIVE: Keepalive not received for 160 seconds
Jan 15 14:30:01.761 AWST: %IOSXE_INFRA-4-NO_PUNT_KEEPALIVE: Keepalive not received for 180 seconds
Jan 15 14:30:21.766 AWST: %IOSXE_INFRA-4-NO_PUNT_KEEPALIVE: Keepalive not received for 200 seconds
Jan 15 14:30:41.776 AWST: %IOSXE_INFRA-4-NO_PUNT_KEEPALIVE: Keepalive not received for 220 seconds
Jan 15 14:31:01.780 AWST: %IOSXE_INFRA-4-NO_PUNT_KEEPALIVE: Keepalive not received for 240 seconds
Jan 15 14:31:41.789 AWST: %IOSXE_INFRA-4-NO_PUNT_KEEPALIVE: Keepalive not received for 280 seconds
Jan 15 14:32:01.791 AWST: %IOSXE_INFRA-4-NO_PUNT_KEEPALIVE: Keepalive not received for 300 seconds
Jan 15 14:32:01.791 AWST: %IOSXE_INFRA-2-FATAL_NO_PUNT_KEEPALIVE: Keepalive not received for 300 seconds resetting
%Software-forced reload
Exception to IOS Thread:
Frame pointer 0x7F0AE0EE29A8, PC = 0x7F0B342C16D2
UNIX-EXT-SIGNAL: Aborted(6), Process = PuntInject Keepalive Process
-Traceback= 1#7b5996c3Betroffen ist der PuntInject Keepalive-Prozess.
Das System muss ein Abbruchsignal auslösen, wenn der Keepalive die 300-Sekunden-Schwellenwertmarke erreicht.
Die punt_debug.log zeigt einige Übertragungsfehler innerhalb des Befehls show platform software infrastructure lsmpi driver:
Reason for TX drops (sticky):
Bad packet len : 0
Bad buf len : 0
Bad ifindex : 0
No device : 0
No skbuff : 0
Device xmit fail : 82541 >>>>>>>>>>>>>>>>>>>>> Tx failureDies ist ein allgemeiner Fehler.
Dieser Zähler wird innerhalb mehrerer in der Datei entnommener Stichproben erhöht.
Das EEM-Skript wurde bereitgestellt, um weitere Daten zu den Ressourcen abzurufen, Datenpfade und andere Befehle im Zusammenhang mit der Infrastruktur zu analysieren.
Durch die Überprüfung der Zähler für den lsmpi-Datenverkehr wird deutlich, dass EIGRP-Pakete auf der Kontrollebene bemerkenswert sind. Dies sind Pakete, die als für US-Pakete identifiziert werden:
17660574 For-us data packets
543616 RP<->QFP keepalive packets
1004 Glean adjacency packets
3260636 BFD control packets
122523839 For-us control packets<<<<
FOR_US Control IPv4 protcol stats:
153551 TCP packets
2663105 GRE packets
104394559 EIGRP packets<<<<Später stellte sich heraus, dass der Hypervisor überausgelastet war, was sich auf die zugrunde liegenden Computing-Ressourcen auswirkte.
Der CSR8000v wurde in einem anderen Hypervisor bereitgestellt, wodurch das Problem gemindert werden konnte.
Verbesserungen
Ab der Version Cisco IOS XE 17.15 über die Cisco Bug-ID CSCwf85505 wurde eine Erweiterung für die automatische Generierung von QFP-Core-Dateien eingeführt.
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
21-Nov-2024 |
Erstveröffentlichung |
Feedback