Introduction

Ce document décrit les problèmes de Redundancy Configuration Manager (RCM) et de User Plane Function (UPF) qui provoquent l'état du serveur sessmgr.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• MCR
• UPF

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• RCM-checkpoint mgr
• UPF-sessmgr

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Présentation de base

Comme l'illustre l'image, vous pouvez observer les connexions directes entre les gestionnaires de redondance (appelés checkpoints mgrs) dans le RCM et les sessmgrs dans les UPF pour le suivi des points de contrôle.

Mappage Redmgrs et Sessmgrs

1. Chaque UP a un numéro « N » de sessmgr.

2. Le RCM a un nombre « M » de redmgrs, selon le nombre de sessmgrs dans UPF.

3. Les redmgrs et les sessmgr ont un mappage 1:1 basé sur leurs ID où il y a des redmgrs distincts pour chaque 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

Journaux requis 

Journaux du RCM - Sorties des commandes :

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

Dépannage

Généralement, il y a 21 instances sessmgr dans UPF, comprenant 20 instances sessmgr actives et 1 instance de secours (bien que ce nombre puisse varier en fonction de la conception spécifique).

Exemple :

show task resources facility sessmgr all

2. Dans ce scénario, tenter de résoudre le problème en redémarrant les sessmgrs problématiques et même en redémarrant sessctrl n'entraîne pas la restauration des sessmgrs affectés.

3. En outre, il est observé que les sessmgrs affectés sont bloqués en mode serveur plutôt qu'en mode client attendu, une condition qui peut être vérifiée à l'aide des commandes fournies.

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

Ici, tous les sessmgrs devraient idéalement être en mode client. Cependant, dans ce problème, ils sont en mode serveur, ce qui les empêche de gérer le trafic.

Sessmgr passe en mode serveur

Remarque : il y a certains problèmes où checkpoint mgr lui-même attend un point de contrôle où RCM a initié un point de contrôle et attend la réponse de UPF. Mais en l'absence de réponse, checkpoint mgr lui-même n'est pas en mesure de communiquer, ce qui entraîne un retard dans l'achèvement de la procédure de basculement franchissant la valeur du compteur de basculement. Ainsi, dans de tels cas, UP est même bloqué dans l'état PendActive.

Cela peut être vérifié dans les statistiques RCM et les journaux redmgr. En outre, avec cette commande, vous pouvez savoir quel checkpoint mgr a un problème avec quel UPF.

rcm show-statistics checkpointmgr-endpointstats

4. Il peut y avoir plusieurs raisons pour que sessmgr passe en mode serveur localement, mais l'une des principales raisons pour cela est comme expliqué ici.

Raison pour laquelle Sessmgr passe en mode serveur

1. En fonction du nombre de gestionnaires de session dans la fonction de plan d’utilisateur (UPF), des réplicas sont créés pour le gestionnaire de redondance (redmgr) et configurés dans le gestionnaire de contrôle des ressources (RCM). Cette configuration garantit que chaque redmgr est connecté à une instance du gestionnaire de session. 

2. S'il existe un mappage 1:1 entre redmgr et sessmgr, que se passe-t-il lorsque l'ID d'instance du gestionnaire de session dépasse une valeur supérieure au nombre de gestionnaires de session ?

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

Solution de contournement

La solution à ce problème est de limiter le nombre d'ID d'instance de sessmgr pour correspondre au nombre de sessmgrs dans UPF et au nombre de redmgrs dans RCM, comme spécifié par la commande mentionnée.

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

Selon cette logique, le nombre de sessmgrs doit être défini, y compris les sessmgrs de secours.

task facility sessmgr max <no of max sessmgrs>

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

En exécutant cette commande, quel que soit le nombre de fois que sessmgr est tué, il obtient toujours une valeur d'ID d'instance égale ou inférieure au nombre maximal de sessmgr. Cela permet d'éviter les problèmes de point de contrôle avec le RCM et empêche sessmgr de passer en mode serveur pour cette raison.