解決済みの問題
このセクションでは、Juniper Routing Directorリリース2.9.0で解決された問題の一覧を示します。
-
マルチノード設定では、ノードに障害が発生した後にバックアップを実行すると、バックアップ操作が失敗することがあります。
-
ネットワーク実装計画の追加>ページのデバイスの追加または編集セクションの 説明 列にインターフェイスの説明>>+)がありません。
サブユニットの説明は、メインインターフェイスの説明と同じになることに注意してください。サブユニットet-0/0/9.100およびet-0/0/9.200の説明が欠落している場合は、メインインターフェイスの説明et-0/0/9を参照してください。
-
すべてのデバイスが、L3VPNアコーディオンのパッシブアシュアランスタブ(Service-Instance-Nameの詳細>ハイパーリンク> service-instance-name オーケストレーション>インスタンス)に表示されているわけではありません。
- イベント履歴テーブル(ネットワーク>トポロジー>可観測性 > トンネルタブ> Tunnel-Name >イベント履歴>表示)のすべての列がイベント履歴に適用できるわけではありません。そのため、空白の列が表示される場合があります。
-
イベントページにリストされているイベント Oネットワーク>トポロジー>>サービス可能性 トンネルタブ>トンネル名>>イベント履歴の表示) には、SRおよびSRv6 LSPのルート情報は含まれていません。 この問題により、SRおよびSRv6 LSPではパス 変更の表示 オプションが機能しない場合があります。
-
Cisco IOS XR上のPath Computation Element Protocol(PCEP)セグメントルーティング(SR)LSPの一括削除はサポートされていません。
-
Routing Director GUIから不要なノードやリンクを削除することはできません。
-
Routing Director GUI からログアウトし、ブラウザーの同じタブまたはウィンドウを使用して再ログインすると、オフライン モデルの計画またはシミュレーション通知サービスに再接続できない場合があります。
-
トラフィック損失ページ(可観測性>健全性>デバイスのトラブルシューティング>デバイス名>の概要>ルーティングおよびMPLSアコーディオン>トラフィック損失アラートリンク)の入力、出力、ドロップ率グラフのY軸スケーリングが一貫していないと、トラフィックレートの誤解を招く表現が発生します。
-
トラフィックが継続していても、トラフィック損失ページ(可観測性>健全性>デバイスのトラブルシューティング > Device-Name >の概要>ルーティングとMPLS アコーディオン>トラフィック 損失アラート リンクをクリック)に重複したブラックホールアラートが表示される場合があります。この問題は、リリース2.5.0からリリース2.6.0またはリリース2.7.0にアップグレードした場合にのみ発生します。以下の場合、この問題は発生しません。
-
リリース2.7.0を新規インストールします。
-
リリース2.6.0またはリリース2.70からリリース2.8.0にアップグレードします。ファブリックドロップが有効になっていないことを確認します。
.
-
-
L1とL2の両方が同時に有効になっている場合、IGPプレフィックスタブ(可観測性>ルーティング>ルートトポロジー)には、両方のレベルのプレフィックスが表示されません。代わりに、L1プレフィックスのみが表示されます。デュアルレベル(L1 + L2)プレフィックスのサポートはサポートされていません。
-
以前にドライランモードで実行されたサービスインスタンスを削除(プロビジョニング解除)しようとすると、システムが誤ってドライランモードで削除アクションを実行します。その結果、サービスインスタンスは削除されず、そのステータスは変更されません。
-
自動更新にもかかわらず、リストされたアラートとグラフに表示されたデータは、 Device-Name ページの出力トラフィックの詳細ページ(監視機能>健全性>デバイスのトラブルシューティング> Device-Name >インターフェイス>の概要(アコーディオン)>出力トラフィック)で同期されない場合があります。
-
バックアップを復元した後、隣接関係タブ(ルートエクスプローラ>ルートエクスプローラの監視機能>)に、BGPピアの誤った状態が表示される場合があります。
-
拡張されたセットアップでは、サービスインスタンスを一括でアップグレードすることはできません。
-
L3VPN-Nameの詳細ページ(オーケストレーション>インスタンス> Service-Instance-Nameハイパーリンク)の注文履歴タブには、サービスインスタンスのプロビジョニングを解除し、後でプロビジョニング解除されたサービスと同じ詳細を使用してサービスをプロビジョニングした場合のすべての注文履歴が一覧表示されます。
-
パッシブアシュアランスタブ(オーケストレーション>インスタンス> Service-Order-Name 詳細)の以下のアコーディオンに、データが正しく表示されないか、まったく表示されません。
-
BGPアコーディオン—VPN状態列には、IPv4またはIPv6ネイバーを持つカスタマーエッジ(CE)またはプロバイダーエッジ(PE)デバイスの誤ったデータが表示されます。
-
OSPFアコーディオン—IPv6ネイバーを持つCEまたはPEデバイスのネイバーアドレス列にIPv6エントリーはありません。
-
L3VPNアコーディオン—VPN状態列には、OSPFおよびBGPプロトコルの誤ったデータが表示されます。静的IPv4またはIPv6アドレスを持つCEまたはPEデバイスでは、ネイバーセッションとVPN状態列は空白です。
この問題は、L3VPNサービスでのみ発生します。
-
-
Kafkaメッセージサイズに制限があるため、一度に削除できるLSPは200個までです。
-
ラベルスイッチパス(LSP)のトラフィックが0に低下すると、
zero-suppressionデフォルトで有効になっているため、テレメトリJunos OS0値は報告されません。これにより、帯域幅のサイズ設定やしきい値を超えた際のLSP再ルーティングなどの機能に予期しない結果が生じる可能性があります。Routing Directorのパス計算エンジンは、LSPの再ルーティングを必要とするイベントの間、LSPの最後の既知のトラフィック値を引き続き使用します。 -
Routing Directorのパス計算エンジン(PCE)は、遅延ベースのトンネルや最大遅延制約のあるトンネルのパスを計算するために、インターフェイス遅延 タイプ フィールド(設定メニュー>システム設定>組織設定>ネットワーク最適化設定)でユーザーが選択した遅延タイプを使用しません。代わりに、PCEは常に平均遅延値を使用します。
-
コンテナLSP機能は、リリース2.8.0ではサポートされていません。組織設定ページ(設定メニュー>システム設定)のコンテナLSP正規化チェックボックスと、APIリファレンスガイドのコンテナLSP関連REST APIは機能しません。
-
トンネルに設定された管理グループ制約は、what-if障害シミュレーション中は考慮されません。
-
オフラインモデルでは、インターフェイスのないリンクがある場合、包括的な障害シミュレーションが失敗し、レポートが生成されない可能性があります。
-
SR-LSP 関連のモデリングでは、[ ライブからインポート] オプションを使用してネットワーク モデルを作成する必要があります。現在、 Configからインポートを使用して 作成されたネットワークモデルには、完全なSR関連情報が含まれていません。
-
ルーティング方法がに設定されている場合、プランナーはTEメトリックを誤って使用してSRトンネルパスを計算します routebydevice。
-
同じサーバーエージェントインターフェイス上で、一度に実行できるパス最大送信単位(パスMTU)サーバーとクライアント測定ペアは1つだけです。複数のパスMTUサーバー測定が同じエージェントインターフェイスで開始されると、最初のサーバーのみが正常に起動します。後続のサーバーは、次のメッセージを含むエラーレポートを生成します:
Failed to create test socket: Address already in use。現在、テスト実行用のタスクを作成する場合、GUIではパスMTUプラグイン用に1つのサーバーエージェントと複数のクライアントエージェントを選択できるため、この問題が発生する可能性があります。
-
プラグインインベントリページ (インベントリ>アクティブアシュアランス)に無効なプラグインをアップロードした場合、UIに明確なエラーメッセージは表示されず、0%のままになります。
-
デバイスのトラブルシューティングページと正常性ダッシュボードページ(監視可能性>正常性)にリストされている不健全なデバイスの数が一致しません。
-
場合によっては、クラスターノードのデプロイメントシェルへのログインに時間がかかることがあります(約10分)。ログインする前に次のメッセージが表示されます。
Awaiting configuration synchronization from the primary node ...
-
複数のネットワークインターフェイスカード(NIC)で構成されたRouting Directorをアップグレードまたは再展開する際に、以下のエラーが発生することがあります。
Current host IP: 10.123.42.1 Master Node 1 IP: 192.168.69.5 error: This host is not master node 1, where this Deployment cluster was initially installed from! Please run upgrade from master node 1: 192.168.69.5
この問題は、 /root/epic/host.ip ファイルにVM内の他のNICが使用するIPアドレスが入力されているか、空であるために発生します。
-
スケールデプロイの場合、システムがリソースに負荷がかかっているときに、 papi-mon サービスポッドが再起動することに気付くことがあります。これは自己修復回復の一環として行われ、サービスが復元されます。
-
応答が遅れると、LLMコネクターのチャットウィンドウが予期せず自動的に上下にスクロールします。
-
IGPプレフィックスタブ(ルーティング>ルートトポロジー>監視機能)のデバイスカウント列に不正確なデータが表示される場合があります。新しいデバイスがプレフィックスの発信を開始したとき、またはデバイスがプレフィックスの発信を停止したときに、デバイスカウントが更新されるまでに約30分かかります。
-
ルーティングとMPLSアコーディオン(監視機能>健全性>デバイスのトラブルシューティング> 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コマンドを使用して、証明書の検証を再度有効にします。
curl -X PUT -H "Content-Type: application/json" \ -u test@test.com:Test-Password \ "https://VIP-1/api/v1/orgs/{org-id}/gnmi/options" \ --data '{"device": {"client-certificate-request": "require-certificate-and-verify"}}' --insecure -
宛先の追加ページ(管理>エクスポートマネージャー>宛先の管理)でTLS暗号化の使用トグルボタンを有効にすると、SASLユーザー名フィールドとパスワードフィールドが予期せずクリアされます。
-
ドキュメント モードが設定されていても、LLM コネクタのチャット ウィンドウを開くと、会話モードが誤ってアクティブになります。
-
特定の条件下では、一時的なトラフィック損失により、パケットドロップ(メジャー)アラートがブラックホール(重大)アラートとして誤って分類されることがあります。開始時刻と終了時刻が同一であることを確認することで、このようなアラートを識別できます。