Fehlerbehebung bei Node-Neuladevorgängen auf Benutzerebene

Einleitung

In diesem Dokument wird der Prozess zum Identifizieren verschiedener Szenarien für Upload-Vorgänge auf Benutzerebene basierend auf den Symptomen zur Fehlerbehebung beschrieben.

Abkürzungen

RCM = Redundancy Configuration Manager

SSD: Support-Details anzeigen

UPF/UP - Benutzerebenenfunktion

VPP = Vector Packet Processing

BFD = Bidirectional Forwarding Detection

Mögliche Szenarien für UP-Neuladevorgänge

1. Problem mit Push-Konfiguration zwischen RCM und UPF
2. BFD, BGP oder Sx Flap
3. VPP-Absturz oder Sessmgr-Absturz

Erforderliche Protokolle für die Symptomerkennung

• RCM-Protokolle (Controller/ConfigMgr)
• Syslogs
• Simple Network Management Protocol (SNMP)-Traps
• RCM-Befehlsausgänge
• Anzeigen von Support-Details (SSDs) - SSD vor und nach dem Neuladen, falls verfügbar

Analyse und Identifizierung von Symptomen

Ansatz zur Identifizierung der Symptome von UP-Reload-Szenarien:

In einer CUPS-Konfiguration treten bei UP-Neuladeszenarien häufig Probleme auf, die eine effektive Symptomerkennung und anschließende Fehlerbehebung erfordern.

Um den Prozess zu starten, untersuchen Sie die Systemverfügbarkeit, um die genaue Zeit des letzten UP-Neustarts zu bestimmen. Diese Informationen erleichtern eine gezielte Analyse der RCM-Protokolle, die dem Ereignis beim erneuten Laden entsprechen.

Verwenden Sie diesen Befehl, um die Systemverfügbarkeit wie folgt zu überprüfen:

******** show system uptime ******* 
Friday July 22 09:28:14 IST 2022 
System uptime: 0D 0H 6M 

Stellen Sie sicher, dass während des erneuten Ladens Abstürze aufgetreten sind. Sie können diesen Befehl verwenden, um nach Absturzvorkommen zu suchen:

******** show crash list ******* 
Sunday January 23 12:12:14 IST 2022 
=== ==================== ======== ========== =============== ======================= 
#           Time         Process  Card/CPU/        SW          HW_SER_NUM 
                                     PID         VERSION       VPO / Crash Card 
=== ==================== ======== ========== =============== ======================= 
1   2022-Jan-14+13:16:40 sessmgr  01/0/11287 21.25.5         NA 
2   2022-Jan-19+20:51:01 sessmgr  01/0/16142 21.25.5         NA 
3   2022-Jan-22+15:51:55 vpp      01/0/07307 21.25.5         NA 
4   2022-Jan-22+15:52:08 sessmgr  01/0/27011 21.25.5         NA 
5   2022-Jan-22+16:07:43 sessmgr  01/0/13528 21.25.5         NA 

In diesem Schritt müssen Sie überprüfen, ob Abstürze aufgetreten sind, z. B. vpp/sessmgr-Abstürze. Wenn ein vpp-Absturz erkannt wird, wird das UP nach dem Absturz sofort neu geladen, und der RCM wird aufgefordert, einen Switchover auf ein anderes UP zu initiieren.

Wenn eine konsistente Abfolge von Sessmgr-Abstürzen vorliegt, kann dies möglicherweise einen VPP-Absturz auslösen, der zu einem Neuladen des UPs führt.

Aktionsplan: Sobald Sie die Core-Datei oder den Minicore erhalten haben, besteht der nächste Schritt darin, das Debuggen der Core-Datei durchzuführen, um die Ursache des Absturzes zu ermitteln.

Analyse basierend auf UP-Syslogs/snmp 

BFD-Schwankungen oder -Ausfälle bei der BFD-Überwachung

Die in Syslogs gefundenen Fehler im Zusammenhang mit BFD-Überwachungsfehlern werden hier erläutert.

Diese Fehler treten auf, wenn es zu BFD-Flaps oder Paketverlusten zwischen RCM und UP kommt, insbesondere in Fällen, in denen die ACI an der Verbindung zwischen beiden beteiligt ist.

