VMware SD-WAN 4.2.2 リリース ノート

2023 年 4 月 25 日更新 VMware SD-WAN™ Orchestrator バージョン R422-20220715-GA VMware SD-WAN™ Gateway バージョン R422-20220805-GA VMware SD-WAN™ Edge バージョン R422-20220805-GA 各リリース ノートへの追加および更新を定期的にご確認ください。

リリース ノートの概要

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

• 対象ユーザー
• 互換性
• 重要な注意事項
• 新しいハードウェア プラットフォームのサポート
• 改訂履歴
• 解決した問題
• 既知の問題

対象ユーザー

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

互換性

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

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

Orchestrator	Gateway	Edge
		ハブ	ブランチ/スポーク
4.2.2	4.0.0	4.0.0	4.0.0
4.2.2	4.2.2	4.0.0	4.0.0
4.2.2	4.2.2	4.2.2	4.0.0
4.2.2	4.2.2	4.0.0、4.0.2	4.2.2
4.2.2	4.0.0	4.2.2	4.0.0、4.0.2
4.2.2	4.0.2	4.2.2	4.0.0、4.0.2
4.2.2	4.0.0	4.2.2	4.2.2
4.2.2	3.4.6	3.4.6	3.4.6
4.2.2	4.2.2	3.4.4、3.4.5、3.4.6	3.4.6
4.2.2	4.2.2	4.2.2	3.4.4、3.4.5、3.4.6
4.2.2	4.2.2	3.4.4、3.4.5、3.4.6	4.2.2
4.2.2	3.3.2 P2 *	3.3.2 P2 *	3.3.2 P2 *
4.2.2	4.2.2	3.3.2 P2, 3.3.2 P3 *	3.3.2 P2 *
4.2.2	4.2.2	4.2.2	3.3.2 P2, 3.3.2 P3 *
4.2.2	4.2.2	3.3.2 P2, 3.3.2 P3 *	4.2.2
4.2.2	3.2.2 *	3.2.2 *	3.2.2 *
4.2.2	4.2.2	3.2.2 *	3.2.2 *
4.2.2	4.2.2	4.2.2	3.2.2 *
4.2.2	4.2.2	3.2.2 *	4.2.2
4.2.1	4.2.2	4.2.2	4.2.1
4.2.1	4.2.1	4.2.2	4.2.2
4.2.2	4.2.1	4.2.2	4.2.2
4.0.2	4.0.2	4.2.2	4.0.2

警告：VMware SD-WAN リリース 3.2.x、3.3.x、および 3.4.x のサポートは終了しました。

• 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 を選択できます。

重要な注意事項

高可用性トポロジを使用するサイトでの潜在的な問題

高可用性トポロジで Edge のペアが展開されているサイトでは、アクティブ/アクティブ状態を解決するためにスタンバイ Edge が 1 回以上再起動すると、問題が発生する場合があります。スタンバイ Edge が再起動すると、カスタマー トラフィックが中断され、拡張高可用性トポロジを使用するサイトへの影響が大きくなる可能性があります。これは、スタンバイ Edge がカスタマー トラフィックも渡すためです。この問題は、これらのリリース ノートの「Edge/Gateway の既知の問題」セクションの問題 #85369 で追跡されています。

高可用性での 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 非対応のタイプにする必要があります。

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

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

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

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

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)」を参照してください。

新しいハードウェア プラットフォームのサポート

Edge 510N、Edge 610N、Edge 620N、Edge 640N、Edge 680N

VMware は、統合された Wi-Fi を含まないいくつかの新しい SD-WAN Edge ハードウェア モデルを導入する予定です。これには、Edge 510N、610N、620N、640N、および 680N が含まれます。これらの Edge モデルは、このリリースでサポートされる予定です。VMware SD-WAN/SASE Orchestrator の設定に含まれる Wi-Fi 設定は、これらの Edge モデルに影響を与えません。

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

Edge モデル 510N、610N、620N、640N、および 680N は、Wi-Fi 対応の同等モデルと同じであるように見えますが、同じモデルの Wi-Fi 対応の Edge と Wi-Fi 非対応の Edge（たとえば、Edge 640 と Edge 640N）を高可用性ペアとして展開することはサポートされません。高可用性ペアとして展開される Edge は、必ず、両方とも Wi-Fi 対応または両方とも Wi-Fi 非対応のタイプにする必要があります。

ドキュメントの改訂履歴

2021 年 9 月 29 日。第 1 版

2021 年 12 月 21 日。第 2 版

• 「Orchestrator で解決した問題」に新しい Orchestrator ビルド R422-20211216-GA を追加しました。Orchestrator ビルドは、Log4j バージョン 2.16.0 に更新することで、Apache Log4j の脆弱性 CVE-2021-44228 を修正します。Apache Log4j の脆弱性の詳細については、VMware セキュリティ アドバイザリ VMSA-2021-0028.5 を参照してください。
• 「重要な注意事項」に次の注意事項を追加：VMware SD-WAN Edge モデル 520、540、620、640、680、3400、3800、および 3810 で自動ネゴシエーションを無効にする場合の制限事項。このリリース ノートでは、ここで示されている Edge モデルの一部のイーサネット ポートで強制速度を設定するときに発生する可能性のある問題について説明します。

2022 年 1 月 4 日。第 3 版

• 「Edge で解決した問題」セクションに新しい Edge ビルド R422-20211216-GA を追加しました。このビルドはリリース 4.2.2 の新しい Edge GA ビルドです。
• この Edge ビルドには、解決した問題 #53951、#67060、#70919、#70954、#72245、#72425、#73251、#72688 が含まれ、該当するセクションで説明しています。

2022 年 1 月 21 日。第 4 版

• 「Edge で解決した問題」セクションに新しい Edge ビルド R422-20220119-GA を追加しました。このビルドはリリース 4.2.2 の新しい Edge GA ビルドです。
• この Edge ビルドには、解決した問題 #58791、#68785、#70933、#72498、#75992、#77040、#77525、#77586 が含まれ、該当するセクションで説明しています。
• 「Orchestrator で解決した問題」に新しい Orchestrator ビルド R422-20220112-GA を追加しました。この Orchestrator ビルドは、Log4j バージョン 2.17.0 に更新することで、Apache Log4j の脆弱性 CVE-2021-44228（最初は Log4j バージョン 2.16.0 を含む Orchestrator ビルド R422-20211216-GA で対処済み）および CVE-2021-45046 を修正します。Apache Log4j の脆弱性と VMware 製品への影響に関する最新情報については、VMware セキュリティ アドバイザリ VMSA-2021-0028.9 を参照してください。

2022 年 2 月 7 日。第 5 版

• 4.2.2 GA ビルドで問題が繰り返し発生していたため、問題 #55327 を「Edge/Gateway で解決した問題」から「Edge/Gateway での未解決の問題」に移動しました。

2022 年 2 月 18 日。第 6 版

• 「Edge で解決した問題」セクションに新しい Edge ビルド R422-20220210-GA を追加しました。このビルドはリリース 4.2.2 の新しい Edge GA ビルドです。
• この Edge ビルドには、解決した問題 #48017、#55327、#57281、#66691、#72859、#72925、#78003、#78300、#78678、#81224 が含まれ、該当するセクションで説明しています。

2022 年 3 月 2 日。第 7 版

• 新しいハードウェア プラットフォームのサポートに、次の重要な注意事項を追加しました。「注：高可用性での Wi-Fi 対応 Edge と Wi-Fi 非対応 Edge の混在はサポートされません。」が Edge 510N、Edge 610N、Edge 620N、Edge 640N、および Edge 680N セクションに追加されました。

2022 年 3 月 16 日。第 8 版

• 「Edge で解決した問題」セクションに新しい Edge ビルド R422-20220310-GA を追加しました。このビルドはリリース 4.2.2 の新しい Edge GA ビルドです。
• Edge ビルド R422-20220310-GA には、解決した問題 #57597、#65695、#67745、#68923、#70586、#77625、#77642、#81221、#83212 が含まれ、該当するセクションで説明しています。
• 「互換性」セクションに、Orchestrator および Gateway のリリース 3.4.x ソフトウェアが 2022 年 3 月 30 日にジェネラル サポートの終了 (EOGS) となり、2022 年 6 月 30 日にテクニカル ガイダンスの終了 (EOTG) を迎えるという新しい警告を追加しました。これは、Orchestrator および Gateway のみが対象です。3.4.x Edge ソフトウェアは、2022 年 12 月 31 日からサポート終了への移行期間に入ります。

2022 年 3 月 23 日。第 9 版

• 「Edge/Gateway の既知の問題」セクションに問題 #84825 を追加しました。
• 解決した問題 #58791 をさらに編集し、このチケットで多数の BGP の match および set フィルタで設定された HA サイトが修正されるという部分を削除しました。問題のこの部分はこのチケットでは修正されず、問題 #84825 で追跡されます。

2022 年 3 月 31 日。第 10 版。

• 最新の Edge ロールアップ ビルド 422-20220310-GA で見つかった「解決した問題 #83212」を「未解決の問題」に再分類しました。  #83212 は、「Edge/Gateway の既知の問題」セクションに移動しました。

2022 年 4 月 13 日。第 11 版

• 「Edge/Gateway の既知の問題」セクションに未解決の問題 #62701 を追加しました。現時点では、この問題はすべてのリリースで未解決のままであるためです。
• 元の Edge ビルド R422-20220310-GA に加えて、Gateway ビルド R422-20220310-GA を「Edge/Gateway で解決した問題」に含めました。
• Gateway ビルド R422-20220310-GA も 2022 年 3 月 15 日にリリースされました。これは現在では 4.2.2 のデフォルト ビルドであり、その機能は ESXi バージョン 7.0 のサポートが検証済みです。ESXi バージョン 7.0 の VMware ハイパーバイザーを使用して Gateway を展開またはアップグレードする場合は、このビルド以降のみを使用する必要があります。

2022 年 4 月 20 日。第 12 版

• 「Edge/Gateway で解決した問題」セクションに新しい Edge/Gateway ビルド R422-20220419-GA を追加しました。このビルドはリリース 4.2.2 の新しい Edge および Gateway GA ビルドです。
• Edge/Gateway ビルド R422-20220419-GA には、解決した問題 #65466、#67336、#69194、#83946、および #84825 が含まれ、該当するセクションで説明しています。

2022 年 5 月 6 日。第 13 版

• Edge ロール アップ ビルド R422-20211216-GA での解決した問題のリストから、解決した問題 #67060 を誤って追加された重複として削除しました。  #67060 の修正は、元の GA ビルド R422-20210923-GA に含まれていたもので、4.2.2 リリース ノートの最初の公開から適切に文書化されていました。
• リリース 4.0.x がサポート終了に近づいていることを知らせる新しい警告を「互換性」セクションに追加しました。

2022 年 5 月 12 日。第 14 版。

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

2022 年 5 月 18 日。第 15 版

• 「Edge/Gateway で解決した問題」セクションに新しい Edge/Gateway ロールアップ ビルド R422-20220511-GA を追加しました。これは 6 番目の Edge/Gateway ロールアップ ビルドで、リリース 4.2.2 の新しい Edge/Gateway GA ビルドです。
  Edge/Gateway ビルド R422-20220511-GA は、問題 #67201 の修正を含んでいて、このセクションで文書化されています。

2022 年 5 月 27 日。第 16 版

• 「Edge/Gateway で解決した問題」セクションに新しい Edge/Gateway ロールアップ ビルド R422-20220518-GA を追加しました。これは 7 番目の Edge/Gateway ロールアップ ビルドで、リリース 4.2.2 の新しい Edge/Gateway GA ビルドです。
  Edge/Gateway ビルド R422-20220518-GA には、問題 #80814、#82485、#88757、および #88796 に対する修正が含まれ、該当するセクションで説明しています。
• Orchestrator の新しい既知の問題として問題 #88796 を追加しました。最新の Gateway ビルドに修正が含まれているため、このチケットは、Orchestrator OVA にのみ適用される問題を追跡します。
• 「Edge/Gateway の既知の問題」セクションに問題 #85369 および #85461 を追加しました。

2022 年 6 月 13 日。第 17 版

• 新しい「重要な注意事項」として、「高可用性トポロジを使用するサイトでの潜在的な問題」を追加しました。これは、Edge のペアに高可用性トポロジを使用しているカスタマーのサイトで現在発生している問題に関する情報を提供します。この問題は、「Edge/Gateway の既知の問題」にある問題 #85369 で引き続き追跡されます。
• 「互換性」で、リリース 4.2.x Edge ソフトウェアのサポート期間の終了日を修正しました。Edge ソフトウェアは別の項目として分類され、次のように記載されています。「リリース 4.2.x の Edge は、2023 年 6 月 30 日にジェネラル サポートの終了 (EOGS) となり、2023 年 9 月 30 日にテクニカル ガイダンスの終了 (EOTG) を迎えます。」  個別の Orchestrator と Gateway のエントリは、以前と同じサポート期間の終了日を保持します。
• 「Edge/Gateway で解決した問題」セクションの「解決した問題 #53951」を改訂し、現場でこの問題に遭遇したカスタマーに影響を与える可能性のある別のシナリオを追加しました。

2022 年 7 月 1 日。第 19 版

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

2022 年 7 月 13 日。第 20 版

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

2022 年 7 月 26 日。第 21 版

• 「Edge/Gateway で解決した問題」セクションに新しい Edge/Gateway ロールアップ ビルド R422-20220530-GA を追加しました。これは 8 番目の Edge/Gateway ロールアップ ビルドで、リリース 4.2.2 の新しい Edge/Gateway GA ビルドです。
  Edge/Gateway ビルド R422-20220530-GA には、問題 #83437 および #87205 に対する修正が含まれ、該当するセクションで説明しています。

2022 年 8 月 8 日。第 22 版

• 「Edge/Gateway で解決した問題」セクションに新しい Edge/Gateway ロールアップ ビルド R422-20220805-GA を追加しました。これは 9 番目の Edge/Gateway ロールアップ ビルドで、リリース 4.2.2 の新しい Edge/Gateway GA ビルドです。
• Edge/Gateway ビルド R422-20220805-GA には、問題 #52659、#59862、#80028、#85369、#87923、#89235、#90280、#90283、#93062、および #94395 に対する修正が含まれ、該当するセクションで説明しています。

2022 年 8 月 10 日。第 23 版

• 「Orchestrator で解決した問題」セクションに新しい Orchestrator ロールアップ ビルド R422-20220715-GA を追加しました。これは 3 番目の Orchestrator ロールアップ ビルドで、リリース 4.2.2 の新しい Orchestrator GA ビルドです。
• Orchestrator ビルド R422-20220715-GA には、問題 #85883 および #88796 に対する修正が含まれ、該当するセクションで説明しています。

2022 年 8 月 26 日。第 24 版。

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

2022 年 9 月 9 日。第 25 版。

• 「Edge/Gateway の既知の問題」セクションに未解決の問題 #89217 を追加しました。
• 9 番目のロールアップ ビルド R422-20220805-GA の「Edge/Gateway で解決した問題」セクションに解決した問題 #93383 を追加しました。この問題は誤って除外されていました。

2022 年 9 月 28 日。第 26 版。

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

2022 年 10 月 3 日。第 27 版

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

2022 年 10 月 31 日。第 11 版。

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

2022 年 12 月 6 日。第 12 版。

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

2023 年 1 月 30 日第 13 版。

• 既知の問題 #89217 を改訂し、問題を解決するために必要な改訂済み Edge バージョン (R5012-20230123-GA-103475) およびプラットフォーム ファームウェア バージョン (R131-20221216-GA) を反映しました。このチケットには、#89217 を取り上げ、6x0 Edge をアップグレードするための詳細な手順が含まれているナレッジベースの記事へのリンクも追加されています。
• 互換性セクションで、4.2.x のサポート終了に関する「重要な注意事項」を改訂し、リリース 4.3.x を追加して、SD-WAN Edge ソフトウェアの新たに改訂された日付を反映しました。

2023 年 4 月 25 日。第 14 版。

• 「互換性」セクションを更新し、すべての 3.x リリースがサービス期間の終了 (EOSL) に達したことを記載しました。また、4.x のセクションを更新し、4.2.x Orchestrator および Gateway がサービス期間の終了 (EOSL) に達したことを記載しました。追加情報については、ナレッジベースの記事「お知らせ： VMware SD-WAN リリース 4.x のサポート期間の終了 (88319)」を参照してください。

解決した問題

解決した問題は、以下のとおり分類されています。

• Edge/Gateway で解決した問題
• Orchestrator で解決した問題

Edge/Gateway で解決した問題

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

Edge/Gateway バージョン R422-20220805-GA は 2022 年 8 月 8 日にリリースされ、リリース 4.2.2 の 9 番目の Edge/Gateway ロールアップです。

この Edge/Gateway ロールアップ ビルドは、8 番目の Edge/Gateway ロールアップ、バージョン R422-20220530-GA 以降の以下の重大な問題に対処します。

• 解決した問題 52659：VMware SD-WAN Edge が DHCP リレー エージェントとして設定されている場合、Edge は DHCP NAK パケットをクライアントに転送しません。

  DHCP サーバが DHCP NAK パケットを送信すると、DHCP リレーとして設定されている Edge はパケットを転送せずにドロップします。 

• 解決した問題 59862：リモート診断の [インターフェイスの状態 (Interface Status)] を実行すると、「テスト用のデータの読み取りエラー」というメッセージが表示されてテストが失敗することがあります。

  この問題は、USB モデムを挿入して取り外した後に、VMware SD-WAN Edge のネットワーク設定ファイルに不要な USB モデム エントリが残っていることが原因で発生します。この問題の修正により、不要なデータがグレースフルに処理され、テストが正しく実行されるようになります。Edge に修正を適用しない場合、Edge を再起動すると不要なエントリがクリアされ、テストが正しく実行されます。

• 解決した問題 80028：高可用性トポロジを使用して展開されたサイトで、スタンバイ Edge にデータプレーン サービスの障害が発生し、その結果再起動する場合があります。

  この問題は、スタンバイ Edge でのみ発生し、アクティブ Edge では発生しません。この問題は、パイプライン内でまだパケットが処理中の間に詳細なパケット インスペクション エンジンがクリーンアップを呼び出したときの競合状態により発生します。これは、いつでも発生する可能性があります。スタンバイ Edge はトラフィックを渡さないため、標準の HA 設定を使用しているユーザーには影響はありませんが、拡張 HA 展開ではスタンバイ Edge もトラフィックを渡すため、スタンバイ Edge サービスを再起動すると、スタンバイを通過するカスタマー トラフィックが約 15 秒間中断されます。 

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

  ロード イベントとシステム イベントによってトリガされた条件により、アクティブ Edge では、スタンバイ Edge への HA ハートビートのタイムリーな配信に遅延が発生します。遅延により、スタンバイ Edge がハートビートを失い、誤ってアクティブ ロールを引き受け、アクティブ/アクティブ状態が発生します。アクティブ/アクティブ状態からリカバリするために、スタンバイ Edge が再起動します（場合によっては複数回）。 

  サイトがアクティブ/アクティブになると、従来の HA 設定では、スタンバイ Edge はこのトポロジでトラフィックを渡さないため、トラフィックの中断が最小限に抑えられますが、スタンバイ Edge もトラフィックを渡す拡張 HA 展開では、再起動によって一部のカスタマー トラフィックが中断されます。

• 解決した問題 87923：不正な形式の ICMP パケットが VMware SD-WAN Edge に送信されると、Edge でデータプレーン サービスの障害が発生し、その結果再起動することがあります。

  Edge は IP パケットの長さ（IP パケット長が 24 の ICMP パケットなど）を検証しません。これにより、Edge のメモリが破損し、データプレーン サービスの障害と再起動がトリガされる可能性があります。 

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

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

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

