既知の問題

VMware ESXiサーバで仮想マシン(VM)をプロビジョニングするときに、ベースOSでディスクを追加する前にブロックストレージディスクを追加すると、Cephが誤ってドライブを識別し、誤ったドライブを使用してクラスタを作成し、ベースOSが破棄されることがあります。

回避策: 最初のディスクをベース OS (大きい方のドライブ) として追加してから、小さい方のブロック記憶域ディスクを追加します。

時系列データベース (TSDB) HA レプリケーションがない場合、TSDB ポッドを実行している Kubernetes ワーカーノードがダウンした場合、ポッドに容量があっても、TSDB サービスは新しいノードでスピンアップされません。これは、大量のデータを新しいノードに転送する必要があるためです。

回避策: TSDB インスタンスをホストしているサーバーまたはストレージに障害が発生した場合は、サーバーまたは損傷したコンポーネントを再構築できます。

レプリケーション係数が 1 に設定されている場合、そのインスタンスの TSDB データは失われます。その場合、Paragon Automationから障害が発生したTSDBノードを削除する必要があります。障害が発生した TSDB ノードを削除するには、次のようにします。

1. Paragon Automation GUIで、[設定 ]>[インサイト設定]を選択します。

   [インサイト設定] ページが表示されます。

2. [TSDB] タブをクリックして、[TSDB 設定] タブ付きページを表示します。

3. 障害が発生したノードを削除するには、[TSDB 設定] タブ ページで、障害が発生した TSDB ノードの名前の横にある [X ] をクリックします。

   メモ：

   TSDBの作業実行中は、一部のサービスが再起動され、Paragon AutomationのGUIが応答しなくなるため、メンテナンス期間中にTSDBノードを削除することをお勧めします。

4. 「 保存してデプロイ」をクリックします。

5. 変更がデプロイされておらず、デプロイ中にエラーが発生した場合は、[ 強制 ] 切り替えボタンを有効にし、[ 保存してデプロイ] をクリックして変更をコミットします。これにより、システムは TSDB 設定の調整中に発生したエラーを無視します。

Paragonオートメーションを完全にアンインストールする場合は、すべてのノードで/ var/lib/rook ディレクトリが削除され、すべてのCephブロックデバイスがワイプされていることを確認する必要があります。

回避策: 『Paragon Automationインストールガイド』の「 CephとRookのトラブルシューティング>故障したディスクを修復する 」セクションを参照してください。

エアギャップ方式を使用してParagon Automationをインストール中に、次のエラーが発生します。

回避策: /config.ymlファイルで以下の設定変数config-dirを編集してから、エアギャップ方式を使用してParagon Automationをインストールします。

根本原因分析(RCA)機能は、Paragon Automationリリース23.1ではデフォルトで無効になっています。

回避策: RCA機能を有効にするには、次の手順を実行します。

1. 環境変数が設定され kubeconfig ているか、~/. kube/admin.conf ファイルが存在することを確認します。

2. Paragon Insightsサービスが稼働していることを確認します。ポッドの状態が [実行中] であることを確認するには、次のいずれかのコマンドを使用します。

   root@primary-node:~# kubectl -n healthbot get pods

   または

   root@primary-node:~# kubectl get po -n healthbot

3. プライマリノードの1つにログインします。

4. 作業ディレクトリを / var/local/healthbot に変更します。

   root@primary-node:~# cd /var/local/healthbot

5. テキスト エディターを使用して healthbot.sys ファイルを編集し、推論エンジン セクションで の値を ENABLE_RCA ""True に変更します。

   ファイルを保存して閉じます。

6. 次のコマンドを使用して、クラスター内の他のすべてのノードに変更を発行します。

7. 次のコマンドを使用して、推論エンジン、alerta、および構成サーバー サービスを再起動します。

   root@primary-node:~# /var/local/healthbot/healthbot restart -s inference-engine --device-group healthbot

   root@primary-node:~# /var/local/healthbot/healthbot restart -s alerta --device-group healthbot

   root@primary-node:~# /var/local/healthbot/healthbot restart -s config-server --device-group healthbot

8. すべてのサービスが稼働していることを確認します。

   root@primary-node:~# kubectl -n healthbot get pods

Junos OS リリース 22.4R1 以降には、SR-TE LSP の制限があります。

PCEP セッションを確立するには、次のコマンドを使用してマルチパス機能を無効にする必要があります。

set protocols pcep disable-multipath-capability

セカンダリ パスはサポートされていません。

LSP が設定済みの場合、PCEP から学習した SR-TE LSP の管理グループは、トポロジーの同期後に消えます。

回避策: PCEP から学習した管理者グループを保持するように SR-TE LSP を変更します。

セーフモードのステータスは、ns-web ポッドの起動時に常に false になります。