Im Wesentlichen wird ein Timer zur Überwachung von BFD-Paketen konfiguriert. Wenn dieser Timer aus irgendeinem Grund abläuft, löst er einen Überwachungsfehler aus. Dieses Ereignis fordert den RCM auf, einen Switchover zu initiieren.

Jan 22 15:51:55 <NODENAME> evlogd: [local-60sec55.823] [bfd 170500 error] [1/0/9345 <bfdlc:0> bfd_network.c:1798] [software internal system] <bfdctx:7> Session(1/-1260920720) DOWN control detection timer expired 
Jan 22 15:51:55 <NODENAME> evlogd: [local-60sec55.856] [bfd 170500 error] [1/0/9345 <bfdlc:0> bfd_network.c:1798] [software internal system] <bfdctx:5> Session(2/1090521080) DOWN control detection timer expired 
Jan 22 15:51:55 <NODENAME> evlogd: [local-60sec55.859] [srp 84220 error] [1/0/10026 <vpnmgr:7> pnmgr_rcm_bfd.c:704] [context: rcmctx, contextID: 7]  [software internal system syslog] BFD down, closing TCP. 
Jan 22 15:51:56 <NODENAME> evlogd: [local-60sec55.979] [srp 84220 error] [1/0/10026 <vpnmgr:7> pnmgr_rcm_bgp.c:428] [context: rcmctx, contextID: 7]  [software internal system syslog] Cannot inform RCM about BGP monitor failure as TCP connection with RCM down. 

Um diesem Problem zu begegnen, ist es wichtig, das System umfassend zu untersuchen und alle potenziellen Probleme zu identifizieren, die die BFD-Klappe verursacht haben könnten. Wenn ein problematischer Zeitstempel aufgedeckt wird, ist eine Abstimmung mit der ACI erforderlich, um zu untersuchen, ob an ihrem Ende Flaps oder Probleme aufgetreten sind, die diesem Zeitstempel entsprechen.

BGP-Flaps oder BGP-Überwachungsfehler

BGP-Flaps oder Überwachungsfehler innerhalb von UP können einen vom RCM initiierten Switchover auslösen. Diese spezifischen Fehler werden wie hier beschrieben charakterisiert.

Mar 21 09:10:37 <NODENAME> evlogd: [local-60sec37.482] [vpn 5572 info] [1/0/10038 <vpnmgr:7> pnmgr_rcm_bgp.c:392] [context: rcmctx, contextID: 7]  [software internal system critical-info syslog] BGP monitor group 3 down.
Mar 21 09:10:37 <NODENAME> evlogd: [local-60sec37.482] [vpn 5572 info] [1/0/10038 <vpnmgr:7> pnmgr_rcm_bgp.c:392] [context: rcmctx, contextID: 7]  [software internal system critical-info syslog] BGP monitor group 4 down.
Mar 21 09:10:37 <NODENAME> evlogd: [local-60sec37.482] [srp 84220 error] [1/0/10038 <vpnmgr:7> pnmgr_rcm_bgp.c:423] [context: rcmctx, contextID: 7]  [software internal system syslog] Informed RCM about BGP monitor failure.

Wed Jan 18 10:30:03 2023 Internal trap notification 1289 (BGPPeerSessionIPv6Down)  vpn upf-in ipaddr abcd:ab:cd:abc::def
Wed Jan 18 10:30:09 2023 Internal trap notification 1288 (BGPPeerSessionIPv6Up)  vpn upf-in ipaddr abcd:ab:cd:abc::def
Wed Jan 18 10:30:19 2023 Internal trap notification 1289 (BGPPeerSessionIPv6Down)  vpn upf-in ipaddr abcd:ab:cd:abc::def
Wed Jan 18 10:30:03 2023 Internal trap notification 1289 (BGPPeerSessionIPv6Down)  vpn upf-in ipaddr abcd:ab:cd:abc::def
Wed Jan 18 10:30:09 2023 Internal trap notification 1288 (BGPPeerSessionIPv6Up)  vpn upf-in ipaddr abcd:ab:cd:abc::defInitiate the process by identifying the context associated with the error that indicates BGP flaps, utilizing the context ID. With the context established, you can precisely determine the particular service involved and retrieve the corresponding IP details.