• 解決した問題 90280：高可用性トポロジを使用して展開され、動的 Edge 間を使用するように設定されたサイトで、VMware SD-WAN HA Edge が予期せずにフェイルオーバーすることがあります。

  この問題は、他の Edge 間の動的トンネルの作成と破棄の割合が高いサイトで発生する可能性があります。このようなシナリオでは、Edge が稼動中のインターフェイスの数を誤って把握し、Edge サービスがすべてのリンクが停止していると判断して HA フェイルオーバーをトリガする可能性があります。

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

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

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

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

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

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

• 解決した問題 94395：高可用性トポロジを使用して展開されたサイトでは、アクティブ Edge に障害が発生した後にスタンバイ Edge がアクティブ状態に移行されないため、HA フェイルオーバーが失敗し、カスタマー トラフィックが中断されることがあります。

  この問題は、複数の HA Edge ペアが同じアップストリーム WAN スイッチまたはブロードキャスト ネットワークに接続されている場合に発生する可能性があります。このシナリオでは、HA Edge が非ピア HA WAN ハートビートを処理することができ、これがローカル HA の状態に影響し、スタンバイ Edge がアクティブに昇格されないなどの予測できない HA 動作につながります。

  この問題の修正を含まない Edge ビルドを使用している HA Edge ペアでは、回避策として、2 つの異なる HA ペア間で同じブロードキャスト ネットワークを共有しないようにします。

___________________________________________________________________

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

Edge/Gateway バージョン R422-20220530-GA は 2022 年 6 月 1 日にリリースされ、リリース 4.2.2 の 8 番目の Edge/Gateway ロールアップです。

この Edge/Gateway ロールアップ ビルドは、7 番目の Edge/Gateway ロールアップ、バージョン R422-20220518-GA 以降の以下の重大な問題に対処します。

• 解決した問題 83437：拡張された高可用性トポロジで設定されたサイトの場合、VMware SD-WAN HA Edge を 4.2.x リリースにアップグレードすると、サイトでのパフォーマンスが劣化します。また、1 つ以上の WAN インターフェイスがいずれかの HA Edge で実際には切断されていても、「稼動中」と表示されることがあります。

  これは、高可用性 Edge の起動サイクル中にインターフェイスが設定される方法に関連するプラットフォームの問題です。場合によっては、拡張 HA 設定で、1 台の HA Edge にのみ物理的に接続された WAN インターフェイスが両方のユニットに接続しているという不正確なフラグ付けがされることがあります。その結果、影響を受けるインターフェイス上の WAN リンクが断続的に最大 100% 劣化し、そのリンク上のすべてのトラフィックがドロップされます。

  ユーザーは、[リモート診断 (Remote Diagnostics)] に移動して [インターフェイスの状態 (Interface Status)] 診断を実行することによって、この問題を特定できます。影響を受ける WAN 回線の場合、出力は次のようになります。「リンクが検出されました (Link detected): true」と表示されるが、速度が「0mps、半二重」と表示され、このサイトではこの問題が生じています。

  この問題は、拡張 HA Edge を 4.2.x リリースにアップグレードするときに発生するのが最も一般的ですが、すでに 4.2.x リリースにアップグレード済みの拡張 HA Edge でも発生する可能性があります。この問題がトリガされるときは、起動サイクルであるため HA Edge は後で再起動されます。

  この修正が適用されていないビルドを使用している HA Edge の場合、HA フェイルオーバーを強制することで問題を修正できます。これは、Orchestrator で [リモート アクション (Remote Actions)] > [HA フェイルオーバーを強制的に行います (Force HA Failover)] を使用して実行できます。これにより状態は修正されますが、後で HA Edge を再起動しても、同じ問題の再発を回避できることにはなりません。

• 解決した問題 87205：カスタマーが Partner Gateway を使用して VMware SD-WAN Edge を展開している場合、Edge が Partner Gateway から新しいルートを学習すると、カスタマー トラフィックが中断することがあります。

  この問題は、トラフィックが誤ったビジネス ポリシーと照合することが原因で発生します。たとえば、Partner Gateway に送信される DHCP トラフィックをインターネット バックホール ルールと照合することで、カスタマー トラフィックが中断することがあります。

  修正を行わない場合、リモート診断の「フローのフラッシュ」を使用して Edge のフローをフラッシュすることでこの問題が修正されます。この方法では、将来 Edge によって Partner Gateway への新しいルートが学習されたときにこの問題が発生する可能性を回避することはできません。

___________________________________________________________________

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

Edge/Gateway バージョン R422-20220518-GA は 2022 年 5 月 24 日にリリースされ、リリース 4.2.2 の 7 番目の Edge/Gateway ロールアップです。

この Edge/Gateway ロールアップ ビルドは、6 番目の Edge/Gateway ロールアップ、バージョン R422-20220511-GA 以降の以下の重大な問題に対処します。

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

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

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

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

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

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

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

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

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

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

  注：この修正は、Gateway OVA のみを対象としています。Orchestrator OVA に影響を与える問題は同じチケット #88796 で追跡されますが、Orchestrator セクションに配置されています。

___________________________________________________________________

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

Edge/Gateway バージョン R422-20220511-GA は 2022 年 5 月 16 日にリリースされ、リリース 4.2.2 の 6 番目の Edge/Gateway ロールアップです。

この Edge/Gateway ロールアップ ビルドは、5 番目の Edge/Gateway ロールアップ バージョン R422-20220419-GA 以降の以下の重大な問題に対処します。

• 解決した問題 67201：高可用性トポロジを使用しているサイトでは、VMware SD-WAN スタンバイ Edge が複数回再起動し、カスタマー トラフィックが中断する可能性があります。

  スタンバイ Edge が検出されると、アクティブ Edge はすべてのパス情報をスタンバイ Edge に同期します。  ただし、パス同期メッセージの数が多い場合は、Edge がこれらのパス同期メッセージを処理する方法によって、スタンバイ Edge でデータプレーン サービスの障害が発生するか、スレッドの優先度が反転して、ハートビート処理が遅延し、アクティブ/アクティブ状態になる可能性があります。従来の HA トポロジでこれらのいずれかの問題が発生した場合、スタンバイ Edge はカスタマー トラフィックを渡さないため、カスタマーへの影響は最小限に抑えられます。ただし、拡張 HA 展開では、スタンバイ Edge もトラフィックを渡すため、再起動によって一部のカスタマー トラフィックが中断されます。この修正を含む HA Edge では、問題の発生を防ぐために、パス情報処理コードのパスが強化されています。

___________________________________________________________________

Edge および Gateway バージョン R422-20220419-GA で解決した問題

Edge/Gateway バージョン R422-20220419-GA は 2022 年 4 月 20 日にリリースされ、Edge および Gateway バージョン R422-20220310-GA 以降の以下の重大な問題に対処します。

• 解決した問題 65466：大規模な BGP ルート交換を処理する VMware SD-WAN Gateway または VMware SD-WAN Edge で、特定のデバッグ コマンドの実行時または診断バンドルの生成時に、データプレーン サービスの障害が発生し、再起動することがあります。

  Edge または Gateway が多数のルート（たとえば、50K BGP ルートを広報している Edge、または Edge から 100K 超の BGP ルートを学習している Gateway）を処理している場合に、デバッグ コマンド dispcnt（パラメータを指定）も実行するとこの問題が発生することがあります。  dispcnt デバッグ コマンドは、キャパシティの低下を監視するために使用され、それぞれのデバイスの CLI でパートナー オペレータによって、または診断バンドルの作成中にユーザーによって実行できます。多数のルートを持つ Edge または Gateway でこのコマンドが実行されている場合に、元の変数が古いメモリの場所を参照する別のイベント（ルートの削除など）が発生すると、メモリへの不正なアクセスが原因でデータプレーン サービスの障害が発生します。

• 解決した問題 67336：Orchestrator の VMware SD-WAN Edge の [監視 (Monitoring )] ページを表示すると、その Edge のアプリケーション統計情報に比べて、トランスポート統計情報の値がはるかに低く表示されます。

  この問題により、ユーザーが特定の Edge のスループットを正確に把握できなくなります。これは、ユーザーが正しいデータ セットを認識できないためです。この問題は、アンダーレイ アカウンティングを含まないトランスポート統計情報とアプリケーション統計情報の結果として発生します。

• 解決した問題 69194：ユーザーが USB モデムをある USB ポートから VMware SD-WAN Edge の別のポートに移動すると、Edge でデータプレーン サービスの障害が発生し、結果として再起動することがあります。

  USB ポートが DPDK AF_PACKET ドライバに誤ってバインドされています。このドライバはポートの削除をサポートしていないため、USB ドングルをあるポートから別のポートに移動すると、Edge のデータプレーン サービスが失敗する可能性があります。

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

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

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

• 解決した問題 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 設定全体が一度に適用され、この問題が発生するリスクが大幅に高まるためです。

___________________________________________________________________

Edge バージョン R422-20220310-GA で解決した問題

Edge バージョン R422-20220310-GA は 2022 年 3 月 15 日にリリースされ、Edge バージョン R422-20220210-GA 以降の以下の重大な問題に対処します。

Gateway バージョン R422-20220310-GA は 2022 年 3 月 15 日にリリースされ、VMware ベースのハイパーバイザーを使用する場合の ESXi バージョン 7.0 のサポートが追加されました。

• 解決した問題 57597：展開の一部としてインターネット バックホールを使用している場合、4.x ソフトウェア バージョンにアップグレードした後、ハンドオフ キューのドロップとパフォーマンスの劣化が発生することがあります。

  Edge ソフトウェア バージョン 4.0 以降では、アプリケーションを同期するためのロックが新たに導入されました。このロックにより、IPv4 インターネット バックホールのパフォーマンスが劣化する可能性があります。このチケットの修正により、アプリケーションの適切な同期を確保しながらロックが解除されます。

• 解決した問題 65695：接続されたサブネットを宛先とするトラフィックが失敗することがあります。

  問題は、「到達可能」状態が False になった後でも、IPv4/IPv6 で接続されたサブネットがオーバーレイに再配分されていることです。親インターフェイスがダウンしている場合、Edge サービスはサブインターフェイスの「ダウン」通知を受信せず、その結果、サブインターフェイスに属する接続されたルートは削除されません。到達可能なときにこれらのサブネットを通常使用するトラフィックはブラックホールになり、完全に失敗します。

• 解決した問題 67745：特定の ISP 提供ルーターに接続された WAN リンクを持つ VMware SD-WAN Edge で、ISP ルートがダウンしてから起動すると、カスタマー トラフィックに問題が発生することがあります。

  Edge から ISP 提供ルーターへの WAN リンク（この問題は、Spectrum で使用されている ISP ルーターで検出されました）がダウンするか、ISP ルーターがダウンしてから再び起動すると、ISP ルーターが診断を実行する場合があります。この診断には、サブネット 192.168.100.0/24 の Edge に一時的にプライベート IP アドレスを割り当ててからパブリック IP アドレスを割り当てることが含まれます。Edge は 192.168.100.0/0 の接続ルートをインストールしますが、これはパブリック IP アドレスを取得した後もクリアされません。

• 解決した問題 68923：BGP を使用しているカスタマー エンタープライズでは、インストールされているデフォルト ルートの到達可能状態が「False」に設定されていても、デフォルト ルートが BGP ピアに再分散されることがあります。

  Edge インターフェイスを参照するスタティック ルートが Edge で設定されていて、その BGP ピアが Edge からデフォルト ルートを学習し、そのインターフェイスが後に無効にされることでそのルートの到達可能フラグが False に変わると、ルートは引き続き広報されます。インターフェイスが停止しているために再分散されていないルートで、その後、インターフェイスが起動してルートの状態が「True」としてマークされても、ルートが引き続き再配分されないのも同様です。どちらの場合も、Edge が新しいルート状態を反映するインターフェイスの状態変更でルートを再広報しないことが原因です。

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

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

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

• 解決した問題 77625：高可用性トポロジを使用して展開されたサイトで、VMware SD-WAN スタンバイ Edge が複数回再起動することがあります。

  HA ハートビート パケットの処理中に HA スレッドが枯渇するため、サイトはアクティブ/アクティブ（スプリット ブレイン）状態になります。アクティブ/アクティブ状態では、アクティブ Edge が実行され、スタンバイ Edge は再起動されて、適切なスタンバイ状態に降格されます。ただし、この場合、アクティブ/アクティブ イベントが複数回検出され、そのたびにサイトをリカバリするたびにスタンバイ Edge が再起動します。 

  フィールドの問題には Edge 6x0（610、620、640、680）モデルが関係していますが、この問題はプラットフォームに依存しないため、他の Edge モデルで発生する可能性があります。

• 解決した問題 77642：VMware SD-WAN Edge で、ハンドオフ キューのドロップ数やパケットのドロップ数が増え、パフォーマンスが劣化することがあります。

  Edge サービスには、使用率が 100% になる可能性のある非同期フローを監視するスレッドがあり、これによりハンドオフ キューのドロップが発生し、パフォーマンスが劣化します。

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

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

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

___________________________________________________________________

Edge バージョン R422-20220210-GA で解決した問題

Edge バージョン R422-20220210-GA は 2022 年 2 月 18 日にリリースされ、Edge バージョン R422-20220119-GA 以降の以下の重大な問題に対処します。

• 解決した問題 48017：OSPF ルートと BGP ルートは、オーバーレイ フロー制御 (OFC) での収束に予想よりも長い時間かかることがあります。

  負荷が高い場合、VMware SD-WAN Edge で学習された一部またはすべてのルートが OFC に表示されないか、必要な広報とプリファレンスの値が割り当てられない（動的コスト計算 (DCC) は無効化される）状態が発生することがあります。これにより、Edge が VMware SD-WAN Orchestrator へのこのようなルートの同期を常に再試行し、Orchestrator の負荷がさらに増加する可能性があります。

• 解決した問題 55327：VMware SD-WAN Gateway から VMware SD-WAN Edge への SSH 接続が、Edge から Gateway へのトンネルが継続的にフラッピングしている場合に機能しないことがあります。

  Edge から Gateway へのトンネルが継続的にフラッピングすると、Gateway からの SSH 接続を許可するために Edge にインストールされたルート エントリが削除され、SSH 接続が失敗することがあります。

• 解決した問題 57281：VMware SD-WAN Edge で、Edge が例外をトリガして再起動する状態になることがあります。

  この問題は、複数のハブが使用されているハブ/スポーク トポロジのカスタマー エンタープライズで発生する可能性があります。例外は、フロー制御の宛先ルートでの無効なメモリ アクセスが原因でトリガされ、そのような状況に対する適切なサニティ チェックが行われていないことが原因で発生しました。

• 解決した問題 66691：VMware SD-WAN Edge モデル 6x0 (610/620/640/680) では、自動ネゴシエーションの状態が正しく表示されません。

  すべての Edge 6x0 モデルで Intel x553 NIC が使用されているため、自動ネゴシエーションは、SFP1 および SFP2 ではサポートされません。ただし、自動ネゴシエーションは GE1～GE6 （カッパー ポート）でサポートされますが、Edge の ethtool は、ixgbe ドライバの欠陥のせいで、すべてのポートで自動ネゴシエーションが常にオンになっていると通知します。

• 解決した問題 72859：VMware SD-WAN Edge でデータプレーン サービスの障害が発生して再起動し、カスタマーのトポロジに応じて 10 ～ 15 秒のカスタマー トラフィック中断または高可用性フェイルオーバーが発生することがあります。

  この問題は、Edge が未定義のプロトコルまたは予期しないプロトコルでパケット フラグメントを受信した場合に発生します。これが発生すると、Edge はパケットをドロップしますが、パケットをドロップする前に、Edge はルックアップを実行し、Edge サービスはこのルックアップが成功することを常に想定しますが、実際には失敗する場合があります。このルックアップが失敗すると、Edge データプレーン サービスで問題がトリガされ、失敗して再起動します。この問題は、失敗したパケット ルックアップで、データプレーン サービスが失敗することを防ぐ NULL チェックを含めることで修正されました。

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

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

• 解決した問題 78003：カスタマーがハブ/スポーク トポロジを使用している場合、VMware SD-WAN スポーク Edge からハブ Edge へのスタティック トンネルが構築されないことがあります。

  通常、スポーク Edge にすでに多数の動的 Edge 間トンネルが確立されている場合、スポークでスタティック トンネルの最大トンネル数チェックがヒットします。このチェックによって、スポークからハブへのスタティック トンネルの構築が妨げられます。

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

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

• 解決した問題 78678：高可用性トポロジを使用して展開されたサイトで、スタンバイ ロールを実行している VMware SD-WAN Edge が、アクティブ Edge からの同期メッセージの処理中に再起動されることがあります。

  スタンバイ Edge が大量のフロー同期メッセージを処理している場合、SD-WAN サービスがバッファ オーバーフロー状態を検出し、スタンバイ Edge の再起動をトリガすることがあります。

• 解決した問題 81224：高可用性トポロジを使用して展開されたサイトで HA フェイルオーバーが発生すると、OSPF ルート タグが HA フェイルオーバー後に伝達されない場合があります。

  HA フェイルオーバーで、OSPF 外部 LSA（リンク状態の広報）にルート タグがないため、ルーティングが正しく行われません。

___________________________________________________________________

Edge バージョン R422-20220119-GA で解決した問題

Edge バージョン R422-20220119-GA は 2022 年 1 月 21 日にリリースされ、Edge バージョン R422-20211216-GA 以降の以下の重大な問題に対処します。

• 解決した問題 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 で追跡されます。

• 解決した問題 68785：DHCP INFORM パケットは、DHCP リレーとして設定されたインターフェイスで受信されると、VMware SD-WAN Edge ソフトウェアによってドロップされます。

  DHCP クライアントは、IP アドレスを取得すると、DHCP INFORM メッセージを使用して DNS サーバや Gateway アドレスなどの追加のネットワーク情報を要求できます。Edge がリレー エージェントとして設定されている場合、これらの INFORM メッセージは DHCP サーバに転送されますが、ドロップされます。

• 解決した問題 70933：設定プロファイルを移行した後、高可用性が有効になっている VMware SD-WAN Edge で複数回再起動が発生することがあります。

  設定プロファイルの移行中に、デバイス設定のみがスタンバイ Edge とすぐに同期されます。残りの設定は、スタンバイ Edge からのハートビートに対してのみ同期されます。スタンバイ Edge からハートビートを受信する前にアクティブ Edge が再起動して最新の設定を適用すると、アクティブ Edge とスタンバイ Edge の設定が一致しなくなり、両方の HA Edge の設定を同期するために Edge が複数回再起動されます。

• 解決した問題 72498：VMware SD-WAN Edge で消費するメモリの割合が増えると、使用可能なメモリ量が少ないモデル（Edge 510、520、610 など）では Edge がサービス再起動を開始してメモリをクリアするため、カスタマーのトラフィックが 5 ～ 10 秒中断することがあります。 

  この問題は、メモリ リークが原因で発生します。動的 Edge から Edge への接続が有効で、Edge がネットワーク内の他の Edge との多数のトンネルを動的に構築および破棄するネットワーク展開では、Edge は破棄されたトンネルから古い IKE をクリーンアップせず、時間の経過とともにメモリをゆっくり消費するため、メモリの少ない Edge では重大レベルに達して、メモリをクリアするために Edge サービスが再起動する可能性があります。

  この修正を適用しない場合、ユーザーはメンテナンス時間帯に Edge サービスをプリエンプティブに再起動してメモリをクリアすることができます。  ただし、Edge はメモリのリークを再びゆっくり開始します。

• 解決した問題 75992：複数の VMware SD-WAN Edge を使用しているカスタマー エンタープライズで、一部の Edge が 3.4.x Edge バージョンを実行し、他の Edge が 4.3.x Edge バージョンを実行している場合、サービスとトラフィックの中断が発生する可能性があります。

  Gateway バージョン 4.3.0 を実行している VMware SD-WAN Gateway と、3.4.x バージョンと 4.3.x バージョンを混在して実行している Edge を使用している一部のカスタマーの展開では、3.4.x を実行している Edge でネットワーク アドレスがゼロ以外でマスクがゼロの無効なルートが見られます。このようなルートが FIB にインストールされると、ルーティングの問題が発生します。

