このページの内容
 

既知の問題

このセクションでは、Juniper Routing Directorの既知の問題を示しています。

デバイスのライフサイクル管理

  • デバイスを Routing Director に一括インポートする場合、ネットワーク実装プランの一部であるデバイスは、プランからの設定がコミットされている間、プランがロックされる可能性があります。この期間中、バッチ内の他のデバイスのインポートがエラーコード HTTP 423 Lockedで失敗することがあります。

    インポートに失敗したデバイスは、元のバッチの一部としてすでにインベントリに登録されているため、新しいバッチに追加してインポートすることはできません。ロックが解除される前に、バッチ内のすべてのデバイスで設定コミットを完了する必要があるため、大規模なバッチでは、ネットワーク実装プランロックが長期間アクティブなままになることがあります。その結果、ネットワーク実装計画に関連するすべてのデバイスオンボーディング操作が完了するまで、デバイスのインポート失敗が続く可能性があります。

    回避策:

    1. ネットワーク実装計画がロックされなくなるまで待ちます。つまり、Routing Directorはすでに進行中のデバイスのオンボーディングを完了し、デバイスのステータスがデバイスバッチページ(デバイス>インベントリ>デバイスバッチ>作成日時列>日付と時刻リンク)にImportedされます。

    2. 障害が発生したデバイスをインベントリから解放します。

      1. [Inventory > devices > Network Inventory]に移動します。

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

      3. リリースルーターをクリックして、インベントリから削除します。

    3. デバイスを新しいバッチに追加し、インポートを再開します。

  • paragon-service-orchestrationグループの一部である以下の意図しない設定は、オンボーディング時に自動的にACXデバイスにプッシュされます。

    回避策:なし。

  • オンボーディング後にデバイスのルーターIDを変更すると、トポロジーに重複するノードが作成される可能性があります。

    回避策:ルーターIDを変更する場合は、デバイスをオフボーディングし、設定でルーターIDを更新してから、デバイスを再度オンボーディングする必要があります。