1. Initiieren Sie den Prozess, indem Sie anhand der Kontext-ID den Kontext identifizieren, der mit dem Fehler verknüpft ist, der BGP-Flaps anzeigt. Mit dem aufgestellten Kontext können Sie den jeweiligen Service exakt bestimmen und die entsprechenden IP-Details abrufen.
2. Nutzen Sie die bereitgestellten Informationen, um gemeinsam Fehler auf Benutzerebene und bei ACI-/Nexus-Komponenten zu beheben. Dieser auf Zusammenarbeit basierende Ansatz zielt darauf ab, die Ursache des BGP-Flapping genau zu identifizieren.
3. Diese BGP-Flapping-Instanzen können zu einem BGP-Überwachungsfehler führen und den Redundancy Configuration Manager (RCM) auffordern, einen Switchover zu initiieren.
4. Der Begriff "BGP-Überwachungsfehler" bezieht sich auf die Situation, in der bei der Überwachung des BGP Probleme auftreten, die dazu führen, dass die kontinuierliche und erwartete Funktionalität der BGP-Verbindungen nicht gewährleistet werden kann.

Sowohl bei RCM-basierten CUPS- als auch bei ICSR-basierten CUPS-Konfigurationen werden individuelle Kontexte innerhalb der UPs erstellt. In einer RCM-Konfiguration wird beispielsweise der "rcm"-Kontext innerhalb des UPs erstellt, während bei einer ICSR-Konfiguration der "srp"-Kontext erstellt wird. Nachfolgend finden Sie eine Beispielkonfiguration für RCM-basierte CUPS:

******** show rcm info *******
Thursday March 17 20:51:40 IST 2022
Redundancy Configuration Module:
-------------------------------------------------------------------------------
Context: rcm 
Bind Address: <UPF IP binding with RCM controller>
Chassis State: Active 
Session State: SockActive 
Route-Modifier: 30 
RCM Controller Address: <RCM controller IP>
RCM Controller Port: 9200 
RCM Controller Connection State: Connected 
Ready To Connect: Yes 
Management IP Address: <UPF management IP>
Host ID: Active7
SSH IP Address: (Deactivated)
SSH IP Installation: Enabled 

redundancy-configuration-module rcm
rcm controller-endpoint dest-ip-addr <Destination RCM controller IP> port 9200 upf-mgmt-ip-addr <UPF management IP> node-name <Nodename> 
bind address <UPF IP binding with RCM controller>
monitor bfd peer X.X.X.X
monitor bgp failure reload active
monitor bgp context GnS5S8-U X.X.X.X group 1
monitor bgp context GnS5S8-U X.X.X.X group 1
monitor bgp context GnS5S8-U abcd:defc:c:f::XXXX group 2
monitor bgp context GnS5S8-U defg:abcg:c:f::XXXX group 2
monitor bgp context SGi Z.Z.Z.Z group 3
monitor bgp context SGi G.G.G.G group 3
monitor bgp context SGi XXXX:YYYY:c:f::aaaa group 4
monitor bgp context SGi XXXX:YYYY:c:f::bbbb group 4
monitor bgp context Li XXXX:YYYY:c:f::cccc group 5
monitor bgp context Li XXXX:YYYY:c:f::dddd group 5
monitor sx context GnS5S8-U bind-address XXXX:YYYY:c:f::eeee peer-address XXXX:YYYY:c:f::ffff
#exit

Sample config for ICSR based CUPs without RCM

******** show srp info *******
Sunday April 23 04:39:49 JST 2023
Service Redundancy Protocol:
-------------------------------------------------------------------------------
Context: SRP 
Local Address: <UP IP>
Chassis State: Active 
Chassis Mode: Backup 
Chassis Priority: 10 
Local Tiebreaker: FA-02-1B-E8-C1-7E
Route-Modifier: 3 