• 解決した問題 77040：カスタマーが Gateway 経由または Edge 経由のいずれかのタイプの Non SD-WAN Destination (NSD) を展開する場合、SA (Security Association) に障害が発生すると、NSD のタイプに固有のメモリ リークが発生する可能性があります。  すなわち、Gateway 経由の NSD では VMware SD-WAN Gateway でメモリ リークが発生し、Edge 経由の NSD では VMware SD-WAN Edge でメモリ リークが発生します。いずれのタイプでも、サービスの再起動がトリガされ、カスタマーのトラフィックが中断する可能性があります。

  いずれの場合も、メモリが十分に構築されている場合、Gateway または Edge はメモリの完全な枯渇を防ぎ、構築されたメモリをクリアするために、防御的なサービス再起動をトリガします。メモリ リークは、Edge/Gateway の各サービスが自動的に ik_ds 構造をクリーンアップしないために発生します。これにより、メモリが 20 秒ごとに増加し、最終的にデバイスのメモリが不足します。

• 解決した問題 77525：高可用性トポロジを使用しているサイトで、VMware SD-WAN HA Edge が新しいソフトウェア イメージにアップグレードされると、スタンバイがアップグレードに失敗し、VMware SD-WAN Orchestrator ユーザー インターフェイスにスタンバイ Edge の状態が誤って「アクティブ」と表示されます。

  アクティブ Edge は、スタンバイ Edge を検出するとスタンバイ Edge のソフトウェア バージョンを取得しようとします。バージョンが 3.4.x 以降の場合、アクティブ Edge はネットワーク設定ファイルをスタンバイ Edge にコピーします。スタンバイ Edge ソフトウェア バージョンの取得中に、Edge の HA コードで処理されない例外が発生することがあり、これにより HA ワーカー スレッドが停止し、スタンバイ Edge との通信が失敗します。この時点で、アクティブ Edge とスタンバイ Edge の間の管理プロセスは中断され、管理プレーンに関連するソフトウェア管理、スタンバイ Edge の状態、設定の変更などはアクティブ Edge とスタンバイ Edge 間で同期されません。これにより、スタンバイ Edge が誤ってアクティブとして検出され、Orchestrator でアクティブ/アクティブの「スプリット ブレイン」状態として表示されますが、スタンバイ Edge は実際には適切なロールを実行しており、その状態ではありません。

  HA フェイルオーバーが発生し、スタンバイ Edge がアクティブに昇格すると、Edge の設定とソフトウェアのセットが一致しなくなります。Orchestrator は、設定の不一致を検出し、更新された設定をこの Edge にプッシュしますが、以前にスタンバイ Edge が失敗したソフトウェア アップグレードも完了します。Edge ソフトウェアのアップグレードでは再起動が必要になるため、新たにアクティブになった Edge が再起動されてスタンバイ状態に降格されたときに、別のフェイルオーバーが発生します。 

  この問題は、HA サイトが Edge のソフトウェアをアップグレードすると一貫して発生するわけではありません。また、この問題は、新しい HA サイトを起動するとき、またはスタンドアローン サイトを高可用性に設定するとき、スタンバイ Edge がソフトウェアをアップグレードする必要があるときにも発生する可能性がありますが、ソフトウェア アップグレードを実行する HA Edge と比較すると、ほとんど発生しません。

  この修正を適用せずにこの問題を回避するには、Edge サービスを再起動するか、HA フェイルオーバーをトリガして問題をクリアする必要があります。

• 解決した問題 77586：高可用性トポロジを使用して展開されたサイトでリリース 4.2.2 GA を使用し、OSPF を使用すると、カスタマーのトラフィックが中断することがあります。

  HA IP アドレスは Edge のサービスによって VMware SD-WAN のルーティング プロトコルに提供され、OSPF サービスはそれを LSA（リンク状態の広報）で使用します。報告されたフィールド ケースでは、Edge が 4.2.1 を実行しているときに HA IP アドレスが OSPF ルーター ID として選択され、HA Edge を 4.2.2 にアップグレードした後、ルーター ID が別のインターフェイス IP アドレスに変更されます。ただし、HA IP LSA は維持され、広報されていたので、SPF (Shortest Path First) の計算が中断され、ネットワークが停止する可能性がありました。

  注：この問題は、以前に説明したフィールド ケースに限定されず、修正されていないプラットフォームやリリースで発生する可能性があります。

___________________________________________________________________

Edge バージョン R422-20211216-GA で解決した問題

Edge バージョン R422-20211216-GA は 2021 年 12 月 20 日にリリースされ、Edge バージョン R422-20210923-GA 以降の以下の重大な問題に対処します。

• 解決した問題 53951：VMware SD-WAN Edge では、インターネットに直接送信されるトラフィックの障害が発生するか、VMware SD-WAN Orchestrator への接続が失われ、Edge がダウンとマークされることがあります。

  この問題は、次の 2 つのシナリオのいずれかで Edge に影響する可能性があります。

  1. パブリック WAN リンクを使用する Edge で WAN リンクのフラップ（リンクがダウンしてからアップする）が発生する場合、このシナリオでのカスタマーへの影響は、影響を受けるリンクにステアリングされ、「ダイレクト」として分類されるトラフィックがドロップすることです。この問題は、ビジネス ポリシー ルールが、特定のトラフィックが直接送信される一方で 1 つの WAN リンクのみを使用するように設定されているサイトに特に影響します。
  2. PPPoE WAN リンクを使用する Edge で HA を有効にすると、PPPoE インターフェイスの IP アドレスが変更され、古い自己ルートが削除されますが、新しい PPPoE IP アドレスを使用しても新しい自己ルートが追加されません。その結果、Orchestrator と Edge 間の通信が機能しなくなります。

  この修正を適用せず問題を一時的に修正する方法は、Edge サービスを再起動してダイレクト トラフィックが影響を受けるパブリック WAN リンクに送信されるようにするか、Edge（PPPoE リンクが使用されている場所）を再起動して Orchestrator へのルートをリカバリすることです。

• 解決した問題 70919：リリース 4.2.1 GA を使用し、Wi-Fi にも対応する VMware SD-WAN Edge で、ユーザーが Edge の Wi-Fi に接続できず、SSID がブロードキャストされない場合があります。

  Edge が Wi-Fi をブロードキャストしていない場合、ログの確認時に wlan0 インターフェイス（Orchestrator ユーザー インターフェイスの WLAN1）が検出されません。これは、トラフィックが多いときに発生する Wi-Fi カードのファームウェアの例外の結果です。この例外により、Wi-Fi に障害が発生します。

  カーネル ログに、次のようなメッセージが記録されます。

  2021-08-26T01:05:21.397 WARNIN kern   kernel:[244841.443763] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 1, skipped old beacon
  2021-08-26T01:05:21.539 INFO   kern   kernel:[244841.586338] ieee80211 phy0: Hardware restart was requested
  2021-08-26T01:05:24.207 WARNIN kern   kernel:[244844.254081] ath10k_warn: 17 callbacks suppressed
  2021-08-26T01:05:24.207 WARNIN kern   kernel:[244844.254091] ath10k_pci 0000:01:00.0: failed to receive control response completion, polling..
  2021-08-26T01:05:24.223 ERR    kern   kernel:[244844.270245] ath10k_pci 0000:01:00.0: firmware crashed! (guid n/a)
  

  この問題は、ファームウェアの障害を検出し、Wi-Fi カーネル モジュールを再ロードするスクリプトで修正されます。モジュールの再ロードの一環として、スクリプトは Wi-Fi デバイスの PCIe リセットも実行し、ファームウェアを再起動してデバイスを再度使用できるようにします。障害の検出とその後の復旧には 30 ～ 40 秒かかることがあります。この間、Wi-Fi は使用できません。これは、最初から問題の発生を防ぐ完全な修正ではなく、防御的な修正として理解する必要があります。

  このスクリプトを適用しない場合、ユーザーは Wi-Fi を復旧するために Edge を再起動するか、電源を入れ直す必要があります。

• 解決した問題 70954：Edge に Zscaler クラウド セキュリティ サービス (CSS) への必須リンクが設定されたビジネス ポリシーがあり、その必須リンクに対するインターフェイスが失敗すると、VMware SD-WAN Edge で複数のデータプレーン サービス障害が発生することがあります。

  必須のインターフェイスがドロップすると、Edge は Zscaler へのトラフィックをドロップし、サービス障害が発生します。

• 解決した問題 72245：VMware SD-WAN Hub Edge が MPLS ネットワークからのインターネット ブレークアウトとして使用されている場合、接続されたスポーク Edge のプライベート インターフェイスからパブリック Gateway への管理 (VCMP) トンネルがダウンすることや起動しないことがあります。

  スポーク Edge のプライベート インターフェイスからパブリック Gateway への管理 (VCMP) パケットは、ハブ Edge を介して送信されます。このシナリオでは、Hub はこのフローを直接フローと見なし、パブリック インターフェイスを介してこれらのパケットをインターネットにプッシュします。ただし、ルーティングの問題により、これらのフローは「Gateway 経由」としてマークされ、これらのフローに影響を与え、上記の問題を引き起こす可能性があります。

• 解決した問題 72425：ローカル VMware SD-WAN Edge によってルートが受信されたことをユーザーが確認できる場合でも、OSPF ルートはリモート サイトに広報されません。

  この問題は、OSPF NSM（ネイバー ステート マシン）イベントおよびルート追加の処理中に Edge で競合状態が発生したことによるものです。問題のある状態では、OSPF ルートを RIB（ルーティング情報ベース）に追加しているときに、Edge が OSPF NSM 状態イベントを処理していないため、Edge が OSPF ネイバー情報を保有します。このため、Edge はネイバー IP アドレスを 0 として OSPF ルートを追加します。ネイバー IP アドレスが 0 の場合、Edge はルートを Orchestrator に同期せず、Gateway に広報しないため、オーバーレイ フロー制御 (OFC) や Gateway ではルートが表示されません。

• 解決した問題 72688：VMware SD-WAN Edge がデータプレーン サービスをランダムに再起動し、再起動によるサービスの中断が発生します。

  復号スレッドに固定されたパケットは、別の復号スレッドにフロートすると、所有していないスレッドによって拒否されます。パケットを拒否するプロセスで、関連する QAT 暗号化リファレンスが誤って解放され、データプレーン サービスで例外が発生し、障害が発生して再起動しました。

• 解決した問題 73251：RADIUS 経由で認証する必要があるユーザーは、断片化されたトラフィックが VMware SD-WAN Edge から送信されないため、認証できないことがあります。

  RADIUS トラフィックは常に断片化され、この問題は、ワイヤレス リンクでの認証を試みるユーザーにさらに影響を与えます。この問題が発生するときは、断片化されたパケット数が、影響を受ける特定のインターフェイスで DPDK が処理できる数を超えています。この修正により、トラフィックの中断を回避するために、断片化の数がプロアクティブにリセットされます。

Edge/Gateway で解決した問題

バージョン R422-20210923-GA で解決した問題

Edge バージョン R421-20210624-GA-57011-60130 および Gateway バージョン R421-20210407-GA 以降で解決した問題は次のとおりです。

• 解決した問題 34037：ピア トンネルがドロップした後、VMware SD-WAN Gateway でデータプレーン サービスの障害が発生する場合があります。

  ピア トンネルが停止すると、クリーンアップ プロセスで fc->vpi が取得され、NULL に割り当てられます。パイプラインには、この fc への参照がまだ残っているパケットがいくつかあるようです。これらのパケットの処理の一環として、fc->vpi にアクセスしますが、これは NULL であるため、Gateway プロセスは例外にヒットして再起動します。

• 解決した問題 34626：VMware Edge から VMware SD-WAN Gateway への無効な制御パケットにより、Gateway でデータプレーン サービスの障害が発生し、再起動する場合があります。

  Edge から Gateway へのフローの場合、Edge は制御メッセージを Gateway に送信して、各フローのビジネス ポリシー アクションを同期します。制御メッセージに無効なアクションがある場合、無効なアクション セットでフローのデータ パケットをルーティングしようとすると、Gateway が再起動する可能性があります。

• 解決した問題 40268：ユーザーが VMware SD-WAN Hub の設定またはハブを介した Edge 間を変更すると、スポーク Edge は「False」とマークされたルートをインストールします。

  スポーク Edge は、False とマークされたルートを FIB にインストールします（これらのルートにはハブからのトンネルがないため）。これらのルートは、FIB に約 2 分間保持された後、クリアされます。  その間、これらの False ルートは一部のネットワークに中断を引き起こす可能性があります。 

• 解決した問題 41837：元の IP アドレスの代わりに、送信元と宛先の NAT IP アドレスが VMware SD-WAN Edge のログに出力されます。

  Edge ファイアウォールのログには元の送信元と宛先の IP アドレスが表示されるはずですが、代わりに NAT された IP が出力され、ファイアウォール ログの有用性は大きく損なわれます。

• 解決した問題 43278：ユーザーがデフォルト ルートまたはプレフィックスと一致するように送信 BGP フィルタを設定し、AS-Path-Prepend を設定すると、デフォルト ルートまたはプレフィックスは BGP ネイバーに広報されますが、AS-Path-Prepend は発生しません。

  プレフィックスおよび設定された AS-Path-Prepend に一致するように設定された BGP 送信ネイバー フィルタは、BGP の高度な設定の「Networks」ステートメントを使用して作成されたプレフィックスでは機能しません。これは、BGP の高度な「条件付き」の [デフォルト ルート広報 (Default Route Advertise)] チェックボックスを介してネイバーの「DR 発信 (DR Originate)」経由でネイバーに発信されたデフォルト ルートに対しても機能しません。

  また、VMware SD-WAN Edge でスタティック ルート設定を使用する場合、デフォルト ルートと「広報」に設定された非 DR スタティック ルートのいずれも、AS パスがプリペンドされた BGP ネイバーに広報されません。プレフィックスの唯一の AS は、Edge 自身の AS です。

• 解決した問題 44379：VMware SD-WAN Gateway で新しいフローを作成できないことがあります。

  この問題は、起動時に Gateway がフローのクリーンアップ イベントを開始しないために発生し、Gateway 経由のフローが最終的に失敗します。

• 解決した問題 44526：2 つの異なるサイトが高可用性トポロジを使用しながら VMware SD-WAN Edge をハブとして展開し、各サイトがプロファイル内のハブとして、他のハブ サイトを使用する企業の場合。  ハブ サイトの 1 つが HA フェイルオーバーをトリガした場合、両方のハブ Edge が相互にトンネルを再確立するのに最大 30 分かかる場合があります。 

  HA フェイルオーバーでは、両方のハブ Edge が同時に互いにトンネルを開始しようとし、どちらもピアに応答せず、両方のハブ間のパケット交換が発生しますが、IKE は成功しません。これにより、デッドロックが発生し、自然に解決するには最大 30 分かかることが確認されています。この問題は断続的であり、HA フェイルオーバーのたびに発生するわけではありません。 

  この修正を行わない場合、この問題の発生を防ぐ唯一の方法は、2 つの HA ハブ サイトの一方のみを設定し、もう一方のハブ サイトをハブとして使用することです。たとえば、Hub1 と Hub2 の 2 つの HA ハブ サイトがある場合、Hub1 はそのプロファイルで Hub2 をそれ自体のハブとして持つことができますが、Hub2 はそのプロファイルで Hub1 をハブとして使用することはできません。

• 解決した問題 46489：異なる Partner Gateway 対応のプロファイルが複数の VMware SD-WAN Edge に割り当てられている場合、Edge は、プロファイルに割り当てられていない VMware SD-WAN Partner Gateway の古いルーティング エントリを保持します。

  異なる Partner Gateway 対応のプロファイルが複数の Edge に割り当てられている場合、Edge は他の Gateway から学習したルーティング エントリを保持し、それらのルートは古いエントリと見なされます。  カスタマーへの影響は、Edge がそのプロファイルの無効なルートにトラフィックを送信しようとしているため、トラフィックが正しくルーティングされないことです。

• 解決した問題 47244：アクティベーション済みの、DPDK が有効な VMware SD-WAN Edge 6x0 では、ケーブルが挿入されていない場合でも、一部の Copper SFP のリンクが Edge によって VMware SD-WAN Orchestrator ユーザー インターフェイスで「稼動中」と表示されます。

  この問題により、6x0 モデル ラインの Edge の特定の SFP ポートの実際の状態に関してユーザーに混乱が生じます。

  この修正以前は、この問題を解決する唯一の方法は、影響を受けた SFP ポートにランダムなケーブルを接続し、そのケーブルを取り外すことでした。

• 解決した問題 48612：X710/XL710 ネットワーク アダプタを使用する VMware SD-WAN 仮想ゲートウェイおよび Edge がすべての Rx パケット VLAN タグを削除します。

  この問題は、DPDK も有効になっているゲートウェイ設定を使用しているカスタマーに大きな影響を及ぼします。それは、ハンドオフ インターフェイスで VLAN タグ付きトラフィックを処理できないためです。この問題は i40evf DPDK ドライバにトレースされ、そこから opcode VIRTCHNL_OP_ADD_VLAN が物理関数 (PF) に送信され、VLAN でフィルタリングされたタグが追加されましたが、VLAN タグのフィルタリングを有効にするために、PF ドライバがコマンドの一部として VLAN タグの削除を有効にした結果、すべての VLAN タグが削除されました。

• 解決した問題 48958：VMware SD-WAN Gateway は、結合されたインターフェイス上で接続を失う場合があります。

  VeloCloud Management Protocol (VCMP) と WAN ポートが同じポートを使用するように設定されている場合、Partner Gateway の VLAN ハンドオフ設定により、ARP 解決が失敗して Gateway がオフラインになることがあります。この修正により、VCMP と WAN ポートが同じ場合、VMware SD-WAN Orchestrator からの VLAN ハンドオフ設定が Gateway で拒否されます。  この修正なしで問題を回避する方法は、VCMP と WAN に同じポートを割り当てないことです。

• 解決した問題 50223：リリース 3.4.x 以降を使用する VMware SD-WAN Edge は、SNMP 経由で物理 LAN インターフェイスの情報を送信しません。 

  VMware SD-WAN が net-snmp を使用していた 3.4.x 以前のリリースでは、LAN インターフェイスは SNMP 経由で送信されました。リリース 3.4.x では、独自の snmpagent を追加しました。これは、コマンド debug.py --interfaces からデータを取得し、その出力には LAN インターフェイスに関する情報が含まれていません。この修正により、コマンドに LAN インターフェイスが追加され、snmpagent が SNMP 経由でデータを送信できるようになります。

• 解決した問題 50422：VLAN タグ付きルーティング インターフェイスを使用すると、ARP を介してピア MAC アドレスが誤って学習されることがあります。

  ルーテッド インターフェイスに VLAN タグが割り当てられていて、ネクスト ホップがタグなし ARP 要求を送信する場合、タグなし MAC が学習され、最初に学習されるエントリによってはトラフィックがブラックホールになる可能性があります。

  この修正を適用しない場合の唯一の回避策は、ルーテッド インターフェイスに VLAN タグがある場合に、ネクスト ホップからタグなし ARP 要求を除外することです。

