Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページの内容
 

既知の問題

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

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

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

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

  • I2C ID 161を使用してvMXを導入する場合、加入者が作成された後、すべてのコミット操作が失敗します。

    回避策:サブスクライバーを削除してから、設定をコミットします。

  • Routing Directorは、デバイスの初期オンボーディング時にのみ、デバイスプロファイルとインターフェイスプロファイルに含まれる設定テンプレートをトリガーします。デバイスプロファイルとインターフェイスプロファイルに含まれる設定テンプレートを使用して、デバイスのオンボーディング後にデバイスに追加の設定を適用することはできません。

    回避策:デバイスのオンボーディング後にデバイスに追加の設定を適用する必要がある場合は、CLIを使用するか、Routing Director GUIを使用して設定テンプレートを実行して、設定を手動で適用する必要があります。

可観測性

  • トラフィック損失ページ(可観測性>健全性>デバイスのトラブルシューティング>デバイス名>の概要>ルーティングおよびMPLSアコーディオン>トラフィック損失アラートリンク)の入力、出力、ドロップ率グラフのY軸スケーリングが一貫していないと、トラフィックレートの誤解を招く表現が発生します。

    回避策:なし。

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

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

  • L1とL2の両方が同時に有効になっている場合、IGPプレフィックスタブ(可観測性>ルーティング>ルートトポロジー)には、両方のレベルのプレフィックスが表示されません。代わりに、L1プレフィックスのみが表示されます。デュアルレベル(L1 + L2)プレフィックスのサポートはサポートされていません。

    回避策:プレフィックスを正しく表示するには、デバイスプロファイルページの分析タブ>(デバイスとインターフェイスプロファイル>デバイスプロファイル>>デバイスプロファイルの追加)で、L1またはL2のみのデバイスに対して LSDB を選択します。L1とL2の両方に設定されたデバイスの選択は避けてください。

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

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

  • バックアップを復元した後、隣接関係タブ(ルートエクスプローラ>ルートエクスプローラの監視機能>)に、BGPピアの誤った状態が表示される場合があります。

    回避策:監視対象デバイス上の BGP ピアをフラップします。

  • 特定の条件下では、一時的なトラフィック損失により、パケットドロップ(メジャー)アラートがブラックホール(重大)アラートとして誤って分類されることがあります。開始時刻と終了時刻が同一であることを確認することで、このようなアラートを識別できます。

    回避策:なし。

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

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

  • ドキュメント モードが設定されていても、LLM コネクタのチャット ウィンドウを開くと、会話モードが誤ってアクティブになります。

    回避策:プロンプトを開始する前に、操作モードを手動で ドキュメントに 切り替えます。選択すると、セッションは期待どおりに動作します。

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

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

  • 宛先の追加ページ(管理>エクスポートマネージャー>宛先の管理)でTLS暗号化の使用トグルボタンを有効にすると、SASLユーザー名フィールドとパスワードフィールドが予期せずクリアされます。

    回避策:TLS暗号化を使用トグルを有効にした後、SASLユーザー名フィールドとパスワードフィールドを再入力します。

  • 自動更新にもかかわらず、リストされたアラートとグラフに表示されたデータは、 Device-Name ページの出力トラフィックの詳細ページ(監視機能>健全性>デバイスのトラブルシューティング> Device-Name >インターフェイス>の概要(アコーディオン)>出力トラフィック)で同期されない場合があります。

    回避策: Device-Name ページの出力トラフィックの詳細(監視機能>健全性>デバイスのトラブルシューティング>> Device-Name >インターフェイスの概要(アコーディオン)>出力トラフィック)を閉じて再度開き、最新のデータを確認します。

  • リリース2.8.0以降、Juniper Routing Directorは、ジュニパーデバイスへのgNMIダイヤルイン接続を開始し、テレメトリデータを収集します。対応するファイアウォールルールが、Routing Directorコレクターからポート32767上のデバイスへのトラフィックを許可していることを確認する必要があります。

    デフォルトでは証明書検証が無効になっています。証明書の検証を再度有効にする場合は、ネットワーク内のデバイスが Junos OS または Junos OS Evolved リリース 24.2R1、24.2R2、24.4R1 以外のリリースで実行されていることを確認してください。次のREST APIコマンドを使用して、証明書の検証を再度有効にします。

  • 場合によっては、デバイスのトラブルシューティングページ(監視機能>健全性>デバイスのトラブルシューティング)の重大度列とトポロジーページのデバイスタブ(監視機能>ネットワーク>トポロジー)に表示される重大度レベルが一致しないことがあります。

    回避策:なし。

  • ルーティングとMPLSアコーディオン(監視機能>健全性>デバイスのトラブルシューティング> Device-Name >概要 タブ)のトラフィック損失リンクには、データ処理が遅いためにアラートの発生に遅延がある場合、アラートはゼロと表示されます。これにより、アクティブアラートカウントが不正確になる可能性があります。

    問題は、データが処理されると解決されます。データが処理されると、ゼロ以外のアクティブなアラートカウントが再び表示されます。

    回避策:なし

  • トラフィックが継続していても、トラフィック損失ページ(可観測性>健全性>デバイスのトラブルシューティング > Device-Name >の概要>ルーティングとMPLS アコーディオン>トラフィック 損失アラート リンクをクリック)に重複したブラックホールアラートが表示される場合があります。この問題は、リリース2.5.0からリリース2.6.0またはリリース2.7.0にアップグレードした場合にのみ発生します。リリース2.7.0を新規インストールした場合、この問題は発生しません。

    回避策: リリース 2.7.0 にアップグレードした場合は、 curl -X DELETE "http://$(kubectl get svc -n common opensearch-cluster-master -ojsonpath='{.spec.clusterIP}'):9200/blackhole_detection コマンドを実行してブラックホール インデックスを削除します。

    注:アップグレード前に処理されたデータがすべて失われる可能性があります。

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

    回避策:なし。

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

    回避策:なし

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

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

  • IGPプレフィックスタブ(ルーティング>ルートトポロジー>監視機能)のデバイスカウント列に不正確なデータが表示される場合があります。新しいデバイスがプレフィックスの発信を開始したとき、またはデバイスがプレフィックスの発信を停止したときに、デバイスカウントが更新されるまでに約30分かかります。

    回避策。デバイスカウントには最近の変更がすぐには反映されない場合があり、最大30分間は不正確になる場合があります。最新のデバイス数を取得するまで、約30分待つことをお勧めします。

  • 応答が遅れると、LLMコネクターのチャットウィンドウが予期せず自動的に上下にスクロールします。

    回避策:なし。

  • デバイスのオンボーディング後、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を使用してデバイスにログインすることで、新しい設定がデバイスに適用されているかどうかを確認できます。

  • デバイスのトラブルシューティングページと正常性ダッシュボードページ(監視可能性>正常性)にリストされている不健全なデバイスの数が一致しません。

    回避策:なし。

  • Routing Director GUIから不要なノードやリンクを削除することはできません。

    回避策: 以下の REST API を使用して、ノードとリンクを削除します。

    • リンクを削除するには、次の REST API を使用します。

      [削除] https://{{server_ip}}/topology/api/v1/orgs/{{org_id}}/{{topo_id}}/links/{{link_id}}

      注:

      ここで説明する手順に従って、実際のURLを取得できます。

      例えば、

      • URL: 'https://10.56.3.16/topology/api/v1/orgs/f9e9235b-37f1-43e7-9153-e88350ed1e15/10/links/15'

      • カール:

    • ノードを削除するREST API:

      [削除] https:// {{Server_IP}}/topology/api/v1/orgs/{{Org_ID}}/{{Topo_ID}}/nodes/{{Node_ID}}

      注:

      ここで説明する手順に従って、実際のURLを取得できます。

      例えば、

      • URL: 'https://10.56.3.16/topology/api/v1/orgs/f9e9235b-37f1-43e7-9153-e88350ed1e15/10/nodes/1'

      • カール:

      以下の手順を使用して、リンクまたはノードを削除するためにCURLで使用する実際のURLを取得します。

      1. トポロジーページ(可観測性>トポロジー)に移動します。

      2. キーボードの CTRL + Shift + I ボタンを使用して、ブラウザーで開発者ツールを開きます。

      3. 開発者ツールで、[ ネットワーク ] を選択し、[ XHR ] フィルター オプションを選択します。

      4. リンクインデックス番号またはノード番号を特定します。ノード番号に対するリンクインデックス番号を識別するには:

        1. Routing Director GUIのトポロジーページで、削除するリンクまたはノードをダブルクリックします。

          リンク Link-Name ページまたはノード Node-Name ページが表示されます。

        2. 詳細タブに移動し、表示されたリンクインデックス番号またはノード番号をメモします。

      5. 開発者ツールで、削除するリンクまたはノードに関連するリンクインデックス番号またはノード番号に基づいて行を選択し、クリックします。

      6. CURL内のリンクまたはノードを削除するために使用するURLをコピーします。

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

    回避策:なし。

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

    モジュール

    Rx 信号損失 KPI

    Tx 信号損失 KPI

    レーザー無効KPI

    SFP光インターフェイス

    いいえ

    いいえ

    いいえ

    CFP 光インターフェイス

    はい

    いいえ

    いいえ

    CFP_LH_ACO光インターフェイス

    はい

    いいえ

    いいえ

    QSFP光インターフェイス

    はい

    はい

    はい

    CXPオプティクス

    はい

    はい

    いいえ

    XFPオプティクス

    いいえ

    いいえ

    いいえ

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

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

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

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

  • MX104およびACX2200デバイスは、gNMIルールをサポートしていません。そのため、パッシブアシュアランスタブ(オーケストレーション>インスタンスのサービスインスタンス名ハイパーリンク>サービスインスタンス名の詳細)には、これらのデバイスの物理インターフェイスと論理インターフェイスのアコーディオンは表示されません。

    回避策:なし。

  • リリース2.6.0以前で作成されたサービスデザインを使用する場合は、サービスデザインを最新バージョンにアップグレードすることをお勧めします。

    以前は古いサービスデザイン用にGUIにハードコーディングされていたサービス設定が、サービスデザイン定義に基づいて自動的に生成されるようになりました。古いサービス設計を引き続き使用する場合は、必ずGUIを使用してIPv4ループバックアドレスを手動で入力してください。

  • 以前にドライランモードで実行されたサービスインスタンスを削除(プロビジョニング解除)しようとすると、システムが誤ってドライランモードで削除アクションを実行します。その結果、サービスインスタンスは削除されず、そのステータスは変更されません。

    回避策: 次のいずれかを実行します。

    • インスタンスで プロビジョニング を実行して、その状態をリセットします。プロビジョニングが完了したら、 プロビジョニング解除を実行します。

    • DELETE /service-orchestration/api/v1/orgs/{orgId}/order/customers/{custId}/instances/{instId} REST API を使用して、Dry-Run 動作をバイパスします。

  • すべてのデバイスが、L3VPNアコーディオンのパッシブアシュアランスタブ(Service-Instance-Nameの詳細>ハイパーリンク> service-instance-name オーケストレーション>インスタンス)に表示されているわけではありません。

    回避策: この問題は主にアップグレード中に発生します。問題を解決するには、すべてのポッド iTSDB 同時に再起動してください。

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

    回避策:なし。

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

    回避策:なし。

  • ネットワーク実装計画の追加>ページのデバイスの追加または編集セクションの 説明 列にインターフェイスの説明>>+)がありません。

    サブユニットの説明は、メインインターフェイスの説明と同じになることに注意してください。サブユニットet-0/0/9.100およびet-0/0/9.200の説明が欠落している場合は、メインインターフェイスの説明et-0/0/9を参照してください。

    回避策:なし。

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

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

  • パッシブアシュアランスタブ(オーケストレーション>インスタンス> Service-Order-Name 詳細)の以下のアコーディオンに、データが正しく表示されないか、まったく表示されません。

    • BGPアコーディオン—VPN状態列には、IPv4またはIPv6ネイバーを持つカスタマーエッジ(CE)またはプロバイダーエッジ(PE)デバイスの誤ったデータが表示されます。

    • OSPFアコーディオン—IPv6ネイバーを持つCEまたはPEデバイスのネイバーアドレス列にIPv6エントリーはありません。

    • L3VPNアコーディオン—VPN状態列には、OSPFおよびBGPプロトコルの誤ったデータが表示されます。静的IPv4またはIPv6アドレスを持つCEまたはPEデバイスでは、ネイバーセッションとVPN状態列は空白です。

    この問題は、L3VPNサービスでのみ発生します。

    回避策:なし。

  • MX 240デバイスの場合、OSPF関連データはパッシブアシュアランスタブ (オーケストレーション>インスタンス> Service-Order-Name 詳細)に入力されません。

    回避策:カスタマーエッジ(CE)デバイスでOSPFを設定します。

  • Service-Instance-Nameの詳細ページ(オーケストレーション>インスタンス> Service-Instance-Name)の更新アイコンをクリックすると、関連イベントセクションに最新のイベントが表示されない場合があります。

    回避策: 最新のイベントを表示するには、更新アイコンを使用する代わりに、[サービスインスタンス]ページ(オーケストレーション>インスタンス)に移動し、最新のイベントを表示する必要があるサービスインスタンスを選択します。

  • L3VPN-Nameの詳細ページ(オーケストレーション>インスタンス> Service-Instance-Nameハイパーリンク)の注文履歴タブには、サービスインスタンスのプロビジョニングを解除し、後でプロビジョニング解除されたサービスと同じ詳細を使用してサービスをプロビジョニングした場合のすべての注文履歴が一覧表示されます。

    回避策:なし。

  • 拡張されたセットアップでは、サービスインスタンスを一括でアップグレードすることはできません。

    回避策:一度にアップグレードするのは、いくつかのサービスインスタンス(4つ以下)のみです。

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

  • プラグインインベントリページ (インベントリ>アクティブアシュアランス)に無効なプラグインをアップロードした場合、UIに明確なエラーメッセージは表示されず、0%のままになります。

    回避策:有効な .nap ファイルをアップロードします。

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

    回避策:なし。

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

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

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

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

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

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

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

  • 同じサーバーエージェントインターフェイス上で、一度に実行できるパス最大送信単位(パスMTU)サーバーとクライアント測定ペアは1つだけです。複数のパスMTUサーバー測定が同じエージェントインターフェイスで開始されると、最初のサーバーのみが正常に起動します。後続のサーバーは、次のメッセージを含むエラーレポートを生成します: Failed to create test socket: Address already in use。

    現在、テスト実行用のタスクを作成する場合、GUIではパスMTUプラグイン用に1つのサーバーエージェントと複数のクライアントエージェントを選択できるため、この問題が発生する可能性があります。

    回避策:なし。

  • テストエージェントがインストールされている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を使用している場合にのみ発生します。

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

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

    回避策:なし。

