簡介
本檔案將說明與RCM中的UPF狀態不相符相關的問題。
必要條件
需求
本文件沒有特定需求。
採用元件
本文中的資訊係根據以下軟體和硬體版本：
- 備援組態管理員(RCM)
- 使用者平面功能(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日誌收集連結。
UP
問題時間戳的SSD、Syslogs和SNMP陷阱在問題開始前至少涵蓋兩個小時的時間範圍。
疑難排解
UP停滯在「待處理」狀態的場景
- 通常，每個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狀態 — 指示RCM和UP之間的BFD狀態（不要將其稱為UF狀態，它僅是BFD狀態）
UPF state - RCM中UPF的當前狀態
UPF state received - UP向RCM傳送的UP狀態
- 按照一般流程，每當從主用到備用切換時，RCM必須執行下面提到的某些平滑切換過程：
1. Checkpointmgr從舊的UP刷新並與新的活動UP同步檢查點
2.配置刷新
3.配置推送
4.管理UP狀態
考慮UP對作為UP-A（主用UP）和UP-B（備用UP）的示例，當在進入主用和備用狀態之前進行切換時，它首先進入掛起狀態。
UP-A（主用UP）--------------------- PendStandby ---------------------- Standby
UP-B（備用UP）------------------- PendActive ---------------------- Active
正如在變為主用/備用之前所看到的，上述程式事務在RCM和UP之間發生，以便順利切換。
- 每當從主用切換為備用（反之亦然）時，RCM必須執行配置推送，推送UP中的主用UP配置成為主用，推送UP中的備用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。 此過程將一直持續，直到配置推送完成。
- 因此，當RCM將配置推送到UP時，RCM需要來自UP的配置完成訊號，RCM根據該訊號瞭解配置推送已完成，並認為這是一次成功的切換。
這是配置推送完成時可以從系統日誌和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停滯在「待定」狀態的問題。
- 由於RCM未獲取配置推送完成狀態，因此它認為切換未完成，並保持UP為Pending狀態。
- UP Reload Causes中說明了配置推送問題的不同原因。
因應措施
1.您可以臨時使用上述命令將配置推送完成訊號從UP推送到RCM，以使UP重新進入主用/備用狀態：
rcm-config-push-complete end-of-config
2.為了識別配置推送花費時間的問題(如UP Reload Causes中所述)，上述的解決方法只是臨時的。
意見