简介
本文档介绍与RCM中的UPF状态不匹配相关的问题。
先决条件
要求
本文档没有任何特定的要求。
使用的组件
本文档中的信息基于以下软件和硬件版本：
- 冗余配置管理器(RCM)
- 用户平面功能(UPF/UP)
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。
日志收集
RCM
步骤1:捕获一些命令输出
首先，您必须确定存在问题的UP以及问题的模式。为了确定哪些UP经历过切换并确定当前问题的位置，必须记录切换的原因。
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
第二步：收集控制器和Configmgr日志
一旦确定问题出在哪些UP中，您就可以收集控制器日志和configmgr日志，以便确定切换的原因以及UP停滞在“待处理”状态时出现哪些错误。
有关日志收集过程，请参阅RCM日志收集链接。
UP
有问题的时间戳的SSD、系统日志和SNMP陷阱在问题开始前至少覆盖两个小时的时间段。
故障排除
UP停滞在“待处理”状态的场景
- 通常，每个UP通过控制器将自身注册到RCM
- 控制器负责维护其从UP接收的UP状态和RCM分配的状态并编译它们
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
},
在控制器统计中，如果观察到，控制器维护的状态不同，每个UP状态都有其含义。
BFD状态 — 表示RCM和UP之间的BFD状态（不要将其称为UF状态，它仅是BFD状态）
UPF state - RCM中UPF的当前状态
UPF state received - UP向RCM发送的UP状态
- 按照流程，每当从主用到备用状态切换时，RCM必须执行下面提到的某些平滑切换步骤：
1. Checkpointmgr从旧UP刷新并与新Active UP同步检查点
2.配置刷新
3.配置推送
4.管理UP状态
以UP对的示例为例：UP-A（主用UP）和UP-B（备用UP），当在进入主用和备用状态之前发生切换时，它首先进入挂起状态。
UP-A（主用UP）--------------------- PendStandby ---------------------- Standby
UP-B（备用UP）------------------- PendActive ---------------------- Active
正如在变为主用/备用之前所看到的，上述程序事务在RCM和UP之间发生，以实现平稳切换。
- 每当从Active切换到Standby时，RCM必须执行配置推送，它将在处于Active状态的UP中推送Active UP配置，并在处于Standby状态的UP中推送Standby UP配置。
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
- 一旦启动切换，RCM的计时器值为15分钟（取决于配置的值），并且在此计时器值内，它必须完成切换，一旦完成配置推送，切换就会结束。
- 现在，由于某种原因，如果在计时器到期后配置推送未完成，并且RCM启动重新加载到UP。 此过程将一直持续到配置推送完成。
- 因此，当RCM将配置推送到UP时，RCM会从UP收到配置完成信号，RCM根据此信号了解配置推送已完成，并认为它是成功的切换。
这是配置推送完成时可以从系统日志和SNMP陷阱中看到的日志。
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
- 但是，如果由于任何问题导致配置推送完成需要时间，从而导致计时器值过期，则会发生类似的UP停滞在“待处理”状态的问题。
- 由于RCM未获取配置推送完成状态，因此它认为切换未完成，并保持UP为“待处理”状态。
- UP Reload Causes中解释了配置推送问题的不同原因。
解决方法
1.您可以临时使用上述命令执行从UP向RCM推送配置完成信号，以使UP重新进入主用/备用状态：
rcm-config-push-complete end-of-config
2.上述解决方法只是临时性的，目的是确定在UP Reload Causes中描述的config push花费时间的问题。
反馈