回避策: ありません。

トンネル テーブルの「委任ビット」列は常に空です。

回避策: LSP を選択して委任ビットを表示し、右クリックして [詳細の表示] を選択します。

キュー内の古いメッセージは、フェデレーション リンクが回復した後に処理されています。

回避策: ありません。

セーフ モード中に信頼できるソースの変更フラグを実行した後、正しくないセーフ モードの状態が表示されます。

回避策: ありません。

Javaクライアントのネットワークアーカイブから需要がありませんが、需要トラフィックは利用可能です。

回避策: ありません。

NETCONF が無効になっているデバイスは、NETCONF ステータスが Up のまま表示されることがあります。

回避策: 変更せずにデバイスプロファイルを編集して、デバイスプロファイルの再読み込みをトリガーします。

Cisco IOS-XR デバイスから発信された SR-TE LSP の色は、LSP が最初にデバイス コレクションから検出された場合にのみ表示されます。

回避策: ありません。

[整合性チェック]タブの構成ビューアが機能しません。代わりに、[トポロジ] タブで使用できる構成ビューアーを使用できます。

回避策: ありません。

Toposerver は、各 LSP のライブ プロパティ(ero および rro)パスを 2 回保存します。

回避策: ありません。

P2MP 論理ツリービューでは、ノードが複数回誤って表示され、ツリー内でサイクルが発生する可能性があります。これは、toposerver が各 LSP のライブ プロパティ パスを 2 回保存する問題が原因です。

回避策: ありません。

メンテナンスモードシミュレーション機能と対応するメンテナンスレポートは使用できません。

回避策: Java プランナーで障害シミュレーションを実行します。

Paragon Automationは、NETCONF(Network Configuration Protocol)のみを使用し、Path Computation Element Protocol(PCEP)は使用しないで、Ciscoルーターのポイントツーマルチポイント(P2MP)ステータスを収集します。Cisco ルータの P2MP グループを作成する場合は、プロビジョニング方法として NETCONF のみを選択する必要があります。

回避 策。なし。

展開がセーフ モードの場合、信頼できる送信元フラグを無効にすることはできません。

回避策: toposerver ポッドを再起動して、セーフ モード中に信頼できる送信元フラグを無効にします。

単一のイングレス ルーターに属する複数の委任されたラベルスイッチ パス(LSP)を選択し、[PCC への委任を返す(Return Delegation to PCC)] をクリックすると、1 つの LSP のみがデバイス制御になります。Junos の問題により、このシナリオが発生します。

回避策: LSP を 1 つずつ選択し、LSP ごとに個別に [ PCC への委任を返す] をクリックします。

委任された SR-TE LSP の動作ステータスは、宛先ノードが再検出された後もダウンしたままになります。

回避策: 委任された SR-TE LSP 宛先ノードが再検出された後に、ネットワーク モデルを同期する必要があります。

PCE サーバーは、rabbitmq の再起動後に rabbitmq に再接続できません。

回避策: ns-pceserver ポッドを再起動します。

REST API/UI から USE-FEDERATED-EXCHANGE 設定を変更することはできません。

回避策: cMGD CLI から直接 use-federated-exchange 設定を変更し、toposerver を再起動して変更を有効にします。

Paragon Insightsは、 名前 (ホスト名またはIPアドレス)フィールドを デバイスID フィールドにマッピングします。ただし、次の理由により、デバイス名は一意ではなくなりました。

• デュアルルーティングエンジンデバイスでは、デバイス名に「-reX」が追加されます。

• Anuta Atomなどのサードパーティ製アプリケーションは、デバイス名にドメイン名を追加します。

また、ホスト名ではなくユニバーサル一意識別子(UUID)でデバイスをマッピングすると、GUIに表示される情報に問題が発生する可能性があります。

回避策: 階層レベルでステート master-only メントを含めて、デバイス上の管理イーサネット インターフェイスに追加の [edit groups] IP アドレスを設定します。その後、この追加の IP アドレスをデバイスのオンボードに使用する必要があります。詳細については、「 管理イーサネットインターフェイス」を参照してください。

TSDB 専用のノードがある場合、関連するポッドが専用ノードで実行されていると、PersistentVolumeClaim が設定されている共通名前空間内の一部のサービス (AtomDB、ZooKeeper など) が影響を受ける可能性があります。つまり、TSDB ノードで実行されているポッドの状態は常に [保留中] として表示されます。

デバイスの追加中に、ネットワークで既に使用されている送信元 IP アドレスを指定すると、デバイスをデバイス グループに追加したり、プレイブックをデプロイしたり、関数の取り込み関連のエラーが発生したりできない場合があります。

回避策: 競合する送信元 IP アドレスを修正します。「デプロイメント・ステータス」アイコンをクリックし、変更をコミットします。

