VMware SASE 5.0.1 |2023 年 11 月 15 日

  • VMware SASE™ Orchestrator バージョン R5017-20231111-GA

  • VMware SD-WAN™ Gateway バージョン R5015-20230922-GA

  • VMware SD-WAN™ Edge バージョン R5015-20230922-GA

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

リリース ノートの概要

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

対象ユーザー

本リリースは、リリース 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 および 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) となりました。

  • Edge のリリース 3.4.x は、2022 年 12 月 31 日にジェネラル サポートの終了 (EOGS) となり、2023 年 3 月 31 日にテクニカル ガイダンスの終了 (EOTG) となりました。

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

重要：

VMware SD-WAN リリース 4.0.x のサポート期間が終了しました。リリース 4.2.x は、Gateway および Orchestrator のサポート期間が終了しました。4.3.x は、Gateway および Orchestrator のサポート終了に近づいています。

  • リリース 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) となりました。また、2025 年 9 月 30 日にテクニカル ガイダンスの終了 (EOTG) を迎えます。

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

  • リリース 4.3.x の Edge は、2023 年 6 月 30 日にジェネラル サポートの終了 (EOGS) となりました。また、2025 年 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 は、リリース 4.3.1 以降からリリース 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)」を参照してください。

使用可能な言語

バージョン 5.0.1 を使用する VMware SASE Orchestrator は、次の言語にローカライズされています。チェコ語、英語、欧州ポルトガル語、フランス語、ドイツ語、ギリシャ語、イタリア語、スペイン語、日本語、韓国語、簡体字中国語、繁体字中国語。

ドキュメントの改訂履歴

2023 年 11 月 15 日。第 31 版。

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

  • Orchestrator ビルド R5017-20231111-GA には、#102121、# 116531、および #131789 の問題の修正が含まれています。これらのそれぞれについて、このセクションで説明します。

2023 年 9 月 27 日。第 30 版。

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

    Edge/Gateway ビルド R5015-20230922-GA には、#93237、#95047、#95850、#97321、#98223、#101431、#103558、#103700、#106865、#109906、#110320、#110970、#111924、#112115、#115904、#116368、#117037、#118333、#118591、#119491、#121998、#123593、#124181、#126336 の問題の修正が含まれています。これらのそれぞれについて、このセクションで説明します。

  • 「Edge および Gateway の既知の問題」セクションに未解決の問題 #115136 および #125509 を追加しました。

2023 年 9 月 14 日。第 29 版。

  • 未解決の問題 #92676 を削除しました。これは、VMware エンジニアリング部門がこの問題は想定どおりの動作と判断したためです。回避策は、『管理ガイド』の「Gateway からの BGP over IPsec の設定」の注に記載されています。

2023 年 9 月 4 日。第 28 版。

  • 「ドキュメントの改訂履歴」は、ユーザー エクスペリエンスを向上させるために新しい項目から古い項目の順に読めるように再編成されました。

  • 「Edge および Gateway の既知の問題」セクションに未解決の問題 #117037 を追加しました。

2023 年 8 月 18 日。第 27 版。

2023 年 8 月 3 日。第 26 版。

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

  • Orchestrator ビルド R5016-20230801-GA には、#64145、#116531、#122271 の問題の修正が含まれています。これらのそれぞれについて、このセクションで説明します。

  • 「Edge および Gateway の既知の問題」セクションに未解決の問題 #106865 および #121998 を追加しました。

2023 年 7 月 26 日。第 25 版。

  • 4 番目の Edge ロールアップ ビルド R5014-20230713-GA の「Edge/Gateway で解決した問題」セクションに解決した問題 #103708 を追加しました。この問題は、5.0.1 リリース ノートの以前の版から除外されました。

2023 年 7 月 14 日。第 24 版。

2023 年 6 月 29 日。第 23 版。

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

  • Orchestrator ビルド R5015-20230628-GA には、#109710、#112605、#114291、#114475 の問題の修正が含まれています。これらのそれぞれについて、このセクションで説明します。

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

2023 年 6 月 14 日。第 22 版。

2023 年 4 月 25 日。第 21 版。

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

  • 互換性セクションを更新して、すべての 3.x リリースがサポート期間の終了 (EOSL) に達したことを記載しました。また、4.x セクションを更新して、4.2.x Orchestrator と Gateway がサポート期間の終了 (EOSL) に達したことを記載しました。

2023 年 4 月 12 日。第 20 版。

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

  • Orchestrator ビルド R5014-20230408-GA には、#107766、#108363、#110946、#111946、#111957、#112201 の問題の修正が含まれています。これらのそれぞれについて、このセクションで説明します。

  • 「Edge/Gateway の既知の問題」に未解決の問題 #94980 および #110564 を追加しました。

  • 修正されたチケット #89217 を改訂して、問題を解決するために必要な改訂済み Edge バージョン (R5012-20230327-GA-107522) を反映しました。Edge バージョン R5012-20230327-GA-107522 には、高可用性トポロジに展開されたサイトを Orchestrator を介して自動的にアップグレードする機能が追加されています。この問題の解決に関連する以前の Edge バージョンである R5012-20230123-GA-103475 にはこの機能が含まれていないため、ホストされたすべての Orchestrator で [劣化 (Degraded)] としてマークされます。

2023 年 3 月 26 日。第 19 版。

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

  • Edge/Gateway ビルド R5013-20230322-GA には、問題 #78050、#80149、#84593、#86994、#95603、#96880、#97404、#97559、#98782、#99676、#103527、#103529、#103983、#104141、#104183、#104487、#105360、#105744、#106627、#106700、#107302、#107309、#107356、および #109131 の修正が含まれています。これらのそれぞれについて、このセクションで説明します。

2023 年 3 月 15 日。第 18 版。

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

  • Orchestrator ビルド R5013-20230310-GA には、#105610、#106242、#109595 の問題の修正が含まれています。これらのそれぞれについて、このセクションで説明します。

2023 年 2 月 17 日。第 17 版。

  • [Edge/Gateway の既知の問題] セクションから問題 #39659 を削除しました。これは、リリース 4.3.0 で解決された別のチケット #39501 と重複しています。

2023 年 1 月 30 日第 16 版。

  • 修正されたチケット #89217 を改訂して、問題を解決するために必要な改訂済み Edge バージョン (R5012-20230123-GA-103475) およびプラットフォーム ファームウェア バージョン (R131-20221216-GA) を反映しました。このチケットには、#89217 をカバーし、6x0 Edge をアップグレードするための詳細な手順が含まれているナレッジベースの記事へのリンクも追加されています。

  • 互換性セクションで、4.2.x のサポート終了に関する「重要な注意事項」を改訂し、リリース 4.3.x を追加して、SD-WAN Edge ソフトウェアの新たに改訂された日付を反映しました。

2022 年 12 月 16 日。第 15 版。

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

  • Gateway ビルド R5012-20221214-GA には、#96863、#97272、#99650 の問題の修正が含まれています。これらのそれぞれについて、このセクションで説明します。

  • 重要：

    元の 5.0.1.1 Gateway ビルド (R5011-20221007-GA) のビルドの問題により、Gateway は他の 5.0.1.1 Gateway ビルドにアップグレードできず、5.0.1.1 から 5.0.1.2 に直接アップグレードする必要があります。

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

  • Orchestrator ビルド R5012-20221214-GA には、#96538、#100133、#101835、#102806 の問題の修正が含まれています。これらのそれぞれについて、このセクションで説明します。

2022 年 11 月 30 日。第 14 版。

  • Orchestrator ロールアップ ビルド R5011-20221117-GA を、改訂ビルド R5011-20221129-GA に置き換えました。このビルドでは、Orchestrator をビルド R5011-20221117-GA にアップグレードする際に VMware 運用チームが確認したアップグレードの問題が修正されています。アップグレードの問題は、アップグレード パッケージ マニフェストのバージョンの不一致が原因で発生しました。この新しいビルドでは、新しい機能は追加されていません。

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 で解決した問題」セクションに解決した問題 #89873 を追加しました。この問題は、5.0.1 リリース ノートの第 1 版から誤って除外されました。

  • 「Edge/Gateway の既知の問題」に未解決の問題 #97559 を追加しました。

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 年 10 月 31 日。第 11 版。

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

2022 年 10 月 18 日。第 10 版。

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

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 年 9 月 28 日。第 8 版。

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

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 月 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 月 9 日。第 5 版。

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

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

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

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 年 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 月 5 日。第 1 版。

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

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

