사용자 플레인 노드 다시 로드 사례 트러블슈팅

소개

이 문서에서는 문제를 해결하기 위해 증상을 기반으로 사용자 평면(UP) 다시 로드에 대한 다양한 시나리오를 식별하는 프로세스에 대해 설명합니다.

약어

RCM - Redundancy Configuration Manager

SSD - 지원 세부사항 표시

UPF/UP - 사용자 평면 기능

VPP - 벡터 패킷 처리

BFD - 양방향 포워딩 탐지

UP 재로드로 이어질 수 있는 시나리오

1. RCM과 UPF 간의 Configuration Push 문제
2. BFD, BGP 또는 Sx 플랩
3. VPP 충돌 또는 Essmgr 충돌

증상 식별에 필요한 로그

• RCM 로그(Controller/ConfigMgr)
• Syslog
• SNMP(Simple Network Management Protocol) 트랩
• RCM 명령 출력
• Show Support Details (SSDs)(지원 세부사항 표시) - 사용 가능한 경우, 다시 로드 전후의 SSD

증상 분석 및 식별

UP 다시 로드 시나리오의 증상을 식별하는 접근 방식:

CUPS 설정에서 UP 다시 로드 시나리오에는 효과적인 증상 식별 및 후속 문제 해결을 요구하는 문제가 자주 발생합니다.

프로세스를 시작하려면 시스템 업타임을 검사하여 마지막 UP 재시작의 정확한 시간을 확인합니다. 이 정보는 다시 로드 이벤트에 해당하는 RCM 로그를 중점적으로 분석할 수 있게 합니다.

이 명령을 사용하여 다음과 같이 시스템 가동 시간을 확인합니다.

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

다시 로드 시간 중에 충돌이 발생했는지 확인합니다. 다음 명령을 사용하여 충돌 발생을 확인할 수 있습니다.

******** 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 

이 단계에서는 vpp/essmgr 충돌과 같은 충돌이 발생했는지 여부를 검토해야 합니다. vpp 충돌이 감지되면 충돌로 인해 UP가 즉시 다시 로드되므로 RCM에서 다른 UP로의 전환을 시작하라는 메시지가 표시됩니다.

esmgr crash의 일관된 시퀀스가 있는 경우 VPP 충돌이 트리거되어 UP가 다시 로드될 수 있습니다.

작업 계획: 코어 파일 또는 미니코어를 얻은 후 다음 단계는 코어 파일 디버깅을 수행하여 충돌의 근본 원인을 찾아내는 것입니다.

UP syslogs/snmp 기반 분석 

BFD 모니터링의 BFD 변동 또는 장애

BFD 모니터링 실패와 관련된 syslog에서 발견된 오류에 대해서는 다음에서 설명합니다.

이러한 오류는 RCM과 UP 간에 BFD 플랩 또는 패킷 손실이 있을 때, 특히 ACI가 이들 간의 연결에 관여할 때 발생합니다.

기본적으로 타이머는 BFD 패킷을 모니터링하도록 구성됩니다. 어떤 이유로든 이 타이머가 만료되면 모니터링 실패를 트리거합니다. 이 이벤트는 RCM에 전환을 시작하라는 메시지를 표시합니다.

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. 

이를 해결하려면 시스템에 대한 종합적인 검토를 수행하고 BFD 플랩을 일으켰을 수 있는 잠재적인 문제를 파악하는 것이 중요합니다. 문제가 있는 타임스탬프를 정확하게 파악한 경우, 해당 타임스탬프에 해당하는 플랩이나 문제가 엔드포인트에 있었는지 여부를 조사하기 위해 ACI와 조정해야 합니다.

BGP 플랩 또는 BGP 모니터링 실패

UP 내의 BGP 플랩 또는 모니터링 실패는 RCM에 의해 시작된 전환을 트리거할 수 있습니다. 이러한 특정 오류의 특징은 여기에 설명되어 있습니다.

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. 컨텍스트 ID를 사용하여 BGP 플랩을 나타내는 오류와 관련된 컨텍스트를 식별하여 프로세스를 시작합니다. 컨텍스트가 설정되면 관련된 특정 서비스를 정확하게 확인하고 해당 IP 세부 정보를 검색할 수 있습니다.
2. 제공된 정보를 사용하여 UP(User Plane) 및 ACI/Nexus 구성 요소의 문제를 공동으로 해결합니다. 이러한 협업 접근 방식은 BGP 플래핑의 근본 원인을 정확하게 파악하는 데 목적이 있습니다.
3. BGP 플래핑의 이러한 인스턴스는 BGP 모니터링 실패로 이어질 수 있으므로 RCM(Redundancy Configuration Manager)에 전환을 시작하라는 프롬프트가 표시됩니다.
4. BGP 모니터링 실패는 BGP에 대한 모니터링 프로세스에서 문제가 발생하여 BGP 연결의 지속적이고 예상되는 기능을 보장할 수 없는 상황을 의미합니다.

RCM 기반 CUPS 설정과 ICSR 기반 CUPS 설정 모두에서 UP 내에 개별 컨텍스트가 생성됩니다. 예를 들어, RCM 설정에서 "rcm" 컨텍스트는 UP 내에 설정되는 반면, ICSR 설정에서는 "srp" 컨텍스트를 생성합니다. 다음은 RCM 기반 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

