はじめに
このドキュメントでは、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
ステップ 2：コントローラおよびConfigmgrログの収集
どのUPに問題があるのかを特定したら、コントローラログとconfigmgrログを収集して、スイッチオーバーの原因と、UPが保留状態のままになる原因を特定できます。
ログ収集手順については、『RCM Log Collection』リンクを参照してください。
UP
問題のあるタイムスタンプのSSD、Syslog、およびSNMPトラップには、問題が発生する少なくとも2時間前のタイムフレームが含まれます。
（「トラブルシューティング」）
UPがPending状態のままになるシナリオ
- 通常、各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 state:RCMとUPの間のBFD状態を示します（UF状態とは言わず、純粋にBFD状態のみです）。
UPF state:RCMでのUPFの現在の状態
UPF状態received:UPからRCMに向けて送信されるUP状態
- フローに従って、アクティブUPからスタンバイUPへの切り替えが発生するたびに、RCMは次に示すスムーズなハンドオーバーのために特定の手順を実行する必要があります。
1.古いUPからのCheckpointMgrのフラッシュと、新しいActive UPとのチェックポイントの同期
2.構成のフラッシュ
3.構成のプッシュ
4. UP状態の管理
UPペアの例をUP-A(Active UP)およびUP-B(Standby-UP)と見なします。アクティブ状態とスタンバイ状態になる前にスイッチオーバーがあると、最初に保留状態になります。
UP-A(Active UP)---------------------PendStandby----------------------Standby
UP-B(Standby UP)------------------- PendActive ---------------------- Active
アクティブ/スタンバイになる前に見られるように、上記の手順トランザクションは、円滑なスイッチオーバーを実現するためにRCMとUPの間で発生しています。
- アクティブからスタンバイへの切り替え、およびその逆の切り替えが発生するたびに、RCMは、アクティブになるUPのアクティブUP設定をプッシュし、スタンバイになるUPのスタンバイ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分（設定された値に応じて異なる）になり、このタイマー値内では、設定のプッシュが完了した後に終了するスイッチオーバーを完了する必要があります。
- この場合、何らかの理由により、タイマーが期限切れになる時間内にconfig pushが完了せず、RCMがUPへのリロードを開始します。 これは、設定のプッシュが完了するまで続きます。
- そのため、RCMが設定をUPにプッシュする際には、UPからの設定完了信号が期待されます。この信号に基づいて、RCMは設定のプッシュが完了したことを認識し、スイッチオーバーが成功したと見なします。
これは、設定のプッシュが完了したときにsyslogおよび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
- ただし、config push completionに時間がかかるためにタイマー値が期限切れになる問題がある場合は、UPがPending状態のままになるという問題が発生します。
- RCMはconfig push completionステータスを取得しなかったため、スイッチオーバーが完了していないと見なし、Pending状態で起動し続けます。
- コンフィギュレーションのプッシュに関するさまざまな問題の原因については、「アップ状態のリロードの原因」で説明しています。
回避策
1.一時的に、次のコマンドを使用して、UPからRCMに向かうconfig push complete信号を適用し、UPをアクティブ/スタンバイ状態に戻すことができます。
rcm-config-push-complete end-of-config
2.上記の回避策は、UPリロードの原因で説明されているconfig pushに時間がかかる問題を特定するための一時的なものです。
フィードバック