Edge/Gateway ビルド R5015-20230922-GA は 2023 年 9 月 27 日にリリースされた、リリース 5.0.1 の 5 番目の Edge/Gateway ロールアップです。

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

  • 解決した問題 93237：1,000 以上のオブジェクト グループが設定されている VMware SD-WAN で、データプレーン サービスの障害が発生し、これをリカバリするための再起動により 10 ～ 15 秒のカスタマー トラフィックの中断が発生します。

    Orchestrator ユーザー インターフェイスの [設定 (Configure)] > [ビジネス ポリシー (Business Policy)] ページで 1,000 以上のオブジェクト グループが設定されている場合、Edge にプッシュされた設定によって Edge メモリの破損が引き起こされ、Edge サービスが失敗して再起動します。

  • 解決した問題 95047：Edge Network Intelligence（分析）が有効になっていない VMware SD-WAN Edge をセキュリティ ポート スキャン ユーティリティがスキャンすると、Syslog ポート 514 が閉じていると報告され、アクセス可能ということになります。

    Edge Network Intelligence はポート 514 (Syslog) で待機します。分析が有効になっていない場合、ポート 514 は引き続きアクセス可能ですが、要求に応答しません。したがって、ポート スキャナはこのポートを「閉じている」と報告します（つまり、このポートはアクセス可能であるが、待機中のアプリケーションはない、ということになります）。

  • 解決した問題 95850：OSPF が使用されているカスタマー エンタープライズで、ユーザーが VMware SD-WAN Edge の診断バンドルを生成すると、バンドルの生成中に OSPF ルートがフラップし、その結果カスタマー トラフィックが中断することがあります。

    診断バンドルの生成の一環として、コマンド vcdbgdump -r remote-routes および vcdbgdump -r remote_routes が実行されます。これらのコマンドの実行には、カスタマー環境で 40 秒より長い時間がかかるため、イベント ディスパッチャ スレッドのキューに登録されていた OSPF Hello は処理されませんでした。このため、OSPF ネイバーシップがフラップすることにより、ネットワークが停止します。

    この問題に対する修正を行わない Edge では、メンテナンス期間以外では診断バンドルを生成しないようにするか、一時的に問題が発生しないようにする内部ツールを持っている VMware SD-WAN サポートにバンドルの生成を依頼する必要があります。

  • 解決した問題 97321：ユーザーが VMware SD-WAN Edge で Edge Network Intelligence 分析を有効にしてから、Edge が Edge サービスの再起動をトリガする場合があります。この場合、各インスタンスで 10 ～ 15 秒のカスタマー トラフィックの中断が発生します。

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

    この問題の症状は、分析の有効化中に複数回発生する可能性があります。

  • 解決した問題 98223：VMware SD-WAN Edge で Edge Network Intelligence 分析が有効になっている場合、Edge が VMware SASE Orchestrator と通信できなくなり、Orchestrator ユーザー インターフェイスで Edge がダウンとマークされる場合があります。

    分析が有効になっている場合、分析バックエンドとの Edge 通信が Orchestrator との Edge 通信と混在することがあります。その結果、Orchestrator との通信が失われ、Orchestrator は Edge がダウンしていないにもかかわらずダウンしていると宣言します。

  • 解決した問題 101431：Edge Network Intelligence をサブスクライブしているカスタマーの場合、ユーザーが VMware SD-WAN Edge で分析を有効にすると、ダッシュボードに Edge の「管理 IP アドレスが割り当てられていません (No Management IP Assigned)」というメッセージが表示される場合があります。

    まれに、Edge が管理 IP アドレスを Edge Network Intelligence バックエンドに送信しないことがあり、その結果上記のメッセージが表示されます。

  • 解決した問題 103558：Edge Network Intelligence を使用しているカスタマー エンタープライズで、VMware SD-WAN Edge の分析が有効になっている場合、ENI ダッシュボードには、その Edge の「管理 IP アドレスが割り当てられていない (No Management IP Assigned)」と表示されることがあります。

    分析を有効にすると、まれに Edge が管理 IP アドレスを Edge Network Intelligence バックエンドに送信しないことがあります。

  • 解決した問題 103700：カスタマーのアプリケーション マップにカスタマイズされたエントリがあるにもかかわらず、アプリケーションが SD-WAN によって誤って分類され、間違ったビジネス ポリシーまたはファイアウォール ルールに一致する場合があります。

    mustNotPerformDpi タグを持つアプリケーション マップ内のアプリケーションは、依然として SD-WAN の詳細なパケット インスペクション (DPI) エンジンを介して分類できます。大規模な展開では、高速データベース キャッシュを介してアプリケーション分類を検索しているときに競合が発生する場合があります。その結果、アプリケーションが mustNotperformDpi を使用して設定されている場合でも、DPI 経由で分類され、予期しない分類が行われる可能性があります。

  • 解決した問題 106865：Edge Network Intelligence サービスを使用し、エンタープライズで分析を有効にしているカスタマーの場合、IP 以外のトラフィック（RADIUS 認証など）がドロップされることがあります。

    分析が有効になっている場合、SD-WAN Edge インターフェイスで IP 以外のフレームを受信すると、Edge が誤ってこれらを IPv4 フラグメントとして処理し、フラグメント レコード リークを引き起こす場合があります。時間の経過とともに、すべてのフラグメント処理が停止し、このようなパケットがすべてドロップされる可能性があります。RADIUS 認証を使用しているカスタマーの場合、すべての Edge で認証が同時に機能しなくなることがあります。

    修正されたビルドを使用していないエンタープライズでは、唯一の回避策は、すべての Edge を再起動することです。

  • 解決した問題 109906：VMware SD-WAN Gateway で、データプレーン サービスの障害が発生してコアを生成し、リカバリするために再起動することがあります。

    この問題は、破損した帯域外メッセージを受信した場合に発生する可能性があります。これにより、配列インデックスがオーバーフローし、Gateway のサービスで例外と障害が発生します。

  • 解決した問題 110320：エンタープライズで分析が有効になっている Edge Network Intelligence をサブスクライブしているカスタマーの場合、VMware SASE Orchestrator で VMware SD-WAN Edge の名前が変更されると、変更が Edge Network Intelligence ユーザー インターフェイスに反映されない場合があります。

    Edge の Edge Network Intelligence サブモジュールは Edge 名の変更に反応せず、その結果、名前の変更は Edge Network Intelligence ユーザー インターフェイスに反映されません。

  • 解決した問題 110970：Edge Network Intelligence をサブスクライブし、高可用性トポロジを使用して 1 つ以上のサイトを展開しているカスタマーの場合、HA サイトに対して分析を有効にすると、分析が機能しない場合があります。

    複数の競合状態が原因で、Edge Network Intelligence スレッドはアクティブ Edge がスタンバイ ロールにあると想定する可能性があり、そのために分析機能が停止します。

  • 解決した問題 111924：VMware SD-WAN Edge の Gateway へのトンネルが稼動して安定しているにもかかわらず、すべてのサイトでマルチパス トラフィック（つまり、VMware SD-WAN Gateway を通過するトラフィック）がドロップされる場合があります。

    Gateway が VCMP パケット（SD-WAN の管理プロトコル）を再送信できる最大回数に制限はなく、そのような再送信により低帯域幅リンクが過負荷状態になる場合があります。また、Edge に低帯域幅リンクがある場合、再送信を十分な速度でドレインできないため、これらの再送信はスケジューラ上でのパケットの蓄積を引き起こします。最終的に、スケジューラのキューがいっぱいになり、スケジューラはすべての Edge からのパケットをドロップするようになります。Gateway を使用しないダイレクト トラフィックは、この問題の影響を受けません。

    この問題の修正が適用されていない Gateway でこの問題を回避する唯一の方法は、オペレータ ユーザーが debug.py --qos_dump_net コマンドを使用してスケジューラ上でパケットの蓄積を引き起こしている Edge を特定し、影響を受ける Gateway 内でブロックすることです。

  • 解決した問題 112115：CPU 負荷の高い VMware SD-WAN Edge でデータプレーン サービスの障害が発生し、リカバリのために再起動する場合があります。

    CPU 負荷が高い場合、デバッグ リング ロックを取得する優先順位の低いスレッドが原因で、ミューテックス監視によってトリガされる複数のサービス障害が発生する可能性があります。この問題の解決策は、特定のスレッドをロックなしと待機なしの両方の状態にするようにデータプレーンを機能強化することです。

  • 解決した問題 115904：ユーザーが VMware SASE Orchestrator を使用して VMware SD-WAN Edge の診断バンドルをトリガすると、Edge でデータプレーン サービスの障害が発生し、コアが生成され、再起動してリカバリが行われる場合があります。

    ユーザーは、[SD-WAN] > [診断 (Diagnostics)] > [診断バンドル (Diagnostic Bundle)] ページで Edge 診断バンドルを生成できます。このアクションを実行すると、dns_name_cache（追加または削除）と DNS 名キャッシュの間で競合状態が発生し、Edge サービスが使用中または削除済みの要素にアクセスしようとして、SIGSEGV または SIGBUS の理由でサービス障害が発生する可能性があります。

  • 解決した問題 116368：VMware SD-WAN Gateway のルーティング ログがキャパシティに達し、追加のエントリが蓄積されないことがあります。

    この問題は、Gateway のルーティング ソフトウェアでログ ローテーション設定が欠落しているために発生します。これは、新しいログ エントリを追加できるように、キャパシティに到達する前にルーティング ログをローテーションすることを目的としています。この設定がないと、ルーティング ログがローテーションされず、オペレータとパートナーが Gateway の重要なログ エントリを失う可能性があります。

  • 解決した問題 117037：複数の WAN リンクを使用してスポーク Edge とハブ Edge の間のトラフィックを送受信するハブ/スポーク トポロジを使用しているカスタマーの場合、WAN リンクが WAN リンクの帯域幅を集約していないため、ビジネス ポリシーによってステアリングされるトラフィックのパフォーマンスが想定よりも低くなる場合があります。

    SD-WAN はカウンタを使用して、再シーケンス キューにバッファされたパケット数を計算します。このカウンタはピアごとに管理され、ピアごとに 4K パケットのみがバッファされるようにするために使用されます。状況によっては、このカウンタが負の値になる場合があります。リリース 4.2.x より前のリリースでは、このカウンタが負の値になると、再シーケンス キュー内のパケットをフラッシュした直後に、各カウンタが 0 にリセットされました。ただし、リリース 4.3.x 以降では、このカウンタは自動的に更新され、カウンタが想定された範囲内に留まるようにしています。

    この動作の変更の結果、カウンタの計算が正しくないため、再シーケンス キューの数値が非常に高くなり、SD-WAN が各パケットをフラッシュすることによって応答することがあります。このアクションにより、帯域幅の集約が妨げられるだけでなく、単一のリンク上にあるはずのフローの効率が低下する場合があります。

    この問題を修正していない Edge では、回避策として、一致するトラフィックを単一の必須リンクにステアリングするビジネス ポリシーを設定します。

  • 解決した問題 118333：高可用性トポロジを使用して展開されたカスタマー サイトで、HA Edge ペアがモデル 520、540、または 610 のいずれかである場合、サイトでアクティブ/アクティブ（スプリット ブレイン）状態が発生しているため、複数の HA フェイルオーバーが発生することがあります。

    VMware SD-WAN Edge 520、540、および 610 は Marvel によって作成されたスイッチを使用します。ここで、インターネット バックホールが設定されている場合、アクティブ Edge を降格しないときにスタンバイ Edge もアクティブになる状況がトリガされる可能性があります。アクティブ/アクティブ状態はスタンバイ Edge を再起動することで解決され、これは Edge イベントに記録されます。

  • 解決した問題 118591：拡張された高可用性トポロジを使用して展開されたカスタマー サイトで、スタンバイ Edge の WAN リンクを使用するトラフィックが、Edge の WAN インターフェイスの複数のフラップによって中断される場合があります。

    [監視 (Monitor)] > [イベント (Events)] で複数のリンク アップ/ダウン イベントが確認されます。イベントは（その Edge モデルに対して）多数のフローが送信された場合、または多数のルートがインストールされた場合にトリガされます。

  • 解決した問題 119491：Edge Network Intelligence 分析が有効になっている VMware SD-WAN Edge の場合、Edge でのメモリ使用量が徐々に増加する場合があります。

    具体的なシナリオは、分析が有効で、RADIUS トラフィックも受信している Edge です。この場合、Edge メモリ リークが発生する場合があります。メモリ リークが十分な期間継続し、Edge のメモリ使用量が利用可能な RAM の 70% というクリティカルしきい値を超えると、Edge は防御的にサービスを再起動してリークを解消します。これにより、カスタマー トラフィックが 10 ～ 15 秒中断される場合があります。

  • 解決した問題 121998：ハブ/スポーク トポロジでステートフル ファイアウォールを使用しているカスタマーの場合、スポークとハブの間のトラフィック用に設定されたファイアウォール ルール（送信元 VLAN が含まれている）に一致するトラフィックがドロップされる場合があります。

    アプリケーション分類、ビジネス ポリシー テーブル、またはファイアウォール ポリシー テーブルのバージョンが変更されると、SD-WAN は次のパケットでフローのファイアウォール参照を実行します。タイミングの問題により、そのパケットは管理トラフィック (VCMP) 側のパケットになる可能性があります。その結果、ファイアウォール ポリシーの参照キーの作成中に、SD-WAN はスポーク Edge VLAN をハブ Edge VLAN とスワップするため、ルールと一致せず、そのトラフィックをドロップします。

    この問題の修正が適用されていない Edge の場合、カスタマーは [送信元 (Source)] を Edge VLAN から「任意」に変更できます。

  • 解決した問題 123593：高可用性トポロジを使用しているカスタマー サイトで、カスタマーが分析をオンにした状態で Edge Network Intelligence も使用している場合、まれに、VMware SD-WAN HA Edge が Edge Network Intelligence バックエンドから分析設定を取得できないことがあります。

    アクティブ Edge とスタンバイ Edge の両方が Edge Network Intelligence バックエンドからトークンを取得できます。スタンバイ Edge がアクティブ Edge の後にトークンを取得すると、アクティブ Edge のトークンが古くなり、このシナリオが発生します。

  • 解決した問題 124181：高可用性トポロジを使用しているカスタマー サイトで、カスタマーが分析をオンにした状態で Edge Network Intelligence も使用している場合、HA Edge が ENI エンドポイントに到達できないと、ログに例外エラーが表示されることがあります。

    HA Edge が Edge Network Intelligence (ENI) バックエンドに到達できない場合、「NameError: global name 'pyutil' is not defined」というエラーが表示されます。これは、別の例外を処理するときに発生する例外です。ENI エンドポイントにアクセスできない、つまり ENI が機能していない場合にのみ発生します。例外は Edge の管理プロセスを終了せず、カスタマー サイトに重大な影響を与えることはありません。ただし、ログに表示されるため、対処する必要があります。

  • 解決した問題 126336：Partner Gateway を展開するときに、プロバイダ Edge (PE) と Partner Gateway 間で BGP ネイバーシップが起動しないことがあります。

    この問題が発生すると、BGP ネイバーシップは PE と Gateway 間で確立されません。PE は接続状態のままで、TCP ハンドシェイクの ACK を送信しません。

