目錄

簡介

必要條件

需求

採用元件

日誌收集

RCM

步驟 1.擷取一些命令輸出

步驟 2.收集控制器和Configmgr日誌

UP

疑難排解

UP停滯在「待處理」狀態的場景

因應措施

簡介

本檔案將說明與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中所述)，上述的解決方法只是臨時的。