Peer Remote Address: <UP IP>
Peer State: Standby 
Peer Mode: Primary 
Peer Priority: 1 
Peer Tiebreaker: FA-02-1B-13-31-D1
Peer Route-Modifier: 6 
Last Hello Message received: Sun Apr 23 04:39:47 2023 (2 seconds ago)
Peer Configuration Validation: Complete 
Last Peer Configuration Error: None 
Last Peer Configuration Event: Sun Apr 23 04:21:10 2023 (1119 seconds ago)
Last Validate Switchover Status: None 
Connection State: Connected

service-redundancy-protocol
monitor bfd context SRP <bfd peer IP> chassis-to-chassis
monitor bfd context SRP <bfd peer IP>  chassis-to-chassis
monitor bgp context SAEGW-U-1 <IP> group 1
monitor bgp context SAEGW-U-1 <IP> group 1
monitor bgp context SAEGW-U-1 <IP> group 2
monitor bgp context SAEGW-U-1 <IP> group 2
monitor bgp context SAEGW-U-1 <IP> group 3
monitor bgp context SAEGW-U-1 <IP> group 3
monitor bgp context SGI-1 <IP> group 4
monitor bgp context SGI-1 <IP> group 4
monitor system vpp delay-period 30
peer-ip-address <IP>
bind address <IP>
#exit

In beiden Konfigurationen wird die BGP-Überwachung (ähnlich der BFD-Überwachung) innerhalb des jeweiligen Kontexts implementiert.

Jeder Überwachungsinstanz wird eine eindeutige Gruppennummer zugewiesen, und verschiedenen Diensten werden separate Gruppennummern zugewiesen. Im RCM-Kontext ist beispielsweise "SGi" mit der Gruppennummer 3, "SGi IPv6" mit der Gruppennummer 4 und "Li" mit der Gruppennummer 5 verbunden.

Bei Verwendung der bereitgestellten Konfiguration als Grundlage für die RCM-Konfiguration werden die angegebenen BGP-Verbindungen in diesem Kontext überwacht. Bei der Überwachung kann es zu Fehlern kommen, wenn bei einer dieser BGP-Verbindungen Flapping auftritt oder wenn Probleme bei der Erkennung der BGP-Verbindung auftreten. In einer ICSR-Konfiguration, bei der kein RCM UP vorhanden ist, wird die BGP-Verbindungsüberwachung durch die SRP durchgeführt. Dieser Mechanismus funktioniert ähnlich wie die in diesem Punkt geschilderte Erklärung.

Das vorrangige Ziel besteht darin, die Verbindungen zu überwachen. Bei Auftreten dieser Überwachungsfehler ist zunächst festzustellen, warum die Verbindungen nicht überwacht werden. Mögliche Ursachen können BGP-Flaps, Konfigurationsabweichungen bei den zur Überwachung eingetragenen IPs im Vergleich zu den in ihrem jeweiligen Kontext angegebenen IPs oder Probleme mit Paketverlusten sein.

Sx-Klappen

Entsprechend wird, wie für BGP-Flaps erläutert, die Überwachung von Sx-Flaps zwischen CP und UP implementiert. Wird eine Sx-Klappe erkannt, leitet der RCM entsprechend einen Switchover ein.

Errors for Sx flap which can be seen from snmp traps

Thu Apr 28 15:22:55 2022 Internal trap notification 1382 (SxPathFailure) Context Name:gwctx, Service Name:sx-srvc-cp, Self-IP:X.X.X.X, Peer-IP:Y.Y.Y.Y, Old Recovery Timestamp:3854468847, New Recovery Timestamp

Analyse basierend auf RCM-Protokollen und Befehlsausgängen

Protokolle des RCM Controllers:

Monitoring failure for BFD

