VMware SASE 5.0.1 | 2022 年 11 月 22 日更新 |

  • VMware SASE™ Orchestrator バージョン R5011-20221117-GA

  • VMware SD-WAN™ Gateway バージョン R5011-20221007-GA

  • VMware SD-WAN™ Edge バージョン R5012-20221107-GA

  • Orchestrator バージョン R5011-20221117-GA を使用する VMware Cloud Web Security™

  • Orchestrator バージョン R5011-20221117-GA を使用する VMware Secure Access™

  • Orchestrator バージョン R5011-20221117-GA を使用する VMware Edge Network Intelligence™

各リリース ノートで、追加および更新された機能をご確認ください。

リリース ノートの概要

このリリース ノートには、次のトピックが含まれています。

対象ユーザー

本リリースは、リリース 5.0.0 で初めて提供された機能を必要とするすべてのカスタマーおよびリリース 5.0.0 以降に解決された以下の問題の影響を受けるカスタマーに推奨されます。

互換性

リリース 5.0.1 の Orchestrator、Gateway、およびハブ Edge では、VMware SD-WAN Edge の以前のバージョンのうちリリース 3.2.2 以降がすべてサポートされます。 

注:

リリース 5.0.1 はメンテナンス リリースとして分類され、メンテナンス リリースには相互運用性テストのサブセットが適用されます。これは、プロトコルがそれらのメンテナンス リリースが属するメジャー/マイナー リリースと同じであるためです。このバージョンのプロトコルがテストされている他のソフトウェア バージョンのリストについては、VMware SASE 5.0.0 リリース ノートを参照してください。

次の相互運用性の組み合わせは、明示的にテストされています。

Orchestrator

Gateway

Edge

ハブ

ブランチ/スポーク

5.0.1

5.0.1

4.3.1

4.3.1

5.0.1

5.0.1

4.5.0

4.5.0

5.0.1

5.0.1

5.0.0

5.0.0

5.0.1

4.3.1

4.3.1

4.3.1

5.0.1

4.5.0

4.5.0

4.5.0

5.0.1

5.0.0

5.0.0

5.0.0

5.0.0

5.0.1

5.0.1

5.0.1

注:

上記の表は、SD-WAN サービスを使用しているカスタマーに対してのみ完全に有効です。VMware Cloud Web Security または VMware Secure Access へのアクセスが必要なカスタマーは、Edge をリリース 4.5.0 以降にアップグレードする必要があります。

注意:

すべてのコンポーネントの VMware SD-WAN リリース 3.2.x と 3.3.x、および Orchestrator と Gateway のリリース 3.4.x のサポートが終了しました。

  • リリース 3.2.x および 3.3.x は、2021 年 12 月 15 日にジェネラル サポートが終了 (EOGS) し、2022 年 3 月 15 日にテクニカル ガイダンスが終了 (EOTG) しました。

  • Orchestrator および Gateway のリリース 3.4.x は、2022 年 3 月 30 日にジェネラル サポートの終了 (EOGS) となりました。2022 年 9 月 30 日にはテクニカル ガイダンスの終了 (EOTG) となります。

  • 注:これは、Orchestrator および Gateway のみが対象です。Edge のリリース 3.4.x は、2022 年 12 月 31 日からサポート終了への移行期間に入ります。

  • 詳細については、ナレッジベースの記事を参照してください。お知らせ:VMware SD-WAN リリース 3.x のサポート期間の終了 (84151)

重要:

VMware SD-WAN リリース 4.0.x および 4.2.x はサポート終了に近づいています。

  • リリース 4.0.x は、2022 年 9 月 30 日にジェネラル サポートの終了 (EOGS) となり、2022 年 12 月 31 日にテクニカル ガイダンスの終了 (EOTG) を迎えます。 

  • リリース 4.2.x の Orchestrator および Gateway は、2022 年 12 月 30 日にジェネラル サポートの終了 (EOGS) となり、2023 年 3 月 30 日にテクニカル ガイダンスの終了 (EOTG) を迎えます。

  • リリース 4.2.x の Edge は、2023 年 6 月 30 日にジェネラル サポートの終了 (EOGS) となり、2023 年 9 月 30 日にテクニカル ガイダンスの終了 (EOTG) を迎えます。

  • 詳細については、ナレッジベースの記事を参照してください。お知らせ:VMware SD-WAN リリース 4.x のサポート期間の終了 (88319)

注:

リリース 3.x では、AES-256-GCM が適切にサポートされていませんでした。これは、AES-256 を使用しているカスタマーは、GCM が無効な状態 (AES-256-CBC) で Edge を常に使用していたことを意味していました。カスタマーが AES-256 を使用している場合は、Edge を 4.x リリースにアップグレードする前に、Orchestrator から GCM を明示的に無効にする必要があります。すべての Edge で 4.x リリースが実行されている状態になったら、カスタマーは AES-256-GCM または AES-256-CBC を選択できます。

Orchestrator、Gateway、Edge のアップグレード パス

Orchestrator、Gateway、または Edge を旧リリースからリリース 5.0.1 にアップグレードする場合のパスを次に示します。

Orchestrator

リリース 4.0.0 以降での Orchestrator のインフラストラクチャの変更により、3.x リリースを使用する Orchestrator は、5.0.1 にアップグレードする前にまず 4.0.0 にアップグレードする必要があります。リリース 4.0.0 以降を使用している Orchestrator は、リリース 5.0.1 にアップグレードできます。それぞれの Orchestrator のアップグレード パスは次のとおりです。

リリース 3.x を使用する Orchestrator → 4.0.0 → 5.0.1。

リリース 4.x を使用する Orchestrator → 5.0.1。

Gateway

Gateway の 3.x から 5.0.1 へのアップグレードはサポートされていません。アップグレードする代わりに、3.x Gateway を同じ仮想マシン属性を使用して新規に展開する必要があります。その後、古いインスタンスは廃止されます。

リリース 4.0.0 以降を使用した Gateway のアップグレードは、すべての Gateway タイプで完全にサポートされています。

注:5.0.1 を使用して新しい Gateway を展開する場合、VMware ESXi インスタンスがバージョン 6.7 Update 3 以降、バージョン 7.0 以前である必要があります。これより前の ESXi インスタンスを使用すると、リリース 5.0.0 以降の実行時に Gateway のデータプレーン サービスが失敗します。

注:Gateway を 5.0.1 にアップグレードする前に、ESXi インスタンスをバージョン 6.7 Update 3 以降、バージョン 7.0 以前にアップグレードする必要があります。これより前の ESXi インスタンスを使用すると、リリース 5.0.1 以降の実行時に Gateway のデータプレーン サービスが失敗します。

Edge

Edge は、任意のリリース 3.x 以降からリリース 5.0.1 に直接アップグレードできます。

重要な注意事項

高可用性での Wi-Fi 対応 Edge と Wi-Fi 非対応 Edge の混在はサポートされません 

2021 年から、VMware SD-WAN に Wi-Fi モジュールを含まない Edge モデル(Edge モデル 510N、610N、620N、640N、および 680N)が導入されました。これらのモデルは、Wi-Fi を除いては、Wi-Fi 対応の対応するモデルと同じように見えますが、同じモデルの Wi-Fi 対応の Edge と Wi-Fi 非対応の Edge(たとえば、Edge 640 と Edge 640N)の高可用性ペアとしての展開はサポートされていません。高可用性ペアとして展開される Edge は、必ず、両方とも Wi-Fi 対応または両方とも Wi-Fi 非対応のタイプにする必要があります。

Orchestrator で Grafana を使用できなくなりました

ライセンスの制限により、リリース 5.0.0 以降の Orchestrator には Grafana アプリケーションが含まれていません。Grafana は主に、Orchestrator をオンプレミスで実行しているカスタマーおよびパートナーによって、Orchestrator のパフォーマンスを監視するために使用されます。このようなニーズに対応するため、カスタマーまたはパートナーは Orchestrator の外部で独自の Grafana アプリケーションをホストし、それを参照するように Orchestrator で Telegraf を設定する必要があります。

VMware SASE ビルドに 4 桁目が含まれています

リリース 5.0.0 以降、リリース ビルドには 4 桁目の数字が含まれるようになりました。

ソフトウェア リリースの場合、VMware SASE は、次のような「a.b.c」の番号付けスキームに従います。

  • a = メジャー(例:5.0.0)→ 複数の大きな機能があり、アーキテクチャが大幅に変更される可能性があるリリース。

  • b = マイナー(例:5.2.0)→ 少数の小さな機能またはいくつかの大きな機能があり、アーキテクチャに大きな変更がないリリース。

  • c = メンテナンス(例:5.2.1)→ 現場で見つかった問題と内部で見つかった問題の修正が多数含まれている可能性のあるリリース。新しいハードウェア プラットフォームに対応している可能性を除き、機能はありません。

リリース 5.0.0 では、Edge、Gateway、Orchestrator のビルドに次の 4 桁目が追加され、番号付けは「a.b.c.d」の形式になりますます。

  • d = ロールアップ ビルド(例:5.2.1.1)→ ロールアップは、カスタマーによって検出された既知の不具合の修正、または内部で検出された重大な欠陥の累積を集計したものです。

4.x 以前のロールアップ ビルドは、イメージ名の GA 日で区別されます。これは、ビルド バージョンをカスタマーに伝える方法として最適ではありません。5.0.0 ビルド以降で 4 桁目の数字を追加することにより、特定のコンポーネントで使用されているソフトウェア バージョンがより明確になります。

このビルド番号付けの規則は、リリース 5.0.0 以降にのみ適用され、4.x 以前のリリースでは引き続き既存の方法で日付により識別できるロールアップ ビルドと 3 桁の数字が使用されます。

Cloud Web Security と Secure Access へのアクセス

VMware Cloud Web Security または VMware Secure Access にアクセスする場合は、Edge をリリース 4.5.0 以降にアップグレードする必要があります。4.5.0 より前のリリースを使用している Edge では、これらのサービスにアクセスできません。

AS-PATH プリペンドの BGPv4 フィルタ設定の区切り文字の変更

リリース 3.x 以降では、AS-PATH プリペンドの VMware SD-WAN BGPv4 フィルタ設定で、カンマ ベースとスペース ベースの両方の区切り文字が使用できました。ただし、リリース 4.0.0 以降では、VMware SD-WAN では、AS-PATH プリペンド設定でスペース ベースの区切り文字のみがサポートされます。3.x から 4.x または 5.x にアップグレードする場合は、誤った BGP の最適ルート選択を回避するために、アップグレード前に AS-PATH プリペンド設定を編集して「カンマをスペースで置き換える」必要があります。

Edge 3x00 モデルのアップグレード時間の延長

Edge 3x00 モデル(3400、3800 および 3810 など)では、このバージョンへのアップグレードに通常よりも時間がかかる場合があります(3 ~ 5 分)。これは、問題 53676 を解決するファームウェアのアップグレードが原因で発生します。リリース 3.4.5/3.4.6、4.0.2、4.2.1、4.3.0、4.5.0、または 5.0.0 で Edge 3400 または 3800 がそのファームウェアをアップグレードしていた場合は、Edge は想定時間内でアップグレードされます。詳細については、各リリース ノートの「解決した問題 53676」を参照してください。

Edge および Gateway 上の BGP over IPsec、および Azure Virtual WAN の自動化の制限事項

Edge および Gateway 上の BGP over IPsec 機能は、Edge または Gateway からの Azure Virtual WAN の自動化と互換性がありません。Edge または Gateway から Azure vWAN への接続を自動化するときには、スタティック ルートのみがサポートされます。

VMware SD-WAN Edge モデル 520、540、620、640、680、3400、3800、および 3810 で自動ネゴシエーションを無効にする場合の制限事項

ユーザーが、VMware SD-WAN Edge モデル 620、640 または 680 のポート GE1 〜 GE4 で、または Edge 3400、3800 または 3810 のポート GE3 または GE4 で、あるいは銅線インターフェイスを備えた SFP がポート SFP1 または SFP2 で使用されている場合は Edge 520/540 で、速度とデュプレックスをハードコーディングするために自動ネゴシエーションを無効にすると、再起動してもリンクが起動しない場合があります。

これは、Intel Ethernet Controller i350 を使用するリストされた各 Edge モデルが原因で発生します。これらのモデルには、自動ネゴシエーションがリンクの両側で使用されない場合、送受信する適切なケーブルを動的に検出 (Auto MDIX) することができないという制限があります。接続の両側で送受信に同じケーブルが使用されている場合、リンクは検出されません。ピア側も自動ネゴシエーションなしの Auto MDIX をサポートせず、リンクがストレート ケーブルを使用して起動されていない場合は、リンクを起動するためにクロスオーバー イーサネット ケーブルが必要になります。

詳細については、ナレッジベースの記事「Limitation When Deactivating Autonegotiation on VMware SD-WAN Edge Models 520, 540, 620, 640, 680, 3400, 3800, and 3810 (87208)」を参照してください。

改訂履歴

2022 年 8 月 5 日。第 1 版。

2022 年 8 月 11 日。第 2 版。

  • Orchestrator で解決した問題セクションに、解決した問題 #89346#90067#90128#90540#91054#91720、および #92082 を追加しました。これらのチケットは、5.0.1 リリース ノートの第 1 版から誤って除外されました。

2022 年 8 月 15 日。第 3 版。

  • 「Edge/Gateway で解決した問題」セクションに解決した問題 #89217 を追加しました。このチケットは、5.0.1 リリース ノートの第 1 版から誤って除外されました。

2022 年 8 月 18 日。第 4 版。

  • 「Orchestrator で解決した問題」セクションに更新された Orchestrator ビルド R5010-20220817-GA を追加しました。ビルド R5010-20220817-GA は元の Orchestrator ビルド R5010-20220803-GA に代わるもので、リリース 5.0.1 の新しい Orchestrator GA ビルドです。

  • この更新された Orchestrator ビルドには、問題 #95613 の修正が含まれています。これは、「Orchestrator で解決した問題」セクションに追加されています。

2022 年 9 月 9 日。第 5 版。

  • 「Edge/Gateway で解決した問題」セクションに、解決した問題 #87552、#90151、および #93383 を追加しました。これらのチケットは、5.0.1 リリース ノートの第 1 版から誤って除外されました。

  • コードの欠陥ではなく設定エラーが原因であるとエンジニアリングが結論付けたため、未解決の問題 #49712 を「Edge/Gateway の既知の問題」から削除しました。

  • 「Edge/Gateway の既知の問題」から未解決の問題 #90065 を削除しました。エンジニアリング部門ではこの問題を再現できず、5.0.1 Orchestrator ビルドでは DR 同期が期待どおりに動作するためです。

2022 年 9 月 16 日。第 6 版。

  • 「Orchestrator で解決した問題」セクションに更新された Orchestrator ビルド R5010-20220912-GA を追加しました。ビルド R5010-20220912-GA は元の Orchestrator ビルド R5010-20220817-GA に代わるもので、リリース 5.0.1 の新しい Orchestrator GA ビルドです。

  • この更新された Orchestrator ビルドには、問題 #90749、#95847、および #96095 の修正が含まれています。これらは、「Orchestrator で解決した問題」セクションに追加されています。

  • 「Edge/Gateway で解決した問題」セクションに解決した問題 #91875 を追加しました。このチケットは、5.0.1 リリース ノートの第 1 版から誤って除外されました。

  • 「Edge/Gateway の既知の問題」セクションに問題 #96055 および #96231 を追加しました。

2022 年 9 月 23 日。第 7 版。

  • 「Orchestrator で解決した問題」セクションの Orchestrator ビルド R5010-20220912-GA に解決した問題 #96108 を追加しました。この問題は、これらのリリース ノートの第 6 版から誤って除外されました。

  • 解決した問題 #90749 を、「Orchestrator で解決した問題」セクションの Orchestrator ビルド R5010-20220912-GA から元の Orchestrator ビルド R5010-20220803-GA に移動しました。これは、この問題の修正がリリース 5.0.1 で実際に追加されたビルドです。

  • 「Edge/Gateway で解決した問題」セクションに解決した問題 #87982 を追加しました。このチケットは、5.0.1 リリース ノートの第 1 版から誤って除外されました。

  • 「Edge/Gateway の既知の問題」セクションに未解決の問題 #86098、#94204#95565#96441、および #96888 を追加しました。

2022 年 9 月 28 日。第 8 版。

  • 「Edge/Gateway の既知の問題」セクションに #98136 を追加しました。

2022 年 10 月 12 日。第 9 版。

  • 「Edge/Gateway で解決した問題」セクションに新しい Edge/Gateway ロールアップ ビルド R5011-20221007-GA を追加しました。これは 1 番目の Edge/Gateway ロールアップ ビルドで、リリース 5.0.1 の新しい Edge/Gateway GA ビルドです。

  • Edge/Gateway ビルド R5011-20221007-GA には、問題 #89235#94430#95503#96055#96231#98157、および #99188 に対する修正が含まれ、該当するセクションで説明しています。

2022 年 10 月 18 日。第 10 版。

  • 元の 5.0.1 GA ビルド R5010-20220729-GA の「Edge/Gateway で解決した問題」セクションに解決した問題 #90876 を追加しました。この問題は、5.0.1 リリース ノートの第 1 版から誤って除外されました。

2022 年 10 月 31 日。第 11 版。

  • 元の 5.0.1 GA ビルド R5010-20220729-GA の「Edge/Gateway で解決した問題」セクションに解決した問題 #72491 を追加しました。この問題は、5.0.1 リリース ノートの第 1 版から誤って除外されました。

2022 年 11 月 14 日。第 12 版。

  • 「Edge/Gateway で解決した問題」セクションに新しい Edge ロールアップ ビルド R5012-20221107-GA を追加しました。これは 2 番目の Edge ロールアップ ビルドで、リリース 5.0.1 の新しい Edge GA ビルドです。Edge リリース 5.0.x.x を実行しているすべてのカスタマーに推奨されます。

  • Edge ビルド R5012-20221107-GA には、問題 #96411#96441#96888#97483#98514#100377、および #101049 に対する修正が含まれ、該当するセクションで説明しています。

  • 重要:

    以前の Edge 5.0.x.x ビルドを使用している場合は、Edge を 5.0.1.2 にアップグレードする必要があります

2022 年 11 月 22 日第 13 版。

  • 「Orchestrator で解決した問題」セクションに新しい Orchestrator ロールアップ ビルド R5011-20221117-GA を追加しました。これは 1 番目の Orchestrator ロールアップ ビルドで、リリース 5.0.1 の新しい Orchestrator GA ビルドです。

  • Orchestrator ビルド R5011-20221117-GA には、問題 #80735#88957#97713#98086、#98357#98518#98654#99109#99247#99250#100656、および #101449 に対する修正が含まれ、該当するセクションで説明しています。

Edge および Gateway で解決した問題

Edge バージョン R5012-20221107-GA で解決した問題

Edge ビルド R5012-20221107-GA は 2022 年 11 月 14 日にリリースされた、リリース 5.0.1 の 2 番目の Edge ロールアップです。

この Edge ロールアップ ビルドは、1 番目の Edge ロールアップ ビルド R5011-20221007-GA 以降の以下の重大な問題に対処します。

重要:

