El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe el proceso para identificar diferentes escenarios para recargas del Plano de usuario (UP) basadas en los síntomas para resolver el problema.
RCM - Administrador de configuración de redundancia
SSD - Mostrar detalles de soporte
UPF/UP: función de plano de usuario
VPP - Procesamiento de paquetes vectoriales
BFD - Detección de reenvío bidireccional
Enfoque para identificar síntomas de escenarios de recarga de UP:
En una configuración de CUPS, los escenarios de recarga de UP a menudo se enfrentan a desafíos, lo que exige una identificación eficaz de los síntomas y la subsiguiente resolución de problemas.
Para iniciar el proceso, examine el tiempo de actividad del sistema para determinar la hora exacta del último reinicio ascendente. Esta información facilita un análisis específico de los registros de RCM correspondientes al evento de recarga.
Utilice este comando para verificar el tiempo de actividad del sistema de la siguiente manera:
******** show system uptime *******
Friday July 22 09:28:14 IST 2022
System uptime: 0D 0H 6M
Nota: compruebe que las marcas de hora RCM y UP estén sincronizadas con la misma zona horaria. Si hay alguna discrepancia, realice las correlaciones necesarias. Por ejemplo, si el tiempo de ACTIVIDAD está en IST y el tiempo del RCM en UTC, tenga en cuenta que el tiempo del RCM se encuentra sistemáticamente 5:30 horas por detrás del tiempo de ACTIVIDAD.
Verifique si se ha producido algún desperfecto durante el tiempo de recarga. Puede utilizar este comando para comprobar si se producen bloqueos:
******** 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
En este paso, debe examinar si se ha producido algún desperfecto, como desperfecto de vpp/sessmgr. Si se detecta un desperfecto de vpp, la UP se recarga inmediatamente debido al desperfecto, lo que indica al RCM que inicie un switchover a otra UP.
Si hay una secuencia consistente de desperfectos de sessmgr, puede potencialmente desencadenar un desperfecto de VPP, lo que resulta en una recarga de la UP.
Siempre que encuentre tales desperfectos, asegúrese de reunir los archivos de núcleo para vpp/sessmgr.
Nota: En el caso de vpp, un minicore podría ser accesible en lugar de un archivo de núcleo completo.
Plan de Acción: Una vez que obtenga el archivo de núcleo o minicore, el siguiente paso es realizar la depuración del archivo de núcleo para identificar la causa raíz del desperfecto.
Aquí se explican los errores encontrados en los registros del sistema relacionados con fallas de monitoreo BFD.
Estos errores surgen cuando hay una inestabilidad BFD o pérdida de paquetes entre el RCM y UP, especialmente en los casos en que ACI está involucrado en la conexión entre ellos.
Básicamente, se configura un temporizador para monitorear los paquetes BFD. Si, por cualquier razón mencionada, este temporizador caduca, se activa una falla de monitoreo. Este evento solicita al RCM que inicie un switchover.
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.
Para abordar este problema, es importante llevar a cabo un examen exhaustivo del sistema e identificar cualquier problema potencial que pueda haber causado la inestabilidad de la BFD. Si se establece una marca de tiempo problemática, es necesaria la coordinación con ACI para investigar si hubo alguna inestabilidad o problemas en su extremo que correspondan a esa marca de tiempo.
Los flaps BGP o los fallos de supervisión dentro de UP pueden activar un switchover iniciado por RCM. Estos errores específicos se caracterizan como se describe aquí.
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.
Posibles factores que contribuyen a los flaps BGP y métodos para identificarlos. Las trampas SNMP podrían revelar errores que indican incidencias de inestabilidad BGP:
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.
Tanto en las configuraciones CUPS basadas en RCM como en las basadas en ICSR, se crean contextos individuales dentro de las UP. Por ejemplo, en una configuración de RCM, el contexto "rcm" se establece dentro de la UP, mientras que una configuración de ICSR implica la creación del contexto "srp". Este es un ejemplo de configuración para CUPS basado en 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
En ambas configuraciones, el monitoreo se implementa para BGP (similar al monitoreo para BFD) dentro de sus respectivos contextos.
A cada instancia de supervisión se le asigna un número de grupo único y a los distintos servicios se les asignan números de grupo independientes. Por ejemplo, en el contexto del RCM, "SGi" está asociado con el grupo número 3, "SGi IPv6" está vinculado con el grupo número 4 y "Li" está conectado con el grupo número 5.
Utilizando la configuración proporcionada como base, la configuración del RCM implica monitorear los links BGP especificados dentro de este contexto. La supervisión puede encontrar una falla si alguno de estos links BGP experimenta inestabilidad o si hay dificultades para detectar el link BGP. En una configuración ICSR, donde no hay RCM UP, el SRP lleva a cabo el monitoreo de link BGP. Este mecanismo funciona de manera similar a la explicación descrita en este punto.
El objetivo principal es supervisar los enlaces. Al encontrar estos errores de monitoreo, el paso inicial es determinar las razones detrás de los links que no están siendo monitoreados. Las causas posibles podrían incluir inestabilidad de BGP, discrepancias de configuración en las IPs registradas para monitoreo frente a las IPs especificadas en sus respectivos contextos, o problemas de pérdida de paquetes.
De manera similar, como se explicó para las inestabilidad BGP, se implementa la supervisión de las inestabilidad SX entre CP y UP. Si se detecta una inestabilidad Sx, el RCM inicia un switchover en consecuencia.
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
Registros del controlador 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"
Resultados 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)
Ejemplos del resultado 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
}
Es importante obtener los registros del controlador y revisarlos cuidadosamente para cualquier escenario de switchover, como se discutió anteriormente. El objetivo de este análisis es garantizar que el proceso de switchover se ejecutó sin problemas y sin problemas.
{"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
Durante un switchover de un UP a otro UP iniciado por el RCM, el RCM envía la configuración necesaria. Para garantizar que esta configuración se aplica correctamente, RCM establece un temporizador para completar el proceso.
Una vez que la configuración se inserta y se almacena en la ruta de la UP, la UP ejecuta la configuración dentro del marco de tiempo especificado definido por el RCM.
Una vez que la UP completa la ejecución de la configuración, envía una señal al RCM. Esta señal se indica mediante una entrada de registro de eventos en los registros del sistema, lo que confirma la finalización correcta de la transferencia de la configuración.
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
rcm-config-push-complete end-of-config
Identifique las CLI problemáticas dentro del archivo de configuración insertado, que se puede determinar a partir de los registros de RCM ConfigMgr.
Los problemas relacionados con SFTP pueden ocurrir cuando el RCM intenta enviar la configuración pero tiene dificultades para establecer una conexión con el UP. Estos retos pueden deberse a complicaciones relacionadas con las contraseñas u otros factores que afectan a las operaciones de SFTP.
La revisión de los registros de ConfigMgr permite supervisar el estado de SFTP e identificar errores de configuración. A continuación se muestra una representación de ejemplo de instancias de error típicas.
Los registros de SFTP en los registros de ConfigMgr de RCM aparecen como:
{"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"}
Vencimiento de la contraseña durante SFTP observado en los registros del sistema UP:
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
Si surgen problemas de SFTP debido a las contraseñas, considere la posibilidad de generar una nueva contraseña o ampliar el período de caducidad de la contraseña.
Si se descartan los problemas de contraseña, examine el número de sesiones SFTP simultáneas, ya que un número excesivo de sesiones puede provocar interrupciones SFTP.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
14-Aug-2023 |
Versión inicial |