Edge バージョン R5014-20230713-GA で解決した問題

Edge/Gateway ビルド R5014-20230713-GA は 2023 年 7 月 14 日にリリースされた、リリース 5.0.1 の 4 番目の Edge ロールアップです。

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

また、解決した問題 89217 に記載されているように、Edge ビルド R5014-20230713-GA（および 5.0.1.x Edge の後続のすべてのバージョン）は、Edge モデル 6x0 でプラットフォーム ファームウェアをアップグレードする必要があるカスタマーに推奨されるビルドです。

  • 解決した問題 103708：BGP フィルタ設定に新しいルールが追加されると、VMware SD-WAN Edge によって予期しない BGP ルートが送受信される可能性があります。

    Orchestrator から BGP フィルタに新しいルールが追加されると、古いエントリを削除することなく、Edge のルーティング設定にプレフィックス リストが追加されます。この動作により、古いルート プレフィックス リストと予期しないフィルタリング動作が発生します。

  • 解決した問題 105160：VMware SD-WAN Edge のソフトウェアのアップグレードに失敗し、Edge がアップグレードを再試行しない場合があります。

    この問題が発生すると、Edge のアップグレード プロセスで例外が発生し、Edge ソフトウェア アップグレードの設定バージョンが更新されますが、Edge は実際にはアップグレードされません。その結果、Edge はターゲット バージョンにアップグレードされたものと判断し、実際には失敗したアップグレードを再試行しません。

    この状態の Edge を修正する唯一の方法は、Edge のバージョンを変更し（ユーザーの判断でダウングレードまたはアップグレード）、その Edge ソフトウェアの更新後に、Edge の目的のアップグレードを再試行することです。

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