可観測性

  • デバイスプロファイルを作成または編集する際に、 ORE と スマートKPIエンジン のトグルボタンを有効にしている場合、AI-ML関連のルールはインスタンス化されません。

    回避策:なし。

  • 高負荷の場合、機能タブ(監視機能>健全性>デバイス> Device-Name >インベントリのトラブルシューティング)に表示されるライセンス情報の要約が遅れることがあります。ただし、ライセンス情報は最終的にネットワークと一致します。

    回避策:なし。

  • ルールの編集中(監視機能>健全性>スマートKPIアシスタント>KPIワークスペース>ルール>編集 オプション)、組織レベルの変数を変更すると、変更されていない他のすべての変数が空の文字列にリセットされ、デフォルト値が上書きされます。

    回避策: 組織レベルの変数を変更する際、意図したデフォルト値を保持するために、他のすべての変数のデフォルト値も設定する必要があります。

  • ドキュメントコネクタの設定([設定]メニュー>[システム設定]>[組織設定]ページ>[LLMコネクタタイトルの設定]>[ドキュメント]タブ>+ )を設定する場合、ベースURLの末尾にスラッシュ(/)を追加することはできません。/ で終わる URL は現在サポートされていないため、コネクタの操作中にエラーが発生する可能性があります。

    回避策:ベースURLが末尾にスラッシュなしで入力されていることを確認してください。たとえば、https://routing.ai.juniper.net/の代わりに https://routing.ai.juniper.netを使用します。

  • MCPサーバーのコマンドブロックリストは、動作モードコマンドのみを対象としています。 delete、 rollback factory、 load factory-default、およびそれに相当するNETCONFなどの破壊的な設定コマンドはブロックされず、ユーザープロンプトやLLM生成のアクションによってトリガーされた場合に実行される可能性があり、重要なデバイス設定を失う可能性があります。

    回避策:破壊的な設定変更をトリガーする可能性のあるプロンプトは避けることをお勧めします。さらに、MCP承認ワークフローで、デバイス上で設定変更コマンドを実行する前に手動で確認することを要求できるようにします。

  • MCP設定ファイル(config.json)のhttp_urlが末尾のスラッシュ(/)で終わり、JunosデバイスにコミットをプッシュするためのRouting DirectorのMCPサーバー機能(junos_config_commitツールコール)が呼び出されると、MCPサーバーはダブルスラッシュ(//)でAPI URLを誤って構築します。これにより、400 Bad Requestエラーが発生し、ツールコールの実行に失敗します。

    回避策:MCPサーバーのconfig.jsonのhttp_urlに末尾のスラッシュが含まれていないことを確認します。http_url": "http://<ip-address>/"の代わりにhttp_url": "http://<ip-address>"を使用してください。

  • FirefoxでLLMコネクターを使用する場合、ストリーミングモードで応答テキストが文字化けして表示されます。同じ応答が会話履歴から正しくレンダリングされます。

    回避策:ChromeまたはSafariの使用をお勧めします。または、会話履歴ドロワーを開き、Firefox で正しくレンダリングする会話スレッドを選択します。

  • routingbotdbのvictoria-metricsサービスは、デプロイ中に必要なキャッシュフォルダが/vm-dataの下に作成されないため、クラッシュする可能性があります。これにより、victoria-metrics ポッドがしばらく実行された後に再起動します。

    回避策: paragon-vmstorage-cache-fix スクリプトを実行して、キャッシュフォルダが見つからないかどうかを特定し、見つからないキャッシュフォルダも自動的に作成します。

  • MCP サーバーにクエリーを実行すると、複数のツール ( mac、 router_mac、 device_mac など) 間でMACアドレスパラメーターの引数命名に一貫性がないため、AI モデルは誤った引数名をハルシネーションします。

    回避策: この問題が発生した場合は、クエリを再試行するか、プロンプトで正しい引数名を明示的に指定して、MCP 副操縦士を適切なパラメータに導くことができます。予想される正確なパラメータ名については、 MCPツールのドキュメント を参照することで、幻覚エラーを回避できます。

  • バックアップから復元する際、復元に失敗して次のエラー メッセージが表示された場合、ルート エクスプローラー ページ (監視機能>ルーティング) の デバイス と隣接関係 タブで一部のデバイスのデータが失われる可能性があります。

    Deployment Failed, Please check the log under /root/epic/config for more details.

    回避策:なし。

  • LLMコネクタを使用すると、アクティブな会話中にチャットウィンドウ内でモデルを変更できます。ただし、別のモデルを選択しても、実際にはモデルが切り替わることはありません。LLMコネクターは、最初に選択したモデルを引き続き使用するため、ライブモデルの変更を想定している場合に混乱する可能性があります。

    回避策: 別のモデルを使用するには、[LLM コネクタの設定] ページ ([設定] メニュー > [システム設定] > [LLM コネクタの設定] タイル> [追加] (+) アイコン) に移動し、必要なモデルを手動で [ Active ] としてマークしてから、新しい会話を開始します。

  • Junos OSまたはJunos OS Evolvedリリース22.3R1以降で実行されているデバイスの場合、IS-ISインターフェイスの統計情報はIS-ISレベルでストリーミングされます。この動作により、同じインターフェイスに対してカウンタ処理が重複する可能性があり、その結果、誤ったインターフェイスレベルのISISアラートが発生する可能性があります。

    次のKPIが影響を受けます:CSNPドロップ、ESHドロップ、IIHドロップ、ISHドロップ、LSPドロップ、PSNPドロップ、および不明なドロップ。

    回避策:なし。

  • Juniper Routing Directorをリリース2.7.0からリリース2.9.0にアップグレードした後、トラフィック損失(可観測性>健全性>デバイスのトラブルシューティング> Device-Name >ルーティングの概要>およびMPLS アコーディオン> トラフィック損失アラート リンク)の履歴グラフデータは表示されません。アラートは正しくキャプチャされていますが、アップグレード前の期間のグラフにはアラートが表示されません。この問題は、リリース2.8.0からリリース2.9.0にアップグレードした場合には発生しません。

    回避策:なし。

  • デバイス上で断続的に syslog-filter を使用するJunos syslogクエリが、期待どおりにデータを返しません。これにより、デバイスからsyslogデータを取得する際に、通常のプル頻度である3分を超える遅延が発生する可能性があります。このため、GUIでのsyslogデータの可用性が遅れる可能性があります。AIOps FPCリセット予測など、タイムリーなsyslogの取り込みに依存するアプリケーションでは、精度が低下したり、インサイトが遅れたりする可能性があります。

    回避策:なし。

  • Nokia 7250 IXR-xおよびNokia 7250 IXR-eデバイスのカスタムルールをアップロードすると、KPIタブのグラフ(監視機能>健全性>スマートKPIアシスタント>KPIワークスペース>ルールインスタンス> Instance-Name >監視 Instance-Name)に check-ntp-synchronization-status ルールのデータが表示されません。

    回避策:なし

  • PTX10002-36CDの場合、以下のページのグラフにはデータが表示されません。

    • Device-Nameのプラグイン可能な詳細(デバイスの監視機能>健全性>トラブルシューティング> Device-Name >インターフェイス>(アコーディオン)>プラグインの概要)

    • Device-Nameのインターフェイスの詳細(監視機能>健全性>デバイスのトラブルシューティング> Device-Name >の概要>インターフェイス(アコーディオン)>入力/出力>信号機能/FECが正しくありません)

    回避策:なし。

  • 隣接関係が失敗するか確立されると、ルーティング監視機能はこれらのイベントを検出し、イベントページ(監視機能>正常性>イベント)に報告します。ただし、同じ隣接イベントが複数回報告される場合があります。

    回避策:自己IDとネイバーIDの組み合わせを関連付けることで、これらの繰り返しイベントを単一のイベントとして扱います。

  • 監視対象のデバイスに致命的な障害が発生し、その後ルーティングディレクトリからオフボーディングされた場合でも、これらの古いデバイスがルートエクスプローラーのデバイステーブル([監視能力]>[ルーティング>デバイス]タブ)に表示されることがあります。

    回避策: 古いデバイスを Routing Director の内部データベースから手動で削除して削除します。

  • パッシブアシュアランスタブ(オーケストレーション>インスタンス>サービスインスタンス> Service-Instance-Name ハイパーリンク)のすべてのアコーディオンの関連イベントセクションにアラートは表示されません。

    回避策:アラートは、イベントページ(監視機能>イベント)またはそれぞれのグラフで表示できます。

  • 自動更新を有効にしていても、 Device-Name のIS-ISルーティングの詳細ページ(監視可能性>健全性>デバイスのトラブルシューティング> Device-Name >ルーティング>とMPLS IS-IS>>IS-IS隣接フラップの概要)のグラフに表示されるアラートとデータは同期されない場合があります。

    回避策: Device-Name のIS-ISルーティング詳細ページを閉じてから再度開き、最新のデータを確認します。

  • KPI が繰り返しパターンで固定値間を継続的に変動する場合、境界は最初は予想通りに適応しますが、数時間後には、振動パターンが変化しないにもかかわらず再調整され始めます。この動作は、完全に適応した後も持続する可能性があり、境界が不必要に変動し続ける原因となります。

    回避策:なし。

  • 2 つのノード間にパラレル リンクを使用する設定では、隣接関係またはリンク フラップは、個々のリンク遷移ではなく、ノード間の接続の完全な喪失または回復でのみ報告されます。

    回避策:なし

  • ノードの急激な減少に関連する異常の報告に予期しない遅延が生じます。異常は、合計遅延期間が経過した後にのみ反映されます。

    回避策: REST API を使用して、この異常に関連する情報を表示できます。

  • デバイスのオンボーディング後、Routing Director はデバイスの健全性に関連する KPI を継続的に監視します。Routing Director は、KPI ごとに KPI を監視し、範囲を予測し、発生する異常を検出します。KPI 値が変更された場合、予測範囲が安定するまでに約 2 時間かかります。

    回避策:なし。

  • ネットワーク実装計画にデバイスプロファイルを追加する際に、ルーティングプロトコル分析を有効にすると、デバイスプロファイルにリストされているデバイスのルーティングデータが収集されます。ネットワーク実装計画を公開すると、オンボーディングワークフローが成功したように見えても、これらのデバイスのルーティングデータの収集に関連するエラーが発生する可能性があります。これらのエラーのため、デバイスは Routing Director にデータを送信するように構成されないため、ルーティング データは Routing Director GUI の [ルート エクスプローラー] ページに表示されません。この問題は、デバイスのオフボーディング時にも発生し、オフボーディングされたデバイスが Routing Director にデータを送信し続ける場合にも発生します。

    この問題は、デバイスでASNまたはルーターIDを設定していない場合や、排他的編集のためにデバイス設定をロックしている場合にも発生します。

    回避策:この問題を解決するには:

    1. 以下のいずれかを実行します。

      • request paragon debug logs namespace routingbot app routingbot service routingbot-apiserverシェルコマンドを実行して、サービスログを確認します。表1に示されているエラーメッセージに基づいて、必要なアクションを実行します。

        表1:エラーメッセージ
        エラーメッセージ 問題点

        {dev_id}dev_idのデバイスプロファイル情報を取得できませんでした:{res.status_code} - {res.text}

        {dev['dev_id']}dev_idデバイス情報を取得できませんでした。デバイスをスキップしています。

        		 デバイス情報を取得するための PAPI への API 呼び出しに失敗しました。

        dev_id {dev_id} の応答で結果が見つかりませんでした

        {dev['dev_id']}dev_idデバイス情報を取得できませんでした。デバイスをスキップしています。

        		 PAPI への API 呼び出しは、データなしの応答を返します。

        dev_id {dev_id} の応答に完全なデバイス情報が見つかりません:{device_info}

        		 PAPI の API 呼び出しは、不完全なデータを含む応答を返します。
        PFからのdev_id{dev_id}に関するデータが見つかりませんでした デバイス情報を取得するためのPathfinderへのAPI呼び出しに失敗しました。
        PFデータからdev_id{dev_id}に必要なデータが見つかりません:{node_data}

        デバイス情報を取得するために Pathfinder を API 呼び出しすると、不完全なデータを含む応答が返されます。
        EMS設定がエラーで失敗しました。設定の場合:{cfg_data}またはEMS設定プッシュエラー{res} {res.text} |try: {retries}.デバイス{mac_id}でのBMPの設定に失敗しました BGPの設定に失敗しました。

        メジャー、マイナー、またはリリースバージョンの形式が無効です:{os_version}

        		 デバイスのOSバージョンはサポートされていません。
        エラーPOST {self.config_server_path}/api/v2/config/device/{dev_id}/ {data} {res.json()} プレイブックの申請に失敗しました。
        エラーPUT:{self.config_server_path}/api/v2/config/device/{dev_id}/ {data} {res_put.json()} プレイブックの削除に失敗しました。
        エラーPUT:{self.config_server_path}/api/v2/config/device/{dev_id}/ {data} {res_put.json()} デバイスグループへのデバイスまたはプレイブックの適用に失敗しました。

        エラーPUT {self.config_server_path}/api/v2/config/device-group/{site_id}/ {data} {res_put.json()}

        デバイスグループからのデバイスまたはプレイブックの削除に失敗しました。

      • デバイスの設定を調べて、デバイスに予期しない設定の有無または存在がないかどうかを確認します。例えば、以下を行うことができます。

        • set groups paragon-routing-bgp-analytics routing-options bmpの下に存在する設定を表示します。

        • JTIMON ポッドのデバイス設定を確認します。

    2. 上記の問題を解決したら、デバイスに適用したネットワーク実装計画のデバイスプロファイルを編集します。デバイスをオンボーディングするかオフボーディングするかに基づいて、デバイスプロファイルのルーティングプロトコル分析オプションを有効または無効にします。

    3. ネットワーク実装計画を公開します。

    4. Routing Director GUIのルートエクスプローラーページに表示されるデータに基づいて、必要な結果が表示されているかどうかを確認します。

  • インターフェイスアコーディオンでは、FEC未修正エラーチャートは、100Gbps以上の速度をサポートするインターフェイスでのみ使用できます。

  • デバイスに新しい設定を適用した後、 Device-Name のアクティブな設定ページ (監視機能>デバイスのトラブルシューティング> Device-Name >設定のアコーディオン>アクティブな設定の表示リンク)に最新の設定がすぐに表示されません。最新の変更が Device-Name のアクティブ設定ページに反映されるまでに数分かかります。

    回避策:CLIを使用してデバイスにログインすることで、新しい設定がデバイスに適用されているかどうかを確認できます。

  • すべての光モジュールがすべての光関連KPIをサポートしているわけではありません。詳細については 、表2 をご覧ください。

    回避策:なし。

    表2:光モジュールでサポートされているKPI

    モジュール

    Rx 信号損失 KPI

    Tx 信号損失 KPI

    レーザー無効KPI

    SFP光インターフェイス

    いいえ

    いいえ

    いいえ

    CFP 光インターフェイス

    はい

    いいえ

    いいえ

    CFP_LH_ACO光インターフェイス

    はい

    いいえ

    いいえ

    QSFP光インターフェイス

    はい

    はい

    はい

    CXPオプティクス

    はい

    はい

    いいえ

    XFPオプティクス

    いいえ

    いいえ

    いいえ

  • PTX100002デバイスでは、インターフェイスアコーディオン(監視能力>健全性>デバイスのトラブルシューティング>Device-Name>の概要)で以下の問題が観察されます。

    • Device-Nameのプラガブルの詳細ページ(インターフェイスアコーディオン>プラガブルデータリンク)に、光送信電力と光受信電力グラフにデータが表示されません。

    • Device-Nameの入力トラフィックの詳細ページ(インターフェイスアコーディオン>入力トラフィックデータリンク)に、信号機能グラフにはデータが表示されません。

サービスオーケストレーション

  • EVPN VPWSの導入では、同じ物理CEデバイスに接続されたアクセスリンクが異なるCE参照名で設定されている場合、特定のマルチホームカスタマーエッジ(CE)トポロジーの配置検証に失敗することがあります。

    回避策:同じ物理 CE デバイスで終端するすべてのアクセス リンクに共通の CE 参照名を設定します。これらのアクセス リンク全体で一貫した CE 参照名を使用することで、サービスの検証とプロビジョニングが正しく行われます。

  • VLAN IDは、すでに別のサイトネットワークアクセス(SNA)によって消費されていても、接続の編集ページ(オーケストレーション>サービス>インスタンス>顧客サイト設定タブ Service-Instance-Name >>サイトネットワークアクセスの編集セクションの変更)のVLANドロップダウンリストに表示され続けます。この不適切な可用性により、同じ VLAN ID を再利用した場合に IRB の配置エラーが発生します。

    回避策:なし。

  • EVPNサービスインスタンスを設定すると、 mpls-evpn と pbb-evpn の両方のVPNサービスタイプがオプションとして表示されます。ただし、Routing Director GUIでサポートされているのは mpls-EVPN のみで、デフォルトのサービスタイプです。

    回避策:なし。

  • リソースインスタンスページ(オーケストレーション>サービス>リソースインスタンス)では、 network-運用担当者:topo リソースはシステム管理リソースです。その結果、システムがリソースを生成するときにワークフロー実行ID列が空になることがあります。ワークフロー実行ID列は、 更新 ボタンをクリックした場合にのみ設定されます。

    回避策:なし。

  • まれに高負荷のシナリオでは、一時的なバックエンドリソースが利用できないために、EVPNインスタンスのプロビジョニングに失敗することがあります。

    回避策:サービスのプロビジョニングを再試行します。

アクティブアシュアランス

  • 少数のモニターが多数のテストエージェントに分散している場合(たとえば、500台のテストエージェントに1,000台のモニターがある場合)、モニターページ(オブザーバビリティ>アクティブアシュアランス)に、すべてのモニターを取得するときにエラーが表示されます。要求された文字列の長さが制限を超えると、API呼び出しは失敗します。

    回避策: 測定ページ(テストエージェント>>測定)で特定のデバイスのすべての測定値を表示するか、モニターページでフィルターを適用して、テストエージェントに基づいてモニターをフィルターできます。

  • 削除されたテストエージェントは、アプリケーションページのテストエージェントタブ(監視機能>健全性>健全性ダッシュボード>アクティブアシュアランス(タブ)>アプリケーションページ>詳細を表示>影響を受けるアイテム)に表示されます。

    回避策:なし。

  • テストエージェントアプリケーションは、Junos OS Evolvedリリース25.4R1およびJunos OS Evolvedリリース25.4R2を実行しているデバイスにはインストールできません。

    回避策:なし。

  • モニターは、生成できる測定数に制限を適用しません。Routing Directorは、作成できるモニターの数を制限しません。大規模なセットアップでは、複数のモニターで一度に大量の測定(25,000など)を開始または停止すると、大量の操作がトリガーされる可能性があります。そのため、運用が完了するまでに大幅な遅延が発生します。

    回避策: パフォーマンスを向上させるには、すべてのモニターを同時に停止または起動しないでください。代わりに、小さなバッチで操作を順次トリガーします。たとえば、モニターのサブセットを開始または停止し、それらの測定が実行または停止するまで待ってから、次のバッチに進みます。

  • GUIを使用してテストエージェントを論理的に削除すると、削除されたテストエージェントは切断され、[ ゴミ箱 ]タブに移動します。論理的に削除されたテストエージェントが後で ゴミ箱 タブから完全に削除された場合、Routing Directorは登録解除コマンドをテストエージェントに送信できません。その結果、資格情報は無効になってもテストエージェントページに表示されたままになります。

    回避策:なし。

  • 監視ページからレポートをダウンロードすると、監視関連のデータがレポートに完全にキャプチャされず、不適切な書式が表示される場合があります。

    回避策:なし。

  • 監視レポートが繰り返し生成されると、タスク構成セクションが生成されたPDFにレンダリングされないことがあります。

    回避策:ページを更新して、レポートの生成を再試行します。

  • タスクの数が多い(約100)モニターのレポートをダウンロードすると、レポートに不完全なデータが含まれており、レポートの[測定の概要]セクションで一部のタスクが省略されます。レポートでは、各測定値の最新の 10 個のイベントやイベント バーは表示されません。

    回避策:なし。

  • テストエージェントクロックのオフセットが大きい場合、テストエージェントが生成する結果は影響を受けます。つまり、現地時間が過去または未来である場合です。これは、次のことを意味します。

    • そのテストエージェントで実行されている測定によって生成されたストリームのメトリックのタイムスタンプが影響を受けます。

    • イベントのアクティブ化時刻とイベントの非アクティブ化時刻が影響を受けます。

    そのため、システムがテスト実行ランタイムと見なす時間範囲にメトリックまたはイベントが含まれていないため、テスト実行が誤って評価される可能性があります。この状況について明示的に警告されない場合があります。ただし、この問題は、時間変化したメトリックまたはイベントとともに現れます。

    回避策: 時間同期はテストエージェントの要件です。テストエージェントのクロックが同期されていることを確認します。

  • QoS プロファイリング テストを実行すると、TCP スループットは輻輳制御の影響を受けます。

    QoSポリシーのプロファイリングは、実際のネットワーク動作を反映しています。そのため、QoSプロファイリングテスト中に観察されるTCPススループットは、TCP輻輳制御の影響を受けます。ドロップポリサーは、パケット損失が輻輳応答をトリガーし、送信レートを低下させるため、測定されたTCPパフォーマンスを低下させる可能性があります。プロファイリング結果のスループットが低下する場合は、使用中のポリサーを確認し、代わりにトラフィックシェーパーの使用を検討することをお勧めします。シェーパーは、余剰パケットをドロップするのではなくキューに入れます。これにより、プロファイリングテストでネットワークの真の容量とパフォーマンスをより正確に表すことができます。

  • テストエージェントがインストールされているACXデバイスを再起動すると、Dockerが削除され、テストエージェントがオフラインになり、アクティブなアシュアランス測定に影響を与えることがあります。

    回避策: 以下を実行します。

    1. ルーターにログインします。

    2. paa test-agentサービスを無効化する

      そして変更をコミットします。

    3. paa test-agentサービスを再アクティブ化し、変更をコミットします。

  • まれに、オフライン状態でプラグインのアップグレードが必要なテストエージェントのみがアップグレードされることがあります。オンラインでプラグインのアップグレードが予定されているテストエージェントでは、プラグインのアップグレードが行われない場合があります。

    回避策: システム内のプラグインの1つのアクティブなバージョンを変更すると(必ずしも同じプラグインまたは同じ組織にある必要はありません)、保留中のアップグレードが再確認され、アップグレード保留中のオンラインテストエージェントのアップグレードが続行されます。これを行うには、次のいずれかの方法があります。

    • プラグインインベントリページ(インベントリ>アクティブアシュアランス)を使用して、プラグインのアクティブバージョンを2つのプラグインバージョン間で前後に変更できます。

    • または、API を使用して同じプラグイン バージョンを再度有効にします。

      1. プラグインインベントリページからプラグインバージョンの ID をコピーします。

      2. 次のリクエストを実行して、同じプラグインを再度有効にします。

  • メトリックグラフには、次の場合に、測定値を含むステップを含むテストのデータが表示されません。

    • テストでは、自己管理プラグインを使用します。

    • テストの実行中にメトリックを生成するストリームをクリックした場合。

    この問題は、同じ開始時刻と終了時刻を設定した場合に発生します。

    回避策:代わりに、カスタム時間範囲を意味のあるものに手動で設定してください。テストの実行が完了すると、メトリックが正しく表示されます。

  • Routing Director インスタンスを復元すると、アクティブ アシュアランス プラグインやパケット キャプチャ ファイルなどの一部のデータがバックアップされない場合があります。これは、どのKubernetesボリュームに対してもバックアップが実行されていないためです。

    回避策: インスタンスを復元する前にパケットキャプチャファイルをダウンロードし、ローカルに保存して分析することをお勧めします。Active アシュアランス Plug-insの場合、プラグインインベントリページ(Inventory > Active アシュアランス)を使用して、新しい(復元された)インスタンスに最新のプラグインを再度アップロードすることをお勧めします。

  • バックアップを作成してRouting Directorインスタンスを復元した後、一部のテストエージェントでステータスが Onlineと誤って表示されることがあります。

    回避策:システムが完全に復元されたら、次の手順を実行します。

    1. テストエージェント test-agent-gateway 更新するには、もう1回再起動します。

    2. Linuxルートシェルから kubectl -n paa delete pod -l app=paa-test-agent-gateway コマンドを実行します。

  • 600 個のストリームを持つモニターを作成すると、モニター作成タイムアウトエラーが発生し、モニターが自動的に停止することがあります。

    回避策: Monitor-Name ページ(アクティブアシュアランス>モニター>監視機能> Monitor-Name)からモニターを再起動し、Routing Director GUIでさらに表示>開始)をクリックします。

  • デバイスのルーティングエンジンがプライマリルーティングエンジンからバックアップルーティングエンジンに、またはその逆に切り替わった後、テストエージェントのステータスはオフラインとして表示されます。この問題は、23.4R2より古いバージョンのJunos OSを使用している場合にのみ発生します。

    回避策:ルーティングエンジンのスイッチオーバー後にテストエージェントを再インストールします。

  • 既存のモニターに新しいホストを追加すると、新しい測定値は正常性ダッシュボードのアクティブアシュアランスタブ(監視能力>正常性)に反映されません。

    回避策:なし。