本リリースは、5.0.x.x を実行しているすべてのカスタマーに推奨されます。以前の Edge 5.0.x.x ビルドを使用している場合は、Edge を 5.0.1.2 にアップグレードする必要があります。

  • 解決した問題 96411:VMware SD-WAN Edge でデータプレーン サービスの障害が発生し、その結果再起動が発生し、カスタマーのトラフィックが 10 ~ 15 秒間中断します。

    この問題は、リンク フラップ(WAN リンクがダウンして、その後急速に稼動状態に戻る)が頻繁に発生する Edge で発生する可能性があります。この問題は、メモリの破損によって「二重の空き」状態になり、Edge サービスに障害が発生することが原因です。

  • 解決した問題 96441:高可用性トポロジを使用しているサイトでは、HA フェイルオーバーが頻繁に発生することがあります。

    この問題は、Edge によって「ダウン」としてマークされた HA インターフェイスが 500 ~ 1000 ミリ秒以内に稼動状態に戻り、HA フェイルオーバーをトリガする場合に発生します。ただし、これらのインターフェイス ダウン イベントは偽りであり、DPDK が有効なインターフェイスがポーリングを使用し、500 ミリ秒の間隔でインターフェイスの状態を判断することが原因で発生します。この方法を使用すると、基盤となるデバイス ドライバが偽りのインターフェイス ダウン イベントを報告する場合があり、各イベントによって、インターフェイスの状態の次回のポーリング(500 ミリ秒後)でインターフェイスが稼動中であると報告されるまで、Edge はインターフェイスを「ダウン」としてマークします。

  • 解決した問題 96888:特定の負荷条件では、BGP または OSPF のいずれかのルーティング プロトコルがランダムに再起動し、ルートの再コンバージェンスとトラフィックの中断が発生することがあります。

    負荷が高い状況では、Edge CPU がスケジュール設定されるために BGP および OSPF ルーティング プロトコルのプロセスが予想よりも長く待機し、ルーティング プロトコルの停止と再起動が発生します。ルーティング プロトコルの遅延は、CPU 帯域幅の割り当てが不十分であることが原因で発生し、どの Edge モデルでも発生する可能性があります。

  • 解決した問題 97483:2 基の CPU コアを持つ VMware SD-WAN 仮想 Edge を使用しているサイトの場合、スループットは送信 (Tx) 方向で 500 Mbps を超えません。

    2 コア仮想 Edge のスループットはソフトウェアの上限(Edge ソフトウェアによって制限される)により 500 Mbps に設定され、CPU が過負荷状態にならないようにします。ただし、Edge ソフトウェアの機能強化により、CPU を過負荷状態にせずに 2 コア仮想 Edge でより多くのトラフィックを処理できるようになったため、既存の 500 Mbps の上限では制限されすぎることになります。この Edge のビルドでは、2 コアのスループットの上限が 1,000 Mbps に引き上げられました。

  • 解決した問題 98514:高可用性トポロジを使用して展開されたカスタマー エンタープライズで、設定の変更が VMware SD-WAN HA Edge に適用されるたびに、スタンバイ Edge で「管理サービスに失敗しました (Management service failed)」というイベントが表示され、その結果、管理サービスが再起動します。

    これは管理サービス(カスタマー トラフィックを含まない)であり、スタンバイ Edge 上では、スタンバイ Edge の管理サービスが再起動したときに HA サイトのクライアント ユーザーに悪影響を与えることはありません。これは引き続き Edge イベントに記録される重要なイベントであり、カスタマー管理者にとって大きな懸念事項になります。

  • 解決した問題 100377:VMware SD-WAN Edge をリリース 5.0.x にアップグレードすると、LAN 側のクライアント ユーザーの環境で、すべてのカスタマーのトラフィックがドロップし、他のサイトおよびインターネットに接続できなくなることがあります。

    説明: この問題はランダムに発生し、LAN 側のトラフィックに影響します。Edge は、Gateway と Orchestrator の両方に接続されたままになります。Orchestrator で [監視 (Monitor)] > [Edge] > [健全性 (Health)] を確認すると、ハンドオフ キューのドロップ数が増大しています。この問題は、5.x Edge ビルドで導入された動作の変更が原因で発生します。これはパケット リークを引き起こす可能性があり、変更に関連する特定のパケットが解放されなくなり、時間の経過とともにパケット バッファが過負荷になり、すべてのパケットのドロップが開始します。

    この問題が修正されていない Edge では、Edge サービスを再起動するとパケット バッファがクリアされます。ただしこれは一時的な処理です。

  • 解決した問題 101049:カスタマー エンタープライズがセキュア ルートと非セキュア ルートの両方を使用している場合、パスの損失が高くなる可能性があります。

    セキュア ルートと非セキュア ルートの両方を使用する例は、Partner Gateway が使用され、Edge が BGP ネイバーからサブネットを学習し(非セキュア)、次に Edge がネットワーク内の別の Edge から同じサブネットを学習する(セキュア)場合です。このシナリオでは、セキュア ルートが優先されますが、セキュア ルートが失効している場合でも、トラフィックは非セキュア ルートに切り替えられません。この問題は、Edge サービスがルーティングを適切に行う管理トンネルをシーケンス処理しないことが原因で発生します。

Edge/Gateway バージョン R5011-20221007-GA で解決した問題

Edge/Gateway ビルド R5011-20221007-GA は 2022 年 10 月 11 日にリリースされ、リリース 5.0.1 の 1 番目の Edge/Gateway ロールアップです。

この Edge/Gateway ロールアップ ビルドは、元の GA ビルド、R5010-20220729-GA 以降の以下の重大な問題に対処します。

  • 解決した問題 89235:ハブ/スポーク トポロジを使用し、インターネット バックホール ポリシーを採用しているカスタマー エンタープライズでは、インターネットに向かう VMware SD-WAN スポーク Edge からのバックホール トラフィックがハブ Edge によってドロップされることがあります。

    この問題が発生すると、クライアント ユーザーはインターネットに向かうトラフィックの問題に気付く可能性があります。この問題は、Edge のパワー サイクル(たとえば、停電の後)、Edge サービスの再起動、または設定の変更のいずれかの後で発生します。これは、スポーク Edge から発信されたバックホール トラフィックとスポーク Edge から広報されたルートの間のタイミングの問題が原因です。

    この修正を適用しないスポーク Edge でこの問題が発生した場合、ユーザーは影響を受けるスポーク Edge のフローをフラッシュして、バックホール トラフィックの通常のルーティングをリストアする必要があります。これは、Orchestrator で [リモート診断 (Remote Diagnostics)] > [フローのフラッシュ (Flush Flows)] を使用して実行できます。

  • 解決した問題 94430:複数のハブが展開されているハブ/スポーク トポロジを使用するカスタマー エンタープライズの場合、VMware SD-WAN スポーク Edge の背後のユーザーの環境では、ハブ Edge に送信されるトラフィックに関する問題が発生する場合があります。

    スポーク Edge がトラフィックを受信することを想定しているハブとは異なるハブにトラフィックを転送すると、クライアント トラフィックの問題が発生します。この問題は、特定のシナリオでリモート BGP ルートの AS パスの長さが正しく計算されないことが原因で発生します。このため、本来ルーティングの優先度が低いハブからのルートの AS_PATH が長くなり、優先される場合があります。

    この問題に対して修正を適用しない場合、カスタマーは優先される予定のルートを取り消して再広報できます。

  • 解決した問題 95503:まれに、VMware SD-WAN Edge モデル 610、610N、または 610-LTE で、すべてのイーサネット インターフェイスに対して同じ MAC アドレスが表示されることがあります。

    Edge 610(任意のタイプ)に、0xF* で終わる eth0 MAC アドレスが表示されることがあります。このような場合、GE1 から GE6 までのポートは、MAC アドレスを計算して割り当てるスクリプトの問題により、同じ MAC アドレスを受信します。

    この修正により、このスクリプトの動作が修正され、影響を受ける Edge 610 タイプは、Edge がこの修正を含むビルドにアップグレードされると、一意の MAC アドレスを適切に計算して割り当てます。

  • 解決した問題 96055:VMware SD-WAN Gateway でシグナル 6 (SIGABRT) のデータプレーン サービス障害が発生し、コアが生成されることがあります。

    この問題は、VMware SD-WAN Edge が無効なセグメントを参照するパケットを Edge のプライマリ Gateway に送信した場合に発生する可能性があります。Gateway がこのパケットを受信すると、そのようなパケットを破棄して状況をグレースフルに処理する代わりに、Gateway のプロセスが失敗します。

  • 解決した問題 96231:カスタマーが、Palo Alto Networks タイプの Gateway 経由の Non SD-WAN Destination (NSD) を展開し、この NSD で使用するために Palo Alto の「Prisma トンネル監視機能」も設定すると、この NSD に対して IPsec トンネルが確立されるときに、5 ~ 15 秒ごとに継続的にトンネルが破棄および再構築され、NSD を使用するトラフィックの中断が発生する場合があります。

    Prisma のトンネル監視が有効になっている場合、Prisma アプリケーションは暗号化された ICMP パケットを SD-WAN Gateway に送信し、Gateway が ICMP パケットに応答すると、Prisma はトンネルが確立されていることを確認します。実際、Prisma は一種の IPsec トンネルの稼動チェックです。ただし、この場合の問題は、Gateway が Prisma の ICMP パケットをドロップしているため、Prisma はトンネルを「ダウン」とマークし、トンネルの破棄と再構築がトリガされることです。

    この問題は、Gateway が ICMP パケットを受信し、それがエコー要求パケットであるかどうかを確認する場合に発生します。タイプ フィールドをチェックする代わりに、Gateway は誤って ICMP ヘッダーのコード フィールドをチェックし、その結果 Gateway が ICMP パケットを破棄し、Prisma がトンネルを破棄します。

    この問題が修正されていない Gateway では、Palo Alto タイプの NSD に Prisma を使用しないでください。

  • 解決した問題 98157:VMware SD-WAN Gateway でデータプレーン サービスの障害が発生し、その結果、サービスが再起動される場合があります。

    まれに、SD-WAN トンネルの送信元ポートが変更されると(中間 NAT デバイスの再起動などが原因)、Gateway のデータプレーン プロセスが失敗して再起動し、コアが生成される場合があります。

  • 解決した問題 99188:状況によっては、カスタマー エンタープライズの BGP セッションが起動しないことがあります。

    この問題は、2147483648 よりも大きい ASN 値が設定されている場合に発生します。このような場合、設定は適用されないため、BGP セッションが起動しません。

Edge/Gateway ビルド R5010-20220729-GA で解決した問題