[アラーム(Alarms)] ページで保存されたクエリを選択すると、保存されたクエリに基づいてアラームがフィルタリングされます。ただし、グラフと日付は更新されません。

回避策: ありません。

[デバイス(Device)] ページで非管理対象デバイスを追加し、後で非管理対象デバイスのホスト名を編集した場合、ホスト名はデバイス グループおよびダッシュボードの [デバイス(Devices)] ダッシュレットに反映されません。

回避策: デバイスのホスト名または IP アドレスを使用して、管理されていないデバイスを追加できます。

ホスト名を使用してアンマネージドデバイスを追加した場合、既存のデバイスを削除し、新しいホスト名でデバイスを追加すると問題が解決します。

IP アドレスを使用して非管理対象デバイスを追加した場合、ダッシュボードのデバイス グループと [デバイス(Devices)] ダッシュレットで、ホスト名ではなく IP アドレスに基づいて非管理対象デバイスを識別する必要があります。

Message Digest Algorithm 5(MD5)認証は、Path Computation Element Protocol(PCEP)サーバーではサポートされません。

回避策: ありません。

デフォルトでは、トポロジーフィルターは無効になっています。Paragon Automation GUIを使用してトポロジー・フィルターを有効にすることはできません。

回避策: トポロジ フィルターを有効にする手順については、「 トポロジ フィルター サービスを有効にする 」トピックを参照してください。

回避策: Cisco IOS XR デバイスのデバイス設定を復元するには、次の手順を実行します。

