Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Informations générales

Présentation de base

Mappage Redmgrs et Sessmgrs

Journaux requis

Dépannage

Sessmgr passe en mode serveur

Raison pour laquelle Sessmgr passe en mode serveur

Solution de contournement

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

Il fournit également un guide de dépannage détaillé pour les problèmes d'état du serveur sessmgr, qui entravent le trafic et le traitement des appels. En outre, une section de test de laboratoire pour la récupération.

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 :

1. Pour identifier les sessmgrs actifs inactifs, vous pouvez utiliser cette commande :

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

1. Afin de faciliter la communication et le transfert des points de contrôle, chaque gestionnaire de session (sessmgr) établit une connexion d'homologue TCP avec le gestionnaire de redondance correspondant (redmgr).

2. Une fois la connexion d'homologue TCP établie, le redmgr peut contrôler tous les contextes d'abonné à partir du sessmgr et les enregistrer. Cela permet une commutation transparente, car les points de contrôle peuvent être transférés vers d'autres fonctions du plan d'utilisateur (UPF) avec leurs instances sessmgr respectives.

3. Il est essentiel que le sessmgr soit toujours en mode CLIENT. Si, pour une raison quelconque, le sessmgr est détecté en mode serveur, il indique une connexion TCP homologue rompue avec le redmgr associé. Dans ce scénario, aucun point de contrôle ne sera effectué.

4. Lorsque les sessmgr sont bloqués dans cet état dans le protocole UPF, l'exécution d'un basculement non planifié vers un autre protocole UPF sans tenir compte de l'état du sessmgr entraîne le même problème. Le sessmgr n'est pas en mesure de gérer le trafic dans cette situation.

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.