두 컨피그레이션 모두에서 모니터링은 각각의 컨텍스트 내에서 BGP에 대해 구현됩니다(BFD에 대한 모니터링과 유사).

각 모니터링 인스턴스에는 고유한 그룹 번호가 할당되고 고유한 서비스에는 별도의 그룹 번호가 할당됩니다. 예를 들어, RCM 컨텍스트에서 "SGi"는 그룹 번호 3에 연결되고, "SGi IPv6"는 그룹 번호 4에 연결되며, "Li"는 그룹 번호 5에 연결됩니다.

제공된 컨피그레이션을 기반으로 RCM 설정에서는 이 컨텍스트 내에서 지정된 BGP 링크를 모니터링합니다. 이러한 BGP 링크 중 하나라도 플래핑을 경험하거나 BGP 링크를 탐지하는 데 어려움이 있는 경우 모니터링에 오류가 발생할 수 있습니다. RCM UP이 없는 ICSR 설정에서 BGP 링크 모니터링은 SRP에 의해 수행됩니다. 이 메커니즘은 이 점에서 개략적으로 설명하는 것과 유사하게 기능한다.

주요 목적은 링크를 감독하는 것입니다. 이러한 모니터링 오류가 발생할 경우, 초기 단계는 링크가 모니터링되지 않는 이유를 확인하는 것입니다. 가능한 원인으로는 BGP 플랩, 모니터링에 등록된 IP의 컨피그레이션 불일치, 해당 컨텍스트에 지정된 IP 또는 패킷 손실 문제가 있을 수 있습니다.

Sx 플랩

마찬가지로, BGP 플랩에 대해 설명한 것처럼 CP와 UP 간의 Sx 플랩에 대한 모니터링이 구현됩니다. Sx 플랩이 감지되면 RCM은 그에 따라 전환을 시작합니다.

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

RCM 로그 및 명령 출력 기반 분석

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"

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)

명령 출력의 예:

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

}

앞서 설명한 대로 컨트롤러 로그를 가져와서 모든 전환 시나리오에서 신중하게 검토하는 것이 중요합니다. 본 분석은 전환 프로세스가 문제없이 원활하게 실행되었는지 확인하는 것을 목표로 한다.

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

RCM과 UPF 간의 Configuration Push 문제

• RCM에 의해 시작된 한 UP에서 다른 UP로의 전환 중에 필요한 컨피그레이션은 RCM에 의해 푸시됩니다. 이 컨피그레이션이 성공적으로 적용되도록 RCM은 프로세스를 완료할 타이머를 설정합니다.

• 구성이 UP의 경로에 푸시되어 저장되면 UP는 RCM에 의해 정의된 지정된 시간 프레임 내에 구성을 실행합니다.

• UP가 컨피그레이션 실행을 완료하면 RCM에 신호를 보냅니다. 이 신호는 syslog의 이벤트 로그 항목으로 표시되며 컨피그레이션 푸시가 성공적으로 완료되었음을 확인합니다.

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

• 이벤트 로그가 syslogs에 표시되면 컨피그레이션 프로세스가 완료되었음을 나타냅니다. 그러나 사후 컨피그레이션 실행 후 이 이벤트가 없을 경우 컨피그레이션 문제로 인해 완료가 지연될 수 있습니다. 이러한 경우 타이머가 만료되어 UP가 다시 로드될 수 있습니다. RCM은 UP에서 응답을 받지 못하면 다시 로드를 시작합니다. 이 주기는 컨피그레이션이 성공적으로 완료될 때까지 계속됩니다.
• 임시 솔루션으로서 특정 명령을 수동으로 실행하여 다시 로드 프로세스를 일시적으로 중지할 수 있습니다. 그럼에도 불구하고 구성 문제의 근본 원인을 정확히 찾아내야 영구적으로 해결할 수 있습니다.

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

컨피그레이션 문제의 원인

문제가 있는 컨피그레이션 CLI

RCM ConfigMgr 로그에서 확인할 수 있는 푸시된 컨피그레이션 파일 내에서 문제 있는 CLI를 식별합니다.

SFTP 문제

SFTP 관련 문제는 RCM에서 컨피그레이션을 보내려고 하지만 UP와의 연결 설정에 문제가 있을 때 발생할 수 있습니다. 이러한 문제는 비밀번호 복잡성 또는 SFTP 운영에 영향을 미치는 기타 요인에서 비롯될 수 있습니다.

ConfigMgr 로그를 검토하면 SFTP 상태를 모니터링하고 구성 오류를 확인할 수 있습니다. 다음은 일반적인 오류 인스턴스의 샘플 표현입니다.

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

비밀번호로 인해 SFTP 문제가 발생할 경우 새 비밀번호를 생성하거나 비밀번호 만료 기간을 연장하는 것이 좋습니다.

비밀번호 문제가 제외된 경우 동시 SFTP 세션 수를 검사합니다. 세션 수가 너무 많으면 SFTP 중단이 발생할 수 있습니다.