目錄

簡介

問題

解決方案

簡介

本文檔描述由於configmgr缺少主機條目而導致的基於RCM的UPF升級失敗

問題

當RCM（冗餘配置管理器）控制器啟動計畫的UPF（使用者平面功能）從UPF 1（活動）切換到UPF 2（備用）時，configmgr應在其主機清單中同時包含UPF 1和UPF 2。但由於某種原因，configmgr在其活動主機清單中沒有活動UPF 1，與控制器上的主機清單衝突。

並且當RCM觸發UPF 1切換到UPF 2時，切換過程被啟動。在切換過程中，configmgr會嘗試在其主機清單中查詢活動UPF 1主機詳細資訊，但查詢失敗。

UPF切換過程失敗，原因是「Old Active由於接收待機狀態超時（計畫的切換）而從PendingStandby移動到Active」，並且UPF1從PendingStandby移動到Active，UPF 2從PendingActive移動到Standby。

//如何檢測切換故障是由於configmgr在其主機清單中缺少主機詳細資訊

在涵蓋此類切換失敗時間的RCM tac dbg中，在configmgr pod日誌中查詢日誌事件。

2024/01/12 09:08:26.878 rcm-configmgr [DEBUG] [sshclient.go:980] [rcm_grpc_ep.msg-process.Int] [RcmGenTrap]：引發的SNMP陷阱：（切換失敗） — 從10.248.187.151:22 到10.248.18 Group:1中的153:22失敗！原因：找不到活動

如果rcm tac dbg不存在，您還可以通過從RCM控制器ops-center查詢snmp陷阱來確認由於此問題導致的UPF切換失敗。

a)登入到活動RCM運營中心

b)運行命令rcm show-snmp-trap history

c)檢視存在的snmp陷阱陷阱

切換故障2024-01-18T05:19:45.Z 2024-01-18T05:19:45.Z rcm-configmgr 從組：10.244.127.23:22到組：1中10.247.29:22的切換失敗！原因：找不到活動

解決方案

永久修正之前可通過思科錯誤ID CSCwi70133 解決方法是使用kubectl delete <configmgr-pod-name> -n <k8-name-space>，從相應的AIO（一體化）K8s主節點中刪除configmgr pod

範例：

1.作為UPF升級自動化工作流的預檢查的一部分，可以進行檢查以比較控制器和configmgr主機清單。如果configmgr主機清單中缺少主機，可以完成configmgr pod刪除，以便configmgr從控制器獲取完整的主機清單。

2.如果手動提供UPF切換，請從活動RCM收集2個CLI命令輸出並進行比較，以查詢configmgr主機輸出中是否缺少任何主機（活動/備用）。如果缺少任何主機，請從RCM AIO K8的主節點發出configmgr pod delete命令，並重新檢查控制器和configmgr主機清單。如果控制器和configmgr上的主機匹配，請繼續從控制器手動切換UPF。

a)rcm show-statistics控制器

b)rcm show-statistics configmgr