• 解決した問題 52127：BGP または OSPF が有効になっている VMware SD-WAN Edge では、ブロックしているソケットが Tx から返されるのを待つ間にタイムアウトが発生すると、Edge でデータプレーン サービスの障害が発生する場合があります。

  これは通常、次のシグネチャで観察されます。
  #0 0x00007f5c09f34754 in send () from deps/lib/libpthread.so.0
  #1 0x000000000092cc7a in vc_zeb_send_to_client (buf=0x7f5aa7fed580 "", length=<optimized out>, client=0x7f5ad402ec90) at /mnt/build/workspace/master-nightly-build/common/libs/drp/vc_zebra.c:188

  Edge ルーティングとデータプレーン プロセスは、ローカルホストの TCP ソケットと通信します。一部のスレッドのランタイムによっては、ローカル コアのタスク キュー システム (ksoftirqd) が最小ランタイムを受信して、ルーティング プロセスに対して開かれたソケットにパケットを配信し、OSPF または BGP スレッドの Tx 呼び出しがブロックされる可能性があります。

  OSPF スレッドと BGP スレッドのスレッド優先度がすべてのコアに対して再分類されました。カーネル スケジューラを利用して、コアを自発的に提供するのではなく先取りすることで、ksoftirqd によるより多くのランタイムおよび協調的なプリエンプションが可能になりました。

  注：同じ問題が重複チケット 39232 でも追跡されますが、これらのリリース ノートでは省略されています。

• 解決した問題 53283：1:1 NAT も設定されている場合、ビジネス ポリシーで指定されたリンク モードは適用されません。

  送信トラフィックの場合、一致する 1:1 NAT ルール（設定されている場合）を検索するときに、ビジネス ポリシーを介して設定されたリンク モードは無視され、最初に一致する 1:1 NAT ルールが常に選択されます。例：ビジネス ポリシーでリンクを「必須」として選択するように求められますが、1:1 NAT の結果、最初に一致する 1:1 NAT ルールで指定されている別のリンクが選択されます。この修正なしで問題を解決する唯一の方法は、影響を受ける VMware SD-WAN Edge に対して [Remote Diagnostic (リモート診断)]> [フローのフラッシュ (Flush Flows)]を実行することです。

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

  VMware SD-WAN Edge は、Gateway から受信したトラフィックの損失を検出すると、失われたパケットを再送信するために否定応答 (NACK) メッセージを Gateway に送信します。Gateway は、再送信スロットをチェックしてパケットを再送信します。Gateway はすべてのスロットがチェックされたら再送信を停止するのが理想的ですが、Gateway は NACK メッセージのシーケンス番号に到達するまで再送信スロットを繰り返しチェックします。これにより、Gateway の監視スレッドがこれをハング スレッドとして検出し、Gateway を再起動します。

• 解決した問題 54001：Tx キューが SFP インターフェイスでハングした後、VMware Edge はトラフィックを送信できません。

  まれに、Edge が無効なサイズのパケット（17 バイト未満または 1526 バイトを超える）を DPDK に送信すると、送信キューが停止し、それ以上のトラフィックが Edge によって転送されない場合があります。Edge を再起動すると一時的に問題が修正されますが、無効なサイズのパケットが Edge サービスから DPDK に送信されると問題が再び発生する可能性があります。この問題は、修正後のレベルにアップグレードすることでのみ回避できます。

• 解決した問題 54136：高可用性トポロジを使用しているサイトでは、VMware SD-WAN のアクティブ Edge がデータプレーン サービスの再起動を開始し、その結果 HA フェイルオーバーが発生する場合があります。

  アクティブ Edge は、フロー数が多い場合（1 秒あたり 190 万フロー）、大量のメモリを消費します。  メモリ消費が重大レベルに達すると、Edge はメモリをクリアするために再起動し、フェイルオーバーが発生します。

• 解決した問題 56218：高可用性トポロジを使用して展開されたカスタマー サイトの場合や HA が有効になっている場合、Edge を 3.2.x から 3.4.x にアップグレードすると、スタンバイ Edge がダウンする場合があります。

  ローカル ユーザー インターフェイスを使用して WAN を設定した後、HA が有効になっているか、HA Edge が 3.2.2 から 3.4.x にアップグレードされると、HA インターフェイス（Edge モデルに応じて LAN1 や GE1 など）がスタンバイ Edge から削除され、VMware SD-WAN Orchestrator の高可用性の状態が HA_FAILED に設定されます。

• 解決した問題 56346：VMware SD-WAN Edge の [監視 (Monitor)] > [システム (System)] ページを確認すると、[ハンドオフ キューのドロップ数 (Handoff Queue Drops)] が表示されることがあります。

  VCRP (VeloCloud Route Protocol) ルート イベントの更新により、VCMP（VeloCloud 管理プレーン）データ スレッドでハンドオフ キューがドロップします。  これは、ルートの更新を受信すると、各セグメントのすべてのルートが無効になるためです。これにより、データ パスで新しいルートが検索されます。ルート検索の一部として呼び出される特定の機能が、コストの高いハッシュ列挙処理を行い、VCMP データ スレッドの使用率が 40% 増加します。  この問題が実際に見つかった事例での、ハンドオフ キューのドロップ数は、ネットワーク パフォーマンスに影響を与えるほどではありませんでした。

• 解決した問題 56379：VMware SD-WAN Gateway がメモリを使い果たし、データプレーン サービスの障害が発生して再起動することがあります。

  VMware SD-WAN Hub Edge が多数のスポーク Edge （たとえば、約 4000）に合わせてスケーリングされ、このスケーリングされたハブ Edge のルートの BGP フラップが発生すると、ハブ Edge のプライマリ Gateway が単一のインスタンスのすべてのスポーク Edge に更新メッセージを送信します。ただし、複数の BGP フラップが連続して発生している場合は、送信前に複数の更新メッセージが蓄積されます。この更新メッセージの蓄積により、メモリが枯渇し、Gateway の再起動がトリガされる可能性があります。

• 解決した問題 56483：VMware SD-WAN Orchestrator の [監視 (Monitor)] > [トランスポート (Transport)] 画面で、WAN リンクのライブ監視にパケット ロス、ジッター、および遅延の値が表示ません。

  ユーザーは、[監視 (Monitor)] > [トランスポート (Transport)] で、特定の WAN リンクのパケット ロス、ジッター、および遅延に関するリアルタイム データを取得できません。グラフには平らな線が表示されます。また、[監視 (Monitor)] > [Edge] > [概要 (Overview)] 画面では、パケット ロス、ジッター、および遅延のすべての値が「0」と表されます。[監視 (Monitor)] > [トランスポート (Transport)] の履歴統計情報は正しく表示されます。この問題は「ライブ モード」統計情報にのみ影響します。 

• 解決した問題 56645：VMware SD-WAN Edge 610 が特定の Meraki Access Point に接続されている場合、WAN リンク フラップが頻繁に発生します。

  Edge 610 が Meraki M36 Access Point（または同様のモデル）に接続されている場合、イーサネット リンクで頻繁にリンク ドロップが発生します。これは、Edge 610 でドライバの問題が発生した結果です。

• 解決した問題 56876：VMware SD-WAN Edge では、メモリ管理に関連する問題が発生し、カーネル パニックをトリガする可能性があります。その結果 Edge が再起動します。

  この解決された問題には、カーネル パニックをトリガする Edge でのメモリ管理を含む 2 つの異なるシナリオの修正が含まれています。

  Edge が動的ブランチ間を使用している最初のシナリオでは、動的トンネルが作成され、ピアごとのカウンタを格納するために少量のメモリが予約されます。動的トンネルが破棄されると、このメモリはクリーンアップされず、次に同じピアが接続されるときに起動時間が最適化されます。その結果、時間の経過とともに多数の異なる宛先に接続する小規模の Edge（Edge 500、510、520、610 など）では、最終的に使用可能なメモリが使い果たされ、カーネル パニックと Edge の再起動がトリガされる可能性があります。  この修正を行わないと、VMware SD-WAN Orchestrator で Edge の [監視 (Monitor)] > [システム (System)] 画面のメモリ使用率が健全性統計の 90% を超える場合、ユーザーは Edge のサービスを事前に再起動する必要があります。

  動的ブランチ間によって引き起こされたメモリ リークを修正するプロセスで、malloc_trim（フラグメントされたメモリをクリアするプロセス）が適切に呼び出されていないことが確認され、この修正のためにこのプロセスも変更されました。malloc_trim を適切に呼び出さないと、別の問題が発生し、あらゆる Edge（小さい Edge だけでなく）に影響を与える可能性があります。その場合、Edge が動的ブランチ間を使用することは要求されなくなり、[監視 (Monitor)] > [システム (System)] 画面には 90% を超えるメモリ使用量が表示されなくなります。このシナリオは、Edge に多数のフローがある場合に発生する可能性が高くなります。

• 解決した問題 57011：高可用性トポロジで設定されたサイトの場合、そのサイトでセグメントが追加されてから削除されると、HA Edge の 1 台でデータプレーン サービスの障害が発生する可能性があります。サービスの障害がアクティブ Edge にある場合、サイトでは HA フェイルオーバーも発生します。

  HA サイトにセグメントが追加されてから削除されると、古いセグメントが残る（つまり、削除されたセグメントが HA ペアの 1 台の Edge に表示される）ことがあります。この HA Edge 間のセグメント情報の不一致により、古いセグメントを対象としたイベントが他の Edge に送信することがあり、データプレーン サービスの障害が発生します。サービスの障害がアクティブ Edge にある場合は HA フェイルオーバーが発生し、フェイルオーバー後に取得された診断バンドルでコア ダンプの生成が確認されます。

• 解決した問題 57859：アクティベーションされたばかりの VMware SD-WAN Edge が VMware SD-WAN Bastian Orchestrator と通信できないため、Orchestrator によってオフラインとしてマークされます。

  この問題は、Bastian Orchestrator にトラフィックを送信するために選択された WAN リンクに、直接トラフィックを送信するための IP アドレスが割り当てられていない場合に発生します。

• 解決した問題 58075：高可用性が有効になっている VMware SD-WAN Edge で、SNMP ウォーク/クエリがタイムアウトします。

  SNMP クエリ出力は部分的な結果のみを返し、最終的には HA が有効な Edge でタイムアウトが発生します。

• 解決した問題 58259：Zscaler ピアを使用して Gateway 側で VMware Non SD-WAN Destination トンネルがダウンすることがあります。

  Zscaler ピア エンドがフェーズ 2 Security Association (SA) を削除しても、VMware SD-WAN Gateway がまだ SA を保持する場合があります。この場合、トンネルは破棄され、カスタマーはトラフィックを渡すことができなくなります。

  修正を行わない場合の回避策は、phase2_sa_check.py スクリプトです。このスクリプトは、Phase2 SA テーブルを参照し、Phase1 SA が欠落している Phase2 SA があるかどうかを確認します。Phase1 SA が欠落している Phase2 SA が見つかると、Gateway はトンネルを再確立します。

• 解決した問題 58527：リモート診断の [アクティブなフローの一覧表示 (List Active Flows)] を実行すると、ビジネス ポリシー名の出力は予想される 32 文字に対して 24 文字に制限され、ビジネス ポリシー名は実際の 32 文字から 24 文字に切り詰められます。

  .edge.info では、設定された biz_policy 名が適切にリストされます（biz_policy_name フィールドの全体を占めている場合でも）。しかし、user_flow_dump/flow_dump の出力に biz_policy_name が表示されているときには、ポリシー名を保存するために 24 文字のみを使用しています。そのため、実際に設定されている biz_policy は完全には表示されません。

• 解決した問題 58535：カスタマーがステートフル ファイアウォールを設定し、[ネットワークおよびフラッド防止の設定 (Network & Flood Protection)] で拒否リストも設定している場合、拒否リストは自動的に新しい接続の最も積極的な設定となり、ステートフル ファイアウォールが新しい接続をブロックします。

  この問題は、ステートフル ファイアウォールを使用しているカスタマーが拒否リスト機能を使用できなくなるという重大な影響が生じます。拒否リスト機能を有効にすると、ファイアウォール イベントに次のログが記録されます。「FLOOD_ATTACK_DETECTED」および「Blacklisting source: xxx.xxx.x.x exceeded CPS limit : 0 per source」。  この場合の IP アドレスは Edge の管理 IP アドレス、CPS は 1 秒あたりの接続数です。[新規接続のしきい値 (New Connection Threshold)] の制限は 0% に設定されています。つまり、接続を試行すると拒否リストがトリガされ、すべての接続がブロックされます。  [新規接続のしきい値 (New Connection Threshold)] のデフォルト値は 25% です。

• 解決した問題 58567：高可用性トポロジで設定され、VNF も設定されているサイトでは、VNF が停止しているために HA フェイルオーバーが頻繁に発生する場合があります。

  HA を使用して Check Point VNF を展開すると、VMware SD-WAN Edge は SNMP クエリを使用して VNF の状態を監視します。VNF の状態が 3 回連続して「停止」とマークされた場合、Edge は VNF が停止していると判断し、HA の切り替えを開始します。問題は、Check Point VNF​が SNMP クエリに断続的に応答するのに 1 秒以上かかるため、Edge が Check Point VNF​の状態に関して誤った決定を下し、稼動していても「停止」としてマークし、この間違いが何度か繰り返されて HA フェイルオーバーが頻繁に発生することです。

  この修正なしで問題を解決する唯一の方法は、VNF が停止していると判断する前に SNMP が再試行される回数を 3 よりも大きい値に増やすことです。これは、/opt/vc/etc/vnf/default.json で設定できます。フィールド「snmp_retries」を変更し、VNF をパワーオフしてから再びパワーオンします。

• 解決した問題 58678：[動的な Edge 間 (Dynamic Edge-to-Edge)] が有効で、「動的な Edge 間が無効」という制御メッセージが VMware SD-WAN Edge で受信された場合、Edge ではデータプレーン サービス障害が発生する場合があります。

  ピア Edge へのトンネルを作成するために、Edge は VMware SD-WAN Gateway に「動的な Edge 間」情報を要求します。Gateway からの応答メッセージが破損している場合、一部のフィールドで適切な検証が行われていないため、Edge が再起動する場合があります。

• 解決した問題 58688：VMware Edge Network Intelligence を使用すると、Edge Network Intelligence データのクライアント MAC アドレスに誤ったランダムな IP アドレスが関連付けられます。

  VMware SD-WAN Edge が、LAN 側のパブリック IP アドレスではなく、WAN 側のパブリック IP アドレスを誤って送信します。このため、Edge Network Intelligence データに、IP アドレスと MAC アドレスの関連付けが一致しないと表示されます。

• 解決した問題 58830：VMware SD-WAN Edge は、ルーティングされたクライアントから Partner Gateway のキャッチオール NAT サブネットを持つ VCMP サーバへのトラフィックをドロップします。

  Edge のルーティングされたクライアントから VCMP トラフィックへの ping が失敗します。デフォルトのスタティック ルートが Partner Gateway から Edge に広報され、Edge 自体に、ルーティングされたクライアントの到達可能性のためにアンダーレイ L3 スイッチのネクスト ホップを指すように設定されたローカルのデフォルトのスタティック ルートがあるといった、リストにあるシナリオでは、ping が失敗します。Edge は VCMP からの ICMP 応答パケットを「rfc1918 cloud route match」というエラーでドロップします。

• 解決した問題 59008：複数の USB リンクのリンク internalID がいくつかの VMware SD-WAN Edge で同じになる可能性があるため、VMware SD-WAN Orchestrator で USB リンクの統計情報が正しく表示されないことがあります。

  異なる Edge の USB リンクには、同じ内部 ID が割り当てられていることがあります。その結果、一部のデータが失われるため、カスタマーのいくつかの Edge にまたがる監視が影響を受けます。

• 解決した問題 59236：拡張高可用性トポロジを使用しているサイトの場合、スタンバイ Edge に接続された WAN リンクが Metanoia SFP であり、HA フェイルオーバー後もこの動作が続く場合、トンネルは形成されません。

  拡張 HA の場合、WAN ポートはスタンバイ Edge でブロックされます（つまり、Edge は WAN インターフェイスで TX を許可しません）。Metanoia SFP インターフェイスを起動するには、ハードウェア間でパケット交換が必要です。Edge は TX を許可しないため、インターフェイスの初期化は成功しません。

• 解決した問題 59527：高可用性トポロジで設定され、HA に VNF も展開されているサイトでは、HA フェイルオーバーが繰り返し発生するため、繰り返し停止が発生する場合があります。

  VNF HA が稼動し、すべての LAN 側リンクが両方の Edge で停止すると、この問題がトリガされ、HA ペアの少なくとも 1 台の Edge で LAN 接続がリストアされるまでこの状態が継続します。

• 解決した問題 59629：高可用性トポロジを使用して展開されたお客様のサイトで、VMware SD-WAN スタンバイ Edge が複数回再起動することがあります。

  アクティブ Edge とスタンバイ Edge の両方で HA ハートビートが失われ、両方の Edge がアクティブ/アクティブ（「スプリット ブレイン」とも呼ばれる）になります。この関連付けを解除するために、新たに昇格したアクティブ Edge（以前のスタンバイ Edge）は、次のイベント ログを記録して再起動します。「アクティブ/アクティブ パニック」。  この問題の修正には、HA Edge ハートビート スレッドの優先度を昇格させて、アクティブ/アクティブ状態の原因となるハートビートの欠落と見なされる可能性のあるハートビートの処理の遅延を最小限に抑えることが含まれます。

• 解決した問題 60006：620 や 640 などのハードウェア ベースの VMware SD-WAN Edge で HA が有効になっている場合、スタンバイ Edge が再起動する場合があります。

  620 または 640（この問題が確認されているモデル）で HA が有効になっている場合、スタンバイ Edge はアクティブ/アクティブ パニックを検出することがあります。その場合、スタンバイ Edge は再起動してアクティブ/アクティブ状態を修正します。この問題は、Edge の初期化中に、HA インターフェイスの初期化と HA 状態のマシンの初期化が競合状態になった場合に発生します。つまり、HA 状態のマシンが、HA インターフェイス ドライバの初期化が完了するよりもはるかに早く起動し、その結果、HA 状態のマシンがピア Edge からのハートビートを検出せず、アクティブ状態に移行します。  この問題は滅多に発生しないため、特定のサイトで発生した場合、同じセッションで 2 回発生することはほとんどありません。つまり、サイトでスタンバイ Edge の再起動が無限に繰り返されることはないと考えられます。

• 解決した問題 60010：高可用性トポロジで展開された VNF を使用する VMware SD-WAN Edge を使用するサイトの場合、LAN 側のポート フラップの後に SSH 経由でスタンバイ Edge の VNF にアクセスできません。

  スタンバイ VNF の LAN 側インターフェイスは、通常、無効な状態です。LAN 側のポートフラップが原因で転送状態になり、ブリッジ インターフェイスで誤った MAC アドレス ポート マッピングが発生し、VNF にアクセスできなくなります。

• 解決した問題 60073：VMware SD-WAN Edge の PPPoE インターフェイス経由の DNS パケットが処理されません。

  Edge の PPPoE インターフェイス経由の DNS パケットは処理されず、ドロップされません。このため、DNS over PPPoE 機能が影響を受け、たとえば、リリース 4.2.0 以降にアップグレードした後に CSS トンネルが発生しないなどの問題が発生します。

• 解決した問題 60130：サイトでは、断続的に高いパケット ロスと接続の問題が発生することがあります。

  これは、ARP 解決をチェックする API が、00:00:00:00 の MAC アドレスを配信しているときにデバイスの ARP 解決が成功したことを Edge に通知することが原因です。  このアドレスは ARP キャッシュに保持され、MAC がゼロとしてリストされているデバイス宛てのパケットはすべてドロップされます。この状況では、このような MAC アドレスがゼロの正常な ARP の多くのインスタンスが配信され、高いパケット ロスと接続の問題が発生します。

  この修正を適用すると、フロー内の MAC アドレスのキャッシュ値に関する問題（この問題の最も一般的な原因）が解決されます。ただし、この修正は ARP がそれ自体をキャッシュし、MAC アドレスをゼロとして返す、まれな状況には対処していません。この問題は 62552 で対処する予定です。この修正を適用した Edge イメージを使用すること以外に、この問題の回避策はありません。

