Introducción
Este documento describe los problemas relacionados con la discordancia de estados UPF en RCM.
Prerequisites
Requirements
No hay requisitos específicos para este documento.
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
- Administrador de configuración de redundancia (RCM)
- Función de plano de usuario (UPF/UP)
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Recopilación Logs
RCM
Paso 1. Capturar algunas salidas de comandos
En primer lugar, debe identificar cuál es el problema UP y cuál es el patrón del problema. Para determinar qué PU experimentaron un switchover e identificar dónde se encuentra el problema actual, es esencial documentar las razones de los switchovers.
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
Paso 2. Recopilar registros de controlador y de Configmgr
Una vez que identifique entre qué UP se encuentra el problema, puede recopilar los registros del controlador y los registros de configmgr para identificar cuál fue la causa del switchover y qué salió mal para que los UP se atascaran en el estado pendiente.
Consulte el enlace RCM Log Collection para obtener información sobre el procedimiento de recopilación de registros.
EN FUNCIONAMIENTO
Las trampas SSD, Syslogs y SNMP para la marca de tiempo problemática cubren el período de tiempo al menos dos horas antes de que comience el problema.
Resolución de problemas
Escenario para los UPs que se quedan atascados en el estado pendiente
- Generalmente, cada UP se registra en el RCM a través del controlador
- El controlador es responsable de mantener los estados UP que recibe de UP y el asignado por RCM y compilarlos
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
},
En las estadísticas del controlador, si se observan, hay diferentes estados que el controlador está manteniendo y cada estado UP tiene su propio significado.
Estado BFD: indica el estado BFD entre el RCM y UP (no lo refiera como estado UF, es solamente estado BFD)
Estado de UPF - Estado actual de la UPF en el RCM
Estado de UPF recibido: estado de UPF enviado por UP hacia RCM
- Según el flujo general, siempre que se produzca un cambio de la función de encendido activo a la de espera, el RCM debe someterse a determinados procedimientos para realizar las transferencias sin problemas que se mencionan a continuación:
1. Vaciado de Checkpoint mgr de la antigua UP y sincronización de checkpoint con la nueva Active UP
2. Vaciado de configuración
3. Transferencia de configuración
4. Administración de estados UP
Considere el ejemplo de un par UP como UP-A (Activo UP) y UP-B (En espera UP) y cuando hay un switchover antes de entrar en los estados Activo y En espera, primero entra en el estado Pendiente.
UP-A (Activo) --------------------- En esperaEn espera ---------------------- En espera
UP-B (Standby UP) ------------------- PendActive ---------------------- Active
Como se puede observar antes de convertirse en Activo/En espera, las transacciones de procedimiento mencionadas se producen entre el RCM y la UP con el fin de que la conmutación sea fluida.
- Siempre que haya un switchover de Activo a En espera y viceversa, el RCM debe realizar un push de configuración en el que empuja la configuración Active UP en la UP que se activa y empuja la configuración Standby UP en la UP que se convierte en Standby.
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
- Tan pronto como se inicia el switchover, el RCM tiene un valor de temporizador de 15 minutos (varía según el valor configurado) y dentro de este valor de temporizador, debe completar el switchover que se concluye una vez que se haya completado la configuración push.
- Ahora, en este caso, por alguna razón, si no se completa la transferencia de la configuración dentro del tiempo que expira el temporizador y el RCM inicia la recarga al UP. Esto continúa hasta que se completa la transferencia de configuración.
- Por lo tanto, cuando el RCM envía la configuración a UP, espera una señal de configuración completa de UP basada en la cual el RCM entiende que la transferencia de configuración se ha completado y la considera un switchover exitoso.
Este es el registro que se puede ver desde los syslogs y las trampas SNMP cuando se completa la inserción de la configuración.
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
- Pero en caso de que haya algún problema debido al cual la finalización de la transferencia de configuración esté tomando tiempo, lo que hace que el valor del temporizador caduque, entonces se producen tales problemas de UP atascado en el estado pendiente.
- Como el RCM no obtuvo el estado de finalización de la transferencia de configuración, considera que el switchover no está completo y mantiene UP en el estado pendiente.
- En UP Reload Causes se explican diferentes razones para los problemas de config push.
Solución Aternativa
1. Temporalmente, puede aplicar la señal de configuración push complete desde UP hacia RCM con este comando mencionado para volver a poner UP en el estado Activo/En espera:
rcm-config-push-complete end-of-config
2. Esta solución alternativa mencionada es solo temporal para identificar el problema que toma tiempo para la transferencia de configuración, que se describe en Causas de Recarga UP.
Comentarios