Risoluzione dei problemi relativi ai casi di ricaricamento dei nodi dei piani utente

Introduzione

Questo documento descrive il processo per identificare diversi scenari per i ricaricamenti del piano utente (UP) in base ai sintomi per risolvere il problema.

Acronimi

RCM - Gestione configurazione ridondanza

SSD - Mostra dettagli supporto

UPF/UP - Funzione User Plane

VPP - Elaborazione pacchetti vettoriali

BFD - Rilevamento inoltro bidirezionale

Scenari possibili che portano al ricaricamento

1. Problema di Push della configurazione tra RCM e UPF
2. BFD, BGP o Sx Flap
3. Arresto anomalo di VPP o arresto anomalo di Sessmgr

Registri necessari per l'identificazione dei sintomi

• Registri di RCM (Controller/ConfigMgr)
• Syslog
• Trap SNMP (Simple Network Management Protocol)
• Output dei comandi di RCM
• Mostra dettagli supporto (SSD) - Se disponibili, SSD prima e dopo il ricaricamento

Analisi e identificazione dei sintomi

Approccio per identificare i sintomi degli scenari di ricarica UP:

In una configurazione CUPS, gli scenari di ricaricamento UP incontrano spesso problemi, richiedendo un'identificazione efficace dei sintomi e la successiva risoluzione dei problemi.

Per avviare il processo, esaminare il tempo di attività del sistema per individuare l'ora esatta dell'ultimo riavvio UP. Queste informazioni semplificano l'analisi mirata dei registri RCM corrispondenti all'evento reload.

Utilizzare questo comando per verificare il tempo di attività del sistema nel modo seguente:

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

Verificare se si sono verificati arresti anomali durante il tempo di ricarica. È possibile utilizzare questo comando per verificare le occorrenze di un arresto anomalo del sistema:

******** 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 questo passaggio sarà necessario verificare se si sono verificati arresti anomali, ad esempio arresti anomali di vpp/sessmgr. Se viene rilevato un arresto anomalo del vpp, l'UP si ricarica immediatamente a causa dell'arresto anomalo, richiedendo a RCM di avviare il passaggio a un altro UP.

Se è presente una sequenza coerente di arresti anomali di sessmgr, è possibile che si verifichi un arresto anomalo del VPP, con conseguente ricaricamento dell'UP.

Piano d'azione: una volta ottenuto il file di base o il minicore, il passo successivo è eseguire il debug dei file di base per individuare la causa principale dell'arresto anomalo.

Analisi basata su UP syslogs/snmp 

Fluttuazioni o errori BFD nel monitoraggio BFD

Gli errori rilevati nei syslog relativi a errori di monitoraggio BFD sono spiegati qui.

Questi errori si verificano quando tra RCM e UP si verifica un flap BFD o una perdita di pacchetti, in particolare nei casi in cui il collegamento tra RCM e UP coinvolge l'ACI.

Fondamentalmente, un timer è configurato per monitorare i pacchetti BFD. Se, per qualsiasi ragione, il timer scade, si verifica un errore di monitoraggio. Questo evento richiede a RCM di avviare un passaggio.

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. 

Per affrontare questo problema è importante condurre un esame completo del sistema e identificare eventuali problemi potenziali che potrebbero aver causato il bap della DCF. Se viene individuato un timestamp problematico, è necessario un coordinamento con l'ACI per verificare se alla fine sono presenti flap o problemi corrispondenti a tale timestamp.

Errore di monitoraggio BGP Flaps o BGP

Gli sfarfallii BGP o gli errori di monitoraggio all'interno di UP possono attivare un passaggio avviato da RCM. Questi errori specifici sono caratterizzati come descritto di seguito.

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. Avviare il processo identificando il contesto associato all'errore che indica i flap BGP, utilizzando l'ID contesto. Una volta stabilito il contesto, è possibile determinare con precisione il particolare servizio interessato e recuperare i dettagli IP corrispondenti.
2. Utilizzare le informazioni fornite per risolvere in modo collaborativo i problemi relativi ai componenti User Plane (UP) e ACI/Nexus. Questo approccio collaborativo mira a identificare con precisione la root cause del flapping dei BGP.
3. Queste istanze di flapping BGP possono causare errori di monitoraggio BGP, richiedendo a Gestione configurazione ridondanza (RCM) di avviare uno switchover.
4. L'errore di monitoraggio BGP si riferisce a una situazione in cui il processo di monitoraggio per BGP incontra dei problemi che impediscono di garantire la funzionalità continua e prevista delle connessioni BGP.

