Introducción
Este documento describe el error de actualización de UPF basado en RCM debido a que a configmgr le falta la entrada de host
Problema
Cuando el controlador RCM (Redundancy Configuration Manager) inicie una conversión planificada de UPF (User Plane Function) de UPF 1(Active) a UPF 2(Standby), se espera que configmgr incluya tanto UPF 1 como UPF 2 en su lista de hosts. Pero debido a alguna razón, configmgr no tiene el UPF 1 activo en su lista de hosts activos, lo que contradice la lista de hosts.en el controlador
Y cuando el RCM acciona el switchover UPF 1 a UPF 2 en tales condiciones, el proceso de switchover se inicia. Durante el proceso de switchover, configmgr intenta encontrar los detalles del host de UPF 1 activo en su lista de hosts, pero no los encuentra.
El proceso de switchover de UPF falla con el motivo "Old Active se movió de PendingStandby a Active debido al tiempo de espera en estado de espera de recepción (switchover planificado)" y UPF1 se mueve de PendingStandby a Active y UPF 2 de PendingActive a Standby.
//How to detect switchover failure is due to configmgr missing host details in its host list
En el dbg de tac del RCM que cubre estos tiempos de falla de switchover, busque el evento de registro en el registro del grupo de dispositivos de configmgr.
2024/01/12 09:08:26.878 rcm-configmgr [DEBUG] [sshclient.go:980] [rcm_grpc_ep.msg-process.Int] [RcmGenTrap]: SNMP Trap Raised: (SwitchoverFailure) - Switchover desde 10.248.187.151:22 a 10.248.187.153:22 en el grupo:1Error! Motivo: no se encuentra activo
Si rcm tac dbg NO está presente, también puede confirmar que el switchover UPF falló debido a este problema buscando snmp trap desde el centro de operaciones del controlador RCM.
a) Inicie sesión en el centro de operaciones del RCM activo
b) Ejecute el comando rcm show-snmp-trap history
c) Mira en el snmp trampas trampa presente
SwitchoverFailure 2024-01-18T05:19:45.Z 2024-01-18T05:19:45.Z rcm-configmgr Switchover desde 10.244.127.23:22 hasta 10.244.127.29:22 Grupo:1Error. Motivo: no se encuentra activo
Solución
Hasta que llegue una solución permanente a través de la identificación de error de Cisco CSCwi70133 La solución consiste en eliminar el grupo de dispositivos configmgr del nodo maestro K8s AIO (Todo en Uno) correspondiente, mediante kubectl delete <configmgr-pod-name> -n <k8-name-space>
Ejemplo:
1. Como parte de las comprobaciones previas del flujo de trabajo de automatización de la actualización de UPF, se pueden realizar comprobaciones para comparar el controlador y la lista de hosts de configmgr. Si falta un host en la lista de hosts de configmgr, se puede eliminar el grupo de dispositivos de configmgr para que configmgr obtenga la lista de hosts completa recién desde el controlador.
2. Si el switchover de UPF se está dando manualmente, recopile 2 salidas de comandos CLI del RCM activo y compárelas para determinar si falta algún Host (Activo/En espera) en la salida del host de configmgr. Si falta algún host, ejecute el comando configmgr pod delete del nodo maestro K8 de RCM AIO y vuelva a comprobar el controlador y la lista de hosts de configmgr. Si los hosts coinciden en controller y configmgr, continúe con el switchover manual de UPFs desde controller.
a) rcm show-statistics controller
b) rcm show-statistics configmgr