ネットワークの最適化

  • トポロジー設定ページの詳細タブ>にある再 解析 オプション(ネットワーク>トポロジー>トポロジーメニューバー>設定アイコン)は現在機能していません。呼び出されると、以前に収集されたデバイス設定出力は期待どおりに再解析されません。

    回避策:トポロジー内の任意のデバイスでデバイス収集をトリガーします。

    1. トポロジーページ(ネットワーク>監視機能)に移動します。

    2. デバイスタブからデバイスを選択します。

    3. さらに表示をクリックして>デバイスコレクションを実行します。

    これにより、トポロジー全体が再解析され、収集された設定でトポロジーがリロードされます。

  • Routing Directorリリース2.9.0にアップグレードすると、トポロジーフィルターは動的トポロジー関連情報(BGP-LS)を処理できません。

    回避策: 以下を実行します。

    1. pf-organizationID名前空間を削除します。

    2. ns-configmonitorポッドを再起動して、pf-organizationIDの下にポッドを作成します。

  • 以前に削除したトンネル名を使用すると、Cisco デバイスで NETCONF RSVP トンネルの作成に失敗することがあります

    回避策: 同期 操作(ネットワーク>トポロジー>トポロジーメニューバー>設定アイコン>詳細タブ )を実行する>同期操作を実行します。

  • デュアルIPv4またはIPv6インターフェイスを持つリンクの場合、パケットロスを測定する際には、IPv4アドレスのみがターゲットpingアドレスとして使用されます。IPv6 のみのインターフェイスを持つリンクの場合、パケット損失測定値は作成されません。

    回避策:なし。

  • トンネルに現在のパスがない場合でも、トポロジーページ(可観測性>トポロジー)のトポロジーマップに、トンネルに必要なパスデータを使用して強調表示されたパスが表示されることがあります。その結果、マップの可視化と [トンネル] テーブルの [現在のパス] 列の間に不一致があることに気付く場合があります。

    回避策:なし。

  • ネットワーク実装計画でActive アシュアランスを有効にすることは、デバイスのパケット損失を収集するための前提条件です。ネットワーク実装計画を変更している間は、Active アシュアランスを有効または無効にすることはできません。そのため、ネットワーク実装計画でActive アシュアランスを無効にし、後で有効にしたい場合は、以下のいずれかを実行する必要があります。

    • オフボードおよびオンボードデバイス、または

    • デバイスのテストエージェントを手動で作成します。

  • SR LSP の委任を解除した後、SID 圧縮が期待どおりに機能しません。

    回避策:なし。

  • まれに、テストエージェントの測定エクスプローラページ(測定エクスプローラ>アクティブアシュアランス監視機能>)に接続エラーが表示され、テストエージェントが損失統計を収集するためにターゲットデバイスに接続できない場合があります。その結果、トポロジーページ(可観測性>トポロジー)の損失統計が古くなっている可能性があります。

    回避策:なし。テストエージェントがターゲットデバイスに再接続すると、パケット損失の統計情報が自動的に更新されます。

  • LSP 委任を削除すると、ルーティング方法が デフォルト から routeByDevice に自動的に変更されます。

    回避策:LSPルーティング方法を目的のオプションに手動で更新する必要があります。

  • 帯域幅サイジングが有効な SR LSP の場合、LSP を介した集約トラフィックに基づく帯域幅のサイズ変更は、設定されたしきい値に従って行われるとは限りません。

    LSPトラフィックの総値が現在の帯域幅を調整しきい値の割合で超えていないにもかかわらず、SR LSPの帯域幅が変更される場合があります。また、計算された集約トラフィックが現在の帯域幅と設定されたしきい値だけ異なるにもかかわらず、LSPの帯域幅が変更されない場合があります。

    これは、Routing Director GUIまたはREST APIを使用してLSPを作成または変更する際に設定されたLSP帯域幅に従って、LSPトラフィックの帯域幅サイズ調整中に誤った比較が行われるために発生します。

  • 誤ったRSVPリンク使用率は、以下のシナリオで発生する可能性があります。

    • LSP 制約により、Routing Director は、閾値交差再ルーティング時に、トラフィックの高い LSP ではなく、トラフィックの低い LSP を再ルーティングします。

    • 次のパス最適化では、Routing Directorは、パスに沿った帯域幅アカウンティングを含め、トラフィックの高いLSPの現在のパスを削除します。その結果、RSVPリンクの使用率が誤ります。

  • Junos OSリリース22.4R1以降では、SR-TE LSPに制限があります。PCEPセッションを確立するには、次のコマンドを使用してマルチパス機能を無効にする必要があります。

    set protocols pcep disable-multipath-capability

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

  • SR-TE LSPのステータスは、委任またはプロビジョニング後にダウンと表示される場合があります。ノードと隣接SIDの両方を使用するパラレルなSR-TE LSP(同じ送信元または宛先ノード)がある場合、RPDログにエラー(RPD_SPRING_TE_ROUTE_LSP_MISMATCH)が発生する可能性があります。

    回避策:すべてのパラレル SR-TE LSP は、ノード SID または隣接 SID のいずれかを使用する必要があります。

  • REST APIを使用してLSPを作成しようとした場合、既存のLSP名を再利用している場合、REST APIサーバーはエラーを返しません。

    回避策:なし。

  • バックアップまたはリストアの操作を実行すると、トラフィックはトポロジーページに0%と表示されます。

    回避策: バックアップまたは復元操作の後、pf-telemetry ポッドを再起動するか、デバイス コレクションをトリガーし、pf- namespaceで pcs ポッドも再起動します。

  • Routing Directorは、IS-ISオーバーロードビットが設定されたデバイスからLSPを自動的に再ルーティングしません。ただし、最適化中は、ルーティング方法が IS-IS に設定されている LSP は、影響を受けるデバイスから再ルーティングされます。

    回避策:オーバーロードビットがあるデバイスに接続されているすべてのリンクで、 Faulty 設定を手動で有効にします。後で、オーバーロード ビットがクリアされたら、これらのリンクの Faulty プロパティをクリアする必要があります。

  • ECMPの多様なパスが複数存在し、定期的な再最適化を有効にしている場合、多様なLSPが2つのルーティングパス間を行き来する可能性があります。

    回避策:この動作を望まない場合は、[LSPの変更]ページで[ パスタイプ ]を[優先]に設定します。

  • 場合によっては、LSPプロビジョニングが成功せず、トポロジー(可観測性>トポロジー)ページのトンネルテーブルにPCC_Pendingエラーが表示されることがあります。

    回避策:Junos OS設定でプロトコルとPCE関連ステートメントを無効にしてアクティブにして、ヘッドエンドルーターでPCEPセッションを再開します。

  • ネットワーク内にブロードキャストリンクが存在する場合、セグメントルーティング(SR)LSPは作成されない場合があります。

    回避策:ルーター設定で、ブロードキャストリンクをポイントツーポイントリンクに変更します。