• 解決した問題 60184：ブランチ VMware SD-WAN Edge は、非プロファイル ハブ Edge （動的ブランチ間）からのアップリンク コミュニティでマークされたルートをインストールし、これらのルートを他よりも優先します。

  動的ブランチ間が使用されている場合、非プロファイル ハブ Edge はブランチ Edge として扱われます。  そのため、動的トンネル ブリングアップが発生すると、上記の問題が発生します。唯一の回避策は、すべてのプロファイルにハブを追加することですが、20 台以上のハブ Edge が存在する大規模なネットワークでは、作成されるルートの数が非常に多いため、拡張できません。

• 解決した問題 60225：VMware SD-WAN Edge のリモート診断の [インターフェイスの状態 (Interface Status)] を実行すると、SFP インターフェイスに対する VMware SD-WAN Orchestrator の出力に、誤った速度とデュプレックス情報が表示されます。

  Orchestrator のデータが、SFP インターフェイスに対して正しくありません。たとえば、0 Mbps/半二重と表示されていても、Edge で直接表示すると、データは 1000 Mbps で全二重、または類似の値を示している場合があります。

• 解決した問題 60367：VLAN 固有のドロップ ルールが設定されている場合でも、ステートフル ファイアウォール ルールが VMware SD-WAN Edge IP アドレスに送信されるフローの最初のパケットをドロップしません。

  VLAN 固有のステートフル ファイアウォール ドロップ ルールを使用しても、ping の送信と Edge の VLAN IP は成功します。VLAN 固有のステートフル ファイアウォール ドロップ ルールでは、VLAN ホストへの ping と Edge の VLAN IP アドレスの動作が一致しません。Edge の VLAN IP アドレスへの ping が成功します。この修正により、Edge VLAN-IP または VLAN ホストへの ping が許可されなくなります。

• 解決した問題 60523：SLA プローブが有効になっている場合、ルーティングされたクライアント IP アドレスへの ping は失敗します。

  ルーティングされたクライアント IP アドレスに対して SLA プローブが有効になっている場合、Edge データプレーン サービスによる ICMP 応答パケットの処理が失敗します。  修正を適用せずにこの問題を解決する唯一の方法は、ICMP プローブを無効にすることでした。

  修正を行わない場合の唯一の回避策は、ICMP プローブを無効にすることです。

• 解決した問題 60570：VMware SD-WAN Orchestrator で新しいユーザー インターフェイスを使用すると、パスの状態に正しくない状態が表示されることがあります。 

  これは表示の問題であり、実際のカスタマー トラフィックには影響しません。また、この問題の例として、Edge の診断バンドル ログにパスが「安定」と表示されている場合に、新しいユーザー インターフェイスにパスが「ダウン」と表示されることがあります。

• 解決した問題 61361：VMware SD-WAN Edge 3400、3800、および 3810 を Edge リリース 3.4.5、4.0.2、または 4.2.1 にアップグレードするためにソフトウェア アップデートを適用すると、アップデートの直後に Edge モデルが起動しないことがあります。

  リリース 3.4.5、4.0.2、および 4.2.1 には、コンプレックス プログラマブル ロジック デバイス (CPLD) の特定のファームウェア アップデートが含まれています。このアップデートにより再起動がトリガされ、「スタック」することがあります。システムを再起動するには手動で電源を入れ直す必要があります。

  修正を行わない場合、ローカル ユーザーは更新を完了するために Edge の電源を手動で入れ直す必要があります。

• 解決した問題 61387：ユーザーがその Gateway の診断バンドルを生成しようとすると、VMware SD-WAN Gateway でデータプレーン サービスの障害が発生し、再起動することがあります。

  この問題は、Gateway でメモリ使用率が高くなる可能性のある Gateway のメモリ リークが原因で発生します。  Gateway のメモリ使用率が十分に高いレベルにある場合、診断バンドルを生成すると、そのメモリ使用率がクリティカルな状態になり、データプレーン サービスの障害が発生して再起動します。

• 解決した問題 61433：1 台の VMware SD-WAN Edge がハブ クラスタへのスポークであり、また別のスポークへのハブでもあるカスケード ハブ/スポーク トポロジでは、ハブ クラスタ メンバーの 1 つでアンダーレイ ルーティングが変更されると、このスポーク/ハブ Edge からルートが削除される場合があります。

  カスケード ハブ トポロジの場合、ハブ クラスタ メンバーでのルートの削除により、VMware SD-WAN Gateway からハブ Edge としても機能するスポーク Edge に対して、意図しない削除メッセージがトリガされました。このメッセージはディープ スポークからの更新によるものであり、Gateway では無視されるものですが、この問題により Gateway はスポーク/ハブ Edge に削除メッセージを送信し、Edge はそれらの（ハブ クラスタから学習した）アンダーレイ ルートを失いました。

  このビルドの修正を適用しない場合、カスケード ハブ トポロジに関連するこの問題の回避策はありません。Edge をハブ クラスタへのスポーク、同時にディープ スポークへのハブにすることは避けることをお勧めします。そうしないと、この問題が発生する場合があります。

• 解決した問題 61502：VMware SD-WAN Edge のアクティベーション中に、適用される新しいソフトウェア イメージのダウンロードが無期限に遅延します。

  ネットワーク接続の信頼性が低い環境、または特定の種類のトラフィック スロットリングがある環境では、新しいソフトウェア イメージの HTTPS ダウンロードがスタックすることがあります。この修正を行わずにこのシナリオが発生した場合は、Edge の電源を入れ直し、数分間待機してください。ダウンロードは自動的に再開されますが、最初から再開されます。

• 解決した問題 61596：パートナー BGP がセキュア オプションで有効になっていて、スタティック ルートが非セキュアとして設定されている場合、またはその逆の場合、パフォーマンスが劣化します。

  パフォーマンスの劣化は、安全でないスタティック ルートが BGP 設定から安全なフラグを取得するときに、IP アドレスの最大長の計算ミスが原因で発生します。最初に VMware SD-WAN Gateway はルート参照を実行し、安全でないスタティック ルートが見つかった場合、Gateway は BGP が有効になっているかどうかを確認します。  BGP が有効になっている場合、Gateway は暗号化セットを確認してから、安全な BGP の暗号化セットを選択します。安全なオプションは安全でないオプションよりも控えめであるため、フラグメンテーションが発生します。

• 解決した問題 61622：Google ドライブ トラフィックが「その他の TCP/UDP」または「APP_UNKNOWN」として誤って識別されます。

  このトラフィックは、「Google Documents（別名：Google Drive）」として識別されます。この問題は、詳細なパケット インスペクション (DPI) エンジンに Google Drive の最新のサブネット/ポートがないことが原因で発生します。

• 解決した問題 61725：USB WAN リンクが使用されている高可用性トポロジを使用しているサイトで、リモート診断「HA 情報」を実行するとエラーが発生します。

  USB/LTE モデムが存在する場合、または以前に VMware SD-WAN アクティブ Edge にのみ存在し、スタンバイ Edge には存在しなかった場合、アクティブ Edge はスタンバイ Edge で USB/LTE インターフェイスの詳細を取得しようとし、結果として、スタンバイ Edge に USB/LTE インターフェイスがないため、Edge がエラーをスローします。

• 解決した問題 61758：VMware SD-WAN Edge 520 または 540 を使用しているサイトでは、スループットが予想よりも低くなります。

  520 または 540 のいずれかを使用すると、サイトのスループットが想定より 100 Mbps 以上減少することがあります。この問題の原因は、新たに実行された Edge プロセスがリング バッファを開かないようにする、以前の Edge データプレーンの親プロセスの子プロセスによって開かれた古いリング バッファです。

• 解決した問題 62197：VMware SD-WAN Gateway がデータプレーン サービスを再起動することがあります。

  Gateway が Gateway 自身から VMware SD-WAN Orchestrator にルートを同期しているときにメモリ リークが発生します。  メモリ消費が重大レベルに達すると、Gateway のデータプレーン サービスが再起動してメモリがクリアされ、Gateway を使用するカスタマー トラフィックが一時的に中断します。

• 解決した問題 62280：VMware SD-WAN Edge の LAN サブインターフェイスが、ルーティングされたホストから Edge 間を通って接続されたクライアントへのトレース ルートに表示されません。

  （Edge に直接接続されていない）ホストから Edge 間トポロジのクライアントに対して traceroute を実行すると、o/p に Edge のインターフェイス IP が表示されません。これは、ホストへのパス上の Edge インターフェイスで VMware SD-WAN Gateway の設定が行われていない場合にのみ発生します。
  
  修正を行わない場合の唯一の回避策は、その traceroute ホストに接続する Edge インターフェイスで Gateway 設定を有効にすることです。

• 解決した問題 62552：サイトでは、断続的に高いパケット ロスと接続の問題が発生することがあります。

  これは、ARP 解決をチェックする API が、00:00:00:00 の MAC アドレスを配信しているときにデバイスの ARP 解決が成功したことを Edge に通知することが原因です。  このアドレスは ARP キャッシュに保持され、MAC がゼロとしてリストされているデバイス宛てのパケットはすべてドロップされます。  この状況では、このような MAC アドレスがゼロの正常な ARP の多くのインスタンスが配信され、高いパケット ロスと接続の問題が発生します。

  注：問題 60130 とこの問題はどちらも根本的な動作と原因は同じですが、各チケットで想定される修正は異なります。60150 が防御的な回避策による修正である一方、62552 はこの問題が繰り返されることを防ぐ完全な修正になります。

• 解決した問題 62620：高可用性トポロジで展開されたサイトでは、一部の宛先へのダイレクト トラフィックが HA フェイルオーバー後に機能しなくなる場合があります。

  アクティブな VMware SD-WAN Edge からのフローは、NAT エントリに割り当てられたポートとともにスタンバイ Edge に同期されるため、フェイルオーバーが発生しても、フェイルオーバー後のトラフィックは中断されません。スタンバイ Edge に割り当てられたポートは、フローの有効期限が切れた後でも解放されません。フェイルオーバーが発生すると、NAT ポートが枯渇し、NAT が失敗する可能性があります。その結果、パケットが Edge でドロップされる場合があります。

• 解決した問題 62685：LAN 側の NAT が、NAT タイプを送信元とする異なる LAN サブネットに対して同じ外部 IP を使用して設定されている場合、クラウドに向かうトラフィックが機能しません。

  LAN 側の NAT ルールで使用される外部 IP については、スタティック ルートを設定し、それをリモート ブランチに広報します。リターン トラフィックが正しい LAN サブネットにルーティングされるようにするには、スタティック ルートのネクスト ホップではなく、LAN 側の NAT ルールで設定された内部 IP に基づいてルート参照を実行する必要があります。ただし、クラウドからのリターン トラフィックの場合、ルート参照はスタティック ルートのネクスト ホップに基づいて行われ、トラフィックが間違った LAN サブネットにルーティングされる場合があります。

• 解決した問題 62815：オペレータ ユーザーが、Edge の VMware SD-WAN プライマリ Gateway を介して SSH 経由で VMware SD-WAN Edge にアクセスできません。 

  SSH セッションがタイムアウトします。  Edge でフローを確認すると、フローが作成されますが、パケット カウンタには送信パケットではなく受信パケットのみが表示されます。

• 解決した問題 62890：Edge Network Intelligence と VMware SD-WAN Orchestrator で統計情報を表示すると、アプリケーション ID が異なります。

  アプリケーションを学習するには 2 つの異なる方法があります。
  1.最初のパケットでは、よく知られた SaaS アプリケーションの IP アドレスとポート（Office 365 など）のデータベースを経由するか、Orchestrator が以前に学習したアプリケーションの IP アドレスを学習する。
  2.一連のパケットが詳細なパケット インスペクション (DPI) を使用して分析された後。

  Edge Network Intelligence のアプリケーション ID は #2 によって更新されませんでした。つまり、Office365 などの最初のパケット アプリケーションは表示されますが、DPI を必要とするアプリケーション（AnyDesk など）は Edge Network Intelligence ではなく Orchestrator に表示されます。

• 解決した問題 63056：VMware SD-WAN Edge でカーネル パニックが発生し、再起動とコアが発生することがあります。

  ミューテックス監視プロセスが SIGXCPU で失敗し、コアがトリガされます。すべてのスレッドが両方のコアを使用できるようにすることは、Edge データプレーン サービス < > frr 通信を Unix ドメイン ソケットに移動することによる修正です。これにより、カーネルのオーバーヘッドが増大せず、パフォーマンスが向上することで、TCP ソケットのすべてのメリットが得られます。

• 解決した問題 63141：Metonia ADSL2 + SFP モジュールが使用されている拡張高可用性トポロジを使用しているサイトで、フェイルオーバー時に ADSL2 + SFP モジュールが起動しません。

  HA Edge がフェイルオーバーするか、ネットワークが再起動されると、ADSL2+ 設定の Edge が起動に失敗します。

• 解決した問題 63359：高可用性トポロジと OSPF で設定され、VMware SD-WAN Edge が管理 IP アドレスを使用する Edge 構築のサイトの場合、これらの Edge を 3.4.x から 4.2.x の管理 IP アドレスの構築にアップグレードすると、アップグレード後に OSPF 接続が切断されることがあります。 

  HA Edge を 4.2.x の管理 IP アドレスの構築にアップグレードすると、HA システムでルーター ID が 169.254.2.2 と定義されることがあります。これは想定外の動作です。Edge でのルーター ID の選択においては、HA インターフェイスの IP アドレスが考慮されないことになっています。このルーター ID は OSPF 接続を切断し、ルート交換が行われなくなるため、完全に切断されます。

  修正を適用せずにこの問題を解決する唯一の方法は、Edge サービスを再起動する（HA フェイルオーバーをトリガする）ことです。これにより、再起動後にルーター ID が再び選択され、正しい ID になります。

• 解決した問題 63362：拡張された高可用性トポロジを使用するサイトの場合、スタンバイ Edge を再起動するか電源を入れ直すと、DHCP/PPPoE が有効になっているインターフェイスがトラフィックの送信を停止します。

  拡張された HA トポロジでは、プロキシ インターフェイスで DHCP/PPPoE が有効になっている場合（つまり、HA リンク状態が USE_PEER に設定されている場合）、スタンバイ Edge の再起動または電源の入れ直し後にサーバからアドレスを取得できません。
  
  修正を適用せずにこの問題を解決する唯一の方法は、動的アドレスを静的アドレス タイプに変更するか、HA の強制フェイルオーバーを実行してサーバから IP アドレスを取得することです。

• 解決した問題 63513：Edge Network Intelligence を使用しているカスタマーの場合、Edge ソフトウェアのアップグレード後に VMware SD-WAN Edge に表示されるソフトウェア バージョンが更新されません。

  Edge は実際には最新の Edge Network Intelligence バージョンにアップグレードされていますが、Edge は古いバージョン番号を VMware SD-WAN Orchestrator に伝達します。カスタマーが見ているのはこの状態です。Edge のアップグレード後に問題が発生します。Edge を古いリリースから新しいリリースにアップグレードした後も、Edge Network Intelligence の古いリリース バージョンが引き続き表示されます。

• 解決した問題 64205：VMware SD-WAN Gateway の VCMP データのハンドオフ キュー ドロップが多数発生し、ユーザー エクスペリエンスが低下します。

  継続的なフロー作成イベントがあると、VCMP (VeloCloud Management Protocol) データスレッドのパケット処理が遅くなります。この修正により、VCMP 制御メッセージが別のスレッドにリダイレクトされ、継続的なログ メッセージの一部が削除されるため、VCMP データ スレッドの負荷が軽減されます。

• 解決した問題 64633：Gateway 経由の Non SD-WAN Destination (NSD) を使用して VMware Cloud (VMC) on AWS ピアに接続している場合、毎回約 30 秒間の断続的なトラフィックのドロップが見られる場合があります。

  この問題は、VMware Cloud (VMC) on AWS でのみ発生します。ピアは、Security Association (SA) の有効期限が切れる 30 秒前に IKE 再キー化を開始し、それぞれの再キー化の後、ピアは古い SA を保持して有効期限が切れるまで使用しますが、VMware SD-WAN Gateway は受信 SA を削除します。受信 SA を削除すると、このピアでトラフィックがドロップします。この問題の頻度は、ピアの再キー化ポリシーによって異なります。ピアが 45 分ごとに再キー化を実行する場合、この問題は 45 分ごとに発生し、12 時間ごとに実行する場合は、12 時間ごとに発生します。ピアが新しい SA に切り替わると、トラフィックは、約 30 秒後に自動的に回復します。

• 解決した問題 64961：オプションを含む IP パケットを処理している場合、VMware SD-WAN Edge でデータプレーン サービス障害が発生し、そのサービスが再起動することがあります。

  オプションを含む IP パケットを処理すると、オプション フィールドの解析が正しく行われず、データプレーン サービスが失敗することがあります（解析はオプション リストの末尾を超えて続行されます）。データプレーン サービスの障害は、mutex mon によってトリガされます。この修正を行わない場合、この問題のリスクを最小限に抑える唯一の方法は、ユーザー トラフィック IP パケットに レコード ルート (RR) および オプションなし (NOP) 以外のオプションを設定しないようにすることです。

• 解決した問題 65037：証明書の SSL 共通名フィールドに特殊文字またはスペースが含まれていると、証明書が破損しているために HTTPS/SSL 接続の確立に失敗することがあります。

  VMware SD-WAN Edge は、トラフィックが属するアプリケーションを識別できるように、この Edge を通過するすべてのユーザー トラフィックを検査します。これは、ビジネス ポリシーを正しく適用するため、および VMware SD-WAN Orchestrator が Edge の [監視 (Monitoring)] ページにアプリケーションごとの統計情報を表示するために必要です。ただし、アプリケーション識別コードの問題により、SSL 共通名に特殊文字またはスペースが含まれていると、SSL 共通名のバイトが上書きされ、その結果、SSL 共通名が破損していました。

• 解決した問題 65186：複数の WAN リンクを使用しているカスタマーのサイトで、優先または必須のポリシーで 1 つのリンクを使用するようにビジネス ポリシーが設定されている場合、ビジネス ポリシーでカバーされるトラフィック タイプは、使用可能なすべてのリンク間でロード バランシングされ続けます。

  ビジネス ポリシーが必須または優先設定を使用して 1 つの WAN リンクにトラフィックをルーティングするように設定されている場合でも、トラフィックは複数の WAN リンクでロード バランシングされます。

• 解決した問題 65219：i40evf ドライバを使用する KVM SR-IOV タイプ VMware SD-WAN Gateway が、1,500 バイト以上の顧客パケットをドロップします。 

  1496 バイト未満のデータ サイズはドロップされません。ユーザーが Gateway ホストに SSH 接続しようとすると、説明されている条件に基づいてハングが発生します。

• 解決した問題 65293：AWS に展開され、Amazon の Elastic Network Adapter (ENA) ドライバで実行されている VMware SD-WAN Gateway のスループット パフォーマンスが、リリース 4.x の使用時に劣化します。

  この問題は、Gateway を（3.x から）4.x ビルドにアップグレードした場合、または 4.x ビルドを使用する新しい展開で発生します。リリース 4.0.0 以降を使用するゲートウェイの DPDK は v19.11 ですが、DPDK v19.02 以降では、Amazon の ENA ドライバは低遅延キュー (LLQ) を使用します。ただし、LLQ を効率的に機能させるには、ENA リファレンス ガイドに従ってメモリ設定の書き込み結合を有効にする必要があります。  メモリ マッピングが書き込み結合されていない場合、AWS に展開された Gateway の CPU 使用率が高くなり、スループットに大きな影響を与えます。この問題の修正により、AWS に展開された Gateway の ENA アダプタで書き込み結合 (write-combining) が有効になります。