Edge/Gateway ビルド R5013-20230322-GA は 2023 年 3 月 25 日にリリースされ、リリース 5.0.1 の 3 番目の Edge/Gateway ロールアップです。

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

  • 解決した問題 78050：PPTP サーバが LAN 側にある場合に、VMware SD-WAN Edge でデータプレーン サービスの障害が発生することがあります。

    PPTP サーバが LAN 側にあり、インターネットからの PPTP クライアントがインバウンド ファイアウォール ルールを介して PPTP サーバに接続すると、PPTP 制御チャンネルのルックアップに失敗して Edge サービスが失敗することがあります。GRE データ チャンネルが同じリンクを介して PPTP クライアントに確実に送信されるようにするには、この制御チャンネルのルックアップが必要です。

    この問題を修正していないビルドを使用している Edge では、PPTP セッションを使用しないことのみが、カスタマーの代替的な回避策となります。

  • 解決した問題 80149：冗長トンネルがある Non SD-WAN Destination (NSD) またはクラウド セキュリティ サービス (CSS) に対してレイヤー 7 (L7) 健全性チェックが有効になっている場合、プライマリ トンネルに転送の問題があると、両方のトンネルが同時にダウンとしてマークされ、その後断続的に稼動状態になることがあります。

    この問題により、プライマリ トンネルとセカンダリ トンネルの両方の L7 プローブがプライマリ トンネル インターフェイスを介して送信されます。プライマリ トンネル インターフェイスでパケット送信に障害（遅延が長いなど）が発生すると、プライマリとセカンダリの両方の L7 プローブ パケットに影響を与え、両方のトンネルが同時に破棄され、その NSD または CSS のカスタマー トラフィックに影響を与えます。

  • 解決した問題 84593：KVM タイプの VMware SD-WAN 仮想 Edge でトンネルが起動しないことがあります。

    フレーム チェック シーケンス (FCS) を使用してパケットを受信すると、各パケットに 4 つのトレーラ バイトが追加され、DPDK IPsec プロセスがパケットの復号化に失敗します。これは、復号化の操作でこのプロセスが実際のパケット長を使用するのではなく、受信したフレーム長を使用するためです。その結果、KVM Edge は Gateaway または Orchestrator への IPsec トンネルを構築できません。

  • 解決した問題 86994：動的なブランチ間が有効になっているカスタマー エンタープライズで、このエンタープライズ内の VMware SD-WAN Edge のトラブルシューティングを試みると、dispcnt デバッグ コマンドが機能しません。

    dispcnt デバイス コマンドでは、一部のカウンタ値が提供されず、「ドメイン（null）が存在しません (Domain (null) does not exist)」で失敗します。これは、Edge 診断バンドル内の関連するログを参照するときにも失敗します。これは、カスタマー ネットワークの問題のトラブルシューティングの大きな妨げになります。

    この問題は、各ピアに対して大量のトンネルが作成および破棄されるために動的なブランチ間が有効になったエンタープライズで発生します。ピアのさまざまなメトリックを格納するカウンタは共有メモリに格納され、時間の経過とともに競合が原因でこれらの共有メモリ セグメントが不良な状態になり、カウンタは dispcnt コマンドで取得されません。

    この問題は、Edge のサービス再起動を実行することによってのみクリアできます。

  • 解決した問題 95603：Zscaler サーバが IP アドレスを変更した場合、DNS ルックアップは引き続き古い IP アドレスを使用するため、Non SD-WAN Destination (NSD) トンネルで障害が発生します。

    リモート サーバが IP アドレスを変更すると、L7 健全性チェックは失敗し、リカバリされません。この問題の修正により、IP アドレスの変更が検出され、L7 健全性チェック テーブルがフラッシュされます。

    この問題の修正が適用されていない VMware SD-WAN Edge では、Edge を再起動するとトンネルが再確立されます。

  • 解決した問題 96880：VMware SD-WAN Edge にリモート IPv6 ルートが存在しない場合があります。

    この問題は、セグメント内で 1 つのサブインターフェイスにのみ IPv6 アドレスが存在し、親のルーテッド インターフェイスには IPv6 アドレスが存在しない場合に発生します。

    この問題の修正が適用されていない Edge では、回避策として親インターフェイスで IPv6 アドレスを設定します。

  • 解決した問題 97404：VMware SD-WAN Edge IPv6/IPv4 インターフェイスが別のセグメントに移動された場合、Edge は新しいセグメントでそれぞれの IPv6/IPv4 リモート ルートを学習せず、リモート ルートは古いセグメントで保持されます。

    インターフェイスがあるセグメントから別のセグメントに移動した場合、設定の変更を完了するために Edge プロセスを再起動する必要がありますが、この問題に対して再起動は（Edge の再起動動作の変更のため。https://kb.vmware.com/s/article/60247 を参照）実行されないため、このシナリオでは Edge ルート学習が失敗します。

    この問題の修正が適用されていない Edge では、ユーザーは [リモート アクション (Remote Actions)] > [サービスの再起動 (Restart Service)] を実行して、設定の変更を完了できます。これは、適切なメンテナンス期間中に行う必要があります。

  • 解決した問題 97559：拡張高可用性トポロジを使用して展開されたカスタマー サイトで、スタンバイ ロールの VMware SD-WAN Edge に接続されている WAN リンクが、WAN リンクが接続されている Edge の WAN インターフェイスが稼動している場合でも、VMware SASE Orchestrator でダウンと表示され、カスタマー トラフィックを渡さないことがあります。

    ユーザーが tcpdump または診断バンドルのログを確認すると、ARP 要求が受信され、スタンバイ Edge はそのポートがブロックされた結果応答していないことが確認されます。拡張 HA では、Edge がスタンバイのロールを引き継ぐと、次のイベントが順番に発生します。

    1. スタンバイ Edge は、すべてのポートをブロックします。

    2. スタンバイ Edge は、拡張 HA に展開されていることを検出し、WAN ポートのブロックを解除してトラフィックを渡します。

    この問題が発生すると、イベント 1 として、初期のポート ブロッキングが完了するまでに予期せず長い時間がかかり、続くイベント 2 では、イベント 1 が完了する前にすべての WAN ポートのブロック解除が完了します。イベント 1 が完了すると、最終的な状態として、スタンバイ Edge ですべての WAN ポートがブロックされます。

    この問題を修正しない HA Edge では、回避策として、スタンバイ Edge をアクティブに昇格する HA フェイルオーバーを強制的に実行し、HA Edge の WAN リンクを起動します。

  • 解決した問題 98782：VMware SD-WAN Gateway で、IPsec トンネルの確立中にデータプレーン サービスの障害が発生し、その結果コアが生成されて再起動することがあります。

    Gateway でこの問題が発生した場合、再起動により、その Gateway に接続されている Edge と、IPsec トンネルに Gateway を使用する Non SD-WAN Destination の両方のカスタマー トラフィックが短時間中断される可能性があります。これは、Gateway が IPsec トンネルを確立しているときに競合状態が発生し、データプレーン サービスの障害がトリガされることが原因で発生します。

  • 解決した問題 99676：Wavefront を使用して VMware SD-WAN Gateway を監視しているカスタマーの場合、出力にコア使用量、ネットワーク インターフェイス (netif)、コア単位のメトリックが含まれません。

    Gateway リリース 5.0.1.3 には、Gateway のコア使用量、netif、コア単位のメトリックを Wavefront 監視サービスにエクスポートするための機能強化が含まれています。

  • 解決した問題 103527：切断後に PPTP (Point-to-Point Tunneling Protocol) セッションが再確立されません。

    PPTP セッションが再接続されると、Edge は呼び出し要求/応答が再送信されるのを確認しますが、送信された応答を受信すると、Edge は GRE-NAT エントリをクリアせずにエラーを返します。既存の GRE-NAT エントリが原因で、以降の接続試行がドロップされます。

    この問題の修正が適用されていない Edge では、回避策として [リモート診断 (Remote Diagnostics)] > [NAT のフラッシュ (Flush NAT)] を実行して NAT データベースをクリアします。

  • 解決した問題 103529：1 つ以上の 1:1 NAT ルールが設定されている高可用性トポロジを使用するカスタマー サイトの場合、HA フェイルオーバーの後で、1:1 NAT ルールを使用するトラフィックがドロップされる場合があります。

    1:1 NAT が設定された HA 設定の Edge の場合は、それぞれのフローがスタンバイ Edge と同期されると、フロー同期テーブルに情報がないために誤った宛先ルートが選択され、誤ったルート選択によってドロップが発生する可能性があります。

    この問題の修正が適用されていない HA Edge ペアでは、[リモート診断 (Remote Diagnostic)] > [フローのフラッシュ (Flush Flows)] を実行すると、次の HA フェイルオーバーまで問題を一時的に解決できます。

  • 解決した問題 103983：冗長トンネルを使用する Edge 経由の Non SD-WAN Destination があり、L7 健全性チェック機能がオンになっている VMware SD-WAN Edge の場合、プライマリ トンネルがダウンすると、バックアップ トンネルもダウンし、この NSD を使用するすべてのトラフィックがドロップされます。

    この問題は、L7 プローブが誤ったパスを通過したために、プライマリ トンネルでプローブが失敗したときにセカンダリ トンネルもプライマリ トンネルとともにダウンしていると Edge が表示することによって発生します。

  • 解決した問題 104141：VMware SD-WAN Edge の背後のユーザー、または VMware SD-WAN Gateway に接続されているカスタマーの環境で、トラフィックがその Edge を使用している場合、またはトラフィックがその Gateway を通過してトラフィックを転送できないポイントに向かう場合、重大な問題が発生する可能性があります。

    この問題が発生すると、ピアから受信する管理トンネルのタイム スタンプが増加するため、Edge または Gateway でジッター バッファ キューによって消費されるメモリ バッファ (mbuf) の数が無制限になります。これにより、ジッター計算で整数アンダーフローがトリガされ、パケットが実質的に無期限にバッファリングされます。最初はバッファリングされたフローにのみ影響しますが、十分な期間が経過すると、ジッター バッファ キューで消費される mbuf の数が使用可能な mbuf の合計に近づき、SD-WAN デバイス（Edge または Gateway）がすべてのトラフィックを完全に転送できなくなる可能性があります。これが Gateway に影響する場合、Gateway を通過するマルチパス トラフィックにのみ影響し、直接送信されるカスタマー トラフィックには影響しません。

    別のチケット #105744 も、ここで見つかったシンプトムに対処しますが、それは個別の原因を修正します。2 つのチケットの違い：#104141 に含まれる修正は、ピアによって受信される管理タイム スタンプの増加によりジッター バッファ キューによって消費されるメモリ バッファに対処します。#105744 に含まれる修正は、他に何が起きてもジッター バッファ カウントをメモリ バッファの合計の 25% に制限し、この問題が再発しないようにします。

    Edge または Gateway でこの問題を修正しない場合は、Orchestrator でメモリ バッファ (mbuf) の使用量を監視し、パケットがジッタ バッファでキューに入れられることによる mbuf の使用量の増加を探すことができます。ユーザーが問題を確認した場合、（リモート診断を介して）Edge または Gateway のフローをフラッシュすれば問題を一時的に軽減できますが、修正を適用しない限り必ず問題が再発します。

  • 解決した問題 104183：USB/LTE モデムを使用する VMware SD-WAN Edge で、データプレーン サービスの障害が発生し、コア ファイルが生成されることがあります。

    1 つ以上の USB モデムが複数回ダウンと起動を繰り返す（フラップ）と、Edge でこの問題が発生する可能性があります。

  • 解決した問題 104487：VMware SD-WAN Edge が特定の VMware SD-WAN Gateway をプライマリ Gateway として使用しているカスタマー サイトでは、Gateway が Orchestrator の監視で「稼動中」として表示されていてもインターネットに接続できないため、Gateway に向かうユーザー トラフィックに問題が発生する可能性があります。

    この問題が発生すると、パケットが Gateway の送信キューで停滞するため、Gateway はリモート アクセス サービス (RAS) へのパケットの送信に失敗します。その結果、この Gateway に接続されている Edge はトンネルを構築できません。この問題は、カスタマー トラフィックを含むデータ パケットでのみ発生し、Gateway と RAS 間のキープアライブ パケットでは発生しません。このため、Gateway は問題が発生しているにもかかわらず Orchestrator の監視で「稼動中」として表示され続けます。[ダイレクト (Direct)] というタグが付いたインターネットへのカスタマー トラフィックは、Gateway を使用してインターネットにアクセスしないため、この問題の影響を受けません。

  • 解決した問題 105360：5.0.x リリースを使用する VMware SD-WAN Gateway で、複数のデータプレーン サービスの障害が発生する場合があり、そのたびに再起動することになります。

    この問題は、Gateway が Edge から Gateway の IP アドレスへの断片化されたパケット（ping からの ICMP パケットなど）を直接受信する場合に発生する可能性があります。この問題は、断片化されたパケットが VCMP (SD-WAN Management) トンネルまたは IPsec トンネルを介して送信される場合には発生しません。

  • 解決した問題 105744：VMware SD-WAN Edge の背後のユーザー、または VMware SD-WAN Gateway に接続されているカスタマーの環境で、トラフィックがその Edge を使用している場合、またはトラフィックがその Gateway を通過してトラフィックを転送できないポイントに向かう場合、重大な問題が発生する可能性があります。

    このチケットと問題 #104141 は直接関連しており、シンプトムと原因はここで繰り返されているものと同じです：この問題が発生すると、ピアから受信する管理トンネルのタイム スタンプが増加するため、Edge または Gateway でジッター バッファ キューによって消費されるメモリ バッファ (mbuf) の数が無制限になります。これにより、ジッター計算で整数アンダーフローがトリガされ、パケットが実質的に無期限にバッファリングされます。最初はバッファリングされたフローにのみ影響しますが、十分な期間が経過すると、ジッター バッファ キューで消費される mbuf の数が使用可能な mbuf の合計に近づき、SD-WAN デバイス（Edge または Gateway）がすべてのトラフィックを完全に転送できなくなる可能性があります。これが Gateway に影響する場合、Gateway を通過するマルチパス トラフィックにのみ影響し、直接送信されるカスタマー トラフィックには影響しません。

    2 つのチケットの違い：#104141 に含まれる修正は、ピアによって受信される管理タイム スタンプの増加によりジッター バッファ キューによって消費されるメモリ バッファに対処します。#105744 に含まれる修正は、ジッター バッファ カウントをメモリ バッファの合計の 25% に制限し、この問題が再発しないようにします。

    Edge または Gateway でこの問題に対する修正が適用されていない場合、ユーザーは Orchestrator で両方のコンポーネントを監視し、パケットがジッター バッファでキューに入れられることによる mbuf の使用量の増加を探して、Edge または Gateway のフローをフラッシュすれば問題を一時的に軽減できます。ただし、修正を適用しない限り最終的に問題が再発します。

  • 解決した問題 106627：冗長トンネルも設定されている Non SD-WAN Destination (NSD) またはクラウド セキュリティ サービス (CSS) でカスタマーがレイヤー 7 (L7) 健全性チェックを使用している場合、すべてのトンネルが実際には稼動していてもダウンと表示されることがあります。

    この問題は、VMware SD-WAN Edge が、プライマリ トンネルではなくバックアップ トンネルに L7 プローブを送信し、その結果トンネルがダウンしているという誤った表示をトリガするために発生します。

  • 解決した問題 106700：VMware SD-WAN Edge で、レイヤー 7 (L7) 健全性チェックの送信元インターフェイスとしてループバック インターフェイスを設定している場合、ループバック インターフェイスのパラメータを変更すると、L7 プローブが失敗し、その L7 健全性チェックに関連付けられている IPsec トンネルがダウンとして報告されます。

    ループバック インターフェイスの設定が何らかの方法で変更されると、L7 プローブが [なし (None)] として指定された IP アドレス 0.0.0.0 のインターフェイスに送信されることがあります。その結果、プローブが失敗し、IPsec トンネルがダウンとしてマークされます。

  • 解決した問題 107302：IP アドレスの変更など、レイヤー 7 (L7) 健全性チェック プローブに選択された送信元インターフェイスが変更されると、L7 健全性チェックに関連付けられている IPsec トンネルが最大 30 秒間ダウンとマークされることがあります。

    プローブが修正されるまで最大 30 秒かかる場合があります。これにより、設定が修正される前に十分なプローブが失敗すると、IPsec トンネルがダウンとマークされる場合があります。

  • 解決した問題 107309：カスタマーが 4.x Orchestrator 上で Edge 経由の Non SD-WAN Destination の L7 健全性チェックを設定し、Orchestrator がリリース 5.x にアップグレードされると、カスタマーが L7 プローブの再試行の値を変更しても、Edge は新しい値を適用しません。

    たとえば、L7 健全性チェック プローブの再試行の値が 3 の場合（トンネルはプローブが 3 回失敗するとダウンとマークされます）、カスタマーがこの値を 1 に変更しても、L7 健全性チェックは再試行回数として元の値 3 を使用し続け、その後トンネルがダウンとマークされます。Edge は Orchestrator から受け取った新しい設定を適用していないため、この問題は Edge ビルドで修正されています。

  • 解決した問題 107356：冗長トンネルとレイヤー 7 (L7) 健全性チェックが有効になっている Non SD-WAN Destination (NSD) を展開したカスタマーの場合、プライマリ トンネルがダウンした後、セカンダリ NSD トンネルが最大 30 秒間起動しない場合があります。

    NSD が冗長なプライマリ/セカンダリ トンネルで設定されている場合、セカンダリ トンネルの L7 状態はインスタンスからインスタンスに引き継がれます。セカンダリ トンネルが起動して終了すると、L7 状態はダウンとマークされ、セカンダリ トンネルがダウン状態のままになります。セカンダリ トンネルが後で再度起動すると、L7 健全性チェック プロセスがトンネルを確認し、セカンダリ トンネルが稼動中であることを確認する L7 プローブの送信を再開するまで、最大 30 秒かかる場合があります。

  • 解決した問題 109131：切断後に PPTP (Point-to-Point Tunneling Protocol) セッションが再接続しません。

    この問題は、PPTP クライアントが WAN 経由で（リモートで）接続されていて、PPTP サーバが VMware SD-WAN Edge の LAN 側で接続されている場合に、LAN 側（PPTP サーバ）からの GRE パケットがドロップされるために発生します。

    この問題の修正が適用されていない Edge では、回避策として [リモート診断 (Remote Diagnostics)] > [NAT のフラッシュ (Flush NAT)] を実行して NAT データベースをクリアします。