Sia nelle configurazioni CUPS basate su RCM che nelle configurazioni CUPS basate su ICSR, vengono creati contesti individuali all'interno delle UP. Ad esempio, in un'installazione di RCM, il contesto "rcm" viene definito all'interno dell'UP, mentre un'installazione di ICSR implica la creazione del contesto "srp". Di seguito è riportato un esempio di configurazione per CUPS basate su RCM:

******** 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 entrambe le configurazioni, il monitoraggio è implementato per BGP (simile al monitoraggio per BFD) all'interno dei rispettivi contesti.

A ogni istanza di controllo viene assegnato un numero di gruppo univoco e a servizi distinti vengono assegnati numeri di gruppo distinti. Ad esempio, nel contesto di RCM, "SGi" è associato al gruppo numero 3, "SGi IPv6" è collegato al gruppo numero 4 e "Li" è collegato al gruppo numero 5.

Utilizzando la configurazione fornita come base, la configurazione di RCM prevede il monitoraggio dei collegamenti BGP specificati in questo contesto. Il monitoraggio può incontrare errori se uno di questi link BGP sperimenta flapping o se ci sono difficoltà nel rilevare il link BGP. In una configurazione ICSR, dove RCM UP è assente, il monitoraggio del collegamento BGP viene eseguito da SRP. Questo meccanismo funziona in modo simile alla spiegazione di cui al presente punto.

L'obiettivo principale è quello di controllare i collegamenti. Quando si verificano questi errori di monitoraggio, la fase iniziale consiste nell'accertare i motivi alla base del mancato monitoraggio dei link. Le cause possibili possono includere i flap BGP, le discrepanze di configurazione negli IP integrati per il monitoraggio rispetto agli IP specificati nei rispettivi contesti o problemi di perdita dei pacchetti.

Sx Flaps

Analogamente, come spiegato per i flap BGP, è implementato il monitoraggio dei flap Sx tra PC e UP. Se viene rilevato un flap Sx, RCM avvia di conseguenza lo switchover.

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

Analisi basata sui log di RCM e sugli output dei comandi

Registri controller RCM:

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"

Output del comando RCM:

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)

Esempi di output del comando:

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

}

È importante ottenere i registri dei controller e analizzarli attentamente per verificare eventuali scenari di switchover, come descritto in precedenza. L'analisi mira a garantire che il processo di switchover sia stato eseguito senza problemi e senza interruzioni.

{"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

Problemi di Push della configurazione tra RCM e UPF

• Durante il passaggio da una UP a un'altra UP avviato da RCM, RCM esegue il push della configurazione necessaria. Per garantire la corretta applicazione di questa configurazione, RCM imposta un timer per completare il processo.

• Una volta che la configurazione è stata inserita e memorizzata nel percorso della UP, la UP esegue la configurazione entro l'intervallo di tempo specificato definito da RCM.

• Al termine dell'esecuzione della configurazione, UP invia un segnale a RCM. Questo segnale è indicato da una voce del registro eventi nei syslog, che conferma il completamento del push di configurazione.

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

• Quando i registri eventi vengono visualizzati nei syslog, indica che il processo di configurazione è stato completato. Tuttavia, se questo evento non è presente dopo l'esecuzione successiva alla configurazione, è possibile che un problema di configurazione causi un ritardo nel completamento. In questi casi, un timer può scadere e portare a ricariche. RCM avvia il ricaricamento quando non riceve una risposta da UP. Questo ciclo continua fino al completamento della configurazione.
• Come soluzione temporanea, è possibile eseguire manualmente un comando specifico per interrompere temporaneamente il processo di ricaricamento. Tuttavia, è fondamentale individuare la root cause del problema di configurazione per risolverlo in modo permanente.

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

Fattori che causano problemi di configurazione

CLI di configurazione con problemi

Identificare le CLI con problemi all'interno del file di configurazione push, che possono essere determinate dai log di RCM ConfigMgr.

Problemi SFTP

I problemi relativi a SFTP possono verificarsi quando RCM tenta di inviare la configurazione ma incontra difficoltà nel stabilire una connessione con UP. Queste problematiche possono derivare da complicazioni delle password o da altri fattori che influiscono sulle operazioni SFTP.

L'analisi dei log di ConfigMgr consente il monitoraggio dello stato SFTP e l'identificazione degli errori di configurazione. Di seguito è riportata una rappresentazione di esempio delle istanze di errore tipiche.

{"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

Se i problemi SFTP derivano dalle password, è consigliabile generare una nuova password o estendere il periodo di scadenza della password.

Se i problemi relativi alle password sono esclusi, esaminate il numero di sessioni SFTP simultanee, in quanto un numero eccessivo di sessioni può causare interruzioni SFTP.