• 解決した問題 65432：VMware SD-WAN Gateway 経由で VMware SD-WAN Edge に LAN 側で接続されているクライアントから DC サーバに traceroute を実行すると、traceroute 出力に Gateway IP アドレスが表示されません。

  LAN クライアントから Gateway 経由でアクセス可能な DC への traceroute を開始すると、traceroute は Gateway IP アドレスを除くすべてのホップを表示します。

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

  Edge サービスを再起動すると、カスタマーのトラフィックが約 5 ～ 10 秒間中断されます。VeloCloud Management Protocol (VCMP) トンネルの作成ハンドシェイク中に予期しない制御メッセージを処理していると、Edge データプレーン サービスが失敗します。この問題は、ネットワーク トポロジやフローの数、スループットに依存しません。これはまれでランダムに発生する問題ですが、あらゆるタイプのカスタマー エンタープライズで発生する可能性があります。

• 解決した問題 65539：カスタマーが VMware SD-WAN Edge をリリース 4.2.x にアップグレードすると、2 つの異なるブランチにまたがる 2 台のデバイス間で確立された BGP セッションが起動しません。

  カスタマーが Edge を低いバージョンからリリース 4.2.x にアップグレードすると、VCMP トンネルを介して確立された異なるブランチの 2 つの LAN デバイス間の BGP セッションが起動しません。

• 解決した問題 65839：VMware SD-WAN Hub Edge の背後にあるクライアントからスポーク Edge の背後にある LAN に対して開始されたフローの場合、デフォルト ルートが Partner Gateway から広報されている場合、スポークからのリターン トラフィックは Partner Gateway 経由でルーティングされます。

  想定される動作は、ハブ Edge から送信されるフローがハブ Edge によって返される場合にも発生します。ハブ Edge からスポーク Edge に広報されたデフォルト ルートまたは Edge 間ルートがない場合、リターン トラフィックのスポーク Edge のルート参照は Partner Gateway のデフォルト ルートと一致し、リターン トラフィックはハブ Edge ではなく Partner Gateway にルーティングされます。
  
  修正を適用せずにこの問題を回避する唯一の方法は、デフォルト ルートまたは Edge 間ルートをハブ Edge からスポーク Edge に広報することです。

• 解決した問題 65985：Edge 間の動的な接続を使用している場合、ネットワーク内の VMware SD-WAN Edge が突然すべてのトンネルをドロップし、ネットワーク内の他のサイトへのトンネルを構築できなくなることがあります。

  サイトがすべてのトンネルをドロップすると、Edge のトンネルの最大値が破損し、トンネルの最大数に負の値が表示されます。この破損した値により、Edge が他の Edge への新しい動的 Edge 間トンネルを形成できなくなります。Edge がネットワーク内の他のサイトと通信できないため、この影響は深刻です。

  この問題を解決する唯一の方法は、Edge サービスの再起動または HA サイトの HA フェイルオーバーを実行することです。

• 解決した問題 66355：ステートフル ファイアウォールが有効で、少なくとも 1 つの LAN 側 NAT (多対 1) ルールが設定されているカスタマーの場合、VLAN 間フローは機能しません。

  多対 1 の LAN 側 NAT ルールでは、VLAN 間トラフィックの TCP 状態が適切に維持されず、ステートフル ファイアウォールも有効になっていると、パケットがドロップされます。

• 解決した問題 66366：多数のネイバーでマルチキャストを使用しているカスタマーの場合、VMware SD-WAN Edge でデータプレーン サービスの障害が発生して再起動し、カスタマー トラフィックが一時的に中断することがあります。

  「多数のネイバー」は、約 1,600 の PIM ネイバーとして定義されます。この問題が発生した場合、1,600 台のスポーク Edge からハブ Edge の背後にある 1 つのレシーバに対してトラフィックが実行されていると、PIM サービスが失敗し、Edge サービスも失敗して、再起動が発生します。

• 解決した問題 66676：ビジネス ポリシー NAT が設定されている場合、VMware SD-WAN Gateway からのリターン トラフィックが元の送信元 IP アドレスに戻らないことがあります。

  コードの NAT エントリ挿入中に、古いエントリを削除することが予測されます。ただし、ハッシュ テーブルの参照にすべてのキーを使用していないため、一部のインスタンスでは古いエントリが削除されず、NAT エントリ挿入エラーが発生していました。

• 解決した問題 66714：ユーザーは、VMware SD-WAN Edge で DCHP オプション 150 のホスト名を使用できません。

  ユーザーが DHCP オプション 150 のホスト名を設定する場合、DHCP クライアントを使用して Edge から IPv4 アドレスを取得しようとすると、Edge ログに dnsmasq エラー メッセージが記録され、ホスト名が不正な IP アドレスとして参照され、DHCP クライアントは Edge の DHCP サービスから IP アドレスを取得しません。  RFC 5859 はホスト名の代わりに IPv4 アドレスを使用するように設計されていますが、他の最新のネットワーク デバイスではオプション 150 のホスト名を使用できます。そのため、他のデバイスでホスト名を使用しているカスタマーは、Edge の DHCP サービスが中断しないように、Edge デバイスに対応する必要があります。

• 解決した問題 66801：高可用性トポロジと VNF を使用しているカスタマー サイトの場合、カスタマーは VNF に接続して管理サーバから信頼の確立を実行できない場合があります。

  この問題は、ルーティング インターフェイスが DHCP 対応で、カーネル ルート テーブルにデフォルト ルートがない場合に HA サイトで発生します。その場合、カーネルは「ICMP 宛先にアクセスできません (ICMP destination unreachable)」と応答します。

  修正を適用せずにこの問題を回避する回避策は、スタンバイ Edge にデフォルト ルートを追加して、Edge が「ICMP 到達不能 (ICMP Unreachable)」を VNF 仮想マシンに返さず、SSH 接続がリセットされないようにすることです。

• 解決した問題 67060：VMware SD-WAN Edge のメモリ使用率が高くなり、十分に高くなると Edge サービスが再起動する可能性があります。

  この問題は、メモリ使用率がゆっくりと継続的に増加するメモリ リークです。この問題は、1 つのフローに対して複数の HTTP 要求パケットが送信された場合に発生します。特に、Edge が HTTP 要求パケットを解析している間にメモリ リークが発生します。

• 解決した問題 67083：VMware SD-WAN Edge でデータプレーン サービスの障害が発生し、その結果再起動が発生し、カスタマーのトラフィックが短時間中断することがあります。

  いくつかのシナリオでは、VeloCloud Management Protocol (VCMP) データ パケットが誤ったパラメータ（たとえば、データ パケットが制御パケットとして誤って分類される）で処理され、例外がトリガされ、サービスが再起動されます。  

• 解決した問題 67173：同じルートが複数の IBGP ネイバーから学習されると、BGP プロセスから選択された 2 番目に最適なルートが VMware SD-WAN Edge によって使用され、特定のカスタマー トラフィックがブラックホール化します。

  Free Range Routing スイート (FRR) の問題により、IBGP は Edge に複数のネクスト ホップを送信し、2 番目のベスト（ネクスト ホップの順序で最後）を選択して転送情報ベース (FIB) を更新していました。この修正では、BGP プロセスに、Edge に最適なネクスト ホップのみを送信するコマンドが含まれています。

• 解決した問題 67197：マルチキャスト グループに関連付けられた送信元が 1,500 を超える環境では、カスタマーのネットワークでマルチキャスト サービスが定期的に中断することがあります。

  マルチキャスト グループに関連付けられた 1500 を超えるソースを持つ環境で join-prune の更新を処理するときに、PIM スタックの join-prune メッセージ処理ロジックが例外で失敗するソフトウェアの問題があります。

  修正を適用せずにこの問題を回避する唯一の方法は、マルチキャスト ソースの合計数を 1000 に制限する方法です。

• 解決した問題 67259：PIM プロセスが複数回再起動し、PIM ネイバーが起動しない場合、マルチキャスト トラフィック フローが中断します。

  1600 PIM ネイバーを使用したスケール設定で、700 スポーク Edge からハブ Edge の背後にあるレシーバへのトラフィックの実行中に PIM プロセスを複数回再起動すると、いずれかの再起動後、1600 PIM ネイバーから 570 以上の PIM ネイバーのみが発生しました。この問題を解決する唯一の方法は、Edge サービスを再起動することです。

• 解決した問題 67790：BGP または OSPF のいずれかを使用し、特定のルートを無視するように受信フィルタを設定しているカスタマー エンタープライズの場合、このエンタープライズで動的コスト計算 (DCC) を有効にすると、受信フィルタは無効になり、トラフィックはこれらのルートを使用しようとします。

  DCC が有効になる前は、転送情報ベース (FIB) には、BGP/OSPF 受信フィルタで IGNORE に設定されたルートは含まれません。  DCC を有効にすると、FIB にこのようなルートが含まれるようになり、トラフィックはこれらのルートを使用しようとしますが、カスタマー エンタープライズにおいて重大なトラフィックの中断が発生する可能性があります。

  この修正を適用しない場合の唯一の回避策は、受信フィルタが適切に適用されるように OSPF/BGP を再起動することです。

• 解決した問題 68840：高可用性トポロジを使用しているカスタマーの場合、SNMP ポーリングは VMware SD-WAN スタンバイ Edge から LAN および WAN 情報を取得できません。

  HA SNMP GET の場合、スタンバイ LAN/WAN の数（vceHaStandbyLanItfNum および vceHaStandbyWanItfNum）が部分的に表示されるか、すべて表示されません。

• 解決した問題 68994：VMware SD-WAN Gateway を使用して VMware SD-WAN Edge から Non SD-WAN Destination (NSD) トンネルを展開する場合、トンネルのフラッピングが発生することがあります。

  この問題は、トンネルの確立時または IKE の再キー化時に発生します。Edge または Gateway は IKESAID=0 に基づいて Security Association (SA) を削除し、トンネルのフラッピングを引き起こします。トンネルは自動的に安定化しますが、これを行うのに必要な時間が一貫していないため、NSD へのカスタマー トラフィックにさらなる影響を与える可能性があります。

• 解決した問題 69497：VMware SD-WAN MIB には、有効なオブジェクトでなくても、vceLinkVpnState SNMP オブジェクトが表示されます。

  VMware SD-WAN Orchestrator で VMware SD-WAN Orchestrator の VPN の区別された状態が表示されなくなりましたが、これは SNMP で引き続き公開されます。  具体的には、SNMP コレクタは SNMP OID 1.3.6.1.4.1.45346.1.1.2.3.2.2.1.26 をポーリングしますが、これは実行する必要がなくなりました。  

• 解決した問題 69681：VMware SD-WAN Edge がホット スタンバイ WAN リンクを使用して設定され、SNMP ポーリングも使用している場合、SNMP エラーが表示されます。

  次のようなエラー メッセージが表示されます。

  ERROR [oids (10028:MainThread:10028)] [VCE.Path]<update>: Path failed update buffer: KeyError('HOTSTANDBY_IDLE',)
  INFO  [oids (10028:MainThread:10028)] [VCE]<update_if_stale>: Current MIB buffer size: 217
  DEBUG [oids (10028:MainThread:10028)] [VCE.Link]<ip2octet>: Failed to convert IP to Octet for caller <class 'vcsnmp.oids.Link'>[publicIpAddress] on []: ValueError("invalid literal for int() with base 10: ''",), used default value[00 00 00 00] instead
  

  この問題の原因は、SNMP パスの状態にホット スタンバイ リンクの状態が含まれないことで、エラー メッセージを含む SNMP の問題が発生します。

• 解決した問題 70154：ステートフル ファイアウォールが有効になっているカスタマー エンタープライズの場合、同じ ICMP ID を持つブランチ クライアント間で双方向 ping を送信すると、パケットのドロップが発生します。

  ブランチ 1 のクライアント A からブランチ 2 のクライアント B に、またはその逆に ping が開始された場合、ICMP ID が同じであれば、両方の ping の ICMP 状態が同じフロー オブジェクトで追跡され、シーケンス番号チェックのために複数のパケット ドロップが発生する可能性があります。

  この修正なしで問題を回避する方法は、ステートフル ファイアウォールを無効にするか、異なる ICMP ID を使用して ping を生成することです。

• 解決した問題 70310：複数のセグメントを使用しているカスタマーの場合、1 つ以上のセグメントを削除または無効にすると、VMware SD-WAN Edge でデータプレーン サービスの障害が発生し、そのサービスが再起動され、カスタマー トラフィックが短時間中断することがあります。 

  セグメントが削除されるときに、Edge はこの削除されたセグメントに関連付けられているメモリを完全にクリーンアップしません。アクティブ Edge がこのようなセグメントを参照してイベントをスタンバイ Edge と同期するシナリオがあります。これにより、これらのセグメントがないため、スタンバイ Edge でサービス障害が発生します。

• 解決した問題 70789：IPsec のアンチ リプレイ検出により、トラフィックがランダムにドロップする場合があります。

  VMware SD-WAN Edge または VMware SD-WAN Gateway のいずれかが 2 つのパケットを受信し、それぞれがキャッシュ エントリ シーケンス番号を更新する場合、最初のパケットがリプレイ ウィンドウを誤って更新する可能性があります。これにより、IPsec のアンチ リプレイ検出がトリガされ、IPsec パケットがドロップする可能性があります。

Orchestrator で解決した問題

Orchestrator ビルド R422-20220715-GA で解決した問題

Orchestrator ビルド R422-20220715-GA は 2022 年 8 月 10 日にリリースされた、リリース 4.2.2 の 3 番目の Orchestrator ロールアップです。

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

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

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

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

  注：このエントリは、Orchestrator OVA のみを追跡します。この問題の Gateway 側は、ビルド R422-20220518-GA 以降で修正されています。

• 解決した問題 85883：VMware SD-WAN Edge がプライマリのアクティブ WAN リンクとバックアップ WAN リンクを VMware SD-WAN Orchestrator 上に持つように事前設定されている場合、バックアップとして指定された WAN リンクを使用して Edge がアクティベーションされると、プライマリ WAN リンクが接続された後でも、Orchestrator はこのリンク状態を引き続きアクティブとして表示します。

  バックアップとして設定された WAN リンクは設定のとおりに使用されているため、これは表示上の問題です。つまり、プライマリ WAN リンクが Edge に接続された後、バックアップ WAN リンクの管理トンネルが破棄され、トラフィックは渡されません。この問題は、Orchestrator が [監視 (Monitor)] > [Edge] > [概要 (Overview)] ページに WAN リンクのバックアップ 状態を正確に表示していないため、WAN リンクの実際の状態に関してユーザーの混乱を招くということです。

___________________________________________________________________

Orchestrator ビルド R422-20220112-GA

Orchestrator ビルド R422-20220112-GA は 2022 年 1 月 21 日にリリースされた、リリース 4.2.2 の 2 番目の Orchestrator ロールアップです。

この Orchestrator ビルドは、Log4j バージョン 2.17.0 に更新することで、Apache Log4j の脆弱性 CVE-2021-44228（最初は Log4j バージョン 2.16.0 を含む Orchestrator ビルド R422-20211216-GA で対処済み）および CVE-2021-45046 を修正します。Apache Log4j の脆弱性と VMware 製品への影響に関する最新情報については、VMware セキュリティ アドバイザリ VMSA-2021-0028.9 を参照してください。

___________________________________________________________________

Orchestrator ビルド R422-20211216-GA

Orchestrator ビルド R422-20211216-GA は 2021 年 12 月 20 日にリリースされた、リリース 4.2.2 の 1 番目の Orchestrator ロールアップです。

Orchestrator ビルドは、Log4j バージョン 2.16.0 に更新することで、Apache Log4j の脆弱性 CVE-2021-44228 を修正します。Apache Log4j の脆弱性の詳細については、VMware セキュリティ アドバイザリ VMSA-2021-0028.5 を参照してください。

___________________________________________________________________

バージョン R422-20210920-GA で解決した問題

Orchestrator バージョン R421-20210415-GA 以降で解決した問題は次のとおりです。

• 解決した問題 20900：MaxMind 位置情報サービスが有効になっていて、MaxMind サーバにアクセスできない場合、新しい VMware SD-WAN Edge のアクティベーションが機能しません。

  Edge は、アクティベーションのために VMware SD-WAN Orchestrator への HTTPS 接続を作成します。要求のデフォルトのタイムアウトは 120 秒で、プロキシ接続の場合は 60 秒です。Orchestrator が Edge（IPv4 リモート アドレス）の位置情報を取得しようと試みると、アップロードはアクティベーションを続けるために MaxMind サービスからの応答を待ちます。そのため、60 秒後に NGINX はアップロード サービスの応答を停止し、接続を閉じます。この結果、NGINX からの 504 タイムアウトのため、アクティベーションは失敗します。 

  新しいシステム プロパティ service.maxmind.timeout.seconds を使用すると、Maxmind API 呼び出しはカスタム タイムアウトを使用して行われます。タイムアウトに達した場合でも、呼び出しはアクティベーション ワークフローを続行するため、Edge は正常にアクティベーションされます。

• 解決した問題 45078：VMware SD-WAN Orchestrator でカスタマーの VNF を設定するときに、VNF の状態がプロファイル レベルで一方向に設定され、Edge 固有のルールを使用してサイト レベルで別の方法で設定された場合、Edge 固有のルールが後で無効になった場合、サイトは引き続き Edge 固有のルール設定を使用し、想定どおりにプロファイル設定に戻りません。

  この問題は、設定プロファイルで VNF 挿入パラメータを設定するときに発生します。この場合、Edge 固有のルールを使用してサイトに対して反対の設定が行われ、その後 Edge 固有のルール自体が無効になりますが、設定は維持されます。

• 解決した問題 48706：ユーザーは、Syslog 設定で送信元インターフェイスが選択されている状態で、[設定] > [Edge] > [デバイス] タブで変更を保存できない場合があります。

  VMware SD-WAN Orchestrator に、「指定された送信元インターフェイスがセグメント <セグメント名> 上のセグメントに存在しません」というエラーが表示されます。これは、ユーザーが多数のセグメントを作成および削除し、セグメントのシーケンスが失われたことが原因です。

• 解決した問題 48791：Edge に Edge 固有のルールを使用してインターフェイスが設定されている場合、ユーザーはプロファイル間で VMware SD-WAN Edge を切り替えることができません。

  たとえば、2 つの設定プロファイル、プロファイル 1 とプロファイル 2 があり、プロファイル 1 とプロファイル 2 は、Edge をプロファイル 1 に関連付けます。  その後、ユーザーが Edge 固有のルールを使用して GE2 をルーティングするように設定し、GE2 のスタティック ルートを追加する場合、ユーザーが後で同じ Edge をプロファイル 2 に割り当てようとすると、ユーザーは、GE2 がルーティング済みとしてプロファイル 2 に存在しないというエラーが表示されます。この問題は、ユーザーがプロファイルに属する Edge 固有のルールを使用して Edge インターフェイスを設定するときに、Orchestrator が Edge 固有のルールの存在を検証しておらず、VMware SD-WAN Orchestrator を切り替えることができないために発生します。

• 解決した問題 52379：VMware SD-WAN Edge が設定された遅延間隔内にリカバリした場合、VMware SD-WAN Orchestrator が「Edge 停止 (Edge Down)」アラート E メールを送信します。

  管理者は、アラートをトリガする前に Edge が一定期間ダウンするように遅延を設定したにもかかわらず、ネットワーク内の Edge が停止しているという誤ったアラートを受け取る可能性があります。

• 解決した問題 52863：VMware SD-WAN Orchestrator ユーザー インターフェイスが非標準の BGP タイマー設定を許可し、エラーをスローしません。

  カスタマー設定ページでパートナーのハンドオフ設定を有効にしているときに、ユーザーが Orchestrator で RFC 4271 の BGP 標準に準拠していない BGP キープ/ホールド タイマーを設定すると、Orchestrator は設定の保存を許可します。ただし、VMware SD-WAN Edge 自身では、FRR は標準に準拠するためにキープ/ホールドの値を変更します。たとえば、ユーザーが Orchestrator でキープ 2 秒/ホールド 5 秒を設定すると、Edge FRR はキープ値を 1 秒に変更して、3 x キープ =（ホールド以下）になるようにします。

