目录

简介

先决条件

要求

使用的组件

日志收集

RCM

步骤1:捕获一些命令输出

第二步：收集控制器和Configmgr日志

UP

故障排除

UP停滞在“待处理”状态的场景

解决方法

简介

本文档介绍与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花费时间的问题。