Risoluzione dei problemi relativi all'errore di aggiornamento di UPF basato su RCM - Host mancante in Configuration Manager

Introduzione

In questo documento viene descritto un errore di aggiornamento UPF basato su RCM dovuto alla mancanza della voce host in configmgr

Problema

Quando il controller di RCM (Redundancy Configuration Manager) avvia il passaggio pianificato di UPF (User Plane Function) da UPF 1 (Active) a UPF 2 (Standby), si prevede che configmgr abbia sia UPF 1 che UPF 2 nel proprio elenco di host. Tuttavia, per qualche motivo, configmgr non dispone di UPF 1 attivo nel proprio elenco di host attivo, in conflitto con list.on controller

Quando RCM attiva il passaggio da UPF 1 a UPF 2 in tali condizioni, viene avviato il processo di passaggio. Durante il processo di switchover, configmgr tenta di trovare i dettagli dell'host UPF 1 attivo nel proprio elenco di host, ma non riesce a trovarli.

Il processo di switchover UPF non riesce con il motivo "Old Active spostato da PendingStandby ad Active a causa di un timeout nello stato Standby di ricezione (switchover pianificato)" e UPF1 viene spostato da PendingStandby ad Active e UPF2 da PendingActive a Standby.

//La modalità di rilevamento dell'errore di switchover è dovuta alla mancanza di dettagli sull'host nell'elenco degli host di configmgr

Nel dbg tac di RCM relativo ai tempi di errore dello switchover, cercare evento log nel log pod di configmgr.

2024/01/12 09:08:26.878 rcm-configmgr [DEBUG] [sshclient.go:980] [rcm_grpc_ep.msg-process.Int] [RcmGenTrap]: Trap SNMP generata: (errore di switching) - Switchover da 10.248.187.151:22 a 10.2 48.187.153:22 nel gruppo:1 Non riuscito! Motivo: non trovato attivo

Se rcm tac dbg NON è presente, è inoltre possibile verificare che lo switchover UPF non sia riuscito a causa di questo problema cercando la trap snmp da RCM controller ops-center.

     a) Accesso al centro operativo RCM attivo 

     b) Eseguire il comando rcm show-snmp-trap history

     c) Osservare le trappole snmp presenti

SwitchoverErrore 2024-01-18T05:19:45.Z 2024-01-18T05:19:45.Z rcm-configmgr Switchover da 10.244.127.23:22 a 10.244.127.29:22 nel gruppo:1Non riuscito! Motivo: non trovato attivo

Soluzione

La correzione definitiva non è ancora disponibile tramite l'ID bug Cisco CSCwi70133 La soluzione è eliminare il pod di configmgr dal nodo master AIO (All In One) K8s corrispondente, utilizzando kubectl delete <nome-pod-configmgr> -n <spazio-nome-k8>

Esempio: 

 1. Nell'ambito dei controlli preliminari del flusso di lavoro di automazione dell'aggiornamento UPF, è possibile eseguire controlli per confrontare il controller e l'elenco di host di configmgr. Se un host non è presente nell'elenco di host di configmgr, è possibile eseguire l'eliminazione del pod di configmgr in modo che configmgr ottenga l'elenco completo degli host da un controller.

2. Se il passaggio al formato UPF viene eseguito manualmente, raccogliere 2 output di comandi CLI da RCM attivo e confrontarli per verificare se nell'output dell'host di configmgr manca un host (Attivo/Standby). Se manca un host, usare il comando configmgr pod delete dal nodo master RCM AIO K8s e ricontrollare il controller e l'elenco di host di configmgr. Se gli host corrispondono sul controller e su configmgr, passare manualmente agli UPF dal controller.

a) comando show-statistics rcm

b) rcm show-statistics configmgr