ネットワークプランナー

  • インストール時またはアップグレード時に実行されるバックアップおよびリストア操作には、Plannerのユースケースのサポートは含まれていません。その結果、プランナー関連のデータや設定はバックアップ中に保存されず、バックアップ後も復元されません。

    回避策:なし。

  • 現在、サイトレベルの多様性は、同じ多様性グループに属するLSPのペアのパスにおいて、デバイスまたはノードの多様性のみを提供します。各デバイスに関連付けられているサイト情報は考慮されません。その結果、各デバイスは独立したサイトとして扱われ、真のサイトレベルの多様性を達成できないパスにつながる可能性があります。

    回避策:なし。

  • 特定のネットワーク トポロジーでは、モデル とパスの更新 操作を実行した後、プランナーがデマンドに対して誤った明示的なルート オブジェクト (ERO) を計算し、予想される最短パスではなく最適ではないパスに沿ってデマンドがルーティングされる場合があります。

    回避策:なし。

  • モデルとパスの更新操作の実行中に、 なし または未 配置のみを選択すると、トンネルが通過するリンクでセグメントルーティング(SR)が無効になっている場合、Plannerはトンネルの計算パスを無効にできません。ルートを無効としてマークする代わりに、Plannerは誤って古いパスを保持します。

    回避策:なし。

  • 包括的な障害シミュレーションを実行すると、トンネルオンリンクレポート(L2_DVSIM.r0)とリンク使用率レポート(DVSIM.r0)で、方向性リンクエントリのPeakCnt値が誤って計算されます。レポートでは、ゼロ以外のPeakCntが、再ルーティングされたトンネルEROが実際に通過していないリンク方向に起因する場合があります。

    回避策:なし。

  • 包括的な障害シミュレーションを実行すると、物理リンクのトラフィックレポート(L2_PHYDVSIM.r0)に誤って疑似ノードリンク障害が記載されていません。

    回避策:トポロジーから疑似ノードリンクを削除し、包括的な障害シミュレーションを再実行して、正しいレポートを取得します。

  • 包括的な障害シミュレーションを実行すると、リンク使用率レポート (DVSIM.r0) は、再ルーティングされた需要によって通過するリンクのPeakBw_AとPeakUtilPct_Aの誤った値を計算します。この計算エラーにより、リンク帯域幅と使用率メトリックのレポートが不正確になります。

    回避策:なし。

  • 網羅的な障害シミュレーションでは、再ルートに失敗した需要は、失敗したパスレポート(PeakSimRoute.r0)には報告されません。これは、Plannerが有効な物理リンクではなく、疑似ノードリンクを介して需要を誤ってルーティングし、失敗した需要がレポートから省略されたために発生します。

    回避策:トポロジーから疑似ノードリンクを削除し、包括的な障害シミュレーションを再実行して、正しい障害パスレポートを取得します。

  • トンネル層での包括的な障害シミュレーション中に、 物理リンクのトラフィック レポートに、リンクを反対方向に通過するトンネルが複数のトンネルとして誤ってカウントされます。具体的には、2つのトンネルが同じ物理リンクを使用しているが、方向が異なる場合(例えば、AからB、BからA)、プランナーは トンネル と PeakCnt の値を1ではなく2として報告します。これは、両方向からのトンネルが一緒にカウントされるのではなく、独立して処理されるために発生します。

    回避策:なし。

  • トンネルパスがECMPパスを通過する場合、Plannerは、ルーティング方法として デバイス別ルート で設定されたSRトンネルから生成された需要をルーティングしません。影響を受けた需要は未ルーティングのままです。

    回避策:なし。

  • Routing Director クラスターのバックアップと復元後、以前に生成された What-if または Exhaustive 障害シミュレーションのレポートは保持されません。

    回避策: バックアップ操作前に生成されたレポートは復元できません。クラスターを復元した後、シミュレーションワークフローを再実行して、必要なレポートを再作成します。

  • デマンド層シミュレーションの失敗パスレポートには、トンネルに関する情報も含まれています。

    回避策:なし。

  • オフラインのトポロジーページ(ネットワーク>の計画> Offline-Model >オープン)のインターフェイスタブからインターフェイスアドレスと帯域幅を変更した場合、オフラインのトポロジーページ(ネットワークの計画> Offline-Model >オープン)のリンクタブに変更>反映されません。

    回避策:なし。

  • Plannerでのパス計算中は、ダウンとマークされたリンクが考慮されたままです。したがって、計算されたパスにはダウンリンクが含まれる可能性があります。

    回避策: シミュレーションを実行する前に、ダウンとしてマークされているリンクを削除してください。リンクは後で再作成できます。

  • オフライントポロジーページ(オフラインモデル>>ネットワーク計画> Model-Name >オープン)で、デバイスを削除しても、関連するリンクは自動的に削除されません。

    回避策: ノードを削除する前に、ノードに接続されているリンクを手動で削除します。

  • トンネルとデマンドは、同じ名前であってはなりません。そうしないと、トンネルと需要のステータスが downと表示される場合があります。

  • オフラインモデルでは、プライマリLSPのみを作成できます。既存のオフラインモデルにセカンダリLSPまたはスタンバイLSPを作成することはできません。ただし、ライブネットワークをインポートするときに、セカンダリまたはスタンバイLSP関連の詳細を表示することができます。

    回避策:なし。