• 解決した問題 53525：VMware SD-WAN Orchestrator で新しいユーザー インターフェイスを使用して、[Edge の概要 (Edge overview)] ページを表示するときに、[リンク (Links)] 列にリンクの状態（バックアップ、スタンバイなど）が表示されません。

  このリンク状態の情報は古いユーザー インターフェイスで正しく表示されており、今回の修正により新しいユーザー インターフェイスで想定通りに表示されます。

• 解決した問題 53652：カスタム アプリケーション マップを使用しているカスタマー エンタープライズを 3.x から 4.x にアップグレードすると、アップグレード前に作成されたカスタム アプリケーションの名前がランダムに表示される場合があります。

  デフォルトの初期アプリケーション マップの一部としてすでに存在しているアプリケーション ID (appId) を使用してカスタム アプリケーションが設定されている場合、VMware SD-WAN Orchestrator では、デフォルトの初期アプリケーション マップの表示名が常に表示され、カスタマーが定義した名前は上書きされます。これは、Orchestrator が下位バージョンから上位バージョンにアップグレードされ、上位バージョンのデフォルトの初期アプリケーション マップに、下位バージョンで作成されたカスタム アプリケーションの appId と競合する appid が含まれている場合にも当てはまります。  Orchestrator のアップグレード後、これらのカスタム アプリケーションには誤った表示名、すなわち上位バージョンのデフォルトの初期アプリケーション マップの appid の表示名が表示されます。

• 解決した問題 53857：リリース 4.0.0 に基づく KVM イメージを使用する VMware SD-WAN Orchestrator の展開が失敗します。

  失敗となる理由は、KVM イメージの仮想ディスク サイズが正しくなく、ボリュームが必要なサイズに拡張されないためです。  展開において、Orchestrator スクリプトによって Orchestrator ボリュームが自動的に拡張され、基になるディスク（物理ボリューム）の最大サイズの 80% を占めます。  この場合、仮想サイズが正しくないため、その拡張は Orchestrator データベース要件に対して不適切となり、展開が失敗します。  この修正を行わずに古いビルドを使用して Orchestrator を展開することはできますが、ボリュームのサイズを手動で変更する必要があります。

• 解決した問題 53919：VMware SD-WAN Orchestrator ユーザー インターフェイスで、短い時間範囲（例：1 時間）の履歴データ（> 2 週間）を表示すると、データが存在していても返されず、より広い時間範囲を使用して表示できます。

  広い時間範囲（例：過去 31 日間）で Edge 統計をクエリすると、時間範囲全体のデータが表示されます。ただし、履歴データを拡大して短い時間範囲をクエリすると、利用可能なデータがないと表示されるようになりました。

• 解決した問題 54546：VMware SD-WAN Orchestrator ユーザー インターフェイスの [監視 (Monitor)] > [Edge (Edges)] ページに、クラウド セキュリティ サービスまたは Edge 経由の Non SD-WAN トンネルが正しく表示されません。

  この問題は、CSS または Edge 経由の NSD トンネル用の USB インターフェイスを介して WAN リンクを使用する VMware SD-WAN Edge が複数ある場合に発生する可能性があります。Orchestrator はトンネル イベントを時間順に並べ替えており、「datakey」ごとの最新のイベントを使用して有効な状態を判断しています。多くのエントリでキーの値が同じであるため、一部のトンネルが除外されています。これは表示のみの問題であり、誤った状態を表示する以外にカスタマーへの影響はありません。

• 解決した問題 55871：REST APIv2 (/sdwan) HTTP に対する API 呼び出しによって、サーバが HTTP 500 エラーを生成する場合があります。

  カスタマーのデータが API が想定するスキーマに正確に準拠していない場合、API は文書化された API スキーマと不整合であるデータを返すのではなく、HTTP 500 エラーを生成します。この動作は、その後に再検討された設計上の判断として発生したものとなります。「GET /enterprises」、「GET /enterprises/{enterpriseLogicalId}/edges」、および「GET /enterprises/{enterpriseLogicalId}/clientDevices」への呼び出しが影響を受けることがわかっています。

• 解決した問題 57046：VMware SD-WAN Orchestrator でのカスタマーの作成時には、オペレータのアクセスは許可されていません。ただし、Orchestrator が 4.0.x リリースにアップグレードされると、オペレータ アクセスをチェックせずに、MODIFY_ENTERPRISE_CUSTOM_ROLES および VIEW_PATH_STATS 権限がシステム パッチによって追加されます。

  カスタマーの設定には、オペレータに委任された権限が示されていますが、オペレータには、たとえばネットワーク サービスの読み取りや Edge/プロファイルの変更などの権限がありません。そのため、オペレータがそのカスタマーのエンタープライズに対して実行できることについて、誤った状態が表示されます。

• 解決した問題 57163：カスタマーが、クラウド セキュリティ サービス (CSS) または Edge 経由の Non SD-WAN Destination (NSD) トンネル アラートに関する通知を SNMP トラップを介して受信できません。

  この問題は、カスタマーが SNMP トラップを使用して CSS/Edge 経由の NSD トンネル アラートを受信するときに、それらのイベントに対して SNMP トラップがトリガされていない場合に発生します。

• 解決した問題 58127：ユーザーが、エンタープライズ レポートに関するいくつかの問題を確認します。

  問題には、表示されるべきではないレポートの ID フィールド、生成されたレポートにユーザー名がない、50 件のレポート制限などが含まれます。  このチケットは、最初の 2 つの問題を修正します。  50 件のレポート制限は、Orchestrator のパフォーマンスの問題を防ぐために設計されたシステム プロパティ設定です。Orchestrator 管理者はレポートの上限を増やすことができますが、Orchestrator のパフォーマンス上のリスクを伴います。

• 解決した問題 58627：アラートを受信するように設定されたユーザーが、リンクがダウンしたままであるのにリンク アップ アラートを受信する場合があります。

  リンクが「ダウン (Down)」とマークされた後、リンクがダウンする前に生成されたリンクの統計情報がイベント後最大 1 分間、VMware SD-WAN Orchestrator に送信されない場合があります。  Orchestrator がこのような遅延リンク統計を受信すると、リンクがバックアップされていると誤解し、アラート設定が厳しい場合（たとえば、0 分の遅延）にリンク アップ アラートをトリガします。  この修正により、Orchestrator は、遅延リンク統計をリンクが起動していることを示すものとして解釈しないようになります。

• 解決した問題 59094：オペレータが VMware SD-WAN Orchestrator をアップグレードしようとするときに、スキーマの更新要件に関する適切な警告メッセージが更新スクリプトで表示されません。

  オペレータがより大きなテーブルにスキーマ変更を適用する手順を行わなかった場合、Orchestrator サービスでエラーが発生する可能性があります。  また、どの変更が欠落しているかを簡単に特定できる方法もありません。この修正により、バックエンドサービスの再起動時に、大きなテーブルで必須の、欠落していたスキーマの変更が再生成される場合に、この問題が解決されます。

• 解決した問題 59689：エンタープライズおよび Edge の数が非常に多い VMware SD-WAN Orchestrator で新しいユーザー インターフェイスを使用すると、[監視 (Monitor)] > [ファイアウォールのログ (Firewall Logs)] ページのロードが遅くなるか、完全に応答しなくなることがあります。

  この問題は、200 以上のカスタマー エンタープライズと数千の Edge を持つホスト型 Orchestrator で発生しています。

• 解決した問題 60502：VMware SD-WAN Edge で学習した BGP ルートが VMware SD-WAN Orchestrator および VMware SD-WAN Gateway にプッシュされず、「OFC 上限に達しました (OFC cap reached)」というメッセージが表示されることがあります。

  この問題は、Edge が 2,000 個以上のルートを処理している場合に発生します。このような場合、Edge は 2,000 個のルート バッチをルーティング API に送信し、このアップロードはバッチ処理に約 300 秒かかります。  ただし、NGINX は 60 秒のタイムアウト後に呼び出しを拒否し、Edge は拒否を受け取り、同じ 2000 ルートを持つルーティング API をリコールします。アップロードにより、ルートは再び正常に処理されますが、NGINX はタイムアウトが原因で呼び出しを拒否し、このループは継続され、Orchestrator は同じバッチを何度も繰り返し処理して、ルートを学習しなくなります。

• 解決した問題 60608：VMware SD-WAN Edge のデバイス設定の [スタティック ルート設定 (Static Route Settings)] セクションでインターフェイスを選択するドロップダウンを使用できません。

  ユーザーが VMware SD-WAN Orchestrator ユーザー インターフェイスで Edge にスタティック ルートを追加しようとすると、ネクスト ホップの IP アドレスに関係なく、インターフェイスは「該当なし (Not Applicable)」のままになります。

• 解決した問題 61000：新しく作成されたオペレータ プロファイルが、VMware SD-WAN Orchestrator ユーザー インターフェイスの [パートナーの概要 (Partner Overview)] ページから選択できない場合があります。

  Orchestrator に 100 件を超えるオペレータ プロファイルがあり、ユーザーが [パートナーの概要 (Partner Overview)] ページからそれらのいくつかを選択しようとすると、100 件のみがユーザー インターフェイスに表示されます。修正を適用せずにこの問題を解決する唯一の方法は、VMware SD-WAN テクニカル サポートに依頼して要求されたオペレータ プロファイルを割り当ててもらうことです。

• 解決した問題 61312：VMware SD-WAN Orchestrator（特に Orchestrator のアップグレード後）では、ルートが更新されなくなり、Orchestrator の CPU 使用率がほぼ 100% になるという問題が発生する可能性があります。

  この問題は、Edge が Orchestrator のルーティング API に 2,000 以上のルート更新を送信すると発生します。Orchestrator が特定の API 呼び出しで送信されたルートのセット全体を 60 秒以内に処理できない場合は、その呼び出しがタイムアウトになります。その結果、API 呼び出しは完全に拒否されます。Edge はこの拒否を受信し、同じ 2,000 以上のルートを Orchestrator に再びプッシュしようと試みます。これにより、以前と同じシナリオが発生し、Orchestrator の仮想 CPU リソースに過負荷を生じさせるループが発生します。この問題が発生すると、ルート更新の処理が妨げられる可能性があります。 

  この問題を解決するために、次の 2 つのシステム プロパティが追加されました。

  edge.learnedRoute.maxRoutePerCall このプロパティを使用すると、Edge から処理されるルートの数が制限されます。プロパティ値が「200」の場合、Edge 要求ごとに 200 のルートが処理され、確認応答がタイムリーに Edge に送信されます。

  vco.learnedRoute.simultaneous.maxQueue このプロパティを使用すると、一度に設定された数の Edge だけがルート要求をキューに登録することができます。このプロパティ値が「8」の場合、一度に 8 台の Edge のみがルート要求の送信を許可され、設定された値を超える Edge は、ルートが処理される直前に拒否されます。

• 解決した問題 61625：OSPF で広報されるルートが約 250 を超える場合、VMware SD-WAN Hub Edge はすべてのルートを広報しません。

  ルートの数にかかわらず、300 または 2000 以上であっても、約 250 個のルートのみが広報済みとして表示され、残りのルートの広報 フラグは FALSE に設定されます。これは、ルートの処理が約 250 個を超える遅延が原因で発生し、要求ごとに処理するルートの数がはるかに少なくなるために解決されます。

• 解決した問題 61852：新しいユーザー インターフェイスの [監視 (Monitor)] > [ファイアウォールのログ (Firewall Logs)] ページに、正しいページ付け情報が表示されません。

  このセクションのページ行数が正しくありません。

• 解決した問題 62145：VMware SD-WAN Orchestrator を下位リリースから 4.2.1 にアップグレードすると、移行が失敗し、一意の制約中断エラーが発生します。これは、クライアント デバイス テーブルの「logicalId」フィールドにあります。

  リリース 4.2.1 には、クライアント デバイス テーブルに「logicalId」を追加する移行時に実行される長期実行操作があります。この操作は、前提条件クエリに基づいてのみ実行されます。この前提条件のクエリが正しくなかったため、logicalId フィールドが空になります。logicalId フィールドに制約を追加すると、複数の行が空の文字列として logicalId で構成されているため、重複エラーが発生しました。

  この修正を行わない場合の唯一の回避策は、移行時に、保留中の長期実行クエリを手動で実行することです。これにより、クライアント デバイス テーブルのすべての行に一意の logicalId が追加され、一意の制約クエリが追加されます。

• 解決した問題 62624：ユーザーが VMware SD-WAN Orchestrator ユーザー インターフェイスの [Gateways] > [概要 (Overview)] ページで [Partner Gateway] ボックスの選択を解除しようとすると、エラーがポップアップ表示され、プロファイル名のみが表示され、カスタマーがプロファイルを所有していることを示すメッセージが表示されません。

  ユーザーがこの Gateway を使用しているカスタマーを把握できないため、VMware SD-WAN Gateway の状態を変更する必要がある場合、これは重大な問題となります。なぜなら、ユーザーが見ることができるのはプロファイルだけで、プロファイルに接続しているカスタマーの表示がないので実質的に意味がないからです。

• 解決した問題 62654：Partner Gateway の使用中に Partner Gateway チェックボックスをオフにすると、カスタマー名が表示されます。

  ユーザーが VMware SD-WAN Orchestrator ユーザー インターフェイスで特定の Gateway の [Partner Gateway] チェックボックスをオフにし、その Gateway が 1 つ以上のカスタマーおよびカスタマー プロファイルでも使用されている場合、Orchestrator には、Gateway を使用しているカスタマー名ではなく、プロファイルの名前と Edge のみが表示されます。

• 解決した問題 63556：ユーザーは、VMware SD-WAN Orchestrator ユーザー インターフェイスに複数の TACAC サーバを追加できます。

  ユーザーは複数の TACAC サーバを追加できますが、これは有効な設定ではありません。  これは、最初の TACAC サーバに障害が発生した場合、2 番目の TACAC サーバが引き継がないためです。  この修正により、複数の TACAC サーバを追加するオプションが削除されます。

• 解決した問題 64039：場合によっては、DHCP サーバが非アクティブと表示されることがあります。

  この問題は、アドレス指定タイプに値を指定した後、DHCP サーバを有効にして値を指定し、[更新] ボタンをクリックすると発生します。ユーザーがサブインターフェイス ポップアップを開くと、DHCP サーバが非アクティブとして表示され、DHCP サーバ上のすべてのフィールドが非表示になります。

• 解決した問題 65253：ファイアウォール ルールを設定する際に、20 個以上のグループを設定すると、VMware SD-WAN Orchestrator のユーザー インターフェイスでオブジェクト グループのドロップダウン リストが使用できません。

  5 個以上のオブジェクト グループ（アドレス グループ、ポート グループ）を設定しても、ブラウザ画面の下方に [オブジェクト グループ] ドロップダウンリストが表示されます。  20 個以上のルールがある場合、オブジェクト グループのリストが画面から完全に消えてしまいます。ブラウザで大きくズームアウトするとリストを表示できますが、文字が非常に小さくなり判読不能になります。

• 解決した問題 65526：VMware SD-WAN Orchestrator が、「オフライン/停止 (Offline/Down)」状態に達することのない、「劣化 (Degraded)」状態の VMware SD-WAN Edge に対してアラートとイベントを生成します。

  VMware SD-WAN Edge が最初にハートビート チェックで Orchestrator への接続を失うと、この状態は「劣化 (Degraded)」と呼ばれます。  Edge から Orchestrator への接続が失われ続けると、Edge は「オフライン/停止 (Offline/Down)」とマークされます。この 2 番目の状態は、Orchestrator の [監視 (Monitor)] > [イベント (Events)] ページに「Edge 停止 (Edge Down)」イベントが投稿され、対応するアラートをカスタマーのアラート設定に応じて送信する必要がある場合です。  ただし、Orchestrator は「劣化 (Degraded)」状態の Edge に対してイベントを生成し、アラートを送信しているため、偽の「Edge ダウン (Edge Down)」イベントとアラート通知が大量に発生する可能性があります。

• 解決した問題 66203：クラウド ホスト Gateway とパートナー管理 Gateway の両方を含む Gateway プールがカスタマーに割り当てられている場合、パートナーは管理対象 Gateway の Gateway ハンドオフ設定を変更できません。

  この問題は、パートナー管理者ユーザーが [カスタマー (customers)] ページにある [カスタマー (Customer)] タブで Gateway ハンドオフ設定を変更しようとした場合に発生します。

• 解決した問題 66597：非常に多くの Edge が展開されている VMware SD-WAN Orchestrator で、カスタマーが使用している Gateway プールに複数の VMware SD-WAN Gateway を追加すると、Orchestrator で多数の Edge がダウンしていると表示されることがあります。

  この問題は、Orchestrator に約 7,000 の Edge が接続されているカスタマーのフィールドで確認されました。そのカスタマーの Gateway プールに変更がある場合、Orchestrator はすべての Edge に設定の変更をプッシュする必要があります。30 秒の時間内に 700 以上の Edge に対する制御プレーンを再計算すると、ハートビート/統計情報のプッシュが「POOL_ENQUEUELIMIT」エラーで失敗します。ハートビート障害により、Orchestrator で Edge がダウンしているように表示されます。

• 解決した問題 66631：移行ツールは、大規模なカスタマー エンタープライズを移行しようとすると機能しません。

  大規模なカスタマー エンタープライズは、100 以上の Edge を持つ 1 つのカスタマー エンタープライズとして定義されます。移行ツールは、データ BLOB 全体を文字列化してファイルに書き込む必要がある手順で失敗します。設定のエクスポートを行うとき、移行ツールは JSON.stringify を使用して出力データを文字列化して、ファイルに書き込みますが、設定が非常に大きい場合は失敗します。

• 解決した問題 67153：設定された遅延間隔内に VMware SD-WAN Edge が起動した場合でも、アラート E メールが送信されます。

  VMware SD-WAN Orchestrator は、設定された遅延間隔内にイベントが発生した場合でも、Edge ダウン/起動アラート通知を送信します。

• 解決した問題 71399：または、ディザスタ リカバリ (DR) 設定で展開された VMware SD-WAN Orchestrator の場合、オペレータ ユーザーは、スタンバイ Orchestrator がアクティブ Orchestrator との同期に失敗したことを確認できます。

   Orchestrator ユーザー インターフェイスの [レプリケーション (Replication)] ページで、アクティビティ モニターにすべての同期アクティビティが失敗と表示されます。DR の同期エラーは、アクティブ Orchestrator が設定データベースをスタンバイ Orchestrator にコピーできない初期ハンドシェイクで発生します。

既知の問題

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

既知の問題は、以下のとおり分類されています。

• Edge/Gateway の既知の問題
• Orchestrator の既知の問題

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 ユーザー インターフェイスで、インターフェイスの「自動ネゴシエーション」と「速度」の状態が誤って表示されることがあります。

• 問題 32981：

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

• 問題 35778：

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

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

• 問題 35807：

  VMware SD-WAN Orchestrator からインターフェイスを無効にして再度有効にすると、DPDK ルーテッド インターフェイスが完全に無効になります。 

• 問題 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 が失敗することがあります。

• 問題 39659：

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

• 問題 39753：

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

• 問題 40096：

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

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

• 問題 40421：

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

• 問題 42278：

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

• 問題 42388：

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

• 問題 42488：

  スイッチ ポートまたはルーティング ポートに対して VRRP が有効になっている VMware SD-WAN Edge で、ケーブルがポートから切断されて、Edge サービスが再起動された場合、LAN に接続されたルートが広報されます。

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

• 問題 42872：

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

• 問題 43373：

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

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

• 問題 44832：

  Edge 経由の Non SD-WAN Destination から別の Edge 経由の Non SD-WAN Destination へのトラフィック（「ヘアピニング」または「NAT ループバック」）が VMware SD-WAN Edge 上でドロップされます。

• 問題 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 暗号化を使用したトンネルが開始されません。

• 問題 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 で使用できます。

