Introducción

Este documento describe los problemas de Redundancy Configuration Manager (RCM) y User Plane Function (UPF) que causan el estado del servidor sessmgr.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• RCM
• UPF

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• RCM-checkpointmgr
• UPF-sessmgr

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.

Antecedentes

Información general básica

Como se muestra en la imagen, puede observar las conexiones directas entre los administradores de redundancia (denominados checkpointmgrs) en el RCM y sessmgrs en las UPF para el seguimiento de los puntos de control.

Asignación de Redmgrs y Sessmgrs

1. Cada UP tiene un número "N" de sessmgr.

2. RCM tiene un número "M" de redmgrs dependiendo del número de sessmgrs en UPF.

3. Tanto redmgrs como sessmgrs tienen mapeo 1:1 basado en sus ID donde hay redmgrs separados para cada sessmgr.

Note :: Redmgr IDs (m) = sessmgr instance ID (n-1)

For example :: smgr-1 is mapped with redmgr 0;smgr-2 is mapped with redmgr-1,

smgr-n is mapped with redmgr(m) = (n-1)

This is important to understand proper IDs of redmgr because we need to have proper logs to be checked

Registros necesarios

Registros de RCM - Salidas de comandos:

rcm show-statistics checkpointmgr-endpointstats

RCM controller and checkpointmgr logs (refer this link)

Log collection

UPF:

Command outputs (hidden mode)

show rcm checkpoint statistics verbose
show session subsystem facility sessmgr all debug-info | grep Mode

If you see any sessmgr in server state check the sessmgr instance IDs and no of sessmgr

show task resources facility sessmgr all

Troubleshoot

Normalmente, hay 21 instancias de sessmgr en UPF, que constan de 20 sessmgr activos y 1 instancia en espera (aunque este recuento puede variar en función del diseño específico).

Ejemplo:

show task resources facility sessmgr all

2. En este escenario, intentar resolver el problema reiniciando los sessmgrs problemáticos e incluso reiniciando sessctrl no conduce a la restauración de los sessmgrs afectados.

3. Adicionalmente, se observa que los sessmgrs afectados están atascados en el modo de servidor en lugar del modo de cliente esperado, una condición que puede verificarse utilizando los comandos proporcionados.

show rcm checkpoint statistics verbose

show rcm checkpoint statistics verbose 
Tuesday August 29 16:27:53 IST 2023
smgr state peer recovery pre-alloc chk-point rcvd chk-point sent
inst conn records calls full micro full micro
---- ------- ----- ------- -------- ----- ----- ----- ----
1 Actv Ready 0 0 0 0 61784891 1041542505
2 Actv Ready 0 0 0 0 61593942 1047914230
3 Actv Ready 0 0 0 0 61471304 1031512458
4 Actv Ready 0 0 0 0 57745529 343772730
5 Actv Ready 0 0 0 0 57665041 356249384
6 Actv Ready 0 0 0 0 57722829 353213059
7 Actv Ready 0 0 0 0 61992022 1044821794
8 Actv Ready 0 0 0 0 61463665 1043128178

Here in above command all the connection can be seen as Actv Ready state which is required 

show session subsystem facility sessmgr all debug-info | grep Mode

[local]<Nodename># show session subsystem facility sessmgr all debug-info | grep Mode 
Tuesday August 29 16:28:56 IST 2023
Mode: UNKNOWN State: SRP_SESS_STATE_SOCK_ACTIVE
Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE
Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE
Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE
Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE
Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE
Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE
Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE
Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE

Aquí, todos los sessmgrs deberían estar idealmente en modo cliente. Sin embargo, en este problema, están en modo de servidor, lo que les impide manejar el tráfico.

Sessmgr entra en modo de servidor

Nota: Hay ciertos problemas en los que checkpointmgr está esperando el punto de control donde RCM ha iniciado el punto de control y esperando la respuesta de UPF. Pero cuando no hay respuesta, el propio checkpoint mgr no puede comunicarse, lo que lleva a un retraso en la finalización del procedimiento de switchover que cruza el valor del temporizador de switchover. Así que en tales casos UP incluso se atasca en el estado PendActive.

Esto se puede verificar en las estadísticas del RCM y en los registros de redmgr. Además, con este comando, puede saber qué checkpointmgr tiene un problema con qué UPF.

rcm show-statistics checkpointmgr-endpointstats

4. Puede haber múltiples razones para que sessmgr entre en modo de servidor localmente pero una de las razones principales para esto es como se explica aquí.

Motivo por el que Sessmgr entra en modo de servidor

1. En función del número de administradores de sesiones en la función de plano de usuario (UPF), se crean réplicas para el administrador de redundancia (redmgr) y se configuran en el administrador de control de recursos (RCM). Esta configuración garantiza que cada redmgr esté conectado con una instancia del administrador de sesiones. 

2. Si hay una asignación 1:1 entre redmgr y sessmgr, ¿qué ocurre cuando el ID de instancia del administrador de sesiones supera un valor superior al número de administradores de sesiones?

For example ::: 

Sessmgr instance ID :: 1 to 20
Redmgr IDs :: 0 to 19

In this example somehow if my sessmgr instance ID goes beyond the mentioned limit i.e say 21/22/23/24/25 so in this case redmgr is already mapped with instance IDs 0 to 19 and would be unaware about this new sessmgr instance ID created by UPF from 21 to 25 and in such a  case sessmgr with this instance IDs :: 21/22/23/24/25 will not be able to form any TCP peer connection with RCM redmgr leading to no checkpoint sync and since there won’t be any checkpoint sync sessmgr will get stuck into server mode and won’t take any traffic.
Refer this diagram

Both this sessmgr instance-7/8 have no TCP peer connection since for RCM redmgr-1 was 
connected with instance-2 and redmgr-2 was connected to instance-5 so even though sessmgr 
came up with new instance ID value which is beyond defined limit it wont have connection 
back with redmgrs which is still just pointing to previous instance but connection is broken

Solución Aternativa

La solución a este problema es limitar el número de IDs de instancia de sessmgr para que coincidan con el número de sessmgr en UPF y el número de redmgrs en RCM, según lo especificado por el comando mencionado.

Max value of sessmgr instance ID = no of checkpointmgr – 1

Según esta lógica, el número de sessmgrs debe ser definido incluyendo sessmgrs standby.

task facility sessmgr max <no of max sessmgrs>

Note :: Implementation of this command needs node reload to enable full functionality of this command

Al ejecutar este comando, independientemente de cuántas veces se está eliminando sessmgr, siempre aparece un valor de ID de instancia igual o inferior al número máximo de sessmgr. Esto ayuda a evitar problemas de verificación con el RCM e impide que sessmgr entre en el modo de servidor por esta razón.