Gateway バージョン R5012-20221214-GA で解決した問題

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

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

重要：

元の 5.0.1.1 Gateway ビルド (R5011-20221007-GA) のビルドの問題により、Gateway は他の 5.0.1.1 Gateway ビルドにアップグレードできず、5.0.1.1 から 5.0.1.2 に直接アップグレードする必要があります。

  • 解決した問題 96863：WAN リンクが IPv6 を優先する VMware SD-WAN Edge でデータプレーン サービスの障害が発生し、カスタマーのトラフィックが短時間中断することがあります。

    この問題は、IPv6 が有効になっている場合に Edge または VMware SD-WAN Gateway のいずれかで発生する可能性があり、その結果、サービスの障害が発生し、リカバリするために再起動します。

  • 解決した問題 97272：OSPF が使用されている高可用性トポロジのサイトでスプリット ブレイン状態（両方の VMware SD-WAN Edge がアクティブになる）が発生すると、コア ルーターへのデフォルト ルートが削除され、HA サイトはネットワーク内のピア サイトにアクセスできません。

    コア ルーターの LSA（リンク状態の広報）の経過時間がアクティブ Edge と同期しています。HA スプリット ブレイン状態が発生すると、スタンバイ Edge はアクティブに移行し、コア ルーターに新しい LSA の経過時間を送信します。アクティブ Edge とスタンバイ Edge のルーター ID が同じであるため、新しいアクティブ Edge によって異なる LSA の経過時間が送信されます。この不一致により、コア ルーターで LSA の経過時間が最大値の 3,600 に設定され、HA サイトへのコア ルートも削除され、サイトで完全に停止します。

  • 解決した問題 99650：IKEv1 を使用して Non SD-WAN Destination が設定されているカスタマー サイトでは、VMware SD-WAN Edge と NSD ピア間でトンネルが形成されず、カスタマー トラフィックがピア サイトに到達できない場合があります。

    最初のパケット分類中に、NSD トンネル上の断片化された ESP パケットが誤って通常のユーザー パケットとして分類され、監視されていないキューに送信されます。これにより、パケットがそのキューに蓄積され、処理およびリークされることがありません。

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

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

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

重要：

以前の Edge 5.0.x.x ビルドを使用している場合は、Edge を 5.0.1.2 にアップグレードする必要があります。以前の Edge 5.0.x.x ビルドは、VMware SASE ホスト型 Orchestrator で廃止としてマークされています。

詳細については、ナレッジベースの記事 https://kb.vmware.com/s/article/90042 を参照してください。

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

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

  • 解決した問題 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.net と fast.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 のスループットが高い場合に見られるため、大規模な展開（例：4,000 台の Edge と 6,000 個のトンネルがある環境）で発生する可能性が高くなります。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：VMware SD-WAN Edge が Edge 経由の Non SD-WAN Destination (NSD) またはクラウド セキュリティ サービス (CSS) のいずれかを使用するように設定されている場合、NSD または CSS トンネルが不安定になると、VMware SD-WAN Edge で定期的にデータプレーン サービスの障害が発生し、再起動することがあります。

    Edge が NSD または CSS（IPsec または GRE）のいずれかへのトンネルを破棄すると、以前に選択したトンネルの誤ったリリースが実行されて、Edge データプレーン サービスで例外がトリガされ、サービスをリストアするために Edge サービスが再起動されます。Edge サービスを再起動すると、カスタマーのトラフィックが 10 ～ 15 秒間中断します。

    この問題の修正が適用されていない Edge では、Edge 経由の NSD または CSS を 1 つの WAN リンクに関連付けることで、この問題が発生する可能性が低くなります。つまり、複数の WAN リンクで NSD または CSS を設定する代わりに、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.1 (R131-20221216-GA) にアップグレードすることで解決されます。これを行うには、6x0 Edge をリリース 5.x（5.0.0 以降）を使用する VMware SASE Orchestrator に接続し、6x0 Edge を最初に Edge ビルド R5014-20230713-GA にアップグレードする必要があります。6x0 Edge を R5014-20230713-GA にアップグレードしたら、次に、Edge のソフトウェア バージョンが変更されるのと同じ方法で、6x0 Edge プラットフォーム ファームウェアをバージョン R131-20221216-GA に更新します。

    6x0 Edge をプラットフォーム ファームウェア 1.3.1 にアップグレードするための詳細な説明やガイドについては、ナレッジベースの記事VMware SD-WAN 6X0 モデル Edge が、LED が消灯してパワーオフし、動作状態に戻るために電源の入れ直しが必要になることがあります (88970)を参照してください。このナレッジベースの記事は、2023 年 4 月 4 日に更新され、この問題の解決に必要な新しい Edge およびプラットフォーム ソフトウェアを反映しています。

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

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

    注：

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

    注：

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

  • 解決した問題 89873：VMware SD-WAN Edge のメモリ使用率が増加した場合に、Orchestrator でのメモリ使用量の警告イベントが発生し、Edge のメモリをリカバリするために予定外の Edge サービスの再起動が行われる可能性があります。

    この問題は、一意の IP アドレスとポートを持つ UDP フローが、Edge で高速で処理された場合に発生します。フローの作成は Edge で非同期的に処理され、同じフローの複数のパケットがフロー作成サービスへのキューに登録されると、フロー オブジェクトがリークし、Edge のメモリ リークが発生します。この影響は、Edge メモリの量が少ない、エントリ レベルの Edge モデル（510、610、620 など）でより一般的に発生しますが、長期間にわたるとすべての Edge モデルでメモリが重大レベル（90 秒以上にわたりメモリ使用率が 60%）に到達し、再起動する可能性があります。メモリをクリアするために計画外の Edge サービスの再起動を行うと、カスタマー トラフィックが一時的に中断する可能性があります。 

    この問題に対する修正を行わない場合、この問題がカスタマー サイトに影響を与えるのを防ぐ唯一の方法は、メモリを監視することです。メモリ使用率が 40% に到達し、Orchestrator がメモリ警告イベントを記録した場合は、メモリをクリアして、カスタマーへの影響を最小限に抑えるために、メンテナンス ウィンドウで Edge サービスの再起動をスケジュール設定します。

  • 解決した問題 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_id と segment_id の組み合わせを使用して BGP フィルタを識別しますが、特定のエンタープライズ/セグメントの組み合わせでは、SD-WAN は 1 つの PG-BGP ネイバーしか持つことができないため、Partner Gateway-BGP においては enterprise_logical_id を使用するだけで十分であったことです。

    しかしながら、同じエンタープライズ セグメントの組み合わせに対して最大 2 つの BGP ネイバー（プライマリとセカンダリ）が存在する可能性がある Gateway 上の NSD-BGP に対しては、この方法が継承されました。そのため、enterprise_logical_id と segment_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 には、この誤ったトンネルを検出して破棄するためのフェイルセーフがありません。

  • 解決した問題 93052：VMware SD-WAN Edge の背後にいるクライアント ユーザーは、長い遅延や遅いスループット速度などのトラフィック品質の劣化を確認する場合があります。

    この問題に直結する原因は、パス FSM（有限状態機械）スレッドが Edge の 100% の CPU 使用率で動作していることです。Edge の CPU 使用率が 100% になると、パス品質が劣化します。

    パス FSM スレッドが Edge CPU を最大限まで使い切っている理由は、このスレッドによって提供されているキューにより多くのメッセージが存在しているとパス FSM スレッドが断定する（実際には存在しない）ことにつながる、信頼できないカウンタ値が発生していることです。この結果、スレッドはスリープなしで常時実行されます。この修正では、実際のキュー データ構造をチェックしてキューの状態を判断する API が追加されました。

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

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