Edge および Gateway バージョン R5010-20220729-GA は 2022 年 8 月 5 日にリリースされ、Edge/Gateway バージョン R5002-20220506-GA 以降の以下の問題を解決しました。つまり、5.0.0 リリース ノートに記載されている Edge または Gateway の問題に対する修正は、すべてのリリース 5.0.1 ビルドに含まれています。

  • 解決した問題 58791:BGP が使用されている高可用性トポロジで展開されたサイトでは、VMware SD-WAN Edge が繰り返しフェイルオーバーする問題が発生する可能性があります。

    ハブ/スポーク トポロジ内で設定された HA サイトで、512 個を超える BGPv4 フィルタ プレフィックスが設定されている場合、この問題は HA サイトに影響します。

    複数のネットワーク コマンドが設定された状態で BGP が使用され、スタンバイ Edge が起動している間、BGP はすべての設定を対称的に解析し、すべてのネットワーク コマンドに対して vtysh が生成されるため、verp スレッドが実行されません。verp スレッドが遅延すると、ハートビート処理の遅延が発生し、それが原因で、スタンバイ Edge はアクティブ Edge がダウンしていると認識して、スタンバイ Edge がアクティブになり、その結果スプリット ブレイン状態(アクティブ/アクティブ)になります。スプリット ブレイン状態から回復するために、スタンバイ Edge が再起動します。これは単にサイクルを繰り返すだけです。

    この修正を適用しない場合の回避策は、BGP フィルタ プレフィックス設定を集約して、合計で 512(256 の受信フィルタと 256 の送信フィルタ)を下回るようにし、設定数を減らすことです。

    注:

    BGP の「match および set」操作を使用しているときに HA サイトが中断されるという同様な問題が発生します。これは「解決した問題 #84825」で個別に追跡され、これもこの Edge ビルドで修正されています。

  • 解決した問題 67458:多数のスポーク Edge を持つ VMware SD-WAN Hub Edge をリリース 4.2.1 以降にアップグレードすると、他のスポーク Edge へのトンネルの一部がハブ Edge に表示されません。

    多数のスポーク Edge が約 1,000 台以上で認識されます。この問題は一貫していませんが、通常、VeloCloud Management Protocol (VCMP) トンネルの約 1/3 はハブ Edge と接続されたスポーク Edge の間で確立されません。これは、ハーフ オープンの TD の数がハブ Edge の上限を超えているため、ハブ Edge が MP_INIT を無視することが原因で発生します。

    この修正を行わずに問題に対処する場合は、Edge サービスを再起動すると、フル トンネル接続がリストアされます。

  • 解決した問題 70129:大規模な VMware SD-WAN Gateway で Syslog を有効にすると、短時間で /var/log フォルダが Syslog ログ ファイルでいっぱいになる場合があります。

    大規模というのは、通常、約 100,000 個から 150,000 個のフローと約 50,000 個から 100,000 個の NAT エントリがある、最大 4,000 個のピアと最大 6,000 個のトンネルを持つゲートウェイのこととして認識されます。サイズが 3.2 GB を超える Syslog.ログ ファイルの場合、わずか 24 時間という短時間でいっぱいになる可能性があります。これは、別のフォルダに転送されるべき一部の NAT ログが /var/log に送られていることが原因で発生します。

  • 解決した問題 70586:VMware SD-WAN Edge のルーテッド インターフェイスが 802.1x 用に設定されている場合(RADIUS 認証を使用)、そのインターフェイスに接続されているクライアントは、その他のインターフェイスがフラップする(つまり、802.1x 以外のインターフェイスが短時間でダウン/起動を繰り返す)たびにサイレントに認証解除され、クライアントが切断し Edge に再接続するまで、すべてのトラフィックはドロップされます。

    Edge は、フラップしたインターフェイスが実際に 802.1x クライアントを認証したインターフェイスであることを確認しないため、すべてのインターフェイス フラップを 802.1x インターフェイス フラップとして扱い、それに応じて動作します。

    修正を適用しない場合の唯一の回避策は、クライアントを物理的に切断してから再接続し、再認証することです。

  • 解決した問題 74291:高可用性トポロジの VMware SD-WAN Edge は、インターネット アクセスが可能で DNS が機能しているにもかかわらず、フェイルオーバー後にオフラインと表示されることがあります。

    この問題は、高可用性フェイルオーバーの後で、新しく昇格したアクティブ Edge でのトークン エラーが原因で発生する可能性があり、その結果 Orchestrator へのハートビート障害が発生します。ハートビートがない場合、Orchestrator は Edge を「ダウン」としてマークします。

    Edge ビルドで修正を適用しない場合、問題を修正する方法は、ローカル ユーザー インターフェイスを使用するか、アクティブ Edge の電源を入れ直して、別のフェイルオーバーをローカルで強制的に実行することです。

  • 解決した問題 72925:エンタープライズを監視するために SNMP ポーリングを使用し、4.x ソフトウェア リリースを実行している下位モデルの VMware SD-WAN Edge(たとえば、Edge モデル 510、520、または 610)を展開しているカスタマーの場合、SNMP ポーリングの処理に非常に長い時間がかかり、タイムアウトする場合もあります。

    この問題により、510、5x0、および 6x0 シリーズの Edge を使用する場合、ネットワーク監視のための SNMP ポーリングの効率が大幅に低下します。この問題は、リリース 4.x の SNMP エージェントが実際には SNMP プロセスに必要のないデバッグ コマンド リストを走査するのに長い時間かかるために発生します。

  • 解決した問題 73830:System Center Configuration Manager (SCCM) アプリケーション トラフィックが VMware SD-WAN Edge によってビジネス インテリジェンス サービス (BITS) トラフィックとして誤って分類されており、SCCM トラフィック用に設計されたビジネス ポリシーまたはファイアウォール ルールを使用しているカスタマーは、そのトラフィックが影響を受けることがわかります。

    Edge の詳細なパケット インスペクション (DPI) エンジンが SCCM アプリケーション パケットを BITS トラフィックとして誤って分類しており、そのトラフィックをステアリングするかファイアウォール ルールによって確実に許可するように設計されたビジネス ポリシーまたはファイアウォール ルールがある場合には、この誤分類により SCCM トラフィックがブロックされてしまい、その結果としてカスタマーにおいて中断が生じます。この問題の修正では、デフォルトの 4.5.1/5.0.1 以降のアプリケーション マップを修正し、この誤分類を確実に防止しています。

  • 解決した問題 74316:VMware SD-WAN スポーク Edge は、Edge がサービスの再起動または完全な再起動を行った場合でも、割り当てられたハブ Edge クラスタの一部またはすべてに接続しない場合があります。

    特定のクラスタ メンバーから Super Gateway へのオーバーレイ フラップ シナリオにおいて、クラスタ メンバーのエンドポイント情報を使用せずにクラスタ割り当てマッピングを作成するクラスタ再割り当てロジックに問題があります。その結果、ハブ クラスタ メンバーに割り当てられたスポーク Edge がハブ クラスタ メンバーのエンドポイント情報を受信できなくなり、スポーク Edge とハブ クラスタ間のオーバーレイがなくなります。

    この修正を適用せずにこの状況を一時的に修正する唯一の方法は、Gateway にアクセスできるユーザーがスーパー Gateway でクラスタの再割り当てを手動でトリガすることです。

  • 解決した問題 76690:VMware SD-WAN Edge の問題のトラブルシューティングを試みると、重要なログが見つからないことがあります。これは、重要度がより低いイベントのエントリが繰り返されることで、重要なログが除外されたためです。

    診断バンドルでは、velocloud/log にイベント vc_peer_qos_update_cos_qlimits のログが繰り返し記録される場合があります。このイベントのログ レベルは管理プレーンであり、ログがオーバーフローしてロールオーバーするポイントまで繰り返しログに記録される可能性があります。トラブルシューティングのシナリオでは、重要なログ メッセージがロールオーバーされてワイプされたために失われる可能性があります。

  • 解決した問題 78276:VMware SD-WAN Gateway では、VMware SD-WAN Edge の名前に非 ASCII 文字が含まれている場合、コマンド debug.py -qos_net を実行すると失敗します。

    この例では、漢字が使用されていましたが、他のどの非 ASCII 文字を使用した場合でも同様です。これを確認するには、Edge の名前を非 ASCII 文字を含むように変更して、Edge を再起動します。次に、Edge に接続された Gateway で CLI コマンドdebug.py --list 3 を実行して、Edge の論理 ID を取得します。次に、Gateway の CLI コマンドdebug.py -qos_net [logical ID] all stats を実行します。ユーザーはこのコマンドが失敗することを確認できます。

  • 解決した問題 78300:VMware SD-WAN Edge がバックアップとして設定された WAN リンクを使用している場合、このリンクに対してトンネルが起動または停止していることを示すログまたは Orchestrator イベントが生成されることがあります。

    設計上、バックアップ リンクのトンネルは確立されません。ただし、リモート エンド(通常は動的 Edge 間トンネル)からのトンネル要求は、スタックを通過するときにリンク状態を変更する可能性があります。今回の修正では、バックアップ リンクに対してトンネルの構築や破棄がログに記録されないように注意が払われています。

  • 解決した問題 78391:Speedtest アプリケーション分類のトラフィックが適切に機能しません。

    speedtest.netfast.com の両方に、デフォルトのアプリケーション マップに含まれていない新しい Speedtest サーバの IP アドレスが追加されたため、これらのアプリケーションを処理するビジネス ポリシーが適用されていません。

    リリース 4.5.1 または 5.0.1 にアップグレードしない場合、オペレータは VMware SASE Orchestrator のアプリケーション マップ エディタを使用して、必要な Speedtest IP アドレスを既存のアプリケーション マップに追加できます。

  • 解決した問題 79261:VMware SD-WAN Edge において、Office 365/Microsoft 365 のアプリケーション トラフィックが Tencent Meeting (VooV Meeting) のアプリケーション トラフィックとして誤って分類されます。

    これは、Office 365/Microsoft 365 のトラフィックのみのルーティングと優先順位付けをビジネス ポリシーまたはファイアウォール ポリシーに依存し、そのトラフィックを Tencent Meeting として分類し、完全に異なるルールを適用するカスタマーに対して、混乱を招く可能性があります。この問題は、Tencent のアプリケーション マップ サブネットの誤りに起因しており、4.3.2 のデフォルト アプリケーション マップで修正されています。4.3.2 を使用していないカスタマーは、Orchestrator アプリケーション マップ エディタを使用してアプリケーション マップを編集できるオペレータに Tencent サブネットを修正してもらうことで、この問題を修正できます。

  • 解決した問題 80010:SD-WAN が到達可能 (SD-WAN Reachable) 機能も設定されているハブ/スポーク トポロジを使用しているカスタマー エンタープライズでは、スポークとハブの間のパスがポイントツーポイントである場合、Hub パス経由のスポークから Gateway へのパス(パブリック WAN リンクを使用)が表示されません。

    スポーク Edge とハブ Edge がポイントツーポイント リンク(つまり、スポークの IP アドレスがハブの接続されたルートと一致する)で接続されている場合、スポーク Edge を接続されたハブを介して Gateway に接続するためのパススルーである、SD-WAN が到達可能 (SD-WAN Reachable) 機能はサポートされません。この問題の修正により、この機能が追加されます。

  • 解決した問題 80196:VMware SD-WAN Gateway で SIGXCPU メッセージによるデータプレーン サービス障害が発生し、Gateway がサービスを再起動してリカバリする場合、Gateway のトラフィックに 15 ~ 30 秒の影響があります。

    この問題は、スループット キャパシティに対して Gateway のスループットが高い場合に見られるため、大規模な展開(例:4000 台の Edge と 6000 個のトンネルがある環境)で発生する可能性が高くなります。Gateway に高速でトラフィックが到達すると、スレッド ロックが発生し、再起動中にコアが生成される場合があります。コアでは、以下が表示されます。Program terminated with signal SIGXCPU, CPU time limit exceeded。というエラーが返されるため、オペレータ ユーザーは本番環境の Gateway の場所を更新できません。

  • 解決した問題 80479:VMware SD-WAN Gateway でデータプレーン サービス障害が発生し、Gateway がサービスを再起動してリカバリすることがあり、その場合 Gateway のトラフィックに 15 ~ 30 秒間の影響が生じます。

    この問題は、VMware SD-WAN Edge が Edge-to-Edge (E2E) を設定した Gateway に接続し、ループバック インターフェイスのルートが広報されている場合に発生する可能性があります。ユーザーがこの Edge の E2E をオフに切り替えると、ルートの開始がトリガされますが、ループバック ルートは削除されず、ルートはルートのプロファイル フラグを更新します。次に、ユーザーがループバック ルートの広報を削除すると、そのルートは FIB から削除されますが、Gateway の E2E テーブルには古いまま残ります。その後、ループバック ルートが再び広報されて FIB に追加されてから、Edge-to-Edge をオンに切り替えて再びフラグを更新すると、Gateway の E2E テーブル(古い状態)にルートが存在するにもかかわらず、実際のルート ref_count が正しくありません。最後に、トンネルが破棄されると、Gateway でのデータプレーン サービスの障害がトリガされます。

    この修正を適用しない場合、オペレータは Edge のプロファイルが変更される前にルートを取り消す必要があります。

  • 解決した問題 80496:SD-WAN トンネルを介して VMware SD-WAN Edge からリモート Edge のブランチ ループバック IP アドレスに ping を実行すると機能しないことがあります。

    この問題は、断片化を引き起こすのに十分な大きさのパケット サイズの ping で見られます。Edge からリモートのブランチ Edge のループバック IP アドレスに対して大きなパケット サイズで ping が実施されると、断片化した ICMP 応答が ping を実施している Edge に到達しますが、次の断片がドロップされるため ping アプリケーションには到達しません。

  • 解決した問題 80721:パートナーおよびオペレータが Telegraf を使用して VMware SD-WAN Gateway を監視しているときに Telegraf でネットワーク タイムアウトが発生すると、メトリックが再開されない場合があります。

    この問題は、ゲートウェイが Telegraf バージョン 1.17.3 を使用している場合に発生します。これは、VMware SASE Orchestrator が使用している Telegraf バージョン 1.21.1 とは異なります。このバージョンの不一致により、ネットワークがタイムアウトしたときに Telegraf が停止する問題が発生します。この問題を修正したゲートウェイには、そのリリース トレインでの将来のゲートウェイ ビルドと同様に Telegraf バージョン 1.21.1 が含まれます(すなわち、4.5.1 または 5.0.1)。

    この問題が発生しているゲートウェイでの唯一の修正方法は、Telegraf を再起動してメトリックの送信を再開することです。

  • 解決した問題 80814:ローカル Edge クライアントの送信元 IP アドレスが存在し、リモート クライアントが宛先 IP アドレスとして設定されていて、他のトラフィックを「すべて拒否」するルールを持つ標準ファイアウォール許可ルールが設定されている VMware SD-WAN Edge では、リモート クライアントからローカル クライアントへのトラフィックがドロップします。

    この問題は、送信元ホストと宛先ホストの間に VLAN IP アドレスの不一致がある場合に発生します。異なる VLAN の一部として送信元ホストと宛先ホストが存在する場合、SD-WAN サービスは、ファイアウォールの検索キーにあるように、最初のパケットの送信元/宛先 IP アドレスを優先します。その結果、オーバーレイ受信フローでは、不一致が発生してトラフィックが [すべて拒否 (Deny All)] ファイアウォール ルールに当たります。

    この修正を適用しない場合、この問題の回避策は、パケットがファイアウォール ルールと一致するようにするために、フローの最初の IP パケットの方向にルールを戻すことです。

  • 解決した問題 80897:VMware SD-WAN Edge が VMware SD-WAN Partner Gateway に接続されているカスタマー エンタープライズでは、カスタマー トラフィックのパフォーマンスが低下することがあります。

    パフォーマンスの低下は、安全な優先スタティック ルートが使用可能な Edge に Partner Gateway がルートを配布するが、その Edge がこれらのルートを安全として適切にラベル付けしないことによるルーティングの問題が原因で発生します。パフォーマンスの低下は、安全な優先スタティック ルートが使用可能な Edge に Partner Gateway がルートを配布するが、その Edge がこれらのルートを安全として適切にラベル付けしないことによるルーティングの問題が原因で発生します。

    注:

    問題を解決するには、Partner Gateway とカスタマー Edge の両方をこの修正を含むビルドにアップグレードする必要があります。

  • 解決した問題 81221:カスタマーが VMware SD-WAN Edge に 1:1 NAT ルールを設定し、その Edge が再起動されると、ルールが機能しなくなります。

    再起動後、Edge は、NAT ルールが適用されている Edge インターフェイス アドレスとして NAT アドレスを割り当てます。そのため、そのルールに一致するトラフィックのトンネルは構築されません。

    この修正を適用せずにこの問題を修正する唯一の方法は、[リモート診断 (Remote Diagnostics)] > [NAT のフラッシュ (Flush NAT)] を実行することです。これにより、NAT テーブル全体がフラッシュされ、正しい NAT ルール操作が再確立されます。

  • 解決した問題 81809:ユーザーが VMware SD-WAN Edge 上の VLAN IP アドレスに SSH を試みる場合、その SSH 試行は、他の Edge の背後にあるリモート クライアントから、または VMware SD-WAN Gateway からであっても失敗します。

    LAN クライアントから Edge の VLAN IP アドレスへの SSH 試行は正しく機能します。元々、Edge の管理 IP アドレスは Edge への SSH 接続に使用されていました。しかし、Edge 管理 IP アドレスが廃止された後、ループバック IP アドレスが依然として SSH をサポートしないため、ユーザーが(リモート Edge クライアントからのオーバーレイ経由で)Edge に SSH 接続するためのオプションがありませんでした。

  • 解決した問題 81859:VMware SD-WAN Edge 610-LTE が Edge リリース 5.0.0 にアクティベーションされると、Edge がそのリリースにアップグレードされた後に CELL インターフェイスが表示されないことがあります。

    この問題は一貫して発生するわけではありませんが、Edge 610-LTE の唯一のパブリック リンクがモバイル CELL リンクである場合、この問題が発生すると大きな影響を与える可能性があります。これは、Edge が事実上停止し、ローカルでこの Edge の介入を行う必要があるためです。

    Edge でこの問題が発生した場合、修正を適用せずに解決するには、Edge サービスを再起動する(または Orchestrator から Edge にアクセスできない場合は電源を入れ直すか再起動する)か、Edge のモデムを再起動して CELL インターフェイスをリストアする必要があります。

  • 解決した問題 82182:Edge リリース 5.0.0 を実行している VMware SD-WAN Edge モデル 510 または 510-LTE の場合、ユーザーが Edge のサービスの再開を試みると、Edge も再起動することがあります。

    Edge を再起動すると、Edge が再起動プロセスを進める間、カスタマーのトラフィックが 2 ~ 3 分間中断されます。Edge 510/510-LTE には、Wi-Fi デバイスのハング監視スクリプトがあって、これが、Edge サービスの再開中に停止に失敗する可能性があり、これにより再起動がトリガされます。

    この修正を適用しない場合、ユーザーは Edge サービスを再起動する必要がありますが、これらのモデルの Edge サービスの再起動は、メンテナンスの時間枠内でのみ実行するか、またはこの問題が発生する可能性があることを理解した上で実行する必要があります。

  • 解決した問題 82264:AWS C4 インスタンスを使用する VMware SD-WAN 仮想 Edge をリリース 5.0.0 にアップグレードできません。

    リリース 5.0.0 にアップグレードされた AWS C4 仮想 Edge はリカバリされず、唯一の修正は、ユーザーが Edge を 5.0.0 以外のバージョンに再アクティベーションすることのみです。他の AWS インスタンス(C5 など)はこの問題の影響を受けませんが、この問題の重大な性質により、AWS Edge アップグレード ソフトウェア パッケージはリリース 5.0.0 では使用できません。

    Edge リリース 5.0.1 以降ではこの問題が修正され、AWS C4 インスタンスはリリース 5.0.1 以降に正常にアップグレードできます。

  • 解決した問題 82463:クラウド セキュリティ サービス (CSS) で設定されたサイトの場合、VMware SD-WAN Edge が CSS に送信されるトラフィックをドロップすることがあります。

    サイトが CSS を介してすべてのインターネット トラフィックをルーティングしている場合、この問題の影響が大きい可能性があります。この問題が発生すると、CSS パケットが実際のインターフェイスの IP アドレスを送信元として誤ったインターフェイス上で送信されるため、アプリケーション アクセスの障害につながります。この問題は、CSS コンテキスト参照スレッドと送信インターフェイス選択スレッドとの間で競合が発生した場合に、送信インターフェイスとフローの誤った関連付けが行われて CSS パス上の一部のフローが失敗するために発生します。

    この修正を適用しない場合は、問題が発生したときに、新しいフローを開始するか、[リモート診断 (Remote Diagnostics)] > [フローのフラッシュ (Flush Flows)] を使用して Edge 上のすべてのフローをフラッシュすることによって、問題を修正できます。

  • 解決した問題 82485:エントリ レベルの VMware SD-WAN Edge モデル(Edge 510、510-LTE、610 など)で、ユーザーがリモート診断の「ルート テーブル ダンプ」を実行すると、Orchestrator ユーザー インターフェイスのページがタイムアウトになり、結果が返されないことがあります。

    この問題は、16,000 個を超えるルートがあると、Edge が結果を返すのに 30 秒以上かかることにより発生します。ページの WebSocket のタイムアウト制限が 30 秒であるため、結果は返されません。この問題の修正により、タイムアウトが発生しないようにルート テーブル ウォークが最適化されます。

  • 解決した問題 82522:高スループット トラフィックが VMware SD-WAN Edge に到達すると、Edge での実際のスループットが低下することがあります。

    高スループットにおいては、Edge の NDP (Neighbor Discovery Protocol) スレッドが、到達可能とマークされていて、それ以上の処理が不要な NDP エントリに対しても 2 回ロックを取得することがありました。これらの重複するロックにより、追加の処理が生じるため、スループットが低下します。

  • 解決した問題 82652:L7 健全性チェックが設定されているクラウド セキュリティ サービス (CSS) を使用している場合、VMware SD-WAN Edge は、5 分以上にわたり「ダウン」とマークされた IPsec CSS トンネルのリカバリを試みません。

     L7 健全性チェックの現在の実装では、Edge はすべての CSS トンネルで L7 プローブを送信し、これらのプローブが一定回数失敗した場合、Edge はそのトンネルを「ダウン」とマークし、L7 プローブの送信を続け、トンネルが自然に起動するまで待機します。これは、5 分以上にわたってダウン状態になったトンネルのリカバリが試行されず、その間 IKE は稼動したままになるという問題です(IKE もダウンしている場合、IPsec トンネルは 20 秒後に自動的にリセットされます)。

    このチケットの修正により、IPsec ベースの CSS トンネルの追加手順が追加され、L7 健全性チェックが強化されました。IPsec ベースの CSS トンネルが 5 分以上ダウンしたまま(L7 プローブが成功しない)、同じ時間にトンネルの IKE が稼動を続けている場合、Edge は IPsec トンネルを破棄し、IKE をリセットして CSS トンネルのリカバリを試みます。L7 プローブは、これが発生している間も送信され続け、成功するとトンネルが稼動中とマークされます。トンネルがダウンしたままの場合は、さらに 5 分後に同じ手順が適用されます。

    この追加された動作は、GRE トンネルを使用する CSS ではなく、IPsec トンネルを使用する CSS にのみ適用されます。

  • 解決した問題 82790:Azure 環境に展開された VMware SD-WAN Gateway で、Gateway インターフェイス カウンタが Wavefront 監視サービスにエクスポートされません。

    Azure は、DPDK を使用するように設定されていない環境のため、DPDK のインターフェイス カウンタ(スループット レート、PPS、ドロップ カウンタ)のみが Wavefront サービスにエクスポートされます。このため、DPDK が使用されていない Azure のようなプラットフォームでは、監視機能が低下します。

  • 解決した問題 82839:ユーザーが VMware SASE Orchestrator 上で Zscaler クラウド セキュリティ サービス トンネルの IPsec 自動削除アクションを実行すると、このアクションによって、それぞれの Zscaler の場所に関連付けられているすべての VPN 資格情報も削除され、場所自体も削除されてしまいます。

    IPsec の自動削除アクションでは、関連付けられている VPN 認証情報のみが Zscaler の場所から削除されます。各 Zscaler の場所に関連付けられている他のすべての VPN 認証情報はそのままで変更されません。

  • 解決した問題 83029:スタンドアローンの VMware SD-WAN Edge、または 1 つ以上の PPPoE リンクが使用されている高可用性トポロジで展開されたサイトの場合、その PPPoE リンクに対する Edge インターフェイス フラップ後または HA サイトでのフェイルオーバーの発生後に、PPPoE エンドポイントの IP アドレスが変わると、トラフィックは影響を受ける PPPoE リンクを通過しません。

    PPPoE リンクを使用するサイトでは、PPPoE エンドポイントの IP アドレスが変わると、カスタマー トラフィックが通過しなくなります。この問題は、古いデフォルト ルートが存在することが原因で発生します。このルートは、新しい PPPoE エンドポイントの IP アドレスを受信した後に削除されていない、Edge 上の PPPoE エンドポイントの古い IP アドレスを使用しています。

    修正を適用しない場合、オンサイト ユーザーは各 PPPoE ケーブルを切断して再接続し、再ネゴシエーションを強制するか、または Edge を再起動する必要があります。再起動により再ネゴシエーションも強制されます。

  • 解決した問題 83083:VMware SD-WAN Gateway をリリース 4.3.1 以降にアップグレードすると、メモリ リークが遅くなり、Gateway のサービスがメモリをクリアするために再起動することがあります。

    Gateway サービスが再起動するには 30〜45 秒間かかるため、Gateway の再起動によりカスタマー トラフィックが中断する可能性があります。オペレータ ユーザーが Gateway で debug.py --flow_dump all all all コマンドを実行するたびに、Gateway はメモリの一部をリークします。このデバッグ コマンドを十分な回数実行すると、Gateway のメモリ使用率が重大レベルに達し、Gateway サービスの再起動がトリガされ、メモリがクリアされます。

    この修正が適用されていない Gateway の場合、オペレータは Gateway で debug.py --flow_dump all all all コマンドを実行しないようにする必要があります。このデバッグ コマンドを使用することが避けられない場合は、メモリ使用率を監視し、サービスをプリエンプティブに再起動するようにメンテナンス時間帯をスケジューリングして、予期しない再起動が起こる前にメモリをクリアします。

  • 解決した問題 83209:カスタマーがエンタープライズで OSPF を使用している場合、OSPF ルーティングが想定どおりに動作しないことがあります。

    この問題は、OSPF ルーター ID に変更があり、Edge サービスが再起動された場合に発生します。ルーター ID の選択では、ループバック インターフェイスと「広報」フラグが設定されているインターフェイスのみが考慮されます。高い IP アドレスで設定された新しいループバック インターフェイスがある場合、Edge サービスを再起動すると、新しいループバック IP アドレスがルーター ID として選択され、Edge が DR(指定ルーター)として選択された場合に問題が発生します。

    修正を適用しない場合の唯一の回避策は、古いルーター ID を強制的に使用することです。古いルーター ID に戻し、各インターフェイスで広報フラグを設定します(Edge サービスの再起動が必要になります)。

  • 解決した問題 83402:複数の WAN リンクを持つ VMware SD-WAN Edge で、1 つ以上の WAN リンクがトラフィックの通過を停止することがあります。

    トラフィックの通過を停止する WAN リンクで、DHCP が取得したアドレスが更新されず、WAN インターフェイスのアドレスが失われます。この問題は、DHCP を使用して IP アドレスを取得するインターフェイスが複数あり、DHCP サーバがクライアントとは異なるネットワークにある場合に発生します。DHCP 更新ユニキャスト パケットの発信インターフェイスは、ルート ルックアップによって決定されます。異なるインターフェイスを介して学習された異なるメトリック値を持つ複数のデフォルト ルートがあるため、DHCP 要求パケットが異なるインターフェイスから送信される可能性があります。 

    修正を適用しない場合、オンサイト ユーザーは Edge から影響を受けた WAN リンクを切断してから再度接続することによって、IP アドレスを再度取得するように強制する必要があります。

  • 解決した問題 83411:新しくアクティベーションされた VMware SD-WAN Edge で高可用性がオンになっていると、HA Edge ペアがオフラインになることがあります。

    HA をオンにすると、すべての Edge インターフェイスの MAC アドレスが仮想 MAC アドレスに変更され、問題の状態が続く間は、DPDK 設定はこれらの VMAC アドレスで更新されません。その結果、宛先の MAC アドレスの不一致が原因で Orchestrator に送信されるハートビート パケットがドロップされ、Orchestrator は HA Edge ペアをダウンとしてマークします。

  • 解決した問題 83424:SNMP ウォークは、インターフェイスおよびパス関連の OID で適切に動作しないことがあります。

    一部の Edge の展開で snmpbulkwalk コマンドを実行すると、SNMP ウォークに時間がかかりすぎてタイムアウトになることがあります。この問題の修正により、SNMP が最適化され、SNMP ウォーク リクエストに対する応答が迅速になります。ただし、まれに SNMP プロセスが Edge で優先度の低いプロセスのままとなり、この問題が引き続き発生する可能性があることに注意してください。

  • 解決した問題 83428:ハブ/スポーク トポロジを使用しているカスタマー エンタープライズでは、VMware ハブ Edge とスポーク Edge 間の静的トンネルが、トンネルの帯域幅を測定しようとする際にトラフィックの通過を止めることがあります。

    ハブ Edge には、トンネルの確立プロセスの途中でトンネル設定が更新されるシナリオを処理するためのメカニズムはありません。次に、帯域幅の測定プロセスによってトンネルが停止状態になり、トラフィックがこのトンネルを通過できなくなります。カスタマーのトラフィックは Gateway を経由して再ルーティングできますが、ハブ/スポーク トラフィックに遅延が発生する可能性があります。

  • 解決した問題 83432:高可用性トポロジを使用して展開されたサイトの場合、サイトにトンネルを追加すると、VMware SD-WAN スタンバイ Edge でデータプレーン サービスがクラッシュし、コアが生成されることがあります。

    トンネルを追加する一般的な方法は、HA Edge に WAN リンクを追加することです。スタンバイ Edge がアクティブ Edge と同期する必要があるトンネルの数が 80 を超えると、例外が発生し、スタンバイでデータプレーン サービスの障害がトリガされます。この問題が従来の HA トポロジで発生した場合、スタンバイ Edge はカスタマー トラフィックを渡さないため、カスタマーへの影響は最小限に抑えられます。拡張 HA 展開では、スタンバイ Edge もトラフィックを渡すため、再起動によって一部のカスタマー トラフィックが中断されます。 

  • 解決した問題 83611:VMware SASE Orchestrator ユーザー インターフェイスに、VMware SD-WAN ハブ Edge からの異常に多くの数の EDGE_NEW_DEVICE イベントが表示されることがあります。

    この問題は、次のトポロジで発生します。クライアント デバイス – スポーク Edge - ハブ Edge -- DHCP サーバ。このトポロジでは、スポーク Edge の背後のクライアント ユーザーが DHCP パケットを送信するたびに、スポーク Edge がこのクライアント デバイスの Edge_New_Device イベントを適切にトリガします。しかし、ハブ Edge が DHCP リレー パケットを受信するときに、ハブ Edge は Orchestrator に Edge_New_Device イベントを再度トリガします。このイベントは正しくありません。

  • 解決した問題 83699:VMware SD-WAN Gateway が VMware SASE Orchestrator の新しいユーザー インターフェイスから停止モードに設定されている場合、ユーザーが新しい代替 Gateway を選択すると、Orchestrator は代替 Gateway に対する設定の変更を許可しません。

    この問題は、Orchestrator の新しいユーザー インターフェイスを使用して Non SD-WAN Destination の移行プロセスを有効にした後に発生します。このプロセスの中で、停止された Gateway の代わりとなる新しい Gateway が選択されます。新しい Gateway が代替 Gateway として指定されると、代替 Gateway の設定を変更しようとするときに、オペレータは次のようなエラー メッセージが表示されるのを確認します。GATEWAY_SERVICE_STATE_INVALID: Cannot change the state of the gateway to null, as it is already used as a replacement gateway。というエラーが返されるため、オペレータ ユーザーは本番環境の Gateway の場所を更新できません。

  • 解決した問題 83928:VMware SD-WAN Edge で CPU 使用率が高くなり、カスタマー トラフィックのパフォーマンスが低下することがあります。

    また、Orchestrator の [監視 (Monitor)] > [Edge] > [QoE] 画面で、その Edge の QoE スコアが低いことも確認できます。この問題が発生するのは、Edge で ACL(アクセス制御リスト)ルールが複数回インスタンス化され、この多数の ACL ルールを一度に処理するために Edge の CPU キャパシティにストレスがかかり、その結果、Edge がカスタマー トラフィックを適切に処理できないためです。

  • 解決した問題 83946:VMware SD-WAN Edge LAN 側クライアントでトラフィックの中断が発生する場合があり、RADIUS 認証を使用しているサイトでは、クライアント ユーザーが認証に失敗することがあります。

    大きなパケットは断片化され、これらの断片化されたパケットは Edge によってドロップされる可能性があります。一部のエラー シナリオでは、フラグメント IP アドレス識別変換中のメモリ リークが原因でパケットがドロップされ、断片化されたパケットに対する Edge の上限を超えると、それ以降の断片化されたパケットが Edge によってドロップされます。

    ワイヤレス クライアントから RADIUS 認証を使用する Edge への大きなパケットが含まれる RADIUS を使用しているカスタマーの場合、認証が失敗する可能性があります。たとえば、ワイヤレス LAN コントローラ (WLC) から RADIUS サーバへの大きなパケットがドロップされることがあります。

  • 解決した問題 84106:VMware SD-WAN Edge が誤った時間間隔で NetFlow 統計情報をエクスポートすることがあり、その結果、受信側のシステムが同期されなくなります。

    NetFlow パケットには、設定した間隔から 5 秒の遅延が追加されることがあります。これは、NetFlow エクスポータが 5 秒に 1 回だけエクスポート時間をチェックし、NetFlow パケットには設定された間隔と実際のエクスポート間隔の間に 5 秒の遅延が生じる可能性があるためです。

  • 解決した問題 84359:VMware SD-WAN Edge インターフェイスがフラップするときに、複数の IPv4 アドレスが割り当てられる可能性があります。

    DHCP クライアントで設定されたインターフェイスがフラップする(急速にダウンとアップが連続する)と、DHCP クライアント プロセス全体が再度実行され、毎回異なる IP アドレスを取得するシナリオになる可能性があります。この場合、古い方の IP アドレスは消去されず、古い状態になります。

    この修正を適用しない場合、問題を修正する唯一の方法として、ユーザーが Linux シェルで ip address del コマンドを使用してインターフェイスから IP アドレスを手動で削除することになります。

  • 解決した問題 84501:802.1x 認証(RADIUS、Cisco ISE など)を使用しているカスタマー エンタープライズの場合、VMware SD-WAN Edge がリリース 4.3.1 以降にアップグレードされると、Edge に接続されているクライアント デバイスは WAN 経由でホストされているネットワーク アクセス サーバ (NAS) に対する認証に失敗します。

    Edge (Authenticator) から RADIUS または ISE サーバに送信される RADIUS または ISE パケットでは、NAS IP アドレスがデフォルトでループバック IP アドレスとして設定されているため、認証パケットが NAS に到達せず、認証に失敗する可能性があります。この問題を修正するには、この修正を適用したビルドで、NAS IP アドレスを、802.1x 認証設定を使用して選択および設定された送信元インターフェイス IP アドレスとして設定します。送信元インターフェイスとして [自動] が選択されている場合、ループバック IP アドレスはデフォルトで NAS IP アドレスとして設定されます。

  • 解決した問題 84825:VMware SD-WAN Edge で大規模な一括ルーティング設定を 1 つの手順で適用すると、Edge でデータプレーン サービスの障害が繰り返され、障害から回復するために Edge サービスの再起動が繰り返されることがあります。

    スタンドアローン(非 HA)Edge でこの問題が発生すると、1 回の Edge サービスの再起動でトラフィックが約 15 秒間中断される一方、Edge サービスの再起動が繰り返されることで約 60 秒以上の中断が発生するため、カスタマー トラフィックに大きな影響があります。高可用性トポロジを使用するサイトでは、Edge サービスの再起動によってフェイルオーバーが繰り返し発生し、カスタマー トラフィックも中断します。

    この問題は、多数のネイバーとルートマップを含む一括ルーティング設定が 1 つの手順で Edge に適用された場合に発生します。これらの設定をコマンド仕様に変換し、短時間でルーティング プロトコルに適用すると、Edge システムに大きな負荷がかかり、これが原因で Edge サービスの失敗と再起動が繰り返されます。

    修正が適用されていない Edge ビルドでは、この問題のリスクを軽減するために、カスタマー ユーザーは次の操作を行う必要があります。

    • 大規模な設定を 1 つの手順で適用する代わりに、設定を複数の小さなセクションに分割し、各セクションを個別に適用します。

    • ルーティング フィルタの数は最小限に抑える必要があります。

    • Edge はメンテナンス期間中にのみ意図的に再起動し、多数のルーティング フィルタが設定されている場合は一般に Edge サービスの再起動を回避する必要があります。これは、再起動中に Edge 設定全体が一度に適用され、この問題が発生するリスクが大幅に高まるためです。

  • 解決した問題 84847:VMware SD-WAN Edge 上で USB ベースの LTE モデムを展開している場合、または VMware SD-WAN Edge LTE モデル(510-LTE または 610-LTE)を展開している場合、モデムのリセット後に CELL インターフェイスからのトンネルの構築で断続的な問題が発生することがあります。

    次のいずれかのシナリオで LTE モデムがリセットされた場合:

    USB モデムを使用する Edge で、USB ポートからモデムを取り外してから再接続する。

    Edge-LTE で、Edge を再起動した後、または [テストとトラブルシューティング (Test & Troubleshoot)] > [リモート診断 (Remote Diagnostics)] > [USB モデムのリセット (Reset USB Modem)] > [CELL1] で CELL1 インターフェイスをリセットする。

    いずれのシナリオでも、基盤となるネットワーク デバイスが wwan0 から wwan1 に変更され、Edge はこの新しい名前を受け入れません。これは、重複するインターフェイスのように見えるためです。

    この修正を適用せずに LTE インターフェイスをリストアする回避策は、[リモート アクション (Remote Actions)] > [サービスの再起動 (Restart Service)] で Edge サービスを再起動することです。

  • 解決した問題 85369:高可用性トポロジを使用して展開されたサイトの場合、カスタマー トラフィックが中断し、VMware SD-WAN スタンバイ Edge が複数回再起動する可能性があります。

    HA Edge 上の複数のスレッドがサスペンド状態になり、HA がアクティブ/アクティブ状態になるなど、HA のさまざまな問題が発生します。サイトがアクティブ/アクティブになると、従来の HA 設定では、スタンバイ Edge はこのトポロジでトラフィックを渡さないため、トラフィックの中断が最小限に抑えられますが、スタンバイ Edge もトラフィックを渡す拡張 HA 展開では、再起動によって一部のカスタマー トラフィックが中断されます。複数のスレッドのサスペンドがカスタマーに影響を与える可能性があるもう 1 つの方法は、パスの中断です。これは、カスタマー トラフィックの中断としても確認されます。このため、スタンバイ Edge が再起動するアクティブ/アクティブ シナリオの兆候が現れずに、カスタマー HA サイトでこの問題が発生する可能性があります。

    複数の HA Edge スレッドがサスペンドされる根本原因は、現在調査中です。

  • 解決した問題 85375:VMware SD-WAN Edge の USB ベースの LTE モデムまたは VMware SD-WAN Edge LTE モデル(510-LTE または 610-LTE)を使用している場合、LTE トラフィックの中断が発生することがあります。

    ユーザーは Edge のログで RX エラーを確認し、このエラーは、LTE インターフェイスを通過するトラフィックがない状態で増加します。この問題の 1 つの特徴として、LTE リンクの MTU が 1500 未満の場合にのみ発生するということがあります。

  • 解決した問題 85459:Edge LAN 側クライアントから Edge への SSH 接続、またはリモート ブランチの Edge クライアントから Edge への SSH 接続の試みが、LAN 側 NAT ルールが設定された後に機能しないことがあります。

    Edge の SSH プロセスから入ってくる SSH 応答パケットは、Edge のデータプレーン サービスを通過します。LAN 側の NAT ルールが設定されているため、SSH 応答パケットは LAN 側の NAT ルールを使用して、SSH トラフィックの生成元のクライアントとは異なる宛先に向かう可能性があり、Edge への SSH 接続の試みが機能しない原因となることが考えられます。

    修正が適用されていない Edge では、唯一の回避策として NAT ルールを削除します。

  • 解決した問題 86032:VMware SD-WAN Gateway をリリース 4.3.x から 4.5.1 または 5.0.0 にアップグレードすると、Gateway は VMware SASE Orchestrator との通信を切断し、eth0 および eth1 インターフェイスは削除されます。

    主要な問題は、アップグレード後に Gateway のデータプレーン プロセスが停止することです。これは、Telegraf サービスが起動に失敗することが原因です。Telegraf サービスは Gateway 起動スクリプトの一部として有効化されるため、Telegraf サービスが起動できない場合は Gateway のサービスも起動に失敗します。

    Gateway がこの修正が適用されていないビルドにアップグレードされた場合、この問題を修正する唯一の方法は、Telegraf サービスの再起動と一緒に Gateway の vc_procmon restart を実行することです。

  • 解決した問題 86103:RADIUS 認証を使用するカスタマー エンタープライズの場合、一部のサイトのクライアント ユーザーが VMware SD-WAN Edge に接続してトラフィックを渡すことができない場合があります。

    この問題は、Edge で、IP ヘッダーに設定された DF (Don't Fragment) ビットを持つ断片化された RADIUS パケットが誤って断片化されていないと分類されることが原因で発生します。これらのパケットの 1 つ以上が複数の Edge に到達できず、RADIUS 認証に依存するトラフィックがこれらの Edge を通過しません。この問題は、ハブ/スポークおよび単純なブランチ間を含むすべてのトポロジで発生する可能性があります。

    この修正を適用しない場合の唯一の回避策は、断片化されたパケットの送信中に IP ヘッダーに DF ビットを設定しないように RADIUS サーバを設定することです。

  • 解決した問題 86314:LAN 側の NAT フローがリモート ピアによって開始されると、VMware SD-WAN Edge が誤ったステートフル ファイアウォール ルールのルックアップを実行することがあります。

    ステートフル ファイアウォールを使用している Edge でユーザーが LAN 側の送信元 NAT を設定して(たとえば、Edge の背後にある内部 IP アドレス サブネットを隠す)、リモート ピアによってフローが開始されると、最初の戻りパケットに対して誤ったファイアウォール参照が行われます。

    たとえば、Edge の設定が次のようになっているとします。

    LAN-side NAT: [source] inside address: 10.0.2.25/32 outside address: 7.0.2.25/32 Static route: 7.0.2.25/32 [advertise] next hop: 10.0.2.1

    リモート クライアントが 10.0.1.25 から 7.0.2.25 に ping を送信すると、Edge で 2 件のファイアウォール ルール参照が発生します。最初の受信パケットでは 10.0.1.25 > 7.0.2.25 のファイアウォール参照が発生し、最初の戻りパケットでは 10.0.2.25 > 10.0.1.25 の非 NAT IP アドレスを使用したファイアウォール ルール参照が発生します。この 2 番目のファイアウォール ルール参照は実行されますがエラーとなります。

    この修正を適用しない場合、ユーザーはフローの最初の戻りパケットを許可するために追加のファイアウォール ルールを作成する必要があります。

  • 解決した問題 86617:BGP が設定されている Partner Gateway でループバック IP アドレスを使用しているカスタマー エンタープライズでは、ループバック IP アドレス ルートを使用する必要があるトラフィックがドロップされ、その結果、カスタマー トラフィックが中断することがあります。

    ループバック IP アドレス ルートが VMware SD-WAN Edge にありません。これは、Edge と Partner Gateway に BGP が設定され、ループバック IP アドレスが BGP 経由で Edge に送信されるが、Edge がループバック IP アドレス ルートを学習しないシナリオが原因です。

  • 解決した問題 86740:リモート診断の「インターフェイスの状態」を実行している場合、VMware SD-WAN Edge の SFP2 インターフェイスに展開されている GPON タイプの SFP モジュールは表示されません。

    この問題は、リモート診断バックエンド スクリプトに欠陥があり、Edge で実行されるときに Edge の SFP2 インターフェイスが適切に考慮されないために発生します。

  • 解決した問題 86808:一部の BGP ルートは、BGP フィルタに従う必要がない場合に広報されます(または、BGP ルートを広報する必要があるときに広報されません)。

    特定のルートマップ ルールの場合、Edge は、ルールの一致タイプに基づいて Edge のルーティングのプレフィックス リストまたはコミュニティ リストの設定を持つことができます。ただし、ルート マップの unapply 関数の場合、Edge は各ルールのプレフィックス リストとコミュニティ リストの両方を削除しようとしていますが、そのうちの 1 つは存在していないものです。

    以前は、存在しないプレフィックス リストやコミュニティ リストのコマンドは別の vtysh コマンドとして Edge のルーティング プロセスに送信され、最終的に操作が実行されないだけで、他のコマンドへの影響がなかったため、問題は発生しませんでした。当時は、ルートマップの unapply 関数をシンプルに保つために、これは意図的な呼び出しでした。

    ただし、問題 #84825 の修正の一環として、Edge は、複数のプレフィックス リスト/コミュニティ リストの削除 vtysh コマンドを Edge のルーティング プロセスにバッチ処理でまとめて送信するようになりました。その結果、存在しないプレフィックス リスト/コミュニティ リストを削除しようとすると、コマンド バッチ処理全体が失敗し、Edge のルーティング プロセス内の古いプレフィックス リスト/コミュニティ リストの設定で Edge がいっぱいになります。

    この問題が修正されていない Edge では、Edge サービスを再起動して、すべての BGP ルートが適切に広報されるようにする必要があります。

  • 解決した問題 87304:VMware SASE Orchestrator ユーザー インターフェイスを使用して VMware SD-WAN Edge で LAN インターフェイスを無効にしても、インターフェイスは SNMP によって「稼動中」として報告されます。

    インターフェイス出力の主要なデバッグ プロセスに、Edge LAN インターフェイス(GE1 や GE2 など)の物理ポートの詳細が含まれていません。その結果、SNMP がそれらのインターフェイスをポーリングすると、インターフェイスの設定に関係なく、稼動中という結果が常に返されます。

  • 解決した問題 87552:Edge 経由の Non SD-WAN Destination (NSD) を使用しているサイトで、Edge から NSD へのトンネルが不安定な場合、VMware SD-WAN Edge でデータプレーン サービスの障害が定期的に発生し、再起動することがあります。

    Edge から NSD へのトンネルが破棄されると、以前に選択したトンネルの誤った解放が実行され、Edge データプレーン サービスで例外がトリガされ、サービスをリストアするために再起動が必要になります。Edge サービスを再起動すると、カスタマーのトラフィックが 10 ~ 15 秒間中断します。

    Edge が修正なしでビルドを使用している場合、Edge 経由の NSD を 1 つの WAN リンクに制限すると、この問題が発生する可能性が低くなります。

  • 解決した問題 87612:1 つ以上の VLAN で VNF 挿入を使用する VMware SD-WAN Edge の場合、それらの VLAN のクライアント ユーザーは DHCP リレー サーバから IP アドレスを取得できません。

    Edge は DHCP リレー パケットを転送していないため、クライアント ユーザーは IP アドレスを受信しません。

    この修正を適用しない場合の唯一の回避策は、VLAN 上での VNF 挿入を無効にすることです。

  • 解決した問題 87982:プライベート PPPoE WAN リンクを備えた Metanoia タイプの SFP モジュールを使用している VMware SD-WAN Edge は、BGP ピアリングを確立して他のサイトに接続できない場合があります。

    プライベート PPPoE リンクを使用する VLAN タグ付きパケットが Edge によって破損し、その結果、宛先に到達しません。この問題は、パブリック PPPoE リンクには影響しません。

  • 解決した問題 88757:Orchestrator ユーザー インターフェイスで [リモート診断 (Remote Diagnostic)] > [ルート テーブル ダンプ (Route Table Dump)] を実行しているときにその試行がタイムアウトし、ページに結果が返されないことがあります。

    ルート テーブル ダンプ診断がタイムアウトするのは、ルートの数が多いサイトにおいてはすべてのルートを Orchestrator に配信するためのデバッグ コマンドにかかる時間が、WebSocket のタイムアウトである 30 秒を超えてしまうことがあるためです。ここでの修正は、ルート テーブル ダンプが確実に結果を返せるように、ルート ダンプ プロセスのタイムアウトを 30 秒未満に減らし、WebSocket がその前にタイムアウトしないようにするためのものです。

  • 解決した問題 88796:VMware SASE Orchestrator または VMware SD-WAN Gateway のいずれかを展開し、vSphere で OVA を使用すると、展開の一部として設定された OVF プロパティ(パスワード、ネットワーク情報など)がイメージに適用されず、展開後はシステムにアクセスできなくなります。

    これは、OVF/vApp プロパティを使用して(ISO ファイルを使用した場合ではなく)OVA から展開された新しいシステムにのみ影響します。この問題は、最近の更新での cloud-init へのアップストリームの変更が原因で発生します。

    Gateway でこの修正を適用しない場合の回避策は、オペレータが cloud-init ユーザーデータ ISO ファイルを使用してシステムを展開することです。

    注:

    このオープン チケットは Gateway ビルドにのみ適用されます。Orchestrator の問題は、リリース R5002-20220517-GA ビルド以降で修正されています。

  • 解決した問題 89217:6x0 モデル ライン(610、610N、610-LTE、620、620N、640、640N、680、680N)の VMware SD-WAN Edge が理由なく突然パワーオフすることがあります。

    6x0 Edge では、前方の状態 LED と後方のイーサネット ポート ライトの両方のすべてのライトがオフになり、Edge の電源を手動で入れ直すことによってのみリカバリできます。

    この問題は、v20M 以前の PIC ファームウェア バージョン(v20L、v20K、v20J)を使用する Edge 6x0 ライン専用の PIC マイクロコントローラに起因しています。この問題は、6x0 Edge が v20M 以前の PIC バージョンを使用している場合にのみ発生しますが、このバージョンでもパワーオフの問題が発生することはまれです(約 1/1,000)。この問題は、PIC ファームウェア バージョンが v20N 以降の 6x0 Edge では発生しません。

    注:

    5.x を使用する Orchestrator で PIC バージョンを含む 6x0 Edge のファームウェアを特定するには、その Edge の [監視 (Monitor)] > [Edge] > [概要 (Overview)] ページに移動し、Edge 情報、デバイス バージョン、デバイス ファームウェアを含む Edge 名の横にあるドロップダウン情報ボックスをクリックします。

    この問題は、6x0 Edge を PIC バージョン v20N を含むプラットフォーム ファームウェア 1.3.0 (R130-20220328-GA) にアップグレードすることで解決されます。これを行うには、6x0 Edge をリリース 5.x(5.0.0 以降)を使用する VMware SASE Orchestrator に接続し、6x0 Edge もリリース 5.x ビルドを使用している必要があります。次に、Edge のソフトウェア バージョンが変更されるのと同じ方法で、6x0 Edge プラットフォーム ファームウェアをバージョン 1.3.0 (R130-20220328-GA) に更新します。

    Orchestrator へのプラットフォーム ファームウェア バンドルのアップロードについては、『VMware SD-WAN オペレータ ガイド』の「新しい Orchestrator UI を使用したプラットフォーム ファームウェアと工場出荷時イメージ」セクションを参照してください。

    6x0 Edge のプラットフォーム ファームウェアの更新については、『VMware SD-WAN 管理ガイド』の「Edge 情報の表示または変更」セクションを参照してください。

    注:

    ユーザーが Edge を下位のソフトウェア リリース(たとえば、リリース 4.3.1 または 4.5.1)に保持することを希望する場合、カスタマーは一時的に Edge を 5.x ビルドにアップグレードし、バージョン 1.3.0 (R130-20220328-GA) へのプラットフォーム ファームウェアのアップグレードを実行して PIC バージョンを v20N にし、それから Edge のソフトウェアをユーザーが希望するバージョンにダウングレードすることができます。6x0 Edge のソフトウェアを以前のバージョンにダウングレードしても、Edge のプラットフォーム ファームウェアはダウングレードされず、Edge はプラットフォーム ファームウェア バージョン 1.3.0 (R130-20220328-GA) を引き続き使用します。このユースケースでは、リリース 5.x を使用している Orchestrator にカスタマーの Edge が配置されている必要があります。

    注:

    6x0 Edge がバージョン 5.x を使用していない Orchestrator 上に配置されていて、この問題が発生したために PIC ファームウェアの更新が必要な場合は、VMware SD-WAN サポートに問い合わせると、Edge の PIC バージョンを手動で更新してもらうことができます。

  • 解決した問題 90151:Gateway の BGP over IPsec では、プライマリ ネイバーとセカンダリ ネイバーに異なる BGP フィルタを適用したときに、想定どおりに動作しないことがあります。

    VMware SD-WAN Gateway のプライマリ ネイバーとセカンダリ ネイバーの Non SD-WAN Destination (NSD)-BGP に異なるフィルタが適用される場合でも、両方の BGP ネイバーに対して 1 つのフィルタのみが適用されます。

    この問題の原因は、Partner Gateway (PG)-BGP では SD-WAN サービスが enterprise_logical_idsegment_id の組み合わせを使用して BGP フィルタを識別しますが、特定のエンタープライズ/セグメントの組み合わせでは、SD-WAN は 1 つの PG-BGP ネイバーしか持つことができないため、Partner Gateway-BGP においては enterprise_logical_id を使用するだけで十分であったことです。

    しかしながら、同じエンタープライズ セグメントの組み合わせに対して最大 2 つの BGP ネイバー(プライマリとセカンダリ)が存在する可能性がある Gateway 上の NSD-BGP に対しては、この方法が継承されました。そのため、enterprise_logical_idsegment_id の組み合わせは、2 つの異なる NSD-BGP ネイバーのフィルタを区別するのに十分ではありません。

  • 解決した問題 90283:VMware SD-WAN Edge で使用されている WAN リンクでアンダーレイ アカウンティングがオンになっている場合、VoIP および videotelephony の通話でオーディオやビデオの品質が低下することがあります。

    ログを確認すると、トラフィックが非対称にルーティングされ、ルートの 1 つがアンダーレイを経由している場合、双方向トラフィックでパケットが確認されます。つまり、フローのルートが非対称で、トラフィックが一方向でアンダーレイ ルートを取得し、逆方向でオーバーレイ パスを使用する場合に、その WAN リンクに対してアンダーレイ アカウンティングがオンに切り替わると、双方向フローでパケット ロスが発生する可能性があります。これは通常 VoIP および videotelephony の通話で発生しますが、それらに限定されません。

  • 解決した問題 90876:LAN インターフェイスまたは Gateway IP アドレスのないルーティングされたサブインターフェイスのいずれかで VMware SD-WAN Edge に接続している 1 ホップ離れたクライアントの非グローバル セグメントでは、DNS が失敗します。

    この問題の原因は、1 ホップ離れたクライアントが使用している Edge インターフェイスのタイプによって異なります。

    • LAN ポートを介して Edge に接続している 1 ホップ離れたクライアントの場合、Edge が VCE1 インターフェイスを介してクライアントに応答パケットをルーティングし、Edge プロセスによってグローバル セグメントとして扱われるため、非グローバル セグメントの DNS 解決が失敗します。その結果、グローバル セグメント ルーティング テーブルでスタティック ルートが使用可能になり、応答パケットがドロップされます。

    • 1 ホップ離れたクライアントが、Orchestrator 上のクライアントに対するゲートウェイ IP アドレスとスタティック ルートを持たないルーティングされたサブインターフェイス ポートを介して Edge に接続されている場合、Edge にクライアントのルートがないため、クライアントの DNS 解決が失敗します。コネクト ルートを照合し、宛先 IP アドレス自体の ARP を送信すると、ARP が失敗し、応答は送信されません。

    この問題が修正されていない Edge の場合、Edge の LAN を使用するクライアントの回避策は、グローバル セグメントのみを使用することです。ルーティングされたサブインターフェイスを使用するクライアントの場合、回避策としてゲートウェイ IP アドレスを指定し、これが不可能な場合はグローバル セグメントのみを使用します。

  • 解決した問題 91875:VMware SD-WAN Edge で WAN リンクをバックアップとして設定したカスタマーの場合、リンクをアクティブにする条件が存在しない場合でも、バックアップ WAN リンクが断続的にアクティブになる場合があります。

    この問題は、Edge プロセスの競合状態が原因で発生します。Edge はバックアップ WAN リンクが必要であると誤って認識し、そのリンクのトンネルの構築を実行しますが、Edge には、この誤ったトンネルを検出して破棄するためのフェイルセーフがありません。

  • 解決した問題 93383:VMware SD-WAN Edge で 1 つ以上のデータプレーン サービスの障害が発生し、カスタマーのトラフィックが中断する可能性があります。

    この問題は、2 つの異なるデータ構造で Edge に格納されているインターフェイスの数がまれに一致しない場合に発生します。これにより例外がトリガされ、Edge サービスが 1 回以上失敗します。Edge サービスを再起動してリカバリする必要があります。そのため、非 HA 展開では、再起動ごとにカスタマーのトラフィックが 10 ~ 15 秒間中断します。ただし、Edge サービスが 3 回連続して失敗した場合、Edge をリカバリするには再起動または電源の入れ直しが必要になります。

Orchestrator で解決した問題

Orchestrator バージョン R5011-20221117-GA で解決した問題

Orchestrator ビルド R5011-20221117-GA は 2022 年 11 月 21 日にリリースされた、リリース 5.0.1 の 1 番目の Orchestrator ロールアップです。

この Orchestrator ロールアップ ビルドは、Orchestrator ビルド R5010-20220912-GA 以降の以下の重大な問題に対処します。

  • 解決した問題 80735:1 台以上の VMware SD-WAN Edge にも割り当てられているプロファイルの設定をユーザーが変更すると、プロファイル レベルで BGP フィルタが削除されます。

    VMware SASE Orchestrator ユーザー インターフェイスで、以前 BGP フィルタの詳細を確認した場所に「エラー: 無効なフィルタ参照 (ERR: invalid filter ref)」と表示されます。BGP に依存するカスタマーのネットワークへの影響は大きく、BGP フィルタをリストアする唯一の方法は手動でリストアすることです。

  • 解決した問題 88957:/30 サブネットを持つ VLAN のユーザー設定が実装されません。

    ユーザーが /30 サブネットを設定して VLAN に適用すると、Orchestrator は、正しい x.x.x.2 ではなく、x.x.x.1 の DCHP 開始範囲を自動的に設定します。ユーザーが DHCP 開始範囲を手動で .2 に戻してこの設定を手動で上書きした場合でも、設定がロードされるたびに、Orchestrator はその設定を .1 に戻します。

  • 解決した問題 97713:[監視 (Monitor)] > [ネットワーク サービス (Network Service)] > [Edge クラスタ (Edge Cluster)] テーブルに移動すると、VMware SASE Orchestrator ユーザー インターフェイスに Edge クラスタの健全性統計メトリックが表示されません。

    この問題は、クラスタ Edge が統計情報を Orchestrator にアップロードし、その間に Orchestrator が予期しない番号を送信するために発生します。Orchestrator は、すべての健全性統計情報をデータベースに保存するのではなく破棄します。

  • 解決した問題 98086:IT スペシャリスト、カスタマー サポート、またはエンタープライズのロールを持つパートナー管理者は、VMware SASE Orchestrator ユーザー インターフェイスでパスの統計情報を表示できません。

    Orchestrator は、これらのパートナー管理者ロールに権限を提供しません。これらのユーザーは、[パス統計情報 (Path Stats)] タブのグラフやメトリックを表示することはできません。

  • 解決した問題 98357:ユーザーが既存のロールに増分 ALLOW 権限を追加しようとすると、エラーが発生して失敗します。

    ユーザーが 5.x Orchestrator でカスタマイズ パッケージを編集してパス統計情報の表示などのアクションに対する ALLOW 権限を追加しようとすると、カスタマイズ パッケージが Orchestrator によって拒否されます。

    この問題は、API バリデータが拒否権限のみを処理し、許可権限をまったく処理しないことが原因で発生します。

  • 解決した問題 98518:カスタマーが割り当てられていない Gateway プールから VMware SD-WAN Gateway を削除すると、Partner Gateway を使用しているカスタマーは、パートナー ハンドオフ設定が複数の Gateway に対しても削除されていることを確認できます。

    Gateway が Gateway プールから削除されると、Orchestrator はハンドオフを確認し、一部のハンドオフを、使用中であっても使用中でないと誤って表示します。これにより、使用中のハンドオフ設定がないことが誤って認識されるため、Orchestrator はその Gateway のハンドオフ設定を解除して上書きします。

  • 解決した問題 98654:VMware SASE Orchestrator がリリース 5.0.0.0 以降にアップグレードされ、VMware SD-WAN Edge が [証明書が必要 (Certificate Required)] モードに設定されている場合、証明書の更新後に Edge は Orchestrator との通信を失い、「ダウン」とマークされることがあります。

    Orchestrator リリース 5.0.0.0 では、[証明書が必要 (Certificate Required)] として設定された Edge のクライアント証明書の拡張キーの使用法を検証する新しい機能が導入されました。この検証プロセスでは、有効な証明書を誤って無効として扱われ、ハートビートが失敗する原因となる不具合が含まれていました。

  • 解決した問題 99109:VMware SASE Orchestrator が 5.0.0 以降にアップグレードされると、既存の Zscaler 展開を使用するカスタマー エンタープライズのユーザーは、Zscaler 設定を変更することができず、「クラウド サブスクリプションを null にすることはできません。クラウド名と一致する必要があります (Cloud Subscription cannot be null and should match Cloud Name)」というエラーが発生します。

    Orchestrator リリース 5.0.0 では、Zscaler などの新しいクラウド サービスを設定するユーザー向けに新しい「クラウド サブスクリプションの設定」プロセスが導入されています。この追加メカニズムの一部として、Orchestrator をリリース 5.0.0/5.0.1 にアップグレードすると、既存の展開が Orchestrator によって検出され、クラウド サブスクリプションに自動的に移行されることが期待されていました。しかしこの問題により、それらは実行されず、カスタマー ユーザーは新しい「クラウド サブスクリプションの設定」方法を使用して Zscaler の各 Edge を手動で設定し、既存の Zscaler 設定を変更する必要がありました。

  • 解決した問題 99247:Zscaler クラウド セキュリティ サービス (CSS) を使用しているカスタマー エンタープライズで、ユーザーが CSS を使用してトラフィックをバックホールするビジネス ポリシーを設定している場合、VMware SASE Orchestrator がリリース 5.0.0/5.0.1 にアップグレードされると、カスタマーは VMware SD-WAN Edge で CSS 設定を変更できませんでした。

    [設定 (Configure)] > [Edge] > [デバイス設定 (Device Settings)] を確認すると、[クラウド サブスクリプション (Cloud Subscription)] がロックされ、[なし (None)] が選択されています。設定を変更しようとすると、「クラウド サブスクリプションを [なし] に変更することはできません (Cloud Subscription cannot be NONE)」というエラーが返されます。また、ユーザーは、最初にバックホール ビジネス ポリシーを検出しないとクラウド サブスクリプションを選択できません。

  • 解決した問題 99250:VMware SD-WAN Edge の CPU コア温度が、VMware SASE Orchestrator で適切にグラフ化されません。

    [監視 (Monitor)] > [Edge] > [システム (System)] タブに移動すると、[CPU コア温度 (CPU Core Temperature)] は常に [0°] と表示されています。

    Edge は正しい CPU コア温度を Orchestrator に報告していますが、フォーマットの問題により数値が破棄され、データがない場合、Orchestrator はデフォルト値の 0 を表示します。

  • 解決した問題 100656:VMware SASE Orchestrator ユーザー インターフェイスで [監視 (Monitor)] > [Edge] > [QoE] に移動すると、Edge の QoE グラフに大きなギャップが生じていることを確認できます。

    この問題は、15 分間のクエリ期間内に QoE データが検出されない場合、バックフィル機能で VMware SASE Orchestrator がエラー状態になるために発生します。

  • 解決した問題 101449:リリース 4.3.x 以降を使用して VMware SD-WAN Edge で 32 を超えるサブインターフェイスを設定すると、Orchestrator でエラーが発生し、設定が適用されなくなります。

    この制限は、4.3.x 以前のリリース(4.2.2 や 3.4.6 など)を実行している Edge を持つカスタマー エンタープライズを保護する目的で設計されており、32 を超えるサブインターフェイスはサポートされません。この変更により、Orchestrator は 32 を超えるサブインターフェイスの設定を許可しますが、Edge がリリース 4.3.0 以降を使用している場合のみそのような設定を行うようカスタマーに対して警告します。

Orchestrator バージョン R5010-20220912-GA で解決した問題

Orchestrator バージョン R5010-20220912-GA は 2022 年 9 月 13 日にリリースされた、リリース 5.0.1 の更新された Orchestrator GA ビルドです。

更新された R5010-20220912-GA Orchestrator ビルドは、Orchestrator ビルド R5010-20220817 以降の以下の問題を解決します。

  • 解決した問題 96108:VMware SASE Orchestrator を 5.x ビルドにアップグレードすると、ユーザー インターフェイスの [監視 (Monitor)] > [Edge] ページで、VMware SD-WAN Edge のメモリ使用率の統計情報が表示されないことがあります。

    この問題は、5.x Orchestrator への移行中に、Orchestrator が現在の名前 (memoryPct) を使用して Edge の過去の健全性統計のメモリ フィールドを受信することを期待しているときに、古い Edge が健全性統計のメモリ フィールドに別の名前 (memPct) を送信することによって発生します。その結果、Orchestrator は予期しない名前 memPct で送信された Edge の健全性統計のメモリ フィールド値を無視し、デフォルトで健全性統計のメモリ フィールド値をゼロに設定します。

    この問題に対する修正により、Orchestrator ユーザー インターフェイスで Edge の健全性統計が欠落するその他の原因が解決されます。最初の原因は元の 5.0.1 GA ビルドの #90749 で修正されています。

  • 解決した問題 96095:VMware SASE Orchestrator がディザスタ リカバリ (DR) 用に設定されている場合、すべてのオペレータ プロファイルから IPv6 Orchestrator の IP アドレスがクリアされ、IPv6 のみの SD-WAN Edge が Orchestrator によって「ダウン」とマークされます。

    オペレータ プロファイルが IPv4 と IPv6 の両方のタイプの Orchestrator IP アドレスで設定されている場合、IPv4 アドレスのみを使用して DR を設定すると、IPv6 アドレスは Orchestrator のオペレータ プロファイルから削除されます。これにより、IPv6 のみの Edge は Orchestrator との通信を停止します。その結果、これらの Edge は「ダウン」とマークされ、設定変更のプッシュが停止します。

    修正が適用されていない Orchestrator でこの問題が発生する場合は、アップグレード後に DR を破棄し、管理 IP アドレスをリストアするためにもう一度設定する必要があります。

  • 解決した問題 95847:VMware SASE Orchestrator をバージョン 5.0.1 にアップグレードすると、スキーマのアップグレードが成功しない場合があり、アップグレードを実行するオペレータは手動で再実行する必要があります。

    Orchestrator が新しい ClickHouse スキーマを持つバージョンにアップグレードされると、バックエンドで競合状態が発生する可能性があり、古いスキーマ バージョンがアップグレード前に起動せず、準備が完了しません。その結果、オペレータはスキーマのアップグレードを手動で再実行する必要があります。

Orchestrator バージョン R5010-20220817-GA で解決した問題

Orchestrator バージョン R5010-20220817-GA は 2022 年 8 月 17 日にリリースされた、リリース 5.0.1 の更新された Orchestrator GA ビルドです。

この Orchestrator ビルドは、問題 #95613 を含む元の GA ビルド R5010-20220803-GA に代わるものです。この問題は、このビルドが 2022 年 8 月 5 日にリリースされた後の Orchestrator のアップグレード中に検出されました。カスタマーは R5010-20220817-GA ビルドのみを使用し、R5010-20220803-GA を使用しないでください。

  • 解決した問題 95613:VMware SASE Orchestrator をビルド R5010-20220803-GA にアップグレードすると、その Orchestrator に接続しているカスタマーが Edge を監視できなくなり、API 呼び出しを使用している場合はそれらの呼び出しに失敗することがあります。オペレータ ユーザーの場合、API プロセスが失敗し、Orchestrator の CPU 使用率が高い状態で再起動が必要になります。

    この問題は、ユーザーが時間間隔のずれなしで API 呼び出しを実行する(つまり、各 API 呼び出しの直後に別の呼び出しが実行される)ようにエンタープライズを設定している場合にトリガされます。このアクティビティにより、API 呼び出しを処理する v2 API プロセスが API 要求を受信するときに、例外が発生して失敗します。v2 API プロセスが失敗すると、リンク統計情報(API 呼び出しに依存)などのデータを監視している Edge が正確なデータを表示せず、API 呼び出しを使用しているカスタマー エンタープライズも失敗します。さらに、同じエンタープライズが時間間隔のずれなしで API 呼び出しを実行し続ける場合、それらの API 呼び出しを停止または変更して時間間隔を含めるまで、v2 API プロセスは失敗と再起動を繰り返し、実質的には停止した状態となります。 

    また、v2 API プロセスの失敗と再起動によって Orchestrator の CPU 使用率が高くなり、API 呼び出しの処理を超えて Orchestrator の全体的なパフォーマンスに影響します。

Orchestrator バージョン R5010-20220803-GA で解決した問題

Orchestrator バージョン R5010-20220803-GA は 2022 年 8 月 5 日にリリースされ、Orchestrator バージョン 5002-20220517-GA 以降の以下の問題を解決しました。つまり、5.0.0 リリース ノートに記載されている Edge または Gateway の問題に対する修正は、すべてのリリース 5.0.1 ビルドに含まれています。

  • 解決した問題 49535:[監視 (Monitor)] > [ネットワーク サービス (Network Services)] ページで、VMware SASE Orchestrator がオフラインになった VMware SD-WAN Edge の BGP ネイバー状態をすぐに更新しません。

    [Edge の BGP ネイバー状態 (BGP Edge Neighbor State)] テーブルにはオフライン Edge が「確立済み」と表示され続け、Edge がオフラインになってから数時間続きます。これは、Orchestrator ユーザー インターフェイスを使用してこれらの詳細を確認するユーザーに影響します。

  • 解決した問題 68463:VMware SASE Orchestrator の [監視 (Monitor)] > [QoE グラフ (QoE graph)] で、グラフ セクションが品質に関して「黄色/普通」と表示されている場合、クラシック ユーザー インターフェイスと新しいユーザー インターフェイスの間で、グラフ セクションが「黄色/普通」と表示される理由が一致しない場合があります。

    この問題が発生した場合、クラシック ユーザー インターフェイスのポップアップ ボックスに「普通」QoE スコアの理由として「遅延」と表示され、新しいユーザー インターフェイスのポップアップ ボックスには、「普通」QoE スコアの理由として「ジッター」と表示されます。この問題は、新しいユーザー インターフェイスで「遅延」と「ジッター」の値が正しくマッピングされていないことが原因です。

  • 解決した問題 70005:VMware Cloud Web Security を使用する場合に、ユーザーは既存のセキュリティ ポリシーを編集し、空または空白の名前に変更して、VMware SASE Orchestrator に保存できます。

    ユーザーが空/空白の名前でセキュリティ ポリシーを作成することはできませんが、既存のポリシーを編集して名前を空白に設定することが可能です。Orchestrator ではそのような変更が許可され、エラーをスローしません。

  • 解決した問題 76036:VMware SASE Orchestrator で、パートナーの [パートナーの概要 (Partner Overview)] ページまたは [設定 (Configure)] > [カスタマー (Customer)] ページにアクセスしようとすると、「予期しないエラーが発生しました」というメッセージが表示されて、ページの読み込みに失敗します。

    enterpriseProxy /getEnterpriseProxyGatewayPools API がタイムアウトするため、そのパートナーによってサポートされているカスタマーの [パートナーの概要 (Partner Overview)] ページや [設定 (Configure)] > [カスタマー (Customer)] ページの読み込みに失敗することがあります。これらのページが読み込まれないトリガは、多数の Gateway プールと Gateway が含まれている場合です。これにより、ページで使用される enterpriseProxy /getEnterpriseProxyGatewayPools API がタイムアウトになり、各ユーザー インターフェイス ページでのページの読み込みの問題が発生する可能性があります。

  • 解決した問題 76036:VMware SASE Orchestrator で、パートナーの [パートナーの概要 (Partner Overview)] ページまたは [設定 (Configure)] > [カスタマー (Customer)] ページにアクセスしようとすると、「予期しないエラーが発生しました」というメッセージが表示されて、ページの読み込みに失敗します。

    enterpriseProxy /getEnterpriseProxyGatewayPools API がタイムアウトするため、そのパートナーによってサポートされているカスタマーの [パートナーの概要 (Partner Overview)] ページや [設定 (Configure)] > [カスタマー (Customer)] ページの読み込みに失敗することがあります。これらのページが読み込まれないトリガは、多数の Gateway プールと Gateway が含まれている場合です。これにより、ページで使用される enterpriseProxy /getEnterpriseProxyGatewayPools API がタイムアウトになり、各ユーザー インターフェイス ページでのページの読み込みの問題が発生する可能性があります。

  • 解決した問題 81835:VMware SASE Orchestrator ユーザー インターフェイスの [監視 (Monitor)] > [Edge] > [QoE] ページで、WAN リンクの状態([オンライン (Online)]、[オフライン (Offline)]、[劣化 (Degraded)] など)が正確に表示されない、または選択した期間のリンク メトリックが正確に表示されない場合があります。

    時間間隔が異なると、QoE グラフに表示される WAN リンク状態の結果が異なることがあります。また、リンクのメトリックの場合、QoE グラフには特定の QoE 値(遅延、ロス、ジッター)が表示され、その正確な時間の実際のメトリック値が反映されない場合があります。

    この問題は、異なるエンタープライズに属する複数の WAN リンクに同じリンクの論理 ID が割り当てられていることが原因で発生し、Orchestrator のリンク データ バックフィル プロセスが正常に機能しなくなります。Orchestrator は、WAN リンクの論理 ID がカスタマーのエンタープライズ ID に関連付けられていないため、誤って一意であると見なします。これにより、リンクの論理 ID が重複し、リンクのメトリックと状態が正しく表示されない可能性があります。

    この問題の修正により、リンク キーは Orchestrator のデータベースにカスタマー エンタープライズの論理 ID と WAN リンクの論理 ID の組み合わせとして格納され、各 WAN リンクが一意になります。

  • 解決した問題 82725:VMware SASE Orchestrator でパスワード リセット リンクが正しく生成されないことがあります。

    この問題は、Orchestrator の URL が正確に https://domain/ または https://domain/operator/ でない場合に発生します。ただし、たとえば URL が https://domain/test/ の場合、パスワードのリセット リンクは機能せず、ログイン ページに戻ります。

    修正を適用しない Orchestrator でこの問題が発生したときに、Orchestrator URL を上記のような URL に修正できない場合は、スーパー ユーザーまたはオペレータがユーザーの新しいパスワードを手動で入力し、影響を受けるユーザーと共有して、ユーザーが正常にログイン後に別のパスワードを再設定できるようにするしか方法はありません。

  • 解決した問題 82775:リリース 5.0.0 を使用している VMware SASE Orchestrator で、カスタマーに Zscaler タイプのクラウド セキュリティ サービス (CSS) が設定され、VMware SD-WAN Edge に関連付けられ、さらにビジネス ポリシーに CSS バックホール ルールが設定されている場合、ユーザーはその CSS の CSS ハッシュまたは暗号化パラメータを変更できません。

    Zscaler CSS 設定が CSS バックホール ビジネス ポリシーに関連付けられると、Orchestrator はユーザーがその設定を変更できないようにします。

    この問題が修正されていない Orchestrator では、ユーザーは、CSS バックホール ビジネス ポリシーを削除して Zscaler CSS 設定を変更し、同じビジネス ポリシーを再作成する必要があります。

  • 解決した問題 82864:リリース 5.0.0 を使用している VMware SASE Orchestrator で、ユーザーが [設定 (Configure)] > [プロファイル (Profiles)] ページで [変更 (Modify)] を選択すると、ユーザーは [プロファイル (Profiles)] > [デバイス設定 (Device Setting)] ページではなく、[プロファイル (Profiles)] >[概要 (Overview)] ページにリダイレクトされます。

    [設定 (Configure)] > [プロファイル (Profiles)] の [変更 (Modify)] ボタンが正しいページにマッピングされていません。

  • 解決した問題 83165:VMware SASE Orchestrator で、カスタマーとパートナーの両者が同じ Gateway プールを持っているのにもかかわらず、同じ Gateway プールを持っていないと見なされてしまい、オペレータ ユーザーはそのカスタマーをパートナーに転送することができません。

    これは、API 呼び出し network/getNetworkEnterpriseProxies が Gateway プールの詳細を返さないため、Orchestrator がパートナーとカスタマーが同じ Gateway プールを持っていないものと想定し、割り当てを拒否してしまうことが原因で発生します。

  • 解決した問題 83538:カスタマーが Secure Access サービスを使用している場合、リモート アクセス サービスを作成するときに、[エンタープライズとネットワークの設定 (Enterprise & Network Settings)] 画面に VMware SASE Orchestrator の内部エラー メッセージ キーが表示されます。

    リモート アクセス サービスを作成するときに、ユーザーが [カスタマー サブネット (Customer Subnet)] または [サブネット ビット (Subnet Bits)] フィールドに無効なデータを入力した場合、これらのフィールドの下に未変換のエラー メッセージが表示されます。このエラー メッセージはユーザーにとって意味がなく、フィールドの無効なデータに関する実際の問題の解決方法を説明したものではありません。

  • 解決した問題 83539:ディザスタ リカバリ (DR) 設定で展開された VMware SASE Orchestrator で、Orchestrator を新しいソフトウェア バージョンにアップグレードすると、DR 同期が失敗します。

    アップグレード前は DR が適切に実行されていますが、オペレータ ユーザーがアクティブおよびスタンバイ Orchestrator をアップグレードすると、DR の状態は失敗と表示されます。

  • 解決した問題 83582:VMware SASE Orchestrator をリリース 4.5.0 からリリース 5.0.0 にアップグレードすると、プロセスに予想以上の時間がかかり、プロセスが完了するまですべての Orchestrator サービスを使用できません。

    代わりに LRQ スキーマを更新する必要がある場合、アップグレード中に Edge 統計情報テーブルが更新されるまで、スキーマの更新に 15 分以上かかることがあります。これにより、Orchestrator の更新が完了するまでに大きな遅延が発生します。

  • 解決した問題 83822:カスタマーが VMware Cloud Web Security を使用している場合、VMware SASE Orchestrator の [監視 (Monitor)] > [ログ (Logs)] > [Web ログ (Web Logs)] を選択すると、最大で 100 件のログしか表示されず、追加のログを表示するためのページをロードすることができません。

    この問題では、Orchestrator ユーザー インターフェイスの Web ログのページネーションが破損しているため、ユーザーは単一のページで最大 100 件のログを使用した状態のままとなり、それ以上のログを表示することができません。これは、ユーザーが長い期間(たとえば 30 日間)にわたるログをロードしようとしても、その期間のすべてのログを表示できないことを意味し、ユーザーにとって大きな障害となります。唯一の回避策は、返されるログの数が 100 以下になるように短い期間をロードすることです。 

  • 解決した問題 84152:カスタマーがエンタープライズのトップ利用者レポートを生成するときに、トップ利用者名が「不明」と表示されることがあります。

    「トップ利用者」とは、指定された時間範囲内のすべてのフローのトップ送信元のことです。(送信元 IP アドレス + MAC アドレス)の一意のペアにクライアント デバイスが存在しない場合、トップ利用者名が表示されないことがあります。これは、VMware SD-WAN Edge に設定されている可視性モード(IP アドレスまたは MAC アドレス)に基づいてクライアント デバイスが保存されるためです。たとえば、Orchestrator が(IP アドレス 1、MAC アドレス 1)のデバイスを保存し、可視性モードが IP アドレスに設定されている場合、(IP アドレス 2、MAC アドレス 2)レコードが保存されないことがあります。これにより、IP アドレス 2/MAC アドレス 2 に対応するトップ利用者が「不明」とマークされます。

  • 解決した問題 84214:オペレータ ユーザーが VMware SASE Orchestrator ユーザー インターフェイスの [ゲートウェイ (Gateways)] ページを開いている場合、Super Gateway のロールに特定の Gateway を割り当てることができない場合があります。

    Gateway にすでに Super Gateway と代替 Super Gateway の両方のロールが割り当てられており、オペレータが [Gateway (Gateways)] > [Gateway の設定 (Configure Gateways)] 画面の [カスタマー使用状況 (Customer Usage)] リストでエンタープライズの Super Gateway の割り当てを編集しようとすると、ユーザー インターフェイスで Super Gateway についての関連データが正しく検出されず、[Super Gateway の割り当て (Assign Super Gateway)] ダイアログが表示されず、コンソールにエラーが表示されます。 

  • 解決した問題 84969:4.2.x リリースを実行している VMware SD-WAN Edge が、オーバーライドされたデフォルト以外の管理 IP アドレスを使用して設定されている場合、4.3.x 以降を実行している VMware SD-WAN Orchestrator でリリース 4.3.x 以降にアップグレードされると、Edge は設定されたオーバーライド済みの管理 IP アドレスを失う場合があります。

    4.3.x 以降を実行している Orchestrator は、Edge を 4.2.x から 4.3.x 以降のビルドにアップグレードするときにループバック インターフェイスを自動的に作成せず、Edge に対して上書きされたデフォルト以外の管理 IP アドレスも保持しません。

  • 解決した問題 86546:カスタマーが VMware Secure Access を使用している場合に、一部の SASE PoP で Secure Access を使用できない可能性があります。また、VMware SASE Orchestrator 上でオフラインとして表示されることもあります。

    Secure Access で使用するように設定されていない VMware Gateway(つまり、PoP 上のトンネル サーバとの Geneve トンネルを持たない Gateway)には、Orchestrator によって Secure Access サービスに関する情報も提供されます。これにより、カスタマー トラフィックをルーティングするための一部のインスタンスで破損したルートが選択されます。この問題は、特定の Orchestrator の Gateway プールごとに、PoP あたり複数の Gateway が 割り当てられている場合にのみ発生します。

    この問題に対する修正がない Orchestrator では、回避策として、Gateway プールごとに PoP あたり 1 つの Gateway のみを追加して保持し、この Gateway が常に Secure Access 用に選択され、正しいルートが確立されるようにします。

  • 解決した問題 86848:カスタマー管理者がネイティブ(ユーザー名/パスワード)の方法を使用した VMware SASE Orchestrator のカスタマー エンタープライズへのログインに失敗すると、Orchestrator はユーザー インターフェイスの [監視 (Monitor)] > [イベント (Events)] ページに失敗した試行のログを記録しません。

    Orchestrator は、すべてのユーザー アカウントの適切な責任を果たすため、およびすべての管理者が通常とは異なるログイン アクティビティを検出できるように、すべてのログイン試行のログを、成功したかどうかに関係なく記録する必要があります。この問題は、Orchestrator が enterpriseId メタデータを失敗したユーザー名/パスワード認証の試行に含めなかったために発生します。これは、ネイティブ(ユーザー名/パスワード)の認証を使用しているカスタマー ユーザーにのみ影響し、シングル サインオン (SSO) を使用しているカスタマー エンタープライズはこの問題の影響を受けません。

  • 解決した問題 87111:VMware SASE Orchestrator を 4.3.x 以降にアップグレードすると、BGP を使用するように設定された Orchestrator に接続されている VMware SD-WAN Edge にアップリンク フラグが設定されません。

    BGP アップリンク フラグは、SD-WAN 4.3.0 リリースおよび Edge バージョン 4.3.0 以降の設定として追加され、アップリンク フラグが存在することを想定しています。ただし、Orchestrator のアップグレード後に、このフラグが設定されていないすべての Edge に設定の更新をプッシュするわけではありません。

  • 解決した問題 88621:移行中の VMware SD-WAN Gateway の設定を変更して、VMware SASE Orchestrator に保存することはできません。

    オペレータ ユーザーは、設定を保存しようとすると Orchestrator がエラーを返すため、本番 Gateway の場所を更新できません。 GATEWAY_SERVICE_STATE_INVALID: Cannot change the state of the gateway to null, as it is already used as a replacement gateway.

  • 解決した問題 89346:ビルド 5.0.0.2 を使用している VMware SASE Orchestrator で、[カスタマーの監視 (Monitor Customers)] 画面から新規レポートを生成すると、レポートの言語が英語以外の言語として指定されていても、新しく生成されたレポートは常に英語で配信されます。

    ダウンロードしたレポートは、[レポートの言語 (Report Language)] で指定された言語で表示される必要がありますが、使用される言語は常に英語です。

  • 解決した問題 89800:ユーザーが VMware SASE Orchestrator のセグメント プロパティを更新すると、Edge から Zscaler クラウド セキュリティ サービス (CSS) へのトンネルがダウンし、Zscaler にルーティングされたトラフィックがドロップされます。

    ユーザーが [設定 (Configure)] > [ネットワーク サービス(任意の CSS タイプ) (Network Service (any CSS type))] で CSS を設定し、[Edge 固有のルール (Edge Override)] を使用して [設定 (Configure)] > [Edge] > [デバイス (Device)] > [クラウド セキュリティ サービス (Cloud Security Service)] で FQDN と PSK 認証の詳細を設定する場合、ユーザーが Orchestrator の [設定 (Configure)] > [セグメント (Segment)] セクションでセグメントを更新すると、Edge の CSS 認証設定が削除され、Edge は Zscaler ピアに接続できなくなります。

  • 解決した問題 90128:クラウド セキュリティ サービス (CSS) が設定されているカスタマー エンタープライズで、ユーザーが CSS 設定を変更すると、CSS イベントには CSS の PSK キーが含まれます。

    この動作は直接的な脆弱性をもたらすことはありませんが、CSS PSK の値は機密情報であり、ログ ファイルに含めてはいけません。

  • 解決した問題 90540:リリース 5.0.0 を使用している VMware SASE Orchestrator で、Edge リリース 4.5.1 を使用している VMware SD-WAN Edge をリリース 5.0.0 にアップグレードすると、Edge の DNS 機能が失われ、インターネットとの接続が失われます。

    5.0.0 への Edge アップグレードの一環として、Orchestrator のロールは更新された Edge 設定をプッシュすることです。その設定の DNS 部分は 4.5.x Edge ビルドと互換性がないため、DNS 設定が失われ、インターネットへの接続が妨げられました。Edge は、DNS が問題の要因とならない他の場所(Orchestrator、他の Edge、ハブ Edge、Non SD-WAN Destination など)に引き続きトラフィックを渡します。

  • 解決した問題 90067:VMware SASE Orchestrator を 4.5.1 または 5.0.0 にアップグレードすると、オペレータの CPU 使用率が高くなり、負荷の問題が発生することがあります。

    アップグレード中に、Orchestrator は重要なシステム プロパティ edge.learnedRoute.maxRoutePerCall を失います。このプロパティは、Orchestrator が一度に受信できるルーティング プロトコル イベントの数に上限を設定します。このプロパティがない場合、Orchestrator にルーティング プロトコル イベントが大量に発生して高負荷の状態になり、Orchestrator のパフォーマンスに影響を与える可能性があります。この修正により、Orchestrator のアップグレード後もシステム プロパティ edge.learnedRoute.maxRoutePerCall が保持されるようになります。

  • 解決した問題 90749:VMware SASE Orchestrator を 5.x ビルドにアップグレードすると、ユーザー インターフェイスの [監視 (Monitor)] > [Edge] ページで、1 台以上の VMware SD-WAN Edge の履歴統計情報が失われることがあります。

    Orchestrator のログで、Orchestrator を 5.x ビルドにアップグレードした直後のタイムスタンプ付きのログ メッセージ「健全性統計情報の移行中にエラーが発生しました (Error while migrating health stats)」および「ClickHouse へのデータ ファイルの書き込み中にエラーが発生しました (Error while writing data file to clickhouse)」が表示されます。この問題は、Orchestrator のアップグレード中に Edge が無効なデータ(負の数の無効なトンネル数など)を Orchestrator に送信し、その結果 Orchestrator が無効なデータだけでなく特定の Edge の履歴データ バッチ全体を拒否するためにトリガされます。その結果、Orchestrator のアップグレード後に [監視 (Monitor)] > [Edge] ページを確認すると、その Edge のグラフに大きな履歴時間のギャップが生じています。この問題は、Orchestrator に接続されているすべての Edge に同じように影響するわけではありません。影響されるのは無効なデータを送信する一部の Edge のみです。

    注:

    関連する問題 #96108 でも Edge 健全性統計情報の欠落が発生しますが、これは Orchestrator ビルド R5010-20220912-GA で修正されました。

  • 解決した問題 90835:カスタマーが VMware Cloud Web Security サービスを使用している場合、ユーザーは VMware SASE Orchestrator を使用して Cloud Web Security の Web プロキシに対する Office 365 ドメイン ルールを設定することができません。

    ユーザーは、PAC ファイル ウィザードを使用して Cloud Web Security の Web プロキシに対する Office 365(最近 Microsoft 365 に名前変更)ドメイン ルールを設定することができません。

  • 解決した問題 91054:VMware Cloud Web Security を使用しているカスタマーの場合、ユーザーがシングル サインオン認証を設定しようとすると、VMware SASE Orchestrator ユーザー インターフェイスで複数のユーザビリティの問題が発生する場合があります。

    Cloud Web Security サービスでユーザーがシングル サインオンを設定するときに発生する可能性のある問題は次のとおりです。

    • [証明書 (Certificate)] ページではなくメインの [認証 (Authentication)] ページに証明書エラーが表示される。•無効な証明書を保存できる場合がある。•証明書を変更すると、認証フォームの他の値がリセットされることがある。•個々のフィールドに、検証メッセージがインラインで表示されない。•[認証 (Authentication)] ページを保存すると、Orchestrator ユーザー インターフェイスに進行状況のスピナーが表示されない。•[詳細デバッグ (Verbose Debugging)] ツールチップに、実際の時刻ではなく「t+2hrs」と表示される。•一部の言語で、[シングル サインオン (Single Sign-On)] トグル ラベルが複数の行にラップされる。•[変更の保存 (Save Changes)] フッター レイアウトが短い画面で正しく表示されない。

    上記のすべての問題は、#91054 の修正を含む Orchestrator で解決されています。

  • 解決した問題 91179:WAN リンクがホット スタンバイとして設定されている VMware SD-WAN Edge では、ホット スタンバイ リンクの状態がスタンバイの場合に、VMware SASE Orchestrator の新しいユーザー インターフェイスにホット スタンバイ リンクの間違った状態(「アクティブ」)が表示されます。

    Orchestrator のクラシック ユーザー インターフェイスには、リンクの正しい状態(「アイドル」)が表示されるため、これは新しいユーザー インターフェイスに限定される問題です。この問題は、ホット スタンバイ WAN リンクの状態変更時に新しいユーザー インターフェイスが正しい更新を取得しないことが原因で発生します。 

  • 解決した問題 91720:ハブ/スポーク トポロジを使用するカスタマー エンタープライズの場合、ユーザーは、そのハブがインターネット バックホールを使用するように設定されたビジネス ポリシーで使用されている場合でも、バックホール ハブ設定から VMware SD-WAN ハブ Edge を削除できます。

    ハブ Edge を介してスポーク Edge トラフィックをバックホールするためのビジネス ポリシーが設定されると、VMware SASE Orchestrator はそのハブ Edge を「ロック」し、ユーザーによって [設定 (Configure)] > [デバイス設定 (Device Settings)] セクションのバックホール ハブ設定から削除されないようにすることが想定されます。しかしこの問題により、ユーザーがハブ Edge を削除できるため、カスタマー トラフィックの重大な中断が発生する可能性があります。 

  • 解決した問題 92082:VMware Cloud Web Security を使用しているカスタマーの場合、設定されたドメインがコンテンツ フィルタリング ルールで考慮されないことがあります。

    コンテンツ フィルタリング ルールは、ユーザーが [カテゴリ (Categories)] で [すべて (ALL)] も選択している場合、設定済みのドメインを上書きします。または、ユーザーが [カテゴリ (Categories)] に [なし (NONE)] を選択した場合、ウィザードはデフォルトでこの選択を「すべてのカテゴリ」と解釈するので、ここでもドメインは同様に考慮されませんでした。これは、コンテンツ フィルタリング ウィザードと API の問題が原因で発生します。ユーザーが 1 つ以上のカテゴリを設定すると、ドメインが考慮されます。

    この修正が適用されていない Orchestrator では、ユーザーはドメインと一緒に特定のカテゴリを設定する必要があり、その後、Orchestrator はコンテンツ フィルタリングでドメインを考慮します。

既知の問題

リリース 5.0.1 での未解決の問題

Edge および Gateway の既知の問題

  • 問題 14655:

    SFP アダプタを接続または取り外すと、Edge 540、Edge 840、Edge 1000 でデバイスが応答を停止し、物理的な再起動が必要になる場合があります。

    回避策:Edge を物理的に再起動する必要があります。これは、Orchestrator で [リモート アクション (Remote Actions)] > [Edge の再起動 (Reboot Edge)] を使用するか、Edge の電源を入れ直すことで実行できます。

  • 問題 25504:

    コストが 255 より大きいスタティック ルートで、ルートの順序設定が予期しない結果になる可能性があります。

    回避策:0 と 255 の間のルート コストを使用します。

  • 問題 25595:

    WAN オーバーレイ上の静的 SLA への変更を適切に機能させるために、再起動が必要になる場合があります。

    回避策:WAN オーバーレイからの静的 SLA の追加と削除後、Edge を再起動します。

  • 問題 25742:

    VMware SD-WAN Gateway に対する最大容量が Gateway に接続されていないプライベート WAN リンクの容量よりも少ない場合でも、アンダーレイが考慮されたトラフィックの上限がこの最大容量に制限されます。

  • 問題 25758:

    USB WAN リンクが、ある USB ポートから別の USB ポートにスイッチされると、VMware SD-WAN Edge が再起動されるまで、正常に更新されない場合があります。

    回避策:1 つのポートから別のポートに USB WAN リンクを移動した後に Edge を再起動します。

  • 問題 25855:

    Partner Gateway(200 BGP が設定された VRF など)で大規模な設定の更新があると、VMware SD-WAN Gateway を経由する一部のトラフィックで約 2 ~ 3 秒間遅延が増加する可能性があります。

    回避策:回避策はありません。

  • 問題 25921:

    ハブに 3,000 個のブランチ Edge が接続されている場合、VMware SD-WAN ハブの高可用性のフェイルオーバーにかかる時間が予想よりも長くなります(最大 15 秒)。

    回避策:回避策はありません。

  • 問題 25997:

    スイッチ ポートに変換されたルーテッド インターフェイスでトラフィックを適切に渡すために、VMware SD-WAN Edge で再起動が必要になる場合があります。

    回避策:設定を変更した後で、Edge を再起動します。

  • 問題 26421:

    クラスタへのトンネルを確立するには、すべてのブランチ サイトのプライマリ Partner Gateway も VMware SD-WAN ハブ クラスタに割り当てる必要があります。

    回避策:回避策はありません。

  • 問題 28175:

    NAT IP アドレスが VMware SD-WAN Gateway インターフェイスの IP アドレスと重複していると、ビジネス ポリシー NAT が失敗します。

    回避策:回避策はありません。

  • 問題 31210:

    VRRP:ARP が VRRP の仮想 IP アドレスに対して LAN クライアントで解決されません。これは、VMware SD-WAN Edge がプライマリで LAN インターフェイスでグローバルでない CDE セグメントが実行されている場合に発生します。 

    回避策:回避策はありません。

  • 問題 32731:

    ルートを無効にすると、OSPF 経由で広報された条件付きデフォルト ルートが正しく戻されないことがあります。

    回避策:ルートを再度有効にしてから再度無効にすると、正常に取り消されます。 

  • 問題 32960:

    有効化された VMware SD-WAN Edge のローカル Web ユーザー インターフェイスで、インターフェイスの「自動ネゴシエーション」と「速度」の状態が誤って表示されることがあります。

    回避策:Orchestrator ユーザー インターフェイスで [リモート診断 (Remote Diagnostics)] > [インターフェイスの状態 (Interface Status)] を参照してください。

  • 問題 32981:

    DPDK が設定されたポートのハードコーディングの速度とデュプレックスで、DPDK をオフにする必要があるため、設定を有効にするために VMware SD-WAN Edge の再起動が必要になる場合があります。

  • 問題 34254:

    Zscaler CSS が作成され、グローバル セグメントで FQDN/PSK が設定されている場合、これらの設定が非グローバル セグメントにコピーされて、IPsec トンネルが Zscaler CSS に形成されます。

  • 問題 35778:

    1 つのインターフェイス上に複数のユーザー定義 WAN リンクがある場合、これらの WAN リンクのうちの 1 つのみが Zscaler への GRE トンネルを持つことができます。 

    回避策:Zscaler への GRE トンネルを構築する必要がある WAN リンクごとに、異なるインターフェイスを使用します。

  • 問題 36923:

    ハブとしてクラスタに接続されている VMware SD-WAN Edge の NetFlow インターフェイスの説明で、そのクラスタ名が正しく更新されない場合があります。

  • 問題 38682:

    DPDK が設定されたインターフェイスで DHCP サーバとして動作している VMware SD-WAN Edge が、接続されているすべてのクライアントに対して「新しいクライアント デバイス」イベントを適切に生成しないことがあります。

  • 問題 38767:

    Zscaler に GRE トンネルが設定されている WAN オーバーレイが自動検出からユーザー定義に変更されると、次に再起動するまで、古いトンネルが残ることがあります。

    回避策:Edge を再起動して、古いトンネルをクリアします。

  • 問題 39134:

    VMware SD-WAN Edge の [監視 (Monitor)] > [Edge] > [システム (System)] と、VMware SD-WAN Gateway の [監視 (Monitor)] > [Gateway (Gateways)] で、システムの健全性統計情報 [CPU 使用率 (CPU Percentage)] が正しく報告されない場合があります。

    回避策:Edge キャパシティを監視するために、ユーザーが CPU の割合ではなくハンドオフ キューのドロップ数を使用する必要があります。

  • 問題 39374:

    VMware SD-WAN Edge に割り当てられた VMware SD-WAN Partner Gateway の順序を変更すると、帯域幅のテストに使用されるローカル ゲートウェイとしてゲートウェイ 1 が正しく設定されない場合があります。

  • 問題 39608:

    リモート診断「Ping テスト」の出力で、正しい結果が表示される前に、無効な内容が一時的に表示されることがあります。

    回避策:この問題の回避策はありません。

  • 問題 39659:

    拡張された高可用性で設定されたサイトで、各 VMware SD-WAN Edge に 1 つの WAN リンクがあり、HA スタンバイ Edge には PPPoE WAN リンクしか接続されておらず、アクティブ Edge には非 PPPoE 接続がある場合に、HA ケーブルで障害が発生するとスプリット ブレイン状態(アクティブ/アクティブ)になることがあります。

  • 問題 39624:

    親インターフェイスが PPPoE で設定されている場合、サブインターフェイス経由の ping が失敗することがあります。

  • 問題 39753:

    動的なブランチ間 VPN をオフに切り替えると、現在、動的なブランチ間を使用して送信されている既存のフローが停止する可能性があります。

    回避策:メンテナンス期間中にのみ動的なブランチ間 VPN を無効にしてください。

  • 問題 40421:

    スイッチ ポートとして設定されたインターフェイスを使用して VMware SD-WAN Edge を通過するときに、traceroute でパスが表示されません。

  • 問題 40096:

    アクティベーション済みの VMware SD-WAN Edge 840 が再起動された場合、リンク ライトと VMware SD-WAN Orchestrator でポートが「稼動中」と表示されていても、Edge に接続されている SFP モジュールがトラフィックの通過を停止する可能性があります。 

    回避策:SFP モジュールを取り外して、ポートに再度接続します。

  • 問題 42278:

    特定のタイプのピアの設定ミスにより、VMware SD-WAN Gateway が IKE 初期化メッセージを非 SD-WAN ピアに継続的に送信することがあります。この問題により、Gateway へのユーザー トラフィックが中断されることはありません。ただし、Gateway のログに IKE エラーが大量に記録されて、有用なログ エントリが確認しづらくなる可能性があります。

  • 問題 42388:

    VMware SD-WAN Edge 540 で、VMware SD-WAN Orchestrator からインターフェイスを無効にして再度有効にすると、SFP ポートが検出されません。

  • 問題 42872:

    ハブ クラスタが関連付けられているハブ プロファイルでプロファイルの隔離を有効にしても、ルーティング情報ベース (RIB) からハブ ルートが取り消されません。

  • 問題 43373:

    複数の VMware SD-WAN Edge から同じ BGP ルートを学習していて、このルートをオーバーレイ フロー制御で優先から対象終了に移動すると、その Edge が広報 リストから削除されず、広報されたままになります。

    回避策:VMware SD-WAN Orchestrator の分散コスト計算を有効にします。

  • 問題 44995:

    ルートがハブ クラスタから戻された場合に、OSPF ルートが VMware SD-WAN Gateway および VMware SD-WAN スポーク Edge から取り消されません。

  • 問題 45189:

    送信元 LAN 側 NAT が設定されている場合、NAT サブネットのスタティック ルートを設定しなくても、VMware SD-WAN スポーク Edge からハブ Edge へのトラフィックが許可されます。

  • 問題 45302:

    VMware SD-WAN ハブ クラスタで、1 つのハブが、そのハブとその割り当てられているスポーク Edge の間で共通のすべての VMware SD-WAN Gateway への接続が 5 分より長い間失われた場合、まれに、スポークがハブ ルートを 5 分後に保持できなくなるという状態になることがあります。この問題は、ハブが Gateway との接続を回復したときに自動的に解消されます。

  • 問題 46053:

    ネイバーがアップリンク ネイバーに変更されても、BGP プリファレンスがオーバーレイ ルートに対して自動修正されません。

    回避策:Edge サービスを再起動すると、この問題は修正されます。

  • 問題 46137:

    3.4.x ソフトウェアを実行している VMware SD-WAN Edge で、Edge が GCM 用に設定されていても、AES-GCM 暗号化を使用したトンネルが開始されません。

    回避策:カスタマーが AES-256 を使用している場合は、Edge を 4.x リリースにアップグレードする前に、Orchestrator から GCM を明示的に無効にする必要があります。すべての Edge で 4.x リリースが実行されている状態になったら、カスタマーは AES-256-GCM または AES-256-CBC を選択できます。

  • 問題 46216:

    ピアが AWS インスタンスの Gateway または Edge 経由の Non SD-WAN Destination で、フェーズ 2 の再キー化をピアが開始すると、フェーズ 1 の IKE も削除されて再キー化が強制されます。これは、トンネルが破棄されてから再構築されることを意味し、その結果トンネルの再構築中にパケット ロスが発生します。

    回避策:トンネルの破棄を回避するには、Gateway または Edge 経由の Non SD-WAN Destination または CSS IPsec の再キー化タイマーを 60 分未満に設定します。これにより、AWS が再キー化を開始できなくなります。

  • 問題 46391:

    VMware SD-WAN Edge 3800 の場合、SFP1 および SFP2 のインターフェイスは、それぞれマルチレート SFP (1/10G) の問題があり、これらのポートで使用できません。

    回避策:ナレッジベースの記事「VMware SD-WAN Supported SFP Module List (79270)」に従って、単一レートの SFP を使用してください。マルチレート SFP は、SFP3 と SFP4 で使用できます。

  • 問題 47664:

    ハブを介したブランチ間 VPN が設定されていないハブとスポークの設定では、L3 スイッチ/ルーターのサマリ ルートを使用してブランチ間トラフィックを戻そうとすると、ルーティング ループが発生します。

    回避策:ブランチ間 VPN を有効にするようにクラウド VPN を設定し、[VPN にハブを使用 (Use Hubs for VPN)] を選択します。

  • 問題 47681:

    VMware SD-WAN Edge の LAN 側のホストが、Edge の WAN インターフェイスと同じ IP アドレスを使用している場合、LAN ホストから WAN への接続が機能しません。

  • 問題 48530:

    VMware SD-WAN Edge 6x0 モデルで、3 つの速度 (10/100/1000 Mbps) の Copper SFP の自動ネゴシエーションが実行されません。

    回避策:Edge 520/540 は 3 つの速度の Copper SFP をサポートしていますが、このモデルは 2021 年の第 1 四半期に販売終了としてマークされています。

  • 問題 48597:ピアへの 2 つのパスのいずれかが停止した場合、マルチホップ BGP ネイバーシップは稼動状態ではなくなります。

    複数のパスがあり、そのうちの 1 つが停止しているピアを持つマルチホップ BGP ネイバーシップがある場合、ユーザーは BGP ネイバーシップが停止して、他の使用可能なパスを使用していないことに気付きます。これには、ローカルの IP ループバック ネイバーシップも含まれます。

    回避策:この問題の回避策はありません。

  • 問題 50518:

    PKI が設定された VMware SD-WAN Gateway で、6,000 個より多い PKI トンネルが Gateway に接続しようとすると、受信 SA が削除されないため一部のトンネルが起動しない場合があります。

    注:プリシェアード キー (PSK) 認証を使用するトンネルには、この問題はありません。

  • 問題 51436:LTE モデムを使用して VMware SD-WAN Edge を展開しているときに、拡張された高可用性トポロジを使用しているサイトでは、サイトが「スプリット ブレイン」状態になった場合、高可用性のフェイルオーバーに 5~6 分かかります。

    スプリット ブレイン状態からのリカバリの一環として、アクティブ Edge 上で LAN ポートが停止し、ポートが停止している間、およびサイトがリカバリできるようになるまで LAN トラフィックに影響が生じます。

    回避策:この問題の回避策はありません

  • 問題 52955:ステートフル DHCP で DAD 障害が発生した後、Edge から DHCP の拒否が送信されず、DHCP の再バインドが再開されません。

    DHCPv6 サーバが、DAD チェック中にカーネルによって重複として検出されたアドレスを割り当てた場合、DHCPv6 クライアントは拒否を送信しません。これにより、インターフェイス アドレスが DAD チェックの失敗としてマークされ、使用されないため、トラフィックのドロップが発生します。これにより、ネットワーク内でトラフィックがループすることはありませんが、トラフィックのブラックホールが発生します。

    回避策:この問題の回避策はありません。

  • 問題 53219:VMware SD-WAN ハブ クラスタの再調整後、いくつかのスポーク Edge で RPF インターフェイス/IIF が正しく設定されていない場合があります。

    影響を受けるスポーク Edge では、マルチキャスト トラフィックが影響を受けます。クラスタの再調整後、一部のスポーク Edge が PIM join の送信に失敗します。

    回避策:この問題は、影響を受けるスポーク Edge が、Edge サービスを再起動するまで続きます。

  • 問題 53337:スループットが 3200 Mbps を超えると、VMware SD-WAN Gateway の AWS インスタンスでパケットのドロップが発生することがあります。

    トラフィックが 3200 Mbps 以上のスループットを超過し、パケット サイズが 1,300 バイトの場合、RX および IPv4 BH ハンドオフでパケットのドロップが発生します。

    回避策:この問題の回避策はありません。

  • 問題 53359:一部の DDoS 攻撃のシナリオで、BGP/BFD セッションが失敗することがあります。

    経路指定されたインターフェイスに接続されているクライアントから LAN クライアントにトラフィックが集中している場合、BGP/BFD セッションが失敗することがあります。また、優先順位の高いリアルタイム トラフィックがオーバーレイの宛先に集中している場合、BGP/BFD セッションが失敗することがあります。

    回避策:この問題の回避策はありません。

  • 問題 53830:VMware SD-WAN Edge では、DCC フラグが設定されている場合、BGP ビューの一部のルートに正しい設定および広報値がなく、Edge の FIB で誤った並べ替え順序が発生する場合があります。

    Edge 上に多数のルートがあるスケーリングされたシナリオで分散コスト計算 (DCC) が設定されている場合、ログ bgp_view の Edge 診断バンドルを確認すると、一部のルートが設定および広報値で適切に更新されていないことがあります。この問題は、検出されるとすれば、大規模なエンタープライズ(ハブ Edge またはハブ クラスタに接続された 100 以上のスポーク Edge)の一部であるいくつかの Edge で検出されます。 

    回避策:この問題を解決するには、アンダーレイ BGP ルートを再学習するか、影響を受けるルートの VMware SD-WAN Orchestrator の [OFC] ページで [更新] オプションを実行します。ルートの [更新 (Refresh)] を実行すると、エンタープライズ内のすべての Edge からルートが再学習されることに注意してください。

  • 問題 53934:VMware SD-WAN ハブ クラスタが設定されているエンタープライズで、プライマリ ハブに LAN 側のマルチホップ BGP ネイバーシップが含まれている場合、LAN 側で障害が発生すると、またはすべてのセグメントで BGP が設定されていないと、カスタマーはスポーク Edge でトラフィックのドロップを経験することがあります。

    ハブ クラスタでは、プライマリ ハブにピア デバイスとのマルチホップ BGP ネイバーシップがあり、ルートを学習します。BGP ネイバーシップが確立されているハブの物理インターフェイスが停止した場合、BGP ビューが空になっているにもかかわらず BGP LAN ルートがゼロにならない場合があります。これにより、ハブ クラスタの再調整が行われなくなる可能性があります。この問題は、BGP がすべてのセグメントで設定されておらず、1 つ以上のマルチホップ BGP ネイバーシップがある場合にも発生する可能性があります。

    回避策:LAN 側に障害がある(または BGP が有効化されていない)ハブを再起動します。

  • 問題 57210:VMware SD-WAN Edge が正常に動作していて、インターネットにアクセスできる場合でも、ローカル ユーザー インターフェイスの [概要 (Overview)] ページの LED が「赤色」で表示されます。

    Edge のローカル ユーザー インターフェイスは、Google の DNS リゾルバ (8.8.8.8) を介して既知の名前を解決できるかどうかによって Edge の接続を決定します。何らかの理由で実行できない場合は、オフラインと見なされ、LED が赤色で表示されます。

    回避策:8.8.8.8 への DNS トラフィックが宛先に到達し、正常に解決されることを確認する以外に、この問題の回避策はありません。

  • 問題 61543:複数の 1:1 NAT ルールが同じ内部 IP を持つ異なるインターフェイス上で設定されている場合、インバウンド トラフィックは 1 つのインターフェイスで受信でき、同じフローの送信パケットは異なるインターフェイス経由でルーティングできます。

    外部から内部への NAT フローの場合、1:1 NAT ルールは、パケットが受信される外部 IP およびインターフェイスに対して照合されます。同じフローの送信パケットの場合、VMware SD-WAN Edge は、内部 IP を比較して NAT ルールを再度照合しようとします。送信トラフィックは、「送信トラフィック」が設定されている最初の一致したルールで設定されたインターフェイスを介してルーティングできます。

    回避策:特定の内部 IP アドレスを使用して 1:1 NAT ルールを 1 つのみ設定する以外に、この問題の回避策はありません。

  • 問題 62701:Edge ハブ クラスタの一部として展開された VMware SD-WAN Edge の場合、クラウド VPN がグローバル セグメントでは有効化されていないが、非グローバル セグメントで有効化されていると、Orchestrator によって送信された制御プレーンの更新により、すべての WAN リンクがハブ Edge でフラップすることがあります。

    ハブ Edge の WAN リンクがフラップする(ダウンして、すぐに起動する)と、音声通話などのリアルタイム トラフィックに影響します。この問題は、ハブ Edge のグローバル セグメントでクラウド VPN が有効化されていないが、クラスタ設定がオンとして設定されている、つまり、このハブ Edge がクラスタの一部になっている(クラスタ設定がすべてのセグメントに適用される)カスタマーの展開で発生しました。設定の変更がハブ Edge にプッシュされると、ハブ Edge のデータプレーンはデータの解析をグローバル セグメントから開始します。このとき、クラウド VPN が有効化されていないことが示され、ハブ Edge は誤ってこのグローバル セグメントでクラスタリングが無効化されていると認識します。その結果、ハブ Edge はハブの WAN リンクからすべてのトンネルを破棄し、その Edge のすべての WAN リンクでリンク フラップが発生します。このようなインシデントの場合、WAN リンクはダウンし、制御プレーンの更新ごとに 1 回だけリカバリします。

    回避策:回避策は、すべてのセグメント(つまり、グローバル セグメントとすべての非グローバル セグメント)でクラウド VPN を有効にすることです。

  • 問題 65560:カスタマーから PE(プロバイダ Edge)デバイスへのトラフィックが失敗します。

    ハンドオフ設定でタグ タイプが「なし」と選択されている場合、Partner Gateway とプロバイダ Edge 間の BGP ネイバーシップが確立されません。これは、タグ タイプが「なし」の場合、Orchestrator のハンドオフ設定ではなく、/etc/config/gatewayd から ctag、stag 値が選択されるためです。

    回避策:/etc/config/gatewayd の vrf_vlan->tag_info で、ctag、stag の値をそれぞれ 0 に更新します。vc_procmon を再起動します。

  • 問題 67879:ユーザーが WAN インターフェイス設定で WAN オーバーレイ設定を自動検出からユーザー定義に変更すると、クラウド セキュリティ サービス (CSS) トンネルが削除されます。

    変更を保存した後、カスタマーがトンネルをダウンしてから、再び起動するまで、CSS トンネルは起動しません。WAN 設定を変更すると、CSS トンネルがダウンし、CSS セットアップが再度解析されます。ただし、場合によっては、nvs_config->num_gre_links が 0 になり、CSS トンネルが起動に失敗することがあります。

    回避策:CSS 設定を無効にしてから再度有効にすると、CSS トンネルが起動します。

  • 問題 68057:DHCPv6 リリース パケットは、WAN インターフェイス アドレス モードが DHCP ステートフルから静的 IPv6 アドレスに変更されても、VMware SD-WAN Edge から送信されず、リースは有効期限に達するまでアクティブのままになります。

    DHCPv6 クライアントは、設定の変更が行われたときに解放されないリースを所有しています。リースは、DHCPv6 サーバで有効期間が切れて削除されるまで有効なままです。

    回避策:リースは有効期間までアクティブなままとなり、この問題を修正する方法はありません。

  • 問題 68851:VMware SD-WAN Edge と VMware SD-WAN Gateway にそれぞれ同じ TCP Syslog サーバが設定されている場合、Edge から Syslog サーバへの TCP 接続は確立されません。

    Edge と Gateway がそれぞれ同じ TCP サーバを持ち、Edge からの Syslog パケットが Gateway 経由でルーティングされる場合、Syslog サーバは TCP リセットを Edge に送信します。

    回避策:Gateway 経由でルーティングする代わりに、Edge から直接 Syslog パケットを送信するか、Edge と Gateway に別の Syslog サーバを設定します。

  • 問題 69284:Edge が HA 設定で VNF をデプロイし、リリース 4.x を使用している高可用性トポロジを使用しているサイトで、これらの HA Edge が HA VNF がサポートされていない 3.4.x リリースにダウングレードされてから 4.5.0 にアップグレードされた場合、HA VNF が再度有効化されると、スタンバイ Edge VNF が起動しません。

    HA VNF ペアが、VNF-HA をサポートするバージョン(リリース 4.0 以降)から、Orchestrator で VNF が設定されていて、VNF-HA(リリース 4.0 以降)をサポートしないリリースにダウングレードされた場合、スタンバイ Edge の VNF 状態は、SNMP を介して停止と通知されます。この問題は、Edge が VNF-HA をサポートするバージョンにアップグレードされ、Orchestrator で再度設定されている場合に発生します。

    回避策:Edge が VNF をサポートしていないバージョンにダウングレードされている場合、HA 設定の場合は、まず VNF を無効にする必要があります。

  • 問題 70311:VMware SD-WAN Edge でデータプレーン サービスの障害が発生し、その結果、サービスが再起動される場合があります。

    Edge サービスの再起動中に、カスタマーのトラフィックが約 15 ~ 30 秒間中断されます。この問題の発生に一貫性はありませんが、発生すると、Edge は IKE Security Association (SA) を破棄します。これは通常、SA タイマー(VMware SD-WAN Orchestrator で設定されている)の有効期限が切れる場合か、または、ユーザーが Orchestrator の IPsec 設定を変更する場合にのみ発生します。

    回避策:この問題の回避策はありません。

  • 問題 71719:Edge からクラウドへのパスに沿って PPTP 接続が確立されません。

    VMware SD-WAN Edge の背後にある PPTP サーバへの接続が確立されません。

    回避策:この問題の回避策はなく、Edge の再開や再起動でも解決されません。

  • 問題 72358:VMware SD-WAN Orchestrator DNS 名の IP アドレスが変更されると、VMware SD-WAN Gateway の管理プレーン プロセスで DNS 名が正しく解決されず、Gateway は Orchestrator に接続できなくなります。

    Gateway の管理プロセスでは、Orchestrator の DNS 名の DNS 解決を定期的にチェックして、Gateway が適切なホストに接続できるように、Orchestrator の DNS 名が最近変更されたかどうかを確認します。DNS 解決コードに問題があるため、これらの解決チェックはすべて失敗し、Gateway は古いアドレスを引き続き使用するため、Orchestrator に接続できなくなります。

    回避策:この問題が解決されるまで、オペレータ ユーザーは Orchestrator の IP アドレスを変更しないでください。Orchestrator の IP アドレスを変更する必要がある場合は、その Orchestrator に接続しているすべての Gateway を再度有効化する必要があります。

  • 問題 77541:IPv6 をサポートする USB モデムを取り外して、VMware SD-WAN Edge USB インターフェイスに再挿入すると、IPv6 アドレスが USB インターフェイスにプロビジョニングされないことがあります。

    これは、ModemManager アプリケーションで管理される USB モデムではなく、IP ベースの USB モデムに影響します。ほとんどの Inseego モデムは IP ベースであり、Inseego は VMware SASE が推奨するモデム メーカーであるため、これは重要です。IP ベースではなく、ModemManager を使用し、IPv6 をサポートする USB モデムは、プラグ アウトとプラグ インのシナリオでは問題ありません。

    回避策:USB モデムが Edge の USB ポートに再挿入された後、Edge を再起動する(または電源を切って入れ直す)必要があります。再起動後、Edge はモデムの IPv6 アドレスを取得します。

  • 問題 81852:L7 健全性チェックをオンにした GRE トンネルを使用する Zscaler タイプのクラウド セキュリティ サービス (CSS) を使用している VMware SD-WAN Edge の場合、その Edge をリリース 5.0.0 にアップグレードすると、場合によっては L7 健全性チェック エラーが発生することがあります。

     これは通常、ソフトウェアのアップグレード中または起動時に発生します。GRE トンネルを使用した CSS の L7 健全性チェックがオンになっている場合、ソケットの getaddress エラーに関連するエラー メッセージが表示されることがあります。観察されたエラーは断続的に発生し、一貫性がありません。このため、L7 健全性チェックのプローブ メッセージは送信されません。

    回避策:この修正を行わない場合、問題を修正するには、ユーザーが L7 健全性チェックの設定をオフにしてから再度オンにする必要があり、これにより、この機能は想定どおりに動作します。

  • 問題 82184:Edge リリース 5.0.0 を実行している VMware SD-WAN Edge で、Edge の br-network IPv4/IPv6 アドレスに対して traceroute または traceroute6 を実行すると、UDP プローブを使用したときに traceroute が適切に終了しません。

    デフォルト モード(UDP プローブ)が使用されている場合、Edge の br-network IPv4/IPv6 アドレスへの traceroute または traceroute6 が適切に機能しません。

    回避策:traceroute および traceroute6 で -I オプションを使用して ICMP プローブを使用すれば、br-network IPv4/IPv6 アドレスへの traceroute が想定どおりに動作します。

  • 問題 83166:IPv6 オプションを選択した AWS ポータルの AWS c5.4xlarge インスタンス タイプを使用して VMware SD-WAN Gateway を新規に展開するときに、IPv6 ルートまたはデフォルト ルートが設定されません。

    IPv6 ルートとデフォルト ルートが設定されていないため、AWS Gateway IPv6 管理トンネルが形成されず、Gateway は機能しません。

    回避策:この問題の回避策はありません。上記のプロパティを使用して Gateway を展開しないでください。

  • 問題 83227:リリース 5.0.0 を実行している VMware SD-WAN Edge が 128 セグメントで設定されている場合、Edge の dnsmasq プロセスが停止して終了します。

    IPv6 が 128 セグメントで有効化されていて、各セグメントの LAN に DCPv6 サーバが設定されている場合、開いているファイル記述子の合計数を超えると、dnsmasq プロセスが停止します。dnsmasq プロセスは、終了するまで約 30 分間続きます。この時点で Edge の DHCP による IP アドレスの割り当ては失敗します。 

    回避策:Edge を再起動すると、dnsmasq プロセスが最大 30 分間リストアされますが、再度失敗します。唯一の現実的な回避策は、セグメント数を 128 未満に減らすことです。

  • 問題 86098:スタンバイ Edge で PPPoE WAN リンクが使用されている拡張高可用性トポロジを使用しているサイトでは、デフォルトのプロキシ ルートがアクティブ Edge にインストールされておらず、そのリンクを使用するトラフィックが失敗することがあります。

    拡張 HA Edge ペアが起動すると、PPPoE リンクはスタンバイ Edge と同期し、ネクスト ホップが 0.0.0.0 のデフォルト ルートを提供します。その結果、このルートはアクティブ Edge にインストールされず、このリンクを使用するトラフィックはドロップされます。

    回避策:この問題の回避策はありません。

  • 問題 92481:VMware SD-WAN Edge の WAN インターフェイスが VMware SASE Orchestrator で無効化されている場合でも、インターフェイスは SNMP によって「稼動中」として報告されます。

    インターフェイス出力の主要なデバッグ プロセスに、Edge WAN インターフェイス(Edge 6x0 または 3x00 モデルの GE3 や GE4 など)の物理ポートの詳細が含まれていません。その結果、SNMP がそれらのインターフェイスをポーリングすると、インターフェイスの設定に関係なく、稼動中という結果が常に返されます。

    回避策:この問題の回避策はありません。

  • 問題 92676:Gateway 経由の Non VMware SD-WAN Destination (NSD) が冗長トンネルと冗長 Gateway を使用するように設定され、BGP over IPsec も使用しているカスタマーの展開の場合、プライマリおよびセカンダリ Gateway がプライマリおよびセカンダリ NSD トンネルへの等しい AS パスを持つプレフィックスを広報すると、プライマリ NSD トンネルは冗長な Gateway パスをプライマリ Gateway より優先します。

    冗長な Gateway パスをプライマリ Gateway よりも優先している、Gateway 上のプライマリ NSD トンネルの影響は、NSD から Gateway へのリターン トラフィックに対してのみ発生します。

    この問題に対して修正を適用しない場合、ユーザーは対象のプレフィックスに対して冗長 Gateway でより高い(3 以上の)メトリックを設定する必要があります。そうすることで、NSD のプライマリ トンネルがリターン トラフィックのためにプライマリ Gateway を選択するのに役立ちます。

    回避策:対象のプレフィックスに対して冗長な Gateway でより高い(3 以上の)メトリックを設定します。そうすることで、NSD のプライマリ トンネルがリターン トラフィックのためにプライマリ Gateway を選択するのに役立ちます。

  • 問題 93062:ユーザーが VMware Orchestrator でリモート診断の「インターフェイスの状態」を実行すると、Orchestrator はそのテストのエラーを返して完了しないか、またはテストがルーテッド インターフェイスの結果を返しません。

    「テスト用のデータの読み取りエラー」というメッセージが表示されます。テストが完了すると、ルーテッド インターフェイスの結果は空で、速度やデュプレックスに関する情報は表示されません。いずれの場合でも、インターフェイスの状態は破損になります。この問題は、DPKD の有効なポートを省略するインターフェイスの状態の下にある debug コマンドに関連しています。

    回避策:ルーテッド インターフェイスの状態を表示するには、Edge の診断バンドルを生成する必要があります。

  • 問題 93141:高可用性トポロジを使用して展開されたサイトで、HA Edge ペアのアップストリームにある L2 スイッチを使用しているカスタマーの場合、実際のループがないにもかかわらず、スイッチ ログに L2 トラフィック ループの証拠が記録されることがあります。

    この問題は、HA Edge がインターフェイスの実際の MAC アドレスではなく仮想 MAC アドレスを持つ HA インターフェイス ハートビートを Orchestrator に送信するために発生します。これは、HA Edge がその MAC ファイルに仮想 MAC アドレスを格納することが原因です。その結果、接続された L2 スイッチは、2 つの異なる Edge インターフェイスの同じ送信元 MAC アドレスからのトラフィックを検出し、L2 ループとしてログに記録します。この問題は、実際の L2 ループがなく、この問題に起因するカスタマーのトラフィックの中断や Orchestrator との通信の切断がないため、ログ レベルでは表示上の問題に過ぎません。

    回避策:カスタマーは、Edge の HA インターフェイス(通常は GE1)で発生したアップストリーム スイッチからの L2 ループ検出イベントを無視できます。 

  • 問題 94204:VNF 対応の VMware SD-WAN Edge の診断バンドルを生成しようとすると失敗することがあります。

    Edge のディスク容量が不足しているため、VNF 対応の Edge で診断バンドルの完了が失敗します。これは、Edge が 1 つ以上のコアを生成し、Edge がこれらのコアを /vnf/tmp フォルダに送信することが原因で発生する場合があります。各コアは /vnf/tmp フォルダに解凍されます。コアの解凍後のサイズにより、このフォルダはすぐにいっぱいになり、診断バンドルが失敗します。 

    VNF(仮想ネットワーク機能)対応の Edge には、次のモデルが含まれます。520v、620、640、680、および 840。

    回避策:この問題の回避策はありません。

  • 問題 95565:高可用性トポロジを使用しているサイトで、VMware SD-WAN アクティブ Edge のデータプレーン サービスの障害が発生し、コアが生成されて高可用性フェイルオーバーがトリガされることがあります。

    この問題は、アクティブ Edge の WAN リンクが 1 回以上フラップ(ダウンして、すぐに起動する)し、そのときに SNMP クエリが頻繁に発生する SNMP を使用している場合にトリガされます。インターフェイスが稼動状態に戻るのと同時に SNMP クエリが発生するというタイミングの問題によりデッドロックがトリガされることが原因で、データプレーン サービスが失敗してコアが生成されます。1 回の WAN リンク フラップのみでこの問題が引き起こされる可能性がありますが、WAN リンク フラップの頻度が高いほど、この問題が発生する可能性が高まります。

    回避策:修正が適用されていない HA Edge ペアでこの問題が発生する場合、回避策は SNMP を無効にすることです。これはタイミングの問題であり、これによってリスクが軽減されるためです。

  • 問題 97321:VMware SD-WAN Edge で Edge Network Intelligence 分析が有効になっている場合、Edge が Edge サービスの再起動をトリガすることがあり、これによりカスタマーのトラフィックが 10 ~ 15 秒間中断されます。

    Edge で分析が有効になっている場合、Edge でメモリ不足の状態が発生し、その後にメモリの「二重の空き」状態が発生することがあります。Edge はサービスを再起動してメモリをリストアします。この問題の症状は、分析の有効化中に複数回発生する可能性があります。

    回避策:この問題の回避策はありません。

  • 問題 98136:動的なブランチ間 VPN が設定されているハブ/スポーク トポロジを使用しているカスタマー エンタープライズの場合、SD-WAN スポーク Edge の背後のクライアント ユーザーの環境では、最適でないパスを使用するトラフィックによって一部のトラフィックに予期しない遅延が発生する場合があります。

    この問題が発生するスポーク Edge トラフィックで使用されるルートは、最初は、スポーク Edge が使用していたプロファイルに含まれていないハブ Edge のアップリンク以外のルートでした。トラフィックが他の無関係なプレフィックスに送信されるため、動的なブランチ間 VPN トンネルをスポーク Edge からハブ Edge に形成できます。この場合、アップリンク以外のルートがスポーク Edge にインストールされます。

    このアップリンク以外のルートの結果として、このプレフィックスに向かうすべてのトラフィックがハブ Edge を経由し始め、アップリンク以外のルートがアップリンクになります(コミュニティがアップリンク コミュニティに変更されます)が、以前にインストールされたアップリンク以外のルートは取り消されず、動的なブランチ間 VPN トンネルが稼動している限り、トラフィックはハブ Edge パスを経由します。

    回避策:動的なブランチ間 VPN トンネルが破棄されるまで待機します。その後、ハブ Edge に向かう新しい動的なブランチ間 VPN トンネルが形成されると、アップリンク ルートはスポーク Edge にインストールされません。

Orchestrator の既知の問題

  • 問題 19566:

    高可用性のフェイルオーバー後、スタンバイ VMware SD-WAN Edge のシリアル番号が Orchestrator でアクティブなシリアル番号として表示されることがあります。

  • 問題 21342:

    セグメントごとに Partner Gateway を割り当てると、VMware SD-WAN Edge の監視リストで、ゲートウェイ割り当ての適切なリストがオペレータ オプションのゲートウェイの [表示 (View)] に表示されない場合があります。

  • 問題 24269:

    観測された WAN リンクの損失が、QoE グラフには反映されても、[監視 (Monitor)] > [トランスポート (Transport)] > [ロス (Loss)] に反映されません。 

  • 問題 25932:

    VMware SD-WAN Orchestrator で、使用中であっても VMware SD-WAN Gateway を Gateway プールから削除できます。

  • 問題 32335:

    ユーザーが契約に同意しようとすると、[エンド ユーザー サービス契約 (End User Service Agreement)] (EUSA) ページでエラーが発生します。

    回避策:エンタープライズ名の先頭または末尾にスペースが含まれていないことを確認してください。

  • 問題 32435:

    ポリシーベースの NAT 設定に対する VMware SD-WAN Edge のオーバーライドが、すでにプロファイル レベルで設定されているタプルで許可されます(その逆も可能)。

  • 問題 32856:

    ハブ クラスタを使用してインターネット トラフィックをバックホールするようにビジネス ポリシーが設定されていても、リリース 3.2.1 からリリース 3.3.x にアップグレードされた VMware SD-WAN Orchestrator 上のプロファイルから、ユーザーがハブ クラスタを選択解除できます。

  • 問題 35658:

    あるプロファイルから CSS 設定が異なる別のプロファイルに VMware SD-WAN Edge が移動されたときに(例:プロファイル 1 は IPsec で、プロファイル 2 は GRE)、Edge レベルの CSS 設定が、以前の CSS 設定(例:IPsec と GRE)を引き続き使用します。 

    回避策:Edge レベルで GRE を無効化してから、GRE を再度有効にして問題を解決します。

  • 問題 35667:

    あるプロファイルから、CSS 設定は同じでも GRE CSS 名は異なる(同じエンドポイントの)別のプロファイルに VMware SD-WAN Edge が移動されたときに、一部の GRE トンネルが監視に表示されません。

    回避策:Edge レベルで GRE を無効化してから、GRE を再度有効化して問題を解決します。

  • 問題 36665:

    VMware SD-WAN Orchestrator がインターネットにアクセスできない場合、Google Maps API へのアクセスを必要とするユーザー インターフェイスのページが完全にはロードされない場合があります。

  • 問題 32913:

    高可用性を有効化した後、VMware SD-WAN Edge のマルチキャストの詳細が [監視 (Monitoring)] ページに表示されません。フェイルオーバーにより、この問題は解決されます。

  • 問題 33026:

    契約を削除した後、[エンド ユーザー サービス契約 (End User Service Agreement)] (EUSA) のページが適切に再ロードされません。

  • 問題 38056:

    Edge ライセンスの export.csv ファイルにリージョン データが表示されません。

  • 問題 38843:

    アプリケーション マップをプッシュするときに、オペレータ イベントがなく、Edge イベントは制限付きのユーティリティになります。

  • 問題 39633:

    ユーザーが Super Gateway として代替 Gateway を割り当てた後、Super Gateway のハイパーリンクが機能しません。

  • 問題 39790:

    VMware SD-WAN Orchestrator を使用すると、サポートされている 32 個のサブインターフェイスを超えてユーザーが VMware SD-WAN Edge のルーテッド インターフェイスを設定できます。これにより、ユーザーは、インターフェイス上で 33 個以上のサブインターフェイスを設定できるようになり、Edge のデータプレーン サービスの障害を引き起こす可能性があります。

  • 問題 41691:

    [設定 (Configure)] > [Edge] > [デバイス (Device)] ページで DHCP プールが枯渇していないのに、ユーザーが [アドレスの数 (Number of addresses)] フィールドを変更できません。

  • 問題 43276:

    VMware SD-WAN Edge またはプロファイルに Partner Gateway が設定されている場合に、ユーザーがセグメント タイプを変更できません。

    回避策:プロファイルまたは Edge から Partner Gateway 設定を一時的に削除して、セグメントをプライベートと通常の間で変更できるようにします。または、プロファイルからセグメントを削除し、そこから変更を加えることができます。

  • 問題 47713:

     クラウド VPN がオフにされているときにビジネス ポリシー ルールが設定された場合、クラウド VPN をオンにするときに NAT を再設定する必要があります。

  • 問題 47820:

    プロファイル レベルで DHCP がオフになっている状態で VLAN が設定されていて、同時に DHCP が有効になっている Edge 上でこの VLAN に対する Edge 固有のルールがある場合に、DNS サーバのフィールドが「なし」(IP アドレスが設定されていない)に設定されているエントリがあると、ユーザーは [設定 (Configure)] > [Edge] > [デバイス (Device)] ページで変更を行うことができず、「無効な IP アドレス [] (invalid IP address [])」というエラー メッセージが表示されます。これは、実際の問題を説明または指摘していません。

  • 問題 48085:VMware SD-WAN Orchestrator で、ユーザーがインターフェイスに関連付けられている VLAN を削除することが許可されます。

    この問題が発生すると、「VLAN ID [xx] を削除できません。Edge [b1-edge1 (Gex-disabled)] によって使用されています (VLAN ID [xx] cannot be removed, in use by edge [b1-edge1 (GEx-disabled)])」のようなエラー メッセージが表示されます。

  • 問題 51722:VMware SASE Orchestrator では、[監視 (Monitor)] > [Edge] タブの統計情報の時間範囲セレクタは 2 週間以内です。

    一連の統計情報の保持期間が 2 週間よりはるかに長い場合でも、時間範囲セレクタの [監視 (Monitor)] > [Edge] タブに [過去 2 週間 (Past 2 Weeks)] を超えるオプションは表示されません。たとえば、フローとリンクの統計情報はデフォルトで 365 日間保持されますが(設定可能)、パスの統計情報はデフォルトで 2 週間のみ保持されます(これも設定可能です)。この問題により、すべての [監視 (Monitor)] タブが統計情報の最も低い保持タイプに従うことになり、ユーザーはその統計情報の保持期間に一致する期間を選択できません。

    回避策:ユーザーは、時間範囲セレクタの [カスタム (Custom)] オプションを使用して、2 週間以上のデータを表示できます。

  • 問題 60522:VMware SD-WAN Orchestrator ユーザー インターフェイスで、セグメントを削除しようとすると多数のエラー メッセージが表示されます。

    この問題は、1 つのセグメントをプロファイルに追加し、セグメントを複数の VMware SD-WAN Edge に関連付ける場合に発生する可能性があります。ユーザーが追加したセグメントをプロファイルから削除しようとすると、多数のエラー メッセージが表示されます。

    回避策:この問題の回避策はありません。

  • 問題 82680:MT-GRE トンネル自動化を使用しているカスタマーの場合、ユーザーが CCI(クラウド間相互接続)を使用するように設定されている VMware SD-WAN Gateway で CCI フラグをオフにすると、Zscaler MT-GRE エントリが Zscaler ポータルから一貫して削除されないことがあります。

    CCI サイトが Gateway から削除された後、このサイトのエントリも削除する必要があります。この問題はテストの自動化時にのみ発生し、手動では再現されていませんが、リスクは残っています。

    回避策:再試行する前に、Zscaler からリソースを手動で削除します。

  • 問題 82681:MT-GRE トンネル自動化を使用しているカスタマーの場合、ユーザーが CCI(クラウド間相互接続)を使用するように設定されている VMware SD-WAN Gateway で CCI フラグをオフにし、Zscaler クラウド セキュリティ サービスを使用する CCI が設定されている VMware SD-WAN Edge から CCI フラグを無効にすると、Zscaler MT-GRE エントリが Edge または Zscaler ポータルから削除されないことがあります。

    CCI サイトが Gateway から削除された後、このサイトのエントリも削除する必要があります。この問題はテストの自動化時にのみ発生し、手動では再現されていませんが、リスクは残っています。

    回避策:再試行する前に、Zscaler からリソースを手動で削除します。

Cloud Web Security の既知の問題

  • 問題 65001:VMware Cloud Web Security を使用しているお客様の場合、VMware Orchestrator を使用してファイル ハッシュ チェックをオン/オフにするようにインスペクション エンジンを設定することはできません。

    ユーザーが Orchestrator を使用して、「不明なファイルのダウンロードに対するアクション」と「不明なドキュメントのダウンロードに対するアクション」のいずれかに対して Cloud Web Security インスペクション エンジンのファイル ハッシュ チェック パラメータを設定している場合、これらの変更はインスペクション エンジンに送信されず、適用されません。

    回避策:この問題の回避策はありません。

  • 問題 63149:お客様の展開でプロファイル内に重複するサブネットがあり、VMware Cloud Web Security ポリシーのサブネットを設定し、Cloud Web Security ポリシーをプロファイルとセグメントに関連付けると、そのサブネット上の Edge クライアントはインターネットに接続できなくなります。

    同じセグメント内の VMware SD-WAN Edge の背後にある LAN セグメントに重複するサブネットが設定されている場合、Edge の背後にあるリソースには、インターネットにバインドされたトラフィックに Cloud Web Security ポリシーを適用できません。これは、インターネットから Cloud Web Security へのリターン トラフィックの宛先 Edge を一意に識別する方法がないためです。

    回避策:Edge で LAN 側 NAT をオンにし、Edge の背後にあるリソースから送信されるトラフィックを表す一意のサブネットを設定します。

  • 問題 62934:VMware Cloud Web Security を使用している企業の場合、クライアント ユーザーがシークレット モードで Chrome ブラウザを開いて、ファイルをダウンロードしようとすると、ダウンロードに失敗する場合があります。

    シークレット モードを使用するには、サードパーティの Cookie をオンにする必要があります。サードパーティの Cookie をオンにして、操作をやり直してください。ダウンロードが失敗すると、ユーザーには「Error occurred contact your administrator」というエラーが表示されるか、またはカスタム Web サーバからのファイルの場合、「This page is not working」というエラーが表示されます。一部の Web サーバまたはファイルでは、ファイル署名に差異があり、Cloud Web Security Service が認識できない場合があるため、この問題が発生することがあります。

    回避策:サードパーティの Cookie を許可する設定をオンにしてから、再試行してください。シークレット モードのウィンドウを使用している場合、この問題の既知の回避策はありません。

Secure Access の既知の問題

  • 問題 64541:VMware Secure Access を使用しているカスタマーの場合、Workspace ONE UEM 設定のオプションを使用して組織グループ内のトンネル ホスト名を設定するときに、ユーザーが [はい (Yes)] を選択すると、ホスト名は手動で設定されるのではなく、UEM Console で自動的に作成されます。

    ユーザーには、ホスト名を自動的に作成するだけでなく、手動で設定するオプションが必要です。 

    回避策:この修正を行わない場合の回避策は、UEM Console で手動で設定することです。

check-circle-line exclamation-circle-line close-line
Scroll to top icon