{"log":"2022/11/12 13:33:31.138  [ERROR] [red.go:2144] [rcm_ctrl.control.main] [handleUpfActiveToDownAction]: UPF 'X.X.X.X' monitor failure, reason UpfMonitor_BFD\n",

Monitoring failure for BGP

{"log":"2022/11/12 15:34:27.644  [ERROR] [red.go:2144] [rcm_ctrl.control.main] [handleUpfActiveToDownAction]: UPF 'X.X.X.X' monitor failure, reason UpfMonitor_BGP\n"

Monitoring failure for Sx

{"log":"2022/11/12 15:34:46.763  [ERROR] [red.go:2144] [rcm_ctrl.control.main] [handleUpfActiveToDownAction]: UPF 'X.X.X.X' monitor failure, reason UpfMonitor_SX\n"

RCM Befehlsausgaben:

rcm show-status
(to check RCM in Master or Backup state)

rcm show-statistics configmgr
(to check number of UPs connected to this configmgr and current stat of about which are the active UPs and standby UPs )

rcm show-statistics controller
(to check number of UPs connected to this controller and current stat of about which are the active UPs and standby UPs )

rcm show-statistics switchover
rcm show-statistics switchover-verbose
(to check which UP got switchovered to which UP and at what time and with what reason)

Beispiele für die Befehlsausgabe:

root@Nodename:
[unknown] ram# ram show-status
message :
{"status”: “MASTER"}


[unknown] rcm# rcm show-statistics switchover
message :
{
  "stats_history": [
    {
      "status": "Success",
      "started": "Mar 21 03:40:37.480",
      "ended": "Mar 21 03:40:41.659",
      "switchoverreason": "BGP Failure",
      "source_endpoint": "X.X.X.X",
      "destination_endpoint": "Y.Y.Y.Y"
    }
  ],

  "num_switchover": 1

}

Es ist wichtig, die Controller-Protokolle abzurufen und sie, wie bereits erwähnt, hinsichtlich aller Switchover-Szenarien sorgfältig zu prüfen. Mit dieser Analyse soll sichergestellt werden, dass der Switchover-Prozess problemlos und problemlos durchgeführt werden konnte.

{"log":"2022/05/10 00:30:48.553  [INFO] [events.go:87] [rcm_ctrl_ep.events.bfdmgr] eventsDbSetCallBack: endpoint X.X.X.X : STATE_UP -\u003e STATE_DOWN\n","stream":"stdout","time":"2022-05-10T00:30:48.553622344Z"}

--------------------Indication of active UP bfd went down

{"log":"2022/05/10 00:30:48.553  [DEBUG] [control.go:2920] [rcm_ctrl.control.main] [stateMachine]: Received Event Endpoint: groupId: 1 endpoint: X.X.X.X status: STATE_DOWN\n","stream":"stdout","time":"2022-05-10T00:30:48.553654666Z"}
{"log":"\n","stream":"stdout","time":"2022-05-10T00:30:48.553661415Z"}
{"log":"2022/05/10 00:30:48.553  [INFO] [red.go:2353] [rcm_ctrl.control.main] [upfHandlUpfAction]: StateChange: UPFAction_ActiveToDown\n","stream":"stdout","time":"2022-05-10T00:30:48.553670033Z"}
{"log":"2022/05/10 00:30:48.553  [ERROR] [red.go:2103] [rcm_ctrl.control.main] [handleUpfActiveToDownAction]: UPF 'X.X.X.X' monitor failure, reason UpfMonitor_BFD\n","stream":"stdout","time":"2022-05-10T00:30:48.55368269Z"}
{"log":"2022/11/12 13:33:27.759  [ERROR] [red.go:2144] [rcm_ctrl.control.main] [handleUpfActiveToDownAction]: UPF 'Z.Z.Z.Z' monitor failure, reason UpfMonitor_BGP\n",
----------- Indication of BFD/BGD timer expired and there is a monitoring failure

{"log":"2022/05/10 00:30:48.553  [WARN] [red.go:2256] [rcm_ctrl.control.main] [handleUpfActiveToDownAction]: upf X.X.X.X Switch over to Y.Y.Y.Y\n","stream":"stdout","time":"2022-05-10T00:30:48.553696821Z"}
---------- Indication of switchover initiated by RCM

{"log":"2022/05/10 00:32:03.555  [DEBUG] [control.go:3533] [rcm_ctrl.control.main] [snmpThread]: SNMP trap raised for : SwitchoverComplete\n","stream":"stdout","time":"2022-05-10T00:32:03.556753903Z"}
{"log":"2022/05/10 00:32:03.603  [DEBUG] [control.go:1885] [rcm_ctrl.control.main] [handleUpfStateMsg]: endpoint: Y.Y.Y.Y State: UpfMsgState_Active RouteModifier: 28 HostID 'Active3'\n","stream":"stdout","time":"2022-05-10T00:32:03.60379131Z"}
{"log":"2022/05/10 00:32:03.603  [DEBUG] [control.go:2048] [rcm_ctrl.control.main] [handleUpfStateMsg]: endpoint: Y.Y.Y.Y OldState: UPFState_Active NewState: UPFState_Active\n","stream":"stdout","time":"2022-05-10T00:32:03.603847124Z"}
---------- Indication of switchover completed and other UP became Active

{"log":"2022/05/10 00:32:03.646  [INFO] [control.go:1054] [rcm_ctrl.control.main] [handleUpfActiveAckMsg]: Subscriber data / Sx messages flowing towards UP 'Y.Y.Y.Y'\n","stream":"stdout","time":"2022-05-10T00:32:03.646883813Z"}
-------------- Traffic routed towards other Active UP

{"log":"2022/05/10 00:32:53.861  [INFO] [red.go:859] [rcm_ctrl.control.main] [handleUpfSetStandby]: Assigning PEND_STANDBY state to UPF 'X.X.X.X'.  Notifies Configmgr, NSO and Redmgrs after receiving State Ack from UPF.\n","stream":"stdout","time":"2022-05-10T00:32:53.862051117Z"}
{"log":"2022/05/10 00:32:53.861  [INFO] [red.go:1681] [rcm_ctrl.control.main] [sendStateToUpf]:send state UpfMsgState_Standby to  upf X.X.X.X  \n","stream":"stdout","time":"2022-05-10T00:32:53.862059689Z"}
{"log":"2022/05/10 00:32:53.890  [INFO] [red.go:1176] [rcm_ctrl.control.main] [handleUpfNotifyMgrs]: Received UpfMsgState_Standby ACK from UPF 'X.X.X.X'. Notifying Configmgr and Redmgrs.\n","stream":"stdout","time":"2022-05-10T00:32:53.890712421Z"}
---------------------- Switchovered UP became Standby

Push-Konfigurationsprobleme zwischen RCM und UPF

• Bei einem von RCM initiierten Switchover von einem UP zu einem anderen UP wird die erforderliche Konfiguration vom RCM übernommen. Um sicherzustellen, dass diese Konfiguration erfolgreich angewendet wird, setzt der RCM einen Timer, um den Vorgang abzuschließen.

• Sobald die Konfiguration verschoben und im Pfad des UPs gespeichert wurde, führt das UP die Konfiguration innerhalb des vom RCM festgelegten Zeitrahmens aus.

• Sobald das UP die Ausführung der Konfiguration abgeschlossen hat, sendet es ein Signal an den RCM. Dieses Signal wird durch einen Ereignisprotokolleintrag in den Syslogs angezeigt, der den erfolgreichen Abschluss des Konfigurations-Pushvorgangs bestätigt.

Nov 13 12:01:09 <NODENAME> evlogd: [local-60sec9.041] [cli 30000 debug] [1/0/10935 <cli:1010935> cliparse.c:571] [context: local, contextID: 1]  [software internal system syslog] CLI command [user rcmadmin, mode [local]INVIGJ02GNR1D1UP12CO]: rcm-config-push-complete
Nov 13 12:01:09 <NODENAME> evlogd: [local-60sec9.041] [cli 30000 debug] [1/0/10935 <cli:1010935> cliparse.c:571] [context: local, contextID: 1]  [software internal system syslog] CLI command [user rcmadmin, mode [local]INVIGJ02GNR1D1UP12CO]: rcm-config-push-complete end-of-config

• Wenn die Ereignisprotokolle in Syslogs angezeigt werden, ist der Konfigurationsprozess abgeschlossen. Wenn dieses Ereignis jedoch nach der Ausführung nach der Konfiguration nicht eintritt, impliziert dies, dass ein Konfigurationsproblem zu einer Verzögerung bei der Fertigstellung führen kann. In solchen Fällen kann ein Timer ablaufen, was zu UP-Neuladevorgängen führt. Der RCM initiiert das Neuladen, wenn er keine Antwort von UP erhält. Dieser Zyklus wird fortgesetzt, bis die Konfiguration erfolgreich abgeschlossen wurde.
• Als temporäre Lösung können Sie einen bestimmten Befehl manuell ausführen, um den Neuladevorgang vorübergehend anzuhalten. Dennoch ist es wichtig, die Ursache des Konfigurationsproblems zu identifizieren, um es dauerhaft zu beheben.

rcm-config-push-complete end-of-config

Faktoren, die zu Konfigurationsproblemen führen

Problematische Konfigurations-CLIs

Identifizieren Sie störende CLIs in der Push-Konfigurationsdatei, die aus RCM ConfigMgr-Protokollen ermittelt werden kann.

SFTP-Probleme

SFTP-bezogene Probleme können auftreten, wenn der RCM versucht, eine Konfiguration zu senden, jedoch Schwierigkeiten beim Herstellen einer Verbindung mit dem UP hat. Diese Probleme können auf Kennwortkomplikationen oder andere Faktoren zurückzuführen sein, die sich auf den SFTP-Betrieb auswirken.

Das Überprüfen der ConfigMgr-Protokolle ermöglicht die Überwachung des SFTP-Status und die Identifizierung von Konfigurationsfehlern. Nachfolgend finden Sie eine Beispieldarstellung typischer Fehlerinstanzen.

{"log":"2022/11/12 23:53:09.066 rcm-configmgr [DEBUG] [sshclient.go:395] [rcm_grpc_ep.msg-process.Int] Initiate a sftp connection to host: X.X.X.X \n","stream":"stdout","time":"2022-11-12T23:53:09.067894173Z"}
{"log":"2022/11/12 23:53:09.066 rcm-configmgr [DEBUG] [sftpClient.go:26] [rcm_grpc_ep.grpc.Int] Conneting to host X.X.X.X for sftp with src path: /cfg/ConfigMgr/upfconfig10-103-108-154_22.cfg and dst path: /sftp/10-103-108-154_22.cfg \n","stream":"stdout","time":"2022-11-12T23:53:09.067903156Z"}
{"log":"2022/11/12 23:53:09.203 rcm-configmgr [DEBUG] [sftpClient.go:58] [rcm_grpc_ep.grpc.Int] Successfully opened the  file%!(EXTRA string=/cfg/ConfigMgr/upfconfig10-103-108-154_22.cfg)\n","stream":"stdout","time":"2022-11-12T23:53:09.203698078Z"}
{"log":"2022/11/12 23:53:09.211 rcm-configmgr [DEBUG] [sftpClient.go:66] [rcm_grpc_ep.grpc.Int] Total bytes copied 405933: \n","stream":"stdout","time":"2022-11-12T23:53:09.212063509Z"}

2022-May-16+17:45:02.834 [cli 30005 info] [1/0/14263 <cli:1014263> _commands_cli.c:1474] [software internal system syslog] CLI session ended for Security Administrator admin on device /dev/pts/5
2022-May-16+17:45:02.834 [cli 30024 error] [1/0/14263 <cli:1014263> cli.c:1657] [software internal system syslog] Misc error: Password change required rc=0
2022-May-16+17:45:02.834 [cli 30087 info] [1/0/14263 <cli:1014263> cli.c:1352] [software internal system critical-info syslog] USER user 'admin' password has expired beyond grace period
2022-May-16+17:45:02.594 [cli 30004 info] [1/0/14263 <cli:1014263> cli_sess.c:164] [software internal system syslog] CLI session started for Security Administrator admin on device /dev/pts/5 from X.X.X.X
2022-May-16+17:45:02.537 [cli 30028 debug] [1/0/9816 <vpnmgr:1> luser_auth.c:1598] [context: local, contextID: 1] [software internal system syslog] Login attempt failure for user admin IP address X.X.X.X - Access type ssh/sftp

Wenn aufgrund von Kennwörtern SFTP-Probleme auftreten, sollten Sie ein neues Kennwort generieren oder den Ablaufzeitraum für Kennwörter verlängern.

Wenn Kennwortprobleme ausgeschlossen werden, überprüfen Sie die Anzahl der gleichzeitigen SFTP-Sitzungen, da eine übermäßige Anzahl von Sitzungen zu SFTP-Unterbrechungen führen kann.