ネットワークの最適化

  • コンテナLSP機能は、リリース2.8.0ではサポートされていません。組織設定ページ(設定メニュー>システム設定)のコンテナLSP正規化チェックボックスと、APIリファレンスガイドのコンテナLSP関連REST APIは機能しません。

    回避策:なし。

  • Routing Directorのパス計算エンジン(PCE)は、遅延ベースのトンネルや最大遅延制約のあるトンネルのパスを計算するために、インターフェイス遅延 タイプ フィールド(設定メニュー>システム設定>組織設定>ネットワーク最適化設定)でユーザーが選択した遅延タイプを使用しません。代わりに、PCEは常に平均遅延値を使用します。

    回避策:なし。

  • Cisco IOS XR上のPath Computation Element Protocol(PCEP)セグメントルーティング(SR)LSPの一括削除はサポートされていません。

    回避策:LSP を個別に削除します。

  • ラベルスイッチパス(LSP)のトラフィックが0に低下すると、zero-suppressionデフォルトで有効になっているため、テレメトリJunos OS0値は報告されません。これにより、帯域幅のサイズ設定やしきい値を超えた際のLSP再ルーティングなどの機能に予期しない結果が生じる可能性があります。Routing Directorのパス計算エンジンは、LSPの再ルーティングを必要とするイベントの間、LSPの最後の既知のトラフィック値を引き続き使用します。

    回避策:set services analytics zero-suppression no-zero-suppressionコマンドを使用して、ルーターのzero-suppressionを無効にします。

  • イベントページにリストされているイベント Oネットワーク>トポロジー>>サービス可能性 トンネルタブ>トンネル名>>イベント履歴の表示) には、SRおよびSRv6 LSPのルート情報は含まれていません。 この問題により、SRおよびSRv6 LSPではパス 変更の表示 オプションが機能しない場合があります。

    回避策:なし。

  • 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サーバーはエラーを返しません。

    回避策:なし。

  • イベント履歴テーブル(ネットワーク>トポロジー>可観測性 > トンネルタブ> Tunnel-Name >イベント履歴>表示)のすべての列がイベント履歴に適用できるわけではありません。そのため、空白の列が表示される場合があります。

    回避策:なし。

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

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

  • MPLS LSPパス上に存在するルーターが、そのIGPドメインでオーバーロード(OL)ビットを上げると、トンネルがそのルーターから再ルーティングされないことがあります。

    回避策: overload ビットのノードで大きな遅延を手動で指定します。

  • Kafkaメッセージサイズに制限があるため、一度に削除できるLSPは200個までです。

    回避策:なし。

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

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

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

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

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

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

