简介
本文档介绍导致sessmgr服务器状态的冗余配置管理器(RCM)和用户平面功能(UPF)问题。
先决条件
要求
Cisco 建议您了解以下主题:
使用的组件
本文档中的信息基于以下软件和硬件版本:
- RCM-checkpointmgr
- UPF-sessmgr
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您的网络处于活动状态,请确保您了解所有命令的潜在影响。
背景信息
它还提供了有关sessmgr服务器状态问题(阻碍流量和呼叫处理)的详细故障排除指南。另外,还有一个恢复实验测试部分。
基本信息概述
如图所示,您可以观察RCM中的冗余管理器(称为checkpointmgr)与UPF中的sessmgrs之间的直接连接,以进行检查点跟踪。
Redmgrs和Sessmgrs映射
1. 每个UP有一个“N”个sessmgr。
2. RCM的redgrs数量为“M”,具体取决于UPF中的sessmgrs数量。
3. Redmgr和sessmgr都根据其ID进行1:1映射,其中每个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
所需的日志
RCM日志-命令输出:
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
故障排除
通常,UPF中有21个sessmgr实例,包括20个活动sessmgr和1个备用实例(尽管此计数可能因具体设计而异)。
示例:
show task resources facility sessmgr all
-
在这种情况下,尝试通过重新启动有问题的sessmgr甚至重新启动sessctrl来解决问题不会导致恢复受影响的sessmgr。
-
此外,我们观察到受影响的会话停滞在服务器模式而不是预期的客户端模式下,这是可以使用提供的命令进行验证的情况。
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
在此,所有会话最好都处于客户端模式。但是,在此问题中,它们处于服务器模式,这会阻止它们处理流量。
Sessmgr进入服务器模式
-
为了便于通信和传输检查点,每个会话管理器(sessmgr)均与相应的冗余管理器(redmgr)建立TCP对等连接。
-
一旦TCP对等连接建立,redmgr就可以从sessmgr检查所有用户上下文并保存它们。这允许无缝切换,因为检查点可以与其各自的sessmgr实例一起转移到其他用户平面功能(UPF)。
-
对sessmgr来说,始终处于CLIENT模式至关重要。如果出于任何原因,在服务器模式下检测到sessmgr,则表明与关联的redmgr的TCP对等连接已断开。在这种情况下,不会执行检查点操作。
-
当SUSMGR在UPF中处于此状态时,在不考虑sessmgr的状态的情况下执行到另一个UPF的计划外切换会导致相同的问题。在这种情况下,sessmgr无法处理流量。
注意:在某些情况下,checkpointmgr本身正在等待RCM已启动检查点的检查点并等待UPF返回响应。但是,如果没有响应checkpointmgr,则其自身无法通信,从而导致切换过程完成时的延迟跨越切换计时器值。因此,在这种情况下,UP甚至会停滞在PendActive状态。
可以在RCM统计信息和redmgr日志中对此进行检查。此外,通过此命令,您可以了解哪个checkpointmgr与哪个UPF存在问题。
rcm show-statistics checkpointmgr-endpointstats
4. sessmgr在本地进入服务器模式可能有多种原因,但其中一个主要原因在此进行说明。
Sessmgr进入服务器模式的原因
1.根据用户平面功能(UPF)中的会话管理器数量,为冗余管理器(redmgr)创建副本,并在资源控制管理器(RCM)中进行配置。此配置可确保每个redmgr都与一个会话管理器实例连接。
2. 如果redmgr和sessmgr之间存在1:1的映射,当会话管理器实例ID超过会话管理器数量的值时,会发生什么情况?
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
解决方法
此问题的解决方案是限制sessmgr实例ID的数量,以匹配UPF中的sessmgr数量和RCM中的redmgr数量,如上述命令所指定。
Max value of sessmgr instance ID = no of checkpointmgr – 1
根据此逻辑,需要定义sessmgr的数量,包括备用sessmgr。
task facility sessmgr max <no of max sessmgrs>
Note :: Implementation of this command needs node reload to enable full functionality of this command
通过执行此命令,无论sessmgr被终止的次数如何,它都会得到一个等于或小于sessmgr最大计数的实例ID值。这有助于防止RCM出现检查点问题,并防止sessmgr因此进入服务器模式。