Orchestrator で解決した問題

Orchestrator バージョン R5017-20231111-GA で解決した問題

Orchestrator ビルド R5017-20231111-GA は 2023 年 11 月 14 日にリリースされた、リリース 5.0.1 の 7 番目の Orchestrator ロールアップです。

この Orchestrator ロールアップ ビルドは、6 番目の Orchestrator ロールアップ ビルド、R5016-20230801-GA 以降の以下の問題に対処します。

  • 解決した問題 102121：Orchestrator ユーザー インターフェイスの使用中に Edge のファイアウォール設定を更新せずに Edge の Secure Access 設定を複数回更新すると、Secure Access 設定の更新が Edge に送信されないことがあります。

    この問題は、エンジニアリング部門がファイアウォールの更新なしで多数の Secure Access 更新を意図的に強制するテストで最も頻繁に発生します。ただし、まれに現場のカスタマーが原因で発生する場合があります。

    修正されていない Orchestrator でこの問題が発生した場合、ユーザーはユーザー インターフェイスから Edge のファイアウォール設定を 1 回だけ手動で更新できます。ファイアウォールの手動更新後、ユーザーはユーザー インターフェイスから Edge Secure Access 設定の変更をやり直すことができます。Orchestrator は Edge Secure Access 設定の変更をユーザー インターフェイスから Edge にプッシュします。

  • 解決した問題 116531：少なくとも 1 つの Edge の説明にカンマ (,) が含まれている VMware SASE Orchestrator でレポートを生成しようとすると、レポートが適切にフォーマットされないことがあります。

    Edge の説明にカンマが含まれている場合（次のスクリーンショットに示すように）、Orchestrator のレポート サービスに混乱が生じ、想定どおりに Edge の [説明 (Description)] 列のテキスト文字列全体が含まれるのではなく、各カンマの後のテキストがレポートの次の列に分割されます。

    そのため、[転送バイト数 (Bytes Transmitted)] に関連付けられた値が表示されるのではなく、最初のカンマの後のテキストが表示され、[受信バイト数 (Bytes Received)] に 2 番目のカンマ（存在する場合）の後のテキストが表示されます（その後も同様）。レポートには引き続き [転送バイト数 (Bytes Transmitted)] と [受信バイト数 (Bytes Received)] のデータが含まれますが、右側にプッシュされ、正しい列に整列されません。

    この問題が修正されていない Orchestrator では、Edge の説明にカンマが使用されていないことを確認する必要があります。

    注：

    この問題の修正は、最初に Orchestrator リリース 5.0.1.6 に記載されていました。ただし、カンマを使用するとアプリケーション名を含むレポートのエクスポートが依然として影響を受けるため、この修正によって問題のすべてが解決されたわけではありません。この問題は 5.0.1.7 で完全に解決済みとみなされ、アプリケーション名も修正されています。

  • 解決した問題 131789：組織のシングル サインオン (SSO) を設定するときに、ID プロバイダ (IdP) の応答にロール情報が含まれている場合でも、ユーザーが Orchestrator にログインできません。

    IdP がネストされた JSON 構造でロール情報を送信する場合、Orchestrator はシングル サインオン (SSO) 経由でログインするユーザーのロールを照合できません。バージョン 5.0.1.7 以降では、ネストされた JSON 構造に存在する場合でも、Orchestrator は SSO ユーザーのロールを参照して、照合することができます。

    この問題の修正が適用されていない Orchestrator でこの問題が発生した場合の回避策は、ネストされた構造ではなく、ロールの詳細を即時レベルで送信するように IdP を設定することです。

Orchestrator バージョン R5016-20230801-GA で解決した問題

Orchestrator ビルド R5016-20230801-GA は 2023 年 8 月 2 日にリリースされた、リリース 5.0.1 の 6 番目の Orchestrator ロールアップです。

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

  • 解決した問題 64145：カスタマーは、VMware SASE Orchestrator で Partner Gateway ハンドオフを正常に設定できない場合があります。

    Orchestrator への以前の変更の一環として、Partner Gateway が古い Orchestrator ビルドに最初に展開され、ハンドオフ設定内に Orchestrator ユーザー インターフェイスが使用しなくなったレガシー キーがある場合、「updateConfigurationModule」を呼び出したときに「gatewayList」キーの下のハンドオフ設定が誤って削除されることがあります。

  • 解決した問題 122271：カスタマーが、VMware SASE Orchestrator の新しいユーザー インターフェイスを使用してプロファイルに LAN 側 NAT ルールを追加すると、これらのルールに一致するすべてのトラフィックがプロファイルを使用する Edge で失敗することがあります。

    新しいユーザー インターフェイスが、内部アドレス プレフィックスから LAN 側 NAT 外部マスクを誤って計算します。内部プレフィックスと外部プレフィックスが同じ（つまり、1:1）になるようにルールが記述されていない場合、ユーザーが新しいユーザー インターフェイスから LAN 側 NAT ルールを変更すると、ルールの動作が変更され、機能しなくなる場合があります。

    この問題の修正が適用されていない Orchestrator では、ユーザーは Orchestrator の従来のユーザー インターフェイスを使用して LAN 側 NAT ルールを編集する必要があります。

Orchestrator バージョン R5015-20230628-GA で解決した問題

Orchestrator ビルド R5015-20230628-GA は 2023 年 6 月 29 日にリリースされた、リリース 5.0.1 の 5 番目の Orchestrator ロールアップです。

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

  • 解決した問題 109710：パートナーの管理者が VMware SASE Orchestrator でパートナー ハンドオフを設定できないことがあります。

    パートナーの管理者ユーザーは、Gateway ごとのレベルで設定されている場合にパートナー ハンドオフでスタティック ルートを設定すると、「未定義のプロパティ v6Detail を設定できません (cannot set property v6Detail of undefined)」というエラー メッセージを受け取ります。オペレータ ユーザーは、問題なく変更を行うことができます。

  • 解決した問題 112605：カスタマーが [設定 (Configure)] > [デバイス (Device)] > [クラウド VPN (Cloud VPN)] > [Edge] から SD-WAN サイトにハブ クラスタを割り当てようとすると、プロファイルが応答せず、設定を保存できない場合があります。

    Orchestrator は複数のバックホール ビジネス ポリシーがある重複した設定の関連付けを作成し、重複した参照によりハブ クラスタの設定と割り当てが失敗します。

  • 解決した問題 114291：Orchestrator の新しいユーザー インターフェイスを使用しているときに、クラウド セキュリティ サービス (CSS) がプロファイルで設定されている場合、CSS が複数の異なるセグメントで変更された後、ユーザーはセグメントを切り替えることができず、[デバイス設定 (Device Settings)] を保存できません。

    この問題は、従来のユーザー インターフェイスを使用している場合ではなく、新しいユーザー インターフェイスでのみ発生します。

  • 解決した問題 114475：オペレータがリリース 4.2.0 から 5.1.0 に VMware SASE Orchestrator をアップグレードしようとすると、Orchestrator がアップグレードに失敗したことを報告することがあります。

    ログで、オペレータは次のエントリを確認します。Error while initializing CWS Server service Error: Too many connections.この問題は、vco-db-schema がインストールされる前に MySQL を再起動するとトリガされます。これは、MySQL が最大接続数を設定していないために発生します。さらに、Orchestrator はインストールに失敗したと報告しますが、実際にはインストールが完了し、Orchestrator を再起動でき、すべてのサービスは期待どおりに動作します。

Orchestrator バージョン R5014-20230408-GA で解決した問題