ネットワークプランナー

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

    回避策:なし。

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

    回避策:なし。

  • ルーティング方法がに設定されている場合、プランナーはTEメトリックを誤って使用してSRトンネルパスを計算します routebydevice。

    回避策:トンネルのルーティング方法をISISまたはOSPFに変更することで、Routing DirectorがIGPメトリックに基づいてトンネルパスを計算できるようにすることができます。

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

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

  • SR-LSP 関連のモデリングでは、[ ライブからインポート] オプションを使用してネットワーク モデルを作成する必要があります。現在、 Configからインポートを使用して 作成されたネットワークモデルには、完全なSR関連情報が含まれていません。

    回避策:SRネットワークでは、設定からインポートではなくライブからインポートを使用します。

  • オフラインモデルでは、インターフェイスのないリンクがある場合、包括的な障害シミュレーションが失敗し、レポートが生成されない可能性があります。

    回避策:なし。

  • Routing Director GUI からログアウトし、ブラウザーの同じタブまたはウィンドウを使用して再ログインすると、オフライン モデルの計画またはシミュレーション通知サービスに再接続できない場合があります。

    回避策:再ログインする前にブラウザを更新してください。

  • トンネルに設定された管理グループ制約は、what-if障害シミュレーション中は考慮されません。

    回避策:なし。

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

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

    回避策:なし。