信頼

このリリースに既知の問題はありません。

管理

  • スーパーユーザーがパスワードのリセットをトリガーし、二要素認証を有効にしている場合、パスワードの変更を求められます。ただし、「パスワードの変更」オプションをクリックすると、次のエラーが発生する場合があります。

    Request failed with status code 401

    回避策: スーパーユーザーがあなたを組織から削除し、再度追加する必要があります。管理者から提供されたパスワードを使用してログインした後、二要素認証を再度有効にできます。

  • 新しいサイトをデバイスに割り当てると、サイトの変更に関する確認メッセージが表示されますが、インベントリページ(デバイス>インベントリ>ネットワークインベントリ)またはデバイスのトラブルシューティングページ(監視機能>健全性)に変更が反映されない場合があります。

    回避策:サイトの割り当てを再試行して、変更が反映されることを確認します。

  • トランスポート層セキュリティ(TLS)証明書を使用して、Nokiaデバイスをオンボードすることはできません。

    回避策:なし。

インストールとアップグレード

  • gnmi-termポッドでは、時間の経過とともにメモリ使用量が徐々に増加する可能性があります。この動作は、通常、デバイスが PAPI にオンボーディングされていないために、多数のデバイスが繰り返しセッション作成に失敗する環境で最も顕著です。セッション作成に失敗が続くと、ポッドのメモリーが持続的に増加する可能性があります。

    回避策: gnmi-term pod は、時間の経過とともにメモリ使用量が徐々に増加することがあります。この動作は、設定ミスやデバイスの削除により、多数のデバイスが繰り返し接続に失敗する環境で最も顕著です。このような継続的なイベントは、一定期間にわたってポッドのメモリーの増加につながる可能性があります。

  • システム負荷が高い場合、以下のストリームプロセスではCPU使用率が100%維持されることがあります。

    • alarm-event

    • device-profiles

    • papi-events

    • papi-mon-v2

    • papi-switch-stats

    この動作は、ストリーム・プロセスが処理ループでスタックした場合に発生します。機能への影響は既知に見られていません。ただし、影響を受けるプロセスは過剰なCPUリソースを消費する可能性があります。

    回避策:ストリームプロセスを再開します。

  • Routing Director をインストールまたはアップグレードすると、OpenSearch のステータスが黄色(オレンジ色)または赤色に表示される場合があります。

    回避策: 以下を実行します。

    1. paragon-utils curl http://opensearch-cluster-master.common:9200/_cat/health?v コマンドを実行して、OpenSearch の最新のステータスを確認します。

      ステータスが緑色で active_shards_percent が 100% の場合、OpenSearch は完全に機能しているか、回復しています。そうでない場合は、残りの手順を実行します。

    2. paragon-utils curl http://opensearch-cluster- master.common:9200/_cat/shards?vコマンドを実行して、OpenSearchシャーディングの割り当てを確認します。

      1つ以上のシャードが Unassigned 状態でスタックしている場合、または実行中でない場合は、次のステップに進みます。

    3. kubectl scale sts -n common opensearch-cluster-master --replicas 0; sleep 120; kubectl scale sts -n common opensearch-cluster-master --replicas 3 コマンドを実行してOpenSearchを再起動します。

      注:

      この処理には数分かかる場合があります。すべてのOpenSearchインスタンスを同時に停止して再起動するため、OpenSearchを必要とする一部のポッドがしばらくクラッシュする可能性があります。

    4. paragon-utils curl http://opensearch-cluster-master.common:9200/_cat/health?vコマンドを使用して、OpenSearchステータスを再度確認します。

      この時点で、OpenSearch のステータスは緑色で、 active_shards_percent は 100% である必要があります。

  • テレメトリバックアップには、エアフローワークフローに関する情報は含まれません。その結果、次のコマンドを実行すると、エラーが発生する場合があります。

    回避策: エラーは無視しても問題ないため、テレメトリバックアップを復元する際にはこのコマンドをスキップすることをお勧めします。

  • Active アシュアランス Victoria Metricsデータベース(時系列データの保存に使用)を含むJuniper Routing Directorインスタンスのバックアップを作成し、インスタンスを復元する場合、GUIに復元されたデータを表示できません。paa Kubernetes名前空間のmetrics-serviceのログに一連のエラーが表示される場合があります。

    回避策:kubectl rollout restart deployment paa-metrics -n paaコマンドを使用してpaa-metrics再起動します

  • クラスターで高負荷が発生すると、一部のコンポーネント、特に Victoria Metrics Operator および ArangoDB Operator ポッドが再起動されることがあります。これは、クラスターの機能には影響しません。

    回避策:なし。