Orchestrator ビルド R5014-20230408-GA は 2023 年 4 月 11 日にリリースされた、リリース 5.0.1 の 4 番目の Orchestrator ロールアップです。

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

  • 解決した問題 107766：カスタマーが Edge 経由の Non SD-WAN Destination またはクラウド セキュリティ サービス (CSS) を設定し、[レベル 7 (L7) 健全性チェック (Level 7 (L7) Health Check)] オプションも設定すると、トンネルが予期せずにダウンまたは稼動中とマークされることがあります。これは、L7 健全性チェックの設定値に基づいて発生する動作とは異なります。

    この問題は、カスタマーが設定した内容に関係なく、Orchestrator がデフォルトの L7 健全性チェック パラメータを VMware SD-WAN Edge にプッシュすることが原因です。その結果、トンネルの条件がカスタマーが設定した条件と一致する場合でも、トンネルの状態はデフォルトの L7 健全性チェック値に従っているため変更されません。

  • 解決した問題 108363：VMware SASE Orchestrator を 5.x リリースにアップグレードした後、Zscaler などのクラウド セキュリティ サービス (CSS) を展開し、[レベル 7 (L7) 健全性チェック (Level 7 (L7) Health Check)] も設定されている VMware SD-WAN Edge では、その CSS を使用するトラフィックが約 30 秒間失われる場合があります。

    Orchestrator をアップグレードすると、すべての Edge に設定の更新がトリガされ、設定が修正されるまで L7 健全性チェックが設定されている一部の CSS サイトがダウンする場合があります。

    この問題は、Edge での問題に対処する「解決した問題 #107302」にリンクされています。この修正により、Orchestrator はアップグレード時に設定の更新を Edge にトリガしなくなり、#107302 の修正が適用されていない Edge が保護されます。

  • 解決した問題 110946：リリース 4.2.x 以前を使用する VMware SD-WAN Orchestrator を、リリース 4.3.x 以降を使用する SASE Orchestrator にアップグレードすると失敗することがあります。

    4.2.x 以前の Orchestrator は、Orchestrator が 4.3.x 以降にアップグレードされるときに、apt update サービス ルーチンを実行する前に apt キャッシュをクリーンアップしません。その結果、アップグレード中に MySQL データベースが再起動し、アップグレードが失敗します。

    この問題に対する修正を適用せずに 任意の Orchestrator バージョンにアップグレードする場合、オペレータはアップグレード前に rm -rf /var/lib/apt/lists/ コマンドを実行できます。

  • 解決した問題 111946：ピア リストが 100 を超えると、VMware SASE Orchestrator の [Edge] > [監視 (Monitor)] > [パス (Paths)] タブにパスが表示されません。

    ユーザーが [Edge] > [監視 (Monitor)] > [パス (Paths)] タブに移動すると、Orchestrator のバックエンドはレコード数が 100 を超えてもすべてのレコードを返します。これは、返されるレコードの最大数を制限する制約をバックエンドが省略しているためです。制限数を超えた後で返されるレコードは正規化されません。これは、ユーザー インターフェイスと互換性のある形式でフォーマットされていないことを意味します。これにより、ユーザー インターフェイスでエラーが発生します。Orchestrator は、送信された制限内のレコードのみを返す必要があります。

  • 解決した問題 111957：オペレータが VMware SASE Orchestrator をアップグレードすると、実行時間の長いスキーマの更新の失敗に関連するエラーが表示されることがあります。たとえば、新しく学習したルート（BGP または OSPF）が OFC ページに表示されないことがあります。学習したルートに関連する Orchestrator のアップロード ログにもエラーが記録されます。

    VELOCLOUD_LEARNED_PARTNER_ROUTE_ASSOC の外部キーがドロップされ、Orchestrator リリース 4.2.x からリリース 4.3.x 以降へのアップグレードで実行時間の長いスキーマの更新として再度追加されます。この外部キーは、アップグレード パスが古い 2.1.x ビルドを経由し、アップグレードの欠陥があり、BGP ルートを学習していた Gateway が Orchestrator から削除された一部の Orchestrator にはすでに存在しません。このような Orchestrator では、テーブルにすでにレコードに違反する外部キーが存在する場合、4.2.x から 4.3.x 以降へのアップグレードで外部キーの追加に失敗します。

    この問題の修正により、レコードに違反している外部キーを削除してから外部キーが再度追加されるため、根本原因が修正されます。

    この問題に対する修正を適用せずに Orchestrator にアップグレードする場合の回避策は、MySQL の VeloCloud スキーマで次のクエリを実行することです。DELETE FROM VELOCLOUD_LEARNED_PARTNER_ROUTE_ASSOC WHERE gatewayId not in (select id from VELOCLOUD_GATEWAY)。その後で、実行時間の長いスキーマの更新を再トリガします。

  • 解決した問題 112201：ユーザーが API を介してクラウド セキュリティ サービス (CSS) を設定し、CSS を [なし (空) (None (Empty))] に設定すると、VMware Edge の CSS 設定では VMware SASE Orchestrator は設定を表示しませんが、Edge のデータベースと API 応答では CSS が稼動中で動作していることが示されます。

    Orchestrator は、どの CSS オブジェクトが特定のセグメントに関連しているかを判断するために、新しい Orchestrator UI によって使用されたセグメントの CSS フィールドを使用して CSS を Edge デバイスの設定オブジェクトに関連付けないため、参照オブジェクトのみが存在します。この状態の CSS は、ビジネス ポリシーの一部として使用できません。

    この問題に対する修正が適用されていない Orchestrator では、カスタマーは API ではなく Orchestrator のユーザー インターフェイスを使用して新しい CSS を設定する必要があります。

Orchestrator バージョン R5013-20230310-GA で解決した問題

Orchestrator ビルド R5013-20230310-GA は 2023 年 3 月 13 日にリリースされた、リリース 5.0.1 の 3 番目の Orchestrator ロールアップです。

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

  • 解決した問題 105610：ユーザーが「255」で始まり「0」で終わるワイルド カード マスク（たとえば、255.0.1.0）を含む新しい IPv4 オブジェクト グループを作成しようとするか、既存の IPv4 オブジェクト グループを更新しようとすると、VMware SASE Orchestrator は、このワイルド カード マスクを許可せず、これが有効なワイルド カード表現で許可する必要があるにもかかわらず、エラーをスローします。

    5.0.x 以降では、Orchestrator にはオブジェクト グループのワイルド カード マスクの検証がなく、その結果、ユーザーがワイルド カード マスクを設定するとエラーがスローされます。

  • 解決した問題 106242：VMware SASE Orchestrator の [診断 (Diagnostics)] > [リモート診断 (Remote Diagnostics)] ページにアクセスしているユーザーが、Edge 診断の実行中に [リモート診断 (Remote Diagnostics)] ページから予期せずにログアウトされることがあります。

    この問題は、Orchestrator が可能な接続数の制限に達し、Orchestrator が正常な機能を維持するためにリモート診断ユーザーをサインアウトすることが原因で発生します。この問題は、Orchestrator が不要になったデータベース接続を誤って解放せず、Orchestrator が接続制限の動作をトリガするために発生します。

  • 解決した問題 109595：オペレータが VMware SASE Orchestrator を 4.x バージョンから 5.x バージョンにアップグレードしようとすると、アップグレードが失敗することがあります。

    この問題が発生すると、オペレータは次のエラー メッセージを確認します：「アップグレード - エラー - インストーラが戻りコード 1 で失敗しました (UPGRADE - ERROR - installer failed with return code 1)」。この問題は、Orchestrator の Docker ソフトウェアが 5.x ビルドにアップグレードするときに必要なフォルダを作成しなかったことが原因で発生します。

Orchestrator バージョン R5012-20221214-GA で解決した問題

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

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

  • 解決した問題 96538：「BGP ネイバー学習済みルートの表示 (Show BGP Neighbor Learned Routes)」リモート診断が失敗します。

    基盤となる API 呼び出しの相互運用性の問題により、「BGP ネイバー学習済みルートの表示 (Show BGP Neighbor Learned Routes)」リモート診断の実行時に検証エラーが発生します。

  • 解決した問題 100133：Orchestrator で Edge 設定にプッシュするたびにパフォーマンスの問題が発生します。

    カスタマーが Edge クラスタを関連付けて多数のビジネス ポリシー ルールを設定すると、Orchestrator で Edge にプッシュするたびにパフォーマンスの問題が発生します。

  • 解決した問題 101835：クラウド VPN が設定されている非グローバル セグメントをユーザーが選択すると、新しい Orchestrator ユーザー インターフェイスで [クラウド VPN (Cloud VPN)] セクションを使用できません。

    新しい Orchestrator ユーザー インターフェイスの [設定 (Configure)] > [Edge (Edge)] > [デバイス (Device)] 設定ページで、クラウド VPN が設定されている非グローバル セグメントをユーザーが選択すると、[クラウド VPN (Cloud VPN)] セクションを使用できません。

  • 解決した問題 102806：カスタマーは Gateway ごとのレベルで Partner Gateway ハンドオフ設定を編集できません。

    この問題は、アップグレード中にカスタマーが Partner Gateway ハンドオフを設定した場合に発生します。

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

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

Orchestrator ビルド R5011-20221129-GA はビルド R5011-20221117-GA を置き換え、Orchestrator をビルド R5011-20221117-GA にアップグレードするときに VMware オペレーション チームによって確認されたアップグレードの問題を解決します。アップグレードの問題は、アップグレード パッケージ マニフェストのバージョンの不一致が原因で発生しました。この新しいビルドでは、新しい機能は追加されていません。