1. [デバイスの設定> ページで、Cisco XR デバイスを選択し、[詳細] > [設定バージョン] をクリックします。

2. 復元する構成バージョンをコピーします。

3. CLI を使用して設定を復元します。

デバイスグループレベルでアウトバウンドSSHを有効にしている場合、デバイスグループ内のいずれかのデバイスのアウトバウンドSSHを無効にすることはできません。

回避策: MGD CLI または Rest API を使用して、デバイスでアウトバウンド SSH を有効または無効にできます。アウトバウンド SSH を無効にするには、無効化フラグを true に設定する必要があります。デバイスで次のコマンドを実行して、MGD CLI を使用してアウトバウンド SSH を無効にします。

set healthbot DeviceName outbound-ssh disable true

Paragon Automation GUIからすべてのサービスログをダウンロードすることはできません。

回避策: エラスティック検索データベース (ESDB) と Kibana ですべてのサービス ログを表示できます。Kibana または ESDB にログインするには、インストール前に config.yml ファイルの [opendistro_es_admin_password] フィールドでパスワードを構成する必要があります。

回避策: パスをプロビジョニングすると、パスはスライスID制約に従い、パスはパスプレビューに正しく表示されます。

PCEPを使用してセグメントルーティングLSPをプロビジョニングする場合、カラー機能は動作しません。この問題は、ルーターがJunos OSリリース20.1R1で実行されている場合に発生します。

回避策: Junos OSをリリース21.4R1にアップグレードします。

プライマリ ロールの切り替え中に PostgresSQL が接続を受け入れないため、マイクロサービスは PostgresSQL に接続できません。これは一時的な状態です。

回避策: プライマリ ロールの切り替えが完了した後、マイクロサービスが PostgresSQL に接続することを確認します。

Postgresデータベースは一部のシステムで動作しなくなり、接続障害につながります。

回避策: プライマリノードで次のコマンドを実行します。

for pod in atom-db-{0..2}; do

kubectl exec -n common $pod -- chmod 750 /home/postgres/pgdata/pgroot/data

done

Cisco IOS XR デバイスのデバイス検出が失敗します。

回避策: Cisco IOS XR デバイスの SSH サーバ レート制限を増やします。コンフィグレーションモードでデバイスにログインし、次のコマンドを実行します。

BGP-LSを使用してリンク遅延とリンク遅延変動に関する情報を取得した場合、過去のリンク遅延データを表示することはできません。

回避策: ありません。

まれなシナリオ (たとえば、Redis がクラッシュして Kubernetes によって自動再起動された場合や、Redis サーバーを再起動する必要がある場合など) では、一部のインターフェイス情報が失われ、ネットワーク情報テーブルの [インターフェイス] タブにインターフェイスが表示されません。しかし、この問題は、パスの計算、統計、または LSP プロビジョニングには影響しません。

回避策: ライブネットワークモデルのインターフェイスを復元するには、デバイス収集タスクを再実行します。

[新しいワークフローの追加] ページと [ワークフローの編集] ページの [タスク] タブで、次の操作を行います。

• [ キャンセル] オプションをクリックしても、タスクの編集中に行った変更は保存されます。
• 既に削除したステップの名前を再利用することはできません。
• 空のエントリを持つステップを追加し、[ 保存して配置] をクリックしてもエラー メッセージは表示されません。

回避策: ありません。

デュアルREモード(PTX5000やPTX300など)を搭載した一部のローエンドPTXデバイスのアップグレードは、Paragon Automationではサポートされていません。これは、デュアルREモードを搭載したローエンドPTXデバイスは、ブリッジングまたはブリッジドメイン設定をサポートしていないためです。

回避策: ありません。

POST /traffic-engineering/api/topology/v2/1/rpc/diverseTreeDesign APIが機能しない。

回避策: POST /NorthStar/API/v2/tenant/1/ topology/1/rpc/diverseTreeDesign API を使用することをお勧めします。

Paragon Automationは、Nokiaデバイスのアラームを表示しません。

回避策: ありません。

ルーティング方法を routeByDevice として SRv6 LSP を設定する場合、セグメント ルーティング - 明示的ルート オブジェクト(SR-ERO)の値を指定する必要があります。そうしないと、SRv6 LSP を使用してトラフィックを伝送できません。

回避策: トンネルを追加するときに、[パス] タブでホップを追加して、必須または優先ルーティングの種類を指定します。

デバイス制御のSRv6 LSPがネットワークから発見された場合、ルートに明示的ルートオブジェクト(ERO)を指定したかどうかに関係なく、このLSPでハイライト表示されているパスは正しくありません。

回避策: ありません。

セグメントルーティングLSPを一括で削除できない場合があります。

回避策: 一括削除のプロセス中に削除されなかった LSP を強制的に削除できます。

Paragon Automation GUIの[新規ワークフローの追加]ページと[ワークフローの編集]ページの[タスク]タブで、何も変更せずに既存のステップを編集して保存しようとすると、次のエラーメッセージが表示されます。

Name already exists

回避策: 誤って [編集] オプションをクリックした場合は、少なくともステップの名前を変更してください。

名前空間内のすべてのポッド northstar を再起動すると、PCEP セッションが Down と表示されることがあります。

回避策: コマンドを使用してトポロジー・サーバーを kubectl delete pods ns-toposerver-<POD_ID> -n northstar 再始動します。

回避策: ありません。

[アラーム(Alarms)] ページのグラフには、最新のデータは反映されません。つまり、アラームがアクティブでなくなった後、グラフは更新されません。

回避策: ありません。

iAgent のアウトバウンド SSH を設定すると、設定したルールのデータは生成されません。

回避策: ありません。

TWAMP(双方向アクティブ管理プロトコル)を設定している場合は、リンク間にパケット損失のゼロパーセント値が表示されます。TWAMP は IS-IS トラフィック エンジニアリング向けのパケット損失のエクスポートをサポートしていないため、これは正しくありません。

回避策: ありません。

MPC10+ラインカードを搭載したデバイスを使用していて、デバイスがリリース21.3R2-S2またはリリース21.4R2-S1以外のJunos OSリリースで実行されている場合、論理インターフェイスの統計情報は収集されません。ただし、物理インターフェイスとLSPの統計情報は収集されます。

回避策: Junos OSリリースをリリース21.3R2-S2または21.4R2-S1にアップグレードします。また、Paragon Automationがリリース23.1にアップグレードされていることを確認してください。

LSP の委任を解除すると、LSP ステータスは委任済みと表示されます。LSP の委任を再度解除しようとすると、ルーター設定が変更され、明示的なルート オブジェクト(ERO)が追加される可能性があります。

回避策: LSP の委任を再度解除する前に、[トンネル] タブを更新します。

SR LSP のステータスがローカルにルーティングされている場合、SR LSP がスライス制約を満たさない場合、Paragon Pathfinder は委任された SR LSP を停止しません。

スライスIDが2**32以上のトポロジーグループを作成した場合、トポロジーグループIDはスライスIDと一致しません。

Paragon Automation Kubernetesクラスターは、自己生成されたkubeadm管理の証明書を使用します。これらの証明書は、Kubernetes のバージョンがアップグレードされるか、証明書を手動で更新しない限り、デプロイ後 1 年で期限切れになります。証明書の有効期限が切れると、ポッドは起動せず、ログに不正な証明書エラーが表示されます。

回避策: 証明書を手動で更新します。証明書を更新するには、次の手順を実行します。

1. クラスターの各プライマリノードでコマンドを使用して kubeadm certs check-expiration 、現在の証明書の有効期限を確認します。

2. 証明書を更新するには、Kubernetes クラスターの各プライマリ ノードでコマンドを使用します kubeadm certs renew all 。

3. クラスターの各プライマリノードでコマンドを使用して kubeadm certs check-expiration 有効期限を再確認します。

4. いずれかのプライマリ ノードから次のポッドを再起動して、新しい証明書を使用します。