소개
이 문서에서는 RCM의 UPF 상태 불일치와 관련된 문제에 대해 설명합니다.
사전 요구 사항
요구 사항
이 문서에 대한 특정 요건이 없습니다.
사용되는 구성 요소
이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.
- RCM(Redundancy Configuration Manager)
- 사용자 평면 기능(UPF/UP)
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
로그 수집
RCM
1단계. 일부 명령 출력 캡처
먼저 문제가 되는 UP와 문제의 패턴을 파악해야 합니다. 어떤 UP가 전환을 경험했는지 파악하고 현재 문제가 어디에 있는지를 파악하기 위해서는 전환 이유를 문서화하는 것이 필수적이다.
rcm show-statistics switchover
rcm show-statistics switchover-verbose
rcm show-statistics configmgr --------------- to check how many UPs are registered for config push
rcm show-statistics controller --------------- to check no of UPs and its states registered with controller
2단계. 컨트롤러 및 Configmgr 로그 수집
문제가 있는 UP를 식별하면 컨트롤러 로그와 configmgr 로그를 수집하여 전환의 원인이 무엇이었는지, UP가 보류 중 상태로 유지되는 동안 무엇이 잘못되었는지 확인할 수 있습니다.
로그 수집 절차는 RCM Log Collection 링크를 참조하십시오.
위로
문제가 있는 타임스탬프에 대한 SSD, Syslogs 및 SNMP 트랩은 문제가 시작되기 최소 2시간 전에 시간 프레임을 다룹니다.
문제 해결
UP가 Pending(보류 중) 상태로 설정되는 시나리오
- 일반적으로 모든 UP는 컨트롤러를 통해 RCM에 등록됩니다
- 컨트롤러는 UP에서 수신한 UP 상태와 RCM에서 할당한 상태를 유지 관리하고 컴파일합니다
rcm show-statistics controller
message :
{
"keepalive_version": "f1ab207c5d3120f8a4286b999b9f4cd207034e7c61e204d74e41f48578c476de",
"keepalive_timeout": "20s",
"num_groups": 2,
"groups": [
{
"groupid": 1,
"endpoints_configured": 7,
"standby_configured": 1,
"pause_switchover": false,
"active": 2,
"standby": 0,
"endpoints": [
{
"endpoint": "X.X.X.X", -------- UP IP
"bfd_status": "STATE_UP",
"upf_registered": true,
"upf_connected": true,
"upf_state_received": "UpfMsgState_Active",
"bfd_state": "BFDState_UP",
"upf_state": "UPFState_PendActive",
"route_modifier": 32,
"pool_received": false,
"echo_received": 253,
"management_ip": "X.X.X.X",
"host_id": "SEUD2413",
"ssh_ip": "Y.Y.Y.Y",
"force_nso_registration": false
},
컨트롤러 통계에서 관찰되는 경우 컨트롤러가 유지 관리하는 상태가 다르며 각 UP 상태는 고유한 의미를 갖습니다.
BFD state(BFD 상태) - RCM과 UP 사이의 BFD 상태를 나타냅니다(UF 상태라고 하지는 않으며 BFD 상태만 해당).
UPF state(UPF 상태) - RCM에 있는 UPF의 현재 상태입니다
UPF state received - UP가 RCM을 향해 보낸 UP 상태
- 플로우에 따라 일반적으로 Active UP에서 Standby UP로의 전환이 있을 때마다 RCM은 여기에서 설명한 원활한 전환을 위해 특정 절차를 거쳐야 합니다.
1. 이전 UP에서 Checkpointmgr 플러시 및 새 Active UP와 검사점 동기화
2. 컨피그레이션 플러시
3. 컨피그레이션 푸시
4. UP 상태 관리
UP 쌍의 예를 UP-A(Active UP) 및 UP-B(Standby-UP)로 간주하고, 활성 및 대기 상태가 되기 전에 전환이 있을 경우 먼저 보류 상태가 됩니다.
UP-A(Active UP) --------------------- PendStandby ---------------------- Standby
UP-B(대기 UP) ------------------- PendActive ---------------------- Active
액티브/스탠바이가 되기 전에 알 수 있듯이, 원활한 전환을 위해 RCM과 UP 간에 언급된 절차 트랜잭션이 발생하고 있습니다.
- Active에서 Standby로 또는 그 반대로 전환이 이루어질 때마다 RCM은 Active가 되는 UP의 Active UP 컨피그레이션을 푸시하고 Standby가 되는 UP의 Standby UP 컨피그레이션을 푸시하는 컨피그레이션 푸시를 수행해야 합니다.
Note :: In Standby UP normally RCM push all the UP config which are currently active so that whenever this UP becomes active it removes all the unwanted config
- 전환이 시작되면 즉시 RCM의 타이머 값은 15분이며(구성된 값에 따라 다름) 이 타이머 값 내에서 구성 푸시가 완료되면 전환이 완료되어야 합니다.
- 경우에 따라 타이머가 만료되고 RCM이 UP에 대한 재로드를 시작하는 시간 내에 config push가 완료되지 않을 경우. 컨피그레이션 푸시가 완료될 때까지 계속됩니다.
- 따라서 RCM이 구성을 UP로 푸시할 때 UP로부터 구성 완료 신호를 기다리고 있는데, 이는 RCM이 구성 푸시가 완료되었음을 이해하고 이를 성공적으로 전환한 것으로 간주하는 것입니다.
구성 푸시가 완료되면 syslog 및 SNMP 트랩에서 볼 수 있는 로그입니다.
Syslogs
Nov 13 12:01:09 INVIGJ02GNR1D1UP12CO 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 INVIGJ02GNR1D1UP12CO 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
SNMP
Fri Mar 24 09:59:01 2023 Internal trap notification 1425 (RCMTCPConnect) Context Name: rcm
Fri Mar 24 09:59:01 2023 Internal trap notification 1421 (RCMConfigPushCompleteSent) Context Name: rcm
Fri Mar 24 09:59:01 2023 Internal trap notification 1426 (RCMChassisState) RCM Chassis State: (2) Chassis State Standby
Fri Mar 24 09:59:04 2023 Internal trap notification 1276 (BFDSessionUp) vpn n6 OurAddr fc00:10:5:132::10 NeighborAddr fc00:10:5:132::254 Session(6/1090552866), Diagnostic code 0 PhyPortId 0
- 그러나 컨피그레이션 푸시 완료에 시간이 걸려 타이머 값이 만료되는 문제가 발생하는 경우 UP의 이러한 문제가 Pending(보류 중) 상태로 유지됩니다.
- RCM에서 config push completion 상태를 가져오지 못했으므로 전환이 완료되지 않은 것으로 간주하고 UP를 Pending 상태로 유지합니다.
- 컨피그레이션 푸시 문제의 다양한 원인은 UP Reload Cause(UP 다시 로드 원인)에서 설명합니다.
해결 방법
1. 이 명령을 사용하여 일시적으로 UP에서 RCM으로 config push complete 신호를 실행하여 UP를 액티브/스탠바이 상태로 되돌릴 수 있습니다.
rcm-config-push-complete end-of-config
2. 앞에서 설명한 이 해결 방법은 UP Reload Cause(UP 다시 로드 원인)에 설명된 컨피그레이션 푸시에 시간이 걸리는 문제를 식별하기 위한 임시적인 조치입니다.
피드백