この Orchestrator ロールアップ ビルドは、元の Orchestrator GA ビルド、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 テスト」の出力で、正しい結果が表示される前に、無効な内容が一時的に表示されることがあります。

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

  • 問題 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 エラーが大量に記録されて、有用なログ エントリが確認しづらくなる可能性があります。

  • 問題 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 ハンドオフでパケットのドロップが発生します。

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

  • 問題 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 を無効にする必要があります。

  • 問題 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 アドレスを取得します。

  • 解決した問題 81181：ユーザーが [設定 (Configure)] > [Edge] > [デバイス (Device)] で行った変更が、Edge が VMware SASE Orchestrator に接続されていても VMware SD-WAN Edge に適用されないことがあります。

    システムの負荷が高く、設定の変更が頻繁に行われると、Edge の管理設定スレッドが停止し、Edge はそれ以降の設定変更を適用しません。

    ユーザーは Edge サービスを再起動して問題の特定のインスタンスをクリアできますが、後で条件が満たされた場合は問題が再発する可能性があります。

  • 問題 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 未満に減らすことです。

  • 問題 84790：510/510-LTE 以外のモデル タイプを使用する VMware SD-WAN Edge を再起動したときに、Edge は誤って重大イベント「サービス wifihang を起動できません (Unable to launch service wifihang)」を VMware SASE Orchestrator に報告することがあります。

    wifihang イベント メッセージは、Edge 510/510-LTE モデルでのみ使用するように設計されており、その Edge モデルの Wi-Fi プロセスに関する問題をカスタマーに通知します。このイベント メッセージが他の Edge モデルで確認された場合、そのモデルが Wi-Fi を使用しているかどうかに関係なく（たとえば、Edge 3400）、イベント メッセージは偽りであり、イベントは無視できます。

    回避策：Edge 510 または 510-LTE 以外の Edge では、wifihang イベント メッセージは偽りであるため、無視してかまいません。

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

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

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

  • 問題 90884：ハブ クラスタ/スポーク トポロジを使用しているカスタマー エンタープライズの場合、クラスタ内のハブ Edge が 1 つ以上のスポーク Edge に再割り当てされると、それらのスポーク Edge の場所でトラフィック障害が発生する可能性があります。

    エンタープライズが Edge ソフトウェアをアップグレードするときに、クラスタ内のハブ Edge をクラスタの再分配の一部として再割り当てできるため、アップグレード後にこの問題が発生する可能性があります。この問題が発生すると、VMware SD-WAN Gateway は新しいスポーク Edge ルートをハブ Edge に送信しません。これは、Gateway がすべてのハブ Edge にすべてのスポーク Edge ルートがあることを想定し、これらのルートがハブ Edge のルーティング テーブルに含まれていないためです。その結果、転送パスがダウンするため、クラスタ内のスポーク Edge とハブ Edge 間のトラフィックが影響を受けます。

    回避策：この問題を修正した Gateway を使用していないエンタープライズで問題が発生した場合は、ハブ Edge で route reinit を実行することで一時的に解決できます。

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

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

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

  • 問題 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。

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

  • 問題 94980：高可用性トポロジで展開されたサイトの場合、VMware SD-WAN スタンバイ Edge でデータプレーン サービス エラーが発生し、HA Edge 用に PPPoE WAN リンクが設定された後に再起動することがあります。

    スタンバイ Edge によって生成されたコアを調べると、PPPoE リンクが設定された後に vc_is_use_cloud_gateway_set というメッセージが表示されています。

    回避策：メンテナンス期間中 PPPoE リンクを設定してこのアクションのリスクを管理する以外に、この問題に対する回避策はありません。

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

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

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

  • 問題 97559：拡張高可用性トポロジを使用して展開されたカスタマー サイトで、スタンバイ ロールの VMware SD-WAN Edge に接続されている WAN リンクが、WAN リンクが接続されている Edge の WAN インターフェイスが稼動している場合でも、VMware SASE Orchestrator でダウンと表示され、カスタマー トラフィックを渡さないことがあります。

    tcpdump または診断バンドルのログを確認すると、ARP 要求を受信した後、ポートがブロックされているためにスタンバイ Edge が応答していないことがわかります。

    拡張 HA では、Edge がスタンバイのロールを引き受けると、次のイベントが順次発生します。

    1. スタンバイ Edge は、すべてのポートをブロックします。

    2. スタンバイ Edge は、拡張 HA に展開されていることを検出し、WAN ポートのブロックを解除してトラフィックを渡します。

    この問題が発生すると、イベント 1 として、初期のポート ブロッキングが完了するまでに予期せず長い時間がかかり、続くイベント 2 では、イベント 1 が完了する前にすべての WAN ポートのブロック解除が完了します。イベント 1 が完了すると、最終的な状態として、スタンバイ Edge ですべての WAN ポートがブロックされます。

    回避策：スタンバイ Edge をアクティブに昇格させる HA フェイルオーバーにより、HA Edge の WAN リンクが起動します。

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

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

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

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

  • 問題 98694：カスタマー エンタープライズに冗長スタティック ルートが設定されている場合、プライマリ ルートがダウンすると、代替ルートは広報されず、トラフィックがドロップされます。

    VMware SD-WAN Edge でインターフェイスがダウンすると、インターフェイス経由でルートに到達できなくなっているにもかかわらず、代替ルートが VMware SD-WAN Gateway にアドバタイズされません。Edge 上のこれらのプレフィックスの他のインターフェイスを介した代替ルートがある場合でも、プレフィックスのルートは Gateway に存在しません。この問題は、SD-WAN サービスが、インターフェイスのダウンを処理中に到達可能な代替スタティック ルートがあるかどうかを確認せずにルート削除を送信するために発生します。

    回避策：Orchestrator を介して Edge サービスを再起動すると、問題は一時的にリカバリされます。

  • 問題 106160：VMware SD-WAN Edge が DNS サーバとして設定され、ネクスト ホップがクライアントが DNS サーバにクエリを実行するインターフェイスに対して定義された Gateway である場合、応答はありません。

    DNS 要求パケットは DNS サーバによって受信されます。ただし、応答パケットは iptables 接続トラッキングに基づいてルート テーブル ルックアップを行い、ネクスト ホップ Gateway の IP アドレスを検出して MAC アドレスを解決します。最終的に、DNS 応答パケットは送信者ではなく Gateway の MAC アドレスを使用します。

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

  • 問題 107994：特権レベルの Secure Edge Access ユーザーがいるカスタマー エンタープライズでは、VMware SASE Orchestrator ユーザー インターフェイスからの [リモート診断 (Remote Diagnostics)] > [HA 情報 (HA Info)] の実行やスタンバイ Edge へのログインなどの高可用性操作が失敗することがあります。

    特権レベルの Secure Edge Access ユーザーがプロビジョニングされると、root アカウントは完全にブロックされます。問題は、高可用性操作が root としてスタンバイ Edge と通信することに依存しており、root アカウントが完全にブロックされているため、実行された HA 操作がすべて機能しなくなることです。この問題は、ユーザー ロール（スーパー ユーザー、標準、またはその他のロール）に関係なく発生します。

    回避策：カスタマーがこの問題を回避するオプションは 2 つあります。

    1. パスワードベースの認証に戻すことができます。

    2. 権限を持つすべての Secure Edge Access ユーザーを削除するか、ベーシック ユーザーに変更することができます。

  • 問題 110564：拡張された高可用性トポロジで展開されたカスタマー サイトの場合、アクティブ Edge とスタンバイ Edge 間のデータ同期に使用される TCP セッションがダウンし、WAN リンク トラフィックがスタンバイ Edge で転送されないことがあります。

    子プロセスがアクティブ Edge とスタンバイ Edge 間の TCP セッション用のポートを使用するシナリオが考えられます。このシナリオでは、バインド エラーが原因でアクティブ Edge が TCP サーバを起動できません。そのため、スタンバイ Edge のインターフェイス状態が交換されず、また、トラフィックの転送に WAN リンクを使用できません。

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

  • 問題 115136：ルーティングに BGP を使用しているカスタマー エンタープライズの VMware SD-WAN Edge で、メモリ使用量が徐々に増加する場合があります。

    Edge の BGP デーモンは、数日間にわたって Edge 上で徐々にメモリ リークを引き起こしており、BGP がその Edge に設定されていない場合でもこの状況が発生することがあります。メモリ リークが十分な期間継続し、Edge のメモリ使用量が利用可能な RAM の 60% というクリティカルしきい値を超える状態が 90 秒以上続くと、Edge は防御的にサービスを再起動してリークを解消します。これにより、カスタマー トラフィックが 10 ～ 15 秒中断される場合があります。

    回避策：Edge を修正せずにこの問題を修正する唯一の方法は、BGP プロセスを終了して再起動するか、適切なサービス期間中に HA フェイルオーバー/Edge サービスの再起動をプリエンプティブに実行することです。

  • 問題 117565：Partner Gateway で設定されたカスタマー エンタープライズのユーザーの環境で、マルチパス トラフィック（VMware SD-WAN Gateway を通過するトラフィック）がドロップすることがあります。

    インターネット/クラウドに直接送信されるトラフィックまたはハブからスポークへのトラフィックは、Gateway を使用しないため影響を受けません。この問題は、Gateway のパートナー ハンドオフが無効になっている場合にトリガされ、その結果、カスタマー エンタープライズへの Gateway のすべての Gateway IPsec (VCMP) トンネルがダウンします。この問題は、ハンドオフが無効になった後も Gateway ハンドオフ IP アドレスがクリアされず、Gateway がこの無効なハンドオフ IP アドレスで同じサブネット チェックを引き続き実行することが原因で発生します。

    回避策：Gateway を再起動すると、問題の特定のインスタンスは解決されますが、同じ条件下での繰り返しは回避されません。

  • 問題 125509：下位の VMware SD-WAN Edge モデルを使用しているカスタマー エンタープライズでは、使用されているルーティング プロトコルに応じて、BFD、BGP、または OSPF のフラップが発生することがあります。

    動的ルーティングや高可用性の設定と組み合わせた高フロー スケールのエントリ レベル Edge プラットフォーム（510、520、540、610、および 620）では、アグレッシブな Hello および Dead インターバル タイマーが設定されているときに、OSPF/BGP ルーティング フラップが発生する可能性があります。また、カスタマーが、分析がオンになっている Edge Network Intelligence も使用している場合は、この問題が発生する可能性が高くなります。

    回避策：この問題が発生した場合の回避策は、OSPF（10、40）または BGP（60、180）のデフォルトのインターバル タイマーに戻すか、BFD を完全に無効にすることです。

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