信頼

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

管理

  • スケールデプロイの場合、システムがリソースに負荷がかかっているときに、 papi-mon サービスポッドが再起動することに気付くことがあります。これは自己修復回復の一環として行われ、サービスが復元されます。

    回避策:なし。

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

    回避策:なし。

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

  • 複数のネットワークインターフェイスカード(NIC)で構成されたRouting Directorをアップグレードまたは再展開する際に、以下のエラーが発生することがあります。

    この問題は、 /root/epic/host.ip ファイルにVM内の他のNICが使用するIPアドレスが入力されているか、空であるために発生します。

    回避策:Routing Directorをアップグレードまたは再デプロイする前に、 /root/epic/host.ip を確認し、適切なIPアドレスを再入力してください。

    また、オプションで /root/epic/host.ip ファイルを不変にして、 chattr +i /root/epic/host.ip を使用して上書きを防ぐこともできます。

  • 場合によっては、クラスターノードのデプロイメントシェルへのログインに時間がかかることがあります(約10分)。ログインする前に次のメッセージが表示されます。

    回避策:rm -rf /root/tempコマンドを使用して、/root/tempフォルダーを手動で削除します。これにより、start.sh スクリプトは強制的に初期化を再実行します。

  • 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 ポッドが再起動されることがあります。これは、クラスターの機能には影響しません。

    回避策:なし。