• 問題 46918：

  3.4.2 リリースを使用する VMware SD-WAN スポーク Edge で、クラスタ ハブ ノードのプライベート ネットワーク ID が適切に更新されません。

• 問題 47084：

  4,000 個のスポーク Edge が接続されている場合に、VMware SD-WAN ハブ Edge が、750 個を超える PIM（プロトコルに依存しないマルチキャスト）ネイバーを確立できません。

• 問題 47355：

  同じルートがローカルのアンダーレイ BGP、ハブ BGP を経由して学習された場合、または Partner Gateway で静的に設定されている場合、またはそのすべての状況で、ルートのソート順序が、アンダーレイ BGP で優先されるハブ BGP と一致しません。

• 問題 47664：

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

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

• 問題 47681：

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

• 問題 47787：

  ハブ Edge から、バックホール ビジネス ポリシーで設定された VMware SD-WAN スポーク Edge にフローが開始された場合、このスポーク Edge が VMware SD-WAN Gateway パスを経由してトラフィックを誤って送信します。

• 問題 48166：

  Ciena の仮想化 OS を使用している場合、KVM 上の VMware SD-WAN 仮想 Edge がサポートされず、Edge では、データプレーン サービスの障害が繰り返し発生します。

• 問題 48175：

  非グローバル セグメントにグローバル セグメントで設定されたインターフェイスと同じ IP アドレス範囲で設定されているインターフェイスがある場合、リリース 3.4.2 を実行している VMware SD-WAN Edge が、非グローバル セグメントに OSPF の隣接関係を形成します。

• 問題 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 ループバック ネイバーシップも含まれます。

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

• 問題 48666：

  IPsec を使用したゲートウェイ パス MTU の計算で、61 バイトの IPsec オーバーヘッドが考慮されていないため、LAN クライアントに対する MTU 広報が多くなり、その後 IPsec パケットの断片化が発生します。

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

• 問題 49172：

  2 つの異なる VMware SD-WAN Edge に同じ NAT サブネットを使用して設定されたポリシー ベースの NAT ルールが機能しません。

• 問題 49738：

  状況によっては、VMware SD-WAN スポーク Edge が複数のハブ Edge を使用するように設定されている場合に、ハブ リストで設定されたハブの 1 つに対して、スポーク Edge がトンネルを形成しないことがあります。

• 問題 50518：

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

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

• 問題 51428：マルチキャスト トラフィックの損失が、VMware SD-WAN Edge に PIM で設定されたサブインターフェイスがあるサイトで発生する場合があります。

  PIM を使用して設定されたサブインターフェイスをその場であるセグメントから別のセグメントに移動すると、pimd（PIM を管理するプロセス）が再起動し、サイトで断続的なマルチキャスト トラフィックの損失が発生する可能性があります。

  回避策：最初にサブインターフェイスをアクティベーション解除してから、サブインターフェイスを別のセグメントに移動します。移動したら、サブインターフェイスを再度有効にします。

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

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

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

• 問題 52483：インターフェイスでアンダーレイ アカウンティング が有効になっている場合、VMware SD-WAN Edge は、トラフィックをオーバーレイに転送するのではなく、誤って同じインターフェイスに転送します。

  この動作は、アンダーレイ アカウンティングと再帰的なルート解決の問題が原因で発生します。

  回避策：影響を受けるインターフェイスのアンダーレイ アカウンティングをオフにします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  回避策：LAN 側に障害がある（または BGP が無効になっている）ハブを再起動します。

• 問題 54846：VMware SD-WAN SNMP MIB は、ジッター、遅延、パケット ロスにカウンタを使用します。

  VMware SNMP MIB では、遅延、ジッター、およびパケット ロスは、これらのタイプに適さない Counter64 として定義されます。カウンタは、値が常に増加し、Tx/Rx バイトのように SNMP でリセットされないデータ タイプに使用する必要があります。対照的に、遅延、ジッター、およびパケット ロスの値は増加しませんが、動的に調整された値であるため、カウンタを使用しないでください。

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

• 問題 59524：DHCP リレーが Edge に設定されていると、VMware SD-WAN Edge でデータプレーン サービスの障害が発生し、リカバリするために再起動することがあります。

  この問題は、負荷の高い状態で発生する可能性があります。DHCP リレー パケットの割り当てが失敗し、Edge の DHCP リレー処理がこれを適切に処理せず、継続的な DHCP 割り当ての失敗により最終的に Edge サービスで例外がトリガされ、再起動が実行されます。

  回避策：この問題の回避策はありませんが、Edge バージョン 4.3.0 以降で解決されています。

• 問題 59920：32 以上のパスで使用される Edge インターフェイスの設定を変更すると、VMware SD-WAN Edge でデータプレーン サービスの障害が発生し、再起動することがあります。

  設定の変更には、インターフェイスの削除や、新しいパラメータによるインターフェイスの更新が含まれます。32 を超えるパスを使用するインターフェイスで変更を行うと、Edge サービスで例外がトリガされ、再起動が発生します。

  回避策：この問題はリリース 4.3.0 以降で修正されました。4.2.2 のホットフィックス ビルドの可用性については、VMware SD-WAN サポートにお問い合わせください。この問題が修正されていないビルドを使用している Edge では、メンテナンス期間中にのみ Edge インターフェイスを変更する必要があります。

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

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

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

• 問題 61716：リリース 4.2.0 以降を使用している VMware SD-WAN Edge では、ルート検索の失敗により、VMware SD-WAN Orchestrator が生成したパケットがドロップすることがあります。

  管理パケットを管理するプロセスには、トラフィックを送信するためのデフォルトのクラウド ルートを選択するためのハード ルールがあります。リリース 4.2.x には並べ替えロジックを変更する修正が含まれており、Edge は BGP/OSPF を介して学習したデフォルト ルートをクラウド ルートよりも優先するようになりました。  このシナリオでは、ルートが並べ替えられたデフォルト ルートは次のようになり、アンダーレイ BGP が最も優先されます。高速パスでは、ルート参照によって宛先のクラウド ルートが提供されず、アンダーレイ BGP ルートが提供されるため、Orchestrator パケットがドロップされます。

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

• 問題 62275：VMware SD-WAN Gateway で診断バンドルを生成すると、メモリ使用量の急増が発生し、Gateway が再起動して、診断バンドルが失敗する可能性があります。

  診断バンドルが大量のリンクを持つ Gateway で取得されると、debug.py デバッグ コマンドはすべてのデータを保持するために大量のメモリを使用し、適切なフォーマット後に Edge プロセスに戻します。  この問題が発生している間に他のメモリ処理の問題が発生した場合は、メモリの急増によって Gateway のメモリが枯渇し、メモリをクリアするための再起動が発生する可能性があります。

• 問題 62552：サイトでは、断続的に高いパケット ロスと接続の問題が発生することがあります。

  これは、ARP 解決をチェックする API が、00:00:00:00 の MAC アドレスを配信しているときにデバイスの ARP 解決が成功したことを Edge に通知することが原因です。  このアドレスは ARP キャッシュに保持され、MAC がゼロとしてリストされているデバイス宛てのパケットはすべてドロップされます。  この状況では、このような MAC アドレスがゼロの正常な ARP の多くのインスタンスが配信され、高いパケット ロスと接続の問題が発生します。

  注：問題 60130 とこの問題はどちらも根本的な動作と原因は同じですが、各チケットで想定される修正は異なります。60130 が防御的な回避策による修正である一方、62552 はこの問題が繰り返されることを防ぐ完全な修正になります。

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

• 問題 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 を有効にすることです。

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

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

  回避策：Edge サービスを再起動すると、フル トンネル接続がリストアされます。

• 問題 69324：高可用性トポロジを使用して展開されたカスタマー サイトの場合、サイトで HA が有効になっていると、両方の VMware SD-WAN Edge がアクティブと表示されます。 

  アクティブとスタンバイが実際に割り当てられたロールを実行しているため、これは実際のスプリット ブレイン シナリオではありません。これは、VMware SD-WAN Orchestrator に表示される誤った状態を報告しているだけです。  HA verp コマンドでアクティブとスタンバイの状態が適切に表示されている場合でも、アクティブ Edge とスタンバイ Edge の両方のプロンプトがアクティブと表示されます。

  回避策：この問題を解決するには、スタンバイ Edge を再開または再起動する必要があります。

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

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

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

• 問題 83212：VMware SASE Orchestrator で [監視 (Monitor)] > [Edge] > [トランスポート (Transport)] を確認すると、[リンク (Link)] 統計情報テーブルと [アプリケーション (Application)] 統計情報テーブルとの間に不一致があります。

  [アプリケーション (Application)] 統計情報と [リンク (Link)] 統計情報は一致している必要がありますが、[アプリケーション (Application)] 統計情報は [リンク (Link)] 統計情報よりも高い値を示しています。この問題は、最も一般的には、スポーク Edge が単一の WAN リンクを使用する VMware SD-WAN Edge のハブ クラスタ トポロジで発生します。この単一の WAN リンクで何らかの損失が発生すると、パケットが再送信され、[アプリケーション (Application)] 統計情報で 2 回集計されるため、不一致が発生します。

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

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

  ロード イベントとシステム イベントによってトリガされた条件により、アクティブ Edge では、スタンバイ Edge への HA ハートビートのタイムリーな配信に遅延が発生します。遅延により、スタンバイ Edge がハートビートを失い、誤ってアクティブ ロールを引き受け、アクティブ/アクティブ状態が発生します。アクティブ/アクティブ状態からリカバリするために、スタンバイ Edge が再起動します（場合によっては複数回）。 

  サイトがアクティブ/アクティブになると、従来の HA 設定では、スタンバイ Edge はこのトポロジでトラフィックを渡さないため、トラフィックの中断が最小限に抑えられますが、スタンバイ Edge もトラフィックを渡す拡張 HA 展開では、再起動によって一部のカスタマー トラフィックが中断されます。

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

• 問題 85461：VMware SD-WAN Edge を使用して DNS を転送し、Edge に接続されている LAN デバイスが DNS 転送に Edge を使用している場合、すべての DNS トラフィックが失敗することがあります。

  条件付き DNS だけでなく、すべての DNS 転送トラフィックが影響を受けます。Edge ソフトウェアによっては、次のように Edge でこの問題が発生する可能性があります。

  • Edge がリリース 4.2.2 を使用し、Gateway IP アドレスが指定されていないルーティングされた LAN ポートを使用している場合、Edge でこの問題が発生する可能性があります。スイッチ LAN ポートと VLAN の使用は、4.2.2 では影響を受けません。 
  • Edge がリリース 4.3.0/4.3.1、4.5.0/4.5.1、または 5.0.0.x のいずれかを使用し、スイッチ LAN ポートと VLAN を使用しているか、Gateway IP アドレスが指定されていないルーティングされた LAN ポートを使用している場合、Edge でこの問題が発生する可能性があります。

  スイッチ インターフェイスの場合、この問題の原因は、リリース 4.3.0、4.5.0、および 5.0.0.x 以降ではループバック インターフェイスが優先されるため、管理 IP インターフェイスが廃止および削除されたことにあります。DNS はセグメント NAT を使用するため、Edge がセグメント NAT テーブルのルックアップを実行し、パケットをドロップすると、DNS パケットは宛先 IP アドレスと一致するエントリを持たなくなります。

  ルーテッド インターフェイスの場合、Gateway IP アドレスがないと、DNS パケットはネクスト ホップとして Edge にルーティングされ、Edge は DNS パケットをそれ以上転送しません。

  回避策：この問題の回避策は、Edge を使用して DNS を転送しないようにするか、次のようにすることです。

  • Edge リリース 4.2.2 を使用している場合：スイッチ LAN ポート、または Gateway IP アドレスを含むルーティングされた LAN ポートのいずれかを使用します。
  • リリース 4.3.x、4.5.x または 5.0.0.x を使用している場合は、Gateway IP アドレスが指定されたルーティングされた LAN ポートのみを使用します。 
• 問題 86098：スタンバイ Edge で PPPoE WAN リンクが使用されている拡張高可用性トポロジを使用しているサイトでは、デフォルトのプロキシ ルートがアクティブ Edge にインストールされておらず、そのリンクを使用するトラフィックが失敗することがあります。

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

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

• 問題 88604：高可用性トポロジを使用しているサイトで、WAN インターフェイスが停止し、スタンバイの VMware SD-WAN Edge に戻った場合に、そのイベントが VMware SASE Orchestrator に記録されません。

  ユーザーに対して、スタンバイ Edge インターフェイス イベントは表示されません。これは特に、スタンバイ Edge もトラフィックを渡している拡張 HA 展開に影響します。

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

• 問題 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 名の横にあるドロップダウン情報ボックスをクリックします。ただし、これはリリース 4.5.1 を使用している Edge でのみ機能します。

  この問題は、6x0 Edge を PIC バージョン v20N を含むプラットフォーム ファームウェア 1.3.1 (R131-20221216-GA) にアップグレードすることで解決されます。これを行うには、6x0 Edge をリリース 5.x（5.0.0 以降）を使用する VMware SASE Orchestrator に接続し、6x0 Edge を最初に Edge ホットフィックス ビルド R5012-20230123-GA-103475 にアップグレードする必要があります。6x0 Edge を R5012-20230123-GA-103475 にアップグレードしたら、次に、Edge のソフトウェア バージョンが変更されるのと同じ方法で、6x0 Edge プラットフォーム ファームウェアをバージョン R131-20221216-GA に更新します。

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

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

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

  回避策：問題の状態から Edge をリカバリするには、次の手順を実行します。

  1. Edge を電源から切断します。
  2. 20 秒間待機します。
  3. Edge を電源に再接続します。

  6x0 Edge のプラットフォーム ファームウェアをアップグレードしない場合、ユーザーは Edge への電力の一貫性を確保し、急速にまたは一貫してフラップが発生しないようにすることができます。信頼性の高い電源を確保する良い方法は、6x0 Edge を無停電電源装置 (UPS) に接続することです。

  ユーザーが Edge を下位のソフトウェア リリース（たとえば、リリース 4.3.1 または 4.5.1）に保持することを希望する場合、カスタマーは一時的に Edge を R5012-20230123-GA-103475 にアップグレードし、バージョン 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 バージョンを手動で更新してもらうことができます。

• 問題 91365：Edge Network Intelligence を使用しているカスタマーの場合は、分析が設定されている VMware SD-WAN Edge でメモリ リークが発生し、Edge が Edge サービスの再起動をトリガしてメモリをクリアします。

  Edge で分析機能が有効になっている場合、Edge のデータプレーン サービスが着実な速さでメモリ リークを開始するため、Edge は重大レベル（90 秒以上にわたりメモリ使用率が 60%）に到達したときに予定外のサービス再起動をトリガして、メモリ リークをクリアする必要があります。Edge サービスを再起動すると、カスタマー トラフィックが 10 秒から 15 秒程度中断します。フィールドでは、Edge サービスの再起動をトリガするのにかかる時間は約 3 ～ 4 日ですが、メモリがクリアされると、一般的な同じ時間枠でメモリ リークが再開し、最終的に Edge サービスの次回の再起動をトリガします。Edge がメモリ使用量について重大レベルに到達する期間は、Edge モデルとその Edge の分析機能が記録している情報の量によって異なります。

  回避策：カスタマーには次の 2 つの選択肢があります。a) 修正された Edge ビルドが提供されるまで、Edge の分析を一時的にオフにする。b) Edge のメモリを監視する。メモリ使用率が 40% に到達し、Orchestrator がメモリ警告イベントを記録した場合は、メンテナンス ウィンドウで手動による Edge サービスの再起動をスケジュール設定して、メモリをクリアし、カスタマーへの影響を最小限に抑えるようにします。

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

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

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

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

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

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

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

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

  回避策：Edge でこの問題が発生している場合は、VMware のサポートにお問い合わせいただくか、Edge をリリース 4.5.1（ビルド R451-20220916-GA 以降）にアップグレードします。

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

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

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

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

Orchestrator の既知の問題

• 問題 19566：

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

• 問題 21342：

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

• 問題 24269：

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

• 問題 25932：

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

• 問題 32335：

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

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

• 問題 32435：

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

• 問題 32856：

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

• 問題 32913：

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

• 問題 33026：

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

• 問題 34828：

  リリース 2.x を使用する VMware SD-WAN スポーク Edge と、リリース 3.3.1 を使用するハブ Edge の間で、トラフィックを送受信できません。

• 問題 35658：

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

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

• 問題 35667：

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

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

• 問題 36665：

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

• 問題 38056：

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

• 問題 38843：

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

• 問題 39633：

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

• 問題 39790：

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

• 問題 40341：

  Skype アプリケーションがリアルタイム トラフィックとしてバックエンドで適切に分類されていても、VMware SD-WAN Orchestrator で Skype ビジネス ポリシーを編集すると、サービス クラスで誤って [トランザクション (Transactional)] と表示されることがあります。

• 問題 41691：

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

• 問題 43276：

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

• 問題 44153：

  VMware SD-WAN Orchestrator が、[アラートと通知 (Alerts and Notifications)] セクションで設定されたメール アドレスに、アラートの E メールを継続して送信しません。

• 問題 46254：

  VMware SD-WAN Edge のアクティベーション中に、VMware SD-WAN Orchestrator が、WAN リンクの MTU が変更されたことや、DHCP が設定されたインターフェイスに VLAN ID が存在することを検出しません。

• 問題 47269：

  LTE インターフェイスがサポートされていない Edge モデルに、VMware SD-WAN 510-LTE インターフェイスが表示されることがあります。

• 問題 47713：

  クラウド VPN が無効な間にビジネス ポリシー ルールが設定された場合、クラウド VPN を有効にするときに NAT を再設定する必要があります。

• 問題 47820：

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

• 問題 48085：

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

• 問題 48737：

  リリース 4.0.0 の新しいユーザー インターフェイスを使用している VMware SD-WAN Orchestrator で、ユーザーが [監視 (Monitor)] ページを表示して開始時刻と終了時刻の間隔を変更してから、タブ間を移動すると、Orchestrator で開始時刻と終了時刻の間隔が新しい値に更新されません。

• 問題 49225：

  VMware SD-WAN Orchestrator で、合計 32 個の VLAN の制限が適用されません。

• 問題 49790：

  VMware SD-WAN Edge のリリース 4.0.0 をアクティベーションするときに、[イベント (Events)] にアクティベーションが 2 回投稿されます。

  回避策：重複イベントは無視してください。

• 問題 50531：

  異なる権限を持つ 2 人のオペレータが、VMware SD-WAN Orchestrator の 4.0.0 リリース バージョンの新しいユーザー インターフェイスにアクセスする際に同じブラウザ ウィンドウを使用する場合、権限の低いオペレータが権限の高いオペレータの後にログインしようとすると、権限の低いオペレータに「ユーザーが権限を持っていない」ことを示すエラーが複数回表示されます。

  注：権限が低いオペレーターの権限の昇格はなく、エラー メッセージの表示のみが行われます。

  回避策：エラーが表示されないようにするために、次のオペレータがログインの前にそのページを更新するか、それぞれのオペレータが別のブラウザ ウィンドウを使用して、この表示の問題を回避できます。

• 問題 51722：リリース 4.0.0 の VMware SD-WAN Orchestrator では、[監視 (Monitor)] > [Edge (Edge)] タブの統計情報の時間範囲セレクタは 2 週間以内です。

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

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

• 問題 60039：VMware SD-WAN Edge モデルの変更時に RMA の再アクティベーションが機能しません。

  Edge モデルも変更されているサイトで RMA の再アクティベーションを実行すると、VMware SD-WAN Orchestrator はモデルの変更を保存しないため、再アクティベーション リンクが無効になります。この問題は、Edge モデルが変更された RMA の再アクティベーションにのみ影響し、Edge モデルが同じままの RMA の再アクティベーションは、想定どおりに機能します。

  回避策：サイトで別の Edge モデルを使用する場合、ユーザーは新しい Edge を作成して、すべての Edge 固有の設定を手動で適用する必要があります。