既知の問題

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

回避策:最初のディスクをベース OS (大容量ドライブ) として追加し、小容量のブロック ストレージ ディスクを追加します。

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

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

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

1. Paragon Automation GUI で、[ Configuration > Insights Settings] を選択します。

   [Insights 設定] ページが表示されます。

2. 「 TSDB 」タブをクリックして、「TSDB 設定」(TSDB Settings) タブページを表示します。

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

   手記：

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

4. [ Save and Deploy] をクリックします。

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

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

回避策: 『Paragon Automation Installation Guide』の「 Troubleshooting Ceph and Rook > Repair a Failed Disk 」の項を参照してください。

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

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

多様なマルチキャスト ツリー設計を実行した直後にシミュレーションを実行すると、 リンク上のトンネル トラフィック (トンネル層シミュレーション レポート>ピーク ネットワーク統計)のレポートが正しくありません。

回避策:多様なマルチキャスト ツリー デザインを実行した後、ネットワークを保存して閉じます。ネットワークを再度開き、シミュレーションを実行します。

障害シナリオのシミュレーション中に([ツール] > [オプション] > [障害シミュレーション])、最初に複数障害シミュレーションを実行し、その後で 1 つの障害シミュレーションを実行すると、[ リンク上のトンネル トラフィック (トンネル層シミュレーション レポート(Tunnel Layer Simulation Report > Peak Network Statistics)]のレポートが正しくありません。レポートには、単一の故障ではなく、複数の故障シミュレーション値が表示されます。

回避策: 1 つの障害シナリオをシミュレートする前に、[ 複数の障害 ] タブのすべてのオプションの選択を解除します。

対称ペアのLSPは、しきい値を超えた再ルーティング時に対称的にルーティングされない場合があります。

回避策:なし。

パス分析レポートが空です。

回避策:パス分析を実行する前に、デバイス収集タスクを実行します。LSPがすでに最適なパス上にある場合、パス分析レポートは空になることがあります。

トラフィックチャートは、ホスト名にre0またはre1のサフィックスを付けてオンボードされたデュアルルーティングエンジンを搭載したデバイスでサポートされるようになりました。ただし、グラフは、ホスト名の接尾辞が小文字で、 -re0 または -re1 形式の場合にのみサポートされます。たとえば、vmx101-re0 や vmx101-re1 などです。

回避策:なし

リンク使用率シミュレーション レポートは、二重障害シナリオ中に負の値を表示する場合があります。

回避策:なし。

コントローラサイトは、Paragon Plannerのネットワークアーカイブには含まれていません。

回避策:なし。

デバイスのホスト名が変更されても、その変更はすべてのデータベースに反映されるわけではありません。

回避策: 次の手順を実行して、新しいデバイスのホスト名がすべてのデータベースおよびコンポーネントに反映されるようにします。

1. ホスト名を変更する前に、すべてのデバイスグループ(コントローラまたは他のプレイブック)からデバイスを削除します。

2. デバイス参照がすべての異なるParagon Automationコンポーネントから削除されていることを確認します。[ Configuration > Devices ] ページに移動します。

   1. デバイスを選択します。

   2. ごみ箱アイコンをクリックして、デバイスを削除します。[ デバイスモデルの削除 ] ページが表示されます。

   3. 「 強制削除 」を選択し、「 はい」をクリックします。

3. [ Configuration > Devices ] ページのデバイスオンボーディングワークフローを使用して、デバイスを再度オンボーディングします。

   これで、デバイスが新しいホスト名でオンボーディングされます。デバイスのプロパティ、特にsystem-id(JTIストリームの受信に重要)も更新する必要があります。

4. 新しいホスト名のデバイスをデバイスグループに追加し直します。

5. (オプション)Grafana またはデバイス CLI を使用して Influxdb のすべてのデバイス統計を確認します。データベースが新しいホスト名で更新されます。

[Network > Topology > Tunnel] タブで、[Filter](じょうご)アイコンにカーソルを合わせて [Add Filter] を選択すると、[Add Criteria] ページが表示されます。[フィールド] ボックスの一覧で [色] を選択すると、フィールド値は [色] ではなく plannedProperties として表示されます。

回避策:なし。

ポイントツーマルチポイント(P2MP)LSP のネットワーク設定プロトコル(NETCONF)プロビジョニング方式は、Cisco IOS-XR ルータではサポートされていません。

最適なパス上の LSP は、PCS 最適化中に不要な PCEP 更新を受け取る可能性があります。

回避策:なし。

Cisco IOS-XR ルータでは、CLI でプロビジョニングされた P2MP LSP の設定状態では、P2MP サブ LSP ステータスはサポートされていません。

回避策:なし。

診断(Configuration > Data Ingest > Diagnostics>Application)機能にエラーがあると、アプリケーションテストが失敗します。

回避策:なし。

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

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

set protocols pcep disable-multipath-capability

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

セーフ モードの状態は、ns-web ポッドの起動時には常に false です。

回避策:なし。

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

回避策:なし。

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

回避策:なし。

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

回避策:変更を行わずにデバイスプロファイルを編集し、デバイスプロファイルのリロードをトリガーします。

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

回避策:なし。

NETCONFおよびPath Computation Element Protocol(PCEP)方式を使用して、Paragon Automation UIを使用してCisco IOS-XRルータにP2MP LSPをプロビジョニングすることはできません。

回避策。CLIを使用してP2MP LSPをプロビジョニングします。設定が解析されたら、デバイス収集タスクを実行してLSPを表示します。

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

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

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

回避策:LSP を 1 つずつ選択し、LSP ごとに [Return Delegation to PCC ] を個別にクリックします。

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

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

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

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

REST API/UI から use-federated-exchange 設定を変更することはできません。

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

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

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

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

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

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

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

委任された LSP の委任を解除する場合、LSP の計画帯域幅は、ユーザー入力値ではなく、デバイスから報告された帯域幅に基づきます。

回避策:なし。

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

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

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

回避策:なし。

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

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

ホスト名を使用して管理対象外のデバイスを追加した場合は、既存のデバイスを削除し、新しいホスト名でデバイスを追加すると、問題が解決します。

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

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

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

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

1. [ Configuration > Devices ] ページで、Cisco XR デバイスを選択し、[ More > Configuration Version] をクリックします。

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

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

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

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

set healthbot DeviceName outbound-ssh disable true

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

回避策: Elastic Search Database (ESDB) と Grafana のすべてのサービス ログを表示できます。Grafana または ESDB にログインするには、インストール前に config.yml ファイルの grafana_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プロビジョニングには影響しません。

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

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

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

回避策:なし。

デュアルREモードを備えた一部のローエンドPTXデバイス(PTX5000やPTX300など)のアップグレードは、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(Two-Way Active Management Protocol)を設定している場合、リンク間にパケット損失のゼロパーセント値が表示されます。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の委任を再度解除する前に、[トンネル]タブを更新してください。

Paragon Pathfinderは、SR LSPのステータスがローカルルーティングの場合、SR LSPがスライス制約を満たさない場合、委任された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. 次のポッドをいずれかのプライマリ ノードから再起動して、新しい証明書を使用します。