VMware SD-WAN バージョン 4.3.1 | 2023 年 2 月 17 日

  • VMware SD-WAN™ Orchestrator バージョン R431-20220715-GA

  • VMware SD-WAN™ Gateway バージョン R431-20220608-GA

  • VMware SD-WAN™ Edge バージョン R431-20220608-GA

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

リリース ノートの概要

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

対象ユーザー

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

互換性

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

注：

3.2.0 より前のリリースはサポートされません。

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

Orchestrator

Gateway

Edge

ハブ

ブランチ/スポーク

4.3.1

3.4.6

3.4.6

3.4.6

4.3.1

4.3.1

3.4.6

3.4.6

4.3.1

4.3.1

4.3.1

3.4.6

4.3.1

4.3.1

3.4.6

4.3.1

4.3.1

4.2.2

4.2.2

4.2.2

4.3.1

4.3.1

4.2.2

4.2.2

4.3.1

4.3.1

4.3.1

4.2.2

4.3.1

4.3.1

4.2.2

4.3.1

4.3.1

4.3.0

4.3.0

4.3.0

4.3.1

4.3.1

4.3.0

4.3.0

4.3.1

4.3.1

4.3.1

4.3.0

4.3.1

4.3.1

4.3.0

4.3.1

4.5.0

4.3.1

4.3.0

4.3.1

4.5.0

4.5.0

4.3.0

4.3.1

4.3.1

4.3.1

3.2.2 

3.2.2 

4.3.1

4.3.1

3.3.2 P2 

3.3.2 P2 
注：

注：リリース 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 を選択できます。

注意：

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

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

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

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

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

重要：

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

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

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

  • リリース 4.2.x の Edge は、2023 年 6 月 30 日にジェネラル サポートの終了 (EOGS) となり、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)

重要な注意事項

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

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

高可用性での 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 プリペンド設定を編集して「カンマをスペースで置き換える」必要があります。

リバース パス フォワーディング (RPF) がデフォルトで有効

以前のリリースでは、VMware SD-WAN Edge の LAN インターフェイスから送信元が不明なパケットが許可されていました。この動作は、Edge の LAN インターフェイスのリバース パス フォワーディング (RPF) がデフォルトで有効になっていないために発生しました。リリース 3.4.5 で最初に追加された「解決した問題 52628」の一環として、この動作は、すべての Edge LAN インターフェイスで RPF が有効になるように変更され、パケットが設定済み LAN サブネットから送信されている場合に限り、LAN インターフェイスからのパケットが許可されます。

Zscaler トンネルが IKEv2 を使用するようになりました

Orchestrator および Gateway がリリース 4.3.0 以降にアップグレードされると、Zscaler タイプを使用するすべての Gateway 経由の Non SD-WAN Destination では、トンネルが IKEv2 に変更され、IKEv1 は使用されなくなります。

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

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

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

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

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

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

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

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

ドキュメントの改訂履歴

2021 年 12 月 15 日。第 1 版

2021 年 12 月 21 日。第 2 版。

  • 「Orchestrator で解決した問題」に新しい Orchestrator ビルド R431-20211217-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 月 7 日。第 3 版。

  • 「Edge で解決した問題」セクションに新しい Edge ビルド R431-20211221-GA を追加しました。このビルドはリリース 4.3.1 の新しい Edge GA ビルドです。 

  • この Edge ビルドについては、解決した問題 #70933 および #76564 を追加し、それぞれ該当するセクションで説明しています。

2022 年 2 月 17 日。第 4 版。

  • 「Edge で解決した問題」セクションに新しい Edge ビルド R431-20220118-GA を追加しました。このビルドはリリース 4.3.1 の新しい Edge GA ビルドです。 

  • この Edge ビルドについては、解決した問題 #64343 および #74149 を追加し、それぞれ該当するセクションで説明しています。

  • 元の GA ビルドの「Edge/Gateway で解決した問題」セクションに解決した問題 #72718 を追加しました。この問題は、元のビルドで解決されましたが、内部チケットのラベル付けエラーが原因で元のリリース ノートから除外されました。

2022 年 2 月 25 日。第 5 版。

  • 「Orchestrator で解決した問題」セクションに新しい Orchestrator GA ビルド R431-20220222-GA を追加しました。

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

  • この Orchestrator ビルドについては、解決した問題 #76036、#80613 および #81498 を追加し、該当するセクションで説明しています。

2022 年 3 月 3 日。第 6 版。

  • 「Edge で解決した問題」セクションに新しい Edge ビルド R431-20220302-GA を追加しました。このビルドはリリース 4.3.1 の新しい Edge GA ビルドです。 

  • この Edge ビルドには、解決した問題 #53951、#55327、#80010、#80551、#80654、#82463 および #82652 が含まれ、該当するセクションで説明しています。

  • 次の 2 つの未解決の問題が追加されました。#72925 および #83747。「Edge/Gateway の既知の問題」セクションに記載されています。

  • 重要な注意事項を追加しました。高可用性での Wi-Fi 対応 Edge と Wi-Fi 非対応 Edge の混在はサポートされません。 

2022 年 3 月 4 日。第 7 版。

  • 未解決の問題 #83747 は、「Edge/Gateway の既知の問題」から削除されました。この問題の症状とカスタマーへの影響について誤解があったため、このチケットは Edge リリース R431-20220302-GA の第 6 版に誤って含まれていましたが、いずれもリリース ノートに含める必要はありませんでした。 

2022 年 3 月 23 日。第 8 版。

  • 「Edge で解決した問題」セクションに新しい Edge ビルド R431-20220316-GA を追加しました。このビルドはリリース 4.3.1 の新しい Edge GA ビルドです。 

  • Edge ビルド R431-20220316-GA については、解決した問題 #61797、#70586、#77525、および #77625 を追加し、それぞれ該当するセクションで説明しています。

  • 「互換性」セクションに、Orchestrator および Gateway のリリース 3.4.x ソフトウェアが 2022 年 3 月 30 日にジェネラル サポートの終了 (EOGS) となり、2022 年 6 月 30 日にテクニカル ガイダンスの終了 (EOTG) を迎えるという新しい警告を追加しました。これは、Orchestrator および Gateway のみが対象です。3.4.x Edge ソフトウェアは、2022 年 12 月 31 日からサポート終了への移行期間に入ります。

  • 「Edge および Gateway 上の BGP over IPsec、および Azure Virtual WAN の自動化の制限事項」に関する新しい「重要な注意事項」を追加しました。注意事項には次のように記載されています。「Edge および Gateway 上の BGP over IPsec 機能は、Edge または Gateway からの Azure Virtual WAN の自動化と互換性がありません。Edge または Gateway から Azure vWAN への接続を自動化するときには、スタティック ルートのみがサポートされます。」

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

2022 年 3 月 29 日。第 9 版。

  • このエディションでは、高可用性トポロジで展開されたサイトでアクティブ/アクティブ状態が発生し、その結果、複数のフェイルオーバーやスタンバイ Edge の再起動が発生する症状に関連するいくつかのチケットが修正または追加されます。修正と追加は次のとおりです。

    • Edge の解決した問題 #77625 を修正し、以前は「HA スレッドの枯渇」と表示されていた根本原因が「HA スレッドの優先度の反転」としてリストされるようになりました。

    • 以前は #77625（HA スレッドの枯渇）に関連付けられていた根本原因は、「HA Edge スレッドのサスペンド」に修正され、新しい問題 #85369 に割り当てられています。この問題は、「Edge/Gateway の既知の問題」セクションに追加され、現在このエディションで調査中です。

    • 解決した問題 #67201 を修正し、症状と解決された内容についてのより正確な説明を提供するようになりました。 

    • 解決した問題 #80654 を修正し、R431-20220302-GA ロールアップ ビルド以降に含まれるこの修正が、元の GA ビルド R431-20211208-GA での #67201 の修正によって導入されたリグレッションの問題を修正するものであることを説明する注意事項を追加しました。

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

2022 年 3 月 31 日。第 10 版。

  • 「Edge/Gateway で解決した問題」セクションに新しい Edge ビルド R431-20220331-GA を追加しました。このビルドはリリース 4.3.1 の新しい Edge および Gateway GA ビルドです。 

  • Edge ビルド R431-20220331-GA には、解決した問題 #65695、#68923、#78003、#80897、#81517、#81575、#81920、#82314 が含まれ、該当するセクションで説明しています。

  • 解決した Edge/Gateway の問題は、次のように分類されます。

    • Edge と Gateway の修正：#80897

    • Edge のみの修正：#65695、#68923、#78003、#81517。

    • Gateway のみの修正：#81575、#81920、#82314。

2022 年 4 月 14 日。第 11 版。

  • 「Edge/Gateway で解決した問題」セクションに新しい Edge ビルド R431-20220407-GA を追加しました。このビルドはリリース 4.3.1 の新しい Edge GA ビルドです。 

  • Edge ビルド R431-20220407-GA には、解決した問題 #58791、#65466、#83029、#83928、#83402、#86103 が含まれ、該当するセクションで説明しています。

  • 「Edge/Gateway の既知の問題」セクションに未解決の問題 #62701 を追加しました。現時点では、この問題はすべてのリリースで未解決のままであるためです。

2022 年 4 月 19 日。第 12 版。

  • 追加の解決した問題 #84847 を Edge ビルド R431-20220407-GA に追加しました。この修正のコードは検証済みの R431-20220407-GA ビルドに含まれていましたが、エンジニアリング部門で #84847 の修正を具体的に検証しなかったため、このチケットは 4 月 14 日に公開されたリリース ノートから除外されました。R431-20220407-GA の #84847 の修正はその後エンジニアリング部門によって検証されたため、このリリース ノートの時点で解決済みとして記載されています。

2022 年 5 月 6 日。第 13 版。

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

  • Orchestrator ロールアップ ビルド R431-20220429-GA については、解決した問題 #84152 および #84969 を追加し、該当するセクションで説明しています。

  • リリース 4.0.x がサポート終了に近づいていることを知らせる新しい警告を「互換性」セクションに追加しました。

2022 年 5 月 12 日。第 14 版。

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

  • Edge ビルド R431-20220509-GA には、問題 #81809、#83209、#84136、および #85459 の修正が含まれ、それぞれ該当するセクションで説明しています。

  • Gateway ビルド R431-20220509-GA には、問題 #65466 および #74316 の修正が含まれています。問題 #65466 は Edge または Gateway のいずれかに影響する可能性があり、Edge の修正は 6 番目のロールアップ ビルド：R431-20220407-GA に含まれていました。ただし、その時点では Gateway の修正は使用できませんでした。

2022 年 5 月 18 日。第 15 版

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

  • Edge/Gateway ビルド R431-20220510-GA には、問題 #64627 および #78568 の修正が含まれ、それぞれ該当するセクションで説明しています。

2022 年 5 月 26 日。第 16 版

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

  • Edge/Gateway ビルド R431-20220518-GA には、問題 #75772 および #88796 の修正が含まれ、それぞれ該当するセクションで説明しています。

  • Orchestrator の新しい既知の問題として問題 #88796 を追加しました。最新の Gateway ビルドに修正が含まれているため、このチケットは、Orchestrator OVA にのみ適用される問題を追跡します。

  • 「Edge/Gateway の既知の問題」セクションに問題 #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」を改訂し、現場でこの問題に遭遇したカスタマーに影響を与える可能性のある別のシナリオを追加しました。

  • 「Orchestrator で解決した問題」セクションの問題 #76016 を移動し、「Orchestrator の既知の問題」セクションに配置しました。このチケットは誤って「修正済み」としてリストされていましたが、この版の 4.3.1 リリース ノートには含まれていません。

2022 年 6 月 27 日。第 18 版

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

  • Edge/Gateway ビルド R431-20220608-GA には、問題 #78678、#83083、および #85369 の修正が含まれ、それぞれ該当するセクションで説明しています。

2022 年 7 月 6 日。第 19 版

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

  • Edge ロールアップ ビルド R431-20220118-GA の「解決した問題」セクションから、問題 #74149 を「Edge/Gateway の既知の問題」セクションに移動しました。この問題は誤って「修正済み」として記載されていましたが、4.3.1 Edge ビルドにはこの問題に対する修正が含まれていないため、リリース 4.3.1 では未解決のままとなります。

2022 年 7 月 14 日。第 20 版

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

2022 年 7 月 22 日。第 21 版

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

  • Orchestrator ロールアップ ビルド R431-20220715-GA については、解決した問題 #76016 および #88796 を追加し、該当するセクションで説明しています。

2022 年 8 月 26 日。第 22 版。

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

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

2022 年 9 月 9 日。第 23 版。

  • 「Edge/Gateway の既知の問題」セクションに未解決の問題 #72245、#81224、#87552、#89873、および #93383 を追加しました。

2022 年 9 月 14 日。第 24 版。

  • 問題 #61797「ルートのバックトラッキングが VMware SD-WAN Edge でサポートされていないため、誤った到達可能性ルートが発生する」を Edge ビルド R431-20220316-GA の「Edge/Gateway で解決した問題」セクションから削除しました。この問題は誤って含まれていました。これは機能強化であるため、「既知の問題」に移動させるのではなく、リリース ノートから完全に削除されました。

2022 年 9 月 28 日。第 25 版。

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

2022 年 11 月 7 日。第 26 版。

  • 新しい公開ツールを使用して、これらのメモを改訂および再公開しました。

2022 年 11 月 22 日第 27 版。

2023 年 1 月 30 日第 28 版。

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

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

2023 年 2 月 17 日。第 29 版。

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

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

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

Edge/Gateway バージョン R431-20220608-GA は 2022 年 6 月 27 日にリリースされ、リリース 4.3.1 の 10 番目の Edge/Gateway ロールアップです。

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

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

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

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

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

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

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

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

    スタンバイ Edge が大量のフロー同期メッセージを処理している場合、SD-WAN サービスがバッファ オーバーフロー状態を検出し、スタンバイ Edge の再起動をトリガすることがあります。影響については、従来の HA 設定では、スタンバイ Edge はこのトポロジでトラフィックを渡さないため、トラフィックの中断が最小限に抑えられますが、スタンバイ Edge もトラフィックを渡す拡張 HA 展開では、再起動によって一部のカスタマー トラフィックが中断されます。

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

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

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

  • 解決した問題 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 で追跡されますが、ビルド R431-20220715-GA の「Orchestrator で解決した問題」セクションに配置されています。

  • 解決した問題 75772：VMware SD-WAN Edge で分析がアクティブになっている Edge Network Intelligence を使用しているカスタマーの場合、Edge でメモリ リークが発生し、Edge がサービスを再起動してメモリ リークをクリアすることがあります。

    分析が有効で、Edge インターフェイスで DHCP が有効になっている場合、クライアント接続イベントによってメモリ使用量が増加します。十分な期間にわたって、メモリ使用率が重大なしきい値に達し、Edge が防御的に通常のメモリ レベルに戻すために Edge サービスを再起動する場合があります。他のメモリ リークの問題と同様に、初期メモリ占有量が小さいほど（Edge 510、520、610 など）、Edge が再起動を実行する可能性が高くなります。

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

Edge/Gateway バージョン R431-20220510-GA は 2022 年 5 月 17 日にリリースされ、リリース 4.3.1 の 8 番目の Edge/Gateway ロールアップです。

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

  • 解決した問題 78568：カスタマーが BGP を使用していて、VMware SD-WAN Partner Gateway に接続している場合、Partner Gateway は、そのサブネットの広報フラグが False に設定された後も、VMware SD-WAN Edge の VLAN サブネットを広報し続けることがあります。

    Edge が L3 BGP ネイバーとの BGP ネイバー隣接状態を解除すると、接続された Partner Gateway の 1 つが Edge VLAN サブネットの所有権を維持するため、ルートは引き続き広報されます。Partner Gateway 上の古いルートはカスタマー トラフィックに悪影響を及ぼし、存在しなくなっているルートにトラフィックがルーティングされるため、カスタマー フロー全体がドロップされる可能性があります。

    この修正を適用せずに問題を修正し、古い BGP ルートをクリアする唯一の方法は、パートナーまたはオペレータが適切なメンテナンス時間帯に Partner Gateway サービスを再起動することです。

  • 解決した問題 64627：VMware SD-WAN Gateway でデータプレーン サービスの再起動が発生し、トラフィックが一時的に中断することがあります。

    VMware SD-WAN Edge の WAN リンクに多数のサブパスが設定されている場合、または接続された Gateway との Edge の管理トンネルのフラップが頻繁に発生する場合、Gateway のメモリ カウンタが枯渇し、Gateway がリカバリするために再起動されることがあります。

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

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

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

Gateway ロールアップ ビルドは、問題 #65466 にも対応しています。この問題は、以前の 6 番目の Edge ロールアップ ビルドにも含まれていましたが、その時点では Gateway の修正が利用できなかったため、ここで利用できるようになりました。

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

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

  • 解決した問題 84136：VMware SD-WAN Edge をリリース 4.3.1 にアップグレードすると、CPU 使用率が高くなり、トラフィックのパフォーマンスが低下することがあります。

    この問題は、[設定 (Configure)] > [ファイアウォール (Firewall)] > [Edge アクセス (Edge Access)] セクション（サポート アクセスまたは SNMP アクセスが許可された IP アドレス）で 400 を超える IP ルールが設定されている Edge で発生します。このシナリオで Edge がファイアウォール設定を送信しようとすると、管理プロセスが CPU を最大限まで使い果たし、タイムアウトになり、このプロセスが繰り返されます。

    高可用性トポロジも使用しているカスタマー サイトでは、アクティブ Edge が想定される時間枠内にハートビートを送信していないため、症状には「HA 不明イベント (HA unknown events)」が含まれます。

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

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

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

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

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

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

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

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

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

Edge バージョン R431-20220407-GA は 2022 年 4 月 13 日にリリースされた、リリース 4.3.1 の 6 番目の Edge ロールアップです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    注：

    注：65466 に対する Gateway 修正は、7 番目の Gateway ロールアップ ビルド R431-20220509-GA 以降に含まれています。6 番目のロールアップがリリースされた時点では、Gateway の修正は利用できませんでした。

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

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

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

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

    注：

    注：このチケットの以前のバージョンの説明では、これは BGP の match および set 操作を含む HA サイトの修正でもあると記載されていました。問題のこの部分はこのチケットでは修正されず、問題 #84825 で追跡されます。

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

Edge および Gateway バージョン R431-20220331-GA は 2022 年 3 月 31 日にリリースされ、Edge バージョン 431-20220316-GA および Gateway バージョン R431-20211208-GA 以降の以下の重大な問題に対処します。

  • 解決した問題 82314：VMware SD-WAN Gateway をアップグレードすると、Intel x710 PCIe パススルー ベースの NIC を使用するときに接続が失われ、例外が発生することがあります。

    Gateway がアップグレードされると、アップグレードの一部としてカーネルが変更され、i40e ドライバのインストールが失敗し、Gateway で使用できなくなります。i40e ドライバが使用できないため、すべての x710 PCIe パススルー ベースの NIC が Gateway で適切に動作せず、パフォーマンスが低下するか、接続が失われます。この問題は、Virtio または VMNet ベースの NIC を使用する Gateway には影響しません。

  • 解決した問題 81920：Intel x710 SR-IOV ベースの NIC を使用する KVM ベースの仮想マシンを使用して展開された VMware SD-WAN Gateway で、Gateway ソフトウェアのアップグレード後に接続の問題が発生することがあります。

    この問題は、Gateway のアップグレードで Linux 仮想機能ドライバ iavf が正しくインストールされないために発生し、その結果、アップグレードされた Gateway で x710 SR-IOV ベースの NIC が機能しません。この問題は、Virtio または VMNet ベースの NIC を使用する Gateway には影響しません。

  • 解決した問題 81575：Intel x710 SR-IOV ベースの NIC を使用する VMware OVA ベースの仮想マシンを使用して展開された VMware SD-WAN Gateway で、Gateway ソフトウェアのアップグレード後に接続の問題が発生することがあります。

    この問題は、Gateway のアップグレードで Linux 仮想機能ドライバ iavf が正しくインストールされないために発生し、その結果、アップグレードされた Gateway で x710 SR-IOV ベースの NIC が機能しません。この問題は、Virtio または VMNet ベースの NIC を使用する Gateway には影響しません。

  • 解決した問題 81517：拡張高可用性トポロジで展開された、VMware SD-WAN Edge モデル 6x0 を使用するサイトで、HA リンクの状態が適切に更新されません。

    HA リンクは拡張 HA Edge ペアを接続するリンクです。このリンクが適切に更新されない場合、スタンバイ Edge もカスタマー トラフィックを渡すため、サイトでカスタマー トラフィックに問題が発生する可能性があります。

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

    パフォーマンスの低下は、安全な優先スタティック ルートが使用可能な Edge に Partner Gateway がルートを配布するが、その Edge がこれらのルートを安全として適切にラベル付けしないことによるルーティングの問題が原因で発生します。その結果、すべてのルートが同等に扱われるため、Edge は安全なルートではなく非優先で非安全なルートを広報する可能性があります。予期される動作は、常に非安全なルートより安全なルートを優先することです。

    注：

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

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

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

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

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

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

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

Edge バージョン R431-20220316-GA で解決した問題

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

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

    HA スレッドの優先度が反転したため、サイトがアクティブ/アクティブ（スプリット ブレイン）状態になり、優先度の低いスレッドが優先され、優先度の高いスレッドが実行されなくなり、その結果ハートビート処理が遅延し、スタンバイ Edge が誤ってアクティブに昇格します。アクティブ/アクティブ状態では、アクティブ Edge が実行され、スタンバイ Edge は再起動されて、適切なスタンバイ状態に降格されます。ただし、この場合、アクティブ/アクティブ イベントが複数回検出され、そのたびにサイトをリカバリするたびにスタンバイ Edge が再起動します。この問題が従来の HA トポロジで発生した場合、スタンバイ Edge はカスタマー トラフィックを渡さないため、カスタマーへの影響は最小限に抑えられます。拡張 HA 展開では、スタンバイ Edge もトラフィックを渡すため、再起動によって一部のカスタマー トラフィックが中断されます。 

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

  • 解決した問題 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 フェイルオーバーをトリガして問題をクリアする必要があります。

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

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

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

Edge バージョン R431-20220302-GA で解決した問題

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

  • 解決した問題 80551：内部 LTE モデムを含む VMware SD-WAN Edge モデル（Edge 510-LTE および Edge 610-LTE）では、CELL インターフェイスの IPv6 アドレスが変更されると、IPv6 リンク経由の LTE トンネルが不安定になります。

    CELL インターフェイスの IPv6 アドレスが変更されるたびに（DHCP リースの期限切れなどが原因）、IPv6 トンネルが不安定になります。これは、トンネルが新しい IPv6 アドレスではなく古い IPv6 アドレスを引き続き使用するためです。

    この修正を行わない場合、問題を修正する唯一の方法は、Edge のサービスを再起動することです。

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

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

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

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

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

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

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

  • 解決した問題 80654：拡張された高可用性トポロジで設定されたサイトの場合、VMware SD-WAN スタンバイ Edge の WAN リンクにおいてトラフィックの断続的なドロップが発生することがあります。

    パス フラップ（頻繁なパスの追加と削除）が発生すると、特定のタイミング シナリオでアクティブ Edge とスタンバイ Edge 間の TCP 接続がリセットされ、スタンバイ Edge の WAN リンクを通過するトラフィックのパケット ドロップが発生します。

    注：

    注：この問題の修正により、元の GA ビルド R431-20211208-GA での #67201 の修正によって導入されたリグレッションが解決されます。

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

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

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

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

  • 解決した問題 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 へのルートをリカバリすることです。

Edge バージョン R431-20220118-GA で解決した問題

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

  • 解決した問題 64343：ピアから学習した BGP ルートは、対応する BGP ネイバーにアップリンク ルートが設定されていても、アップリンク ルートとしてタグ付けされません。

    他の VMware SD-WAN Edge および Gateway に広報されるリモート ルートでは、それぞれの BGP ルートにアップリンク フラグが設定されません。学習した新しい BGP ルートまたは BGP ルートが BGP ネイバーから更新され、オーバーレイ ネットワークに広報されます。

    注：

    注：この問題を修正するには、#77101 の修正を含む VMware SD-WAN Orchestrator ビルドが必要です。この修正は、2022 年 2 月 17 日リリースの更新された 4.5.0 Orchestrator ビルド R450-20220215-GA に含まれています。

Edge バージョン R431-20211221-GA で解決した問題

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

  • 解決した問題 76564：高可用性トポロジで設定されたサイトで、VMware SD-WAN Edge の WAN インターフェイスが VMware SD-WAN Orchestrator ユーザー インターフェイスを使用して有効または無効になっている場合、サイトで「スプリット ブレイン」のアクティブ/アクティブ状態が発生し、カスタマーのトラフィックを中断させる場合があります。

    Edge の WAN 設定が変更されると、Edge のネットワーク サービスが再起動され、一時的な HA パケット ロスが発生します。これにより、Orchestrator はアクティブ Edge がダウンしたと考え、スタンバイ Edge をアクティブに昇格させ、アクティブ/アクティブの「スプリット ブレイン」状態が発生します。

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

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

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

Edge バージョン R430-20211007-GA-61583-69704-59629-72423 および Gateway バージョン R430-20211020-GA-VCG 以降で解決した問題は次のとおりです。

  • 解決した問題 21293：拡張高可用性トポロジを使用しているサイトについては、[リモート診断 (Remote Diagnostic)] セクションにおいて、VMware SD-WAN スタンバイ Edge に存在するインターフェイス（拡張 HA モードで使用されるインターフェイス）に関する適切な情報が表示されません。

    インターフェイス固有の情報やアクション（インターフェイスの状態や ARP キャッシュのクリアなど）を含んでいる特定の [リモート診断 (Remote Diagnostic)] セクションに、拡張 HA モードで使用されるスタンバイのインターフェイスに関する情報が表示されません。

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

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

  • 解決した問題 44256：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 がそのプロファイルの無効なルートにトラフィックを送信しようとしているため、トラフィックが正しくルーティングされないことです。

  • 解決した問題 49787：VMware SD-WAN Orchestrator ユーザー インターフェイスで VMware SD-WAN Edge の [リモート診断 (Remote Diagnostics)] ページに移動すると、ユーザー インターフェイスで要求が処理されても、Edge の診断ページがロードされません。

    この問題は、証明書が無効になっている Edge で発生する可能性があり、Edge が証明書を繰り返し更新するために VMware SD-WAN Edge の接続が継続的にリセットされることが原因です。

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

    ルーテッド インターフェイスに VLAN タグが割り当てられていて、ネクスト ホップがタグなし ARP 要求を送信する場合、タグなし MAC が学習され、最初に学習されるエントリによってはトラフィックがブラックホールになる可能性があります。この修正を適用しない場合の唯一の回避策は、ルーテッド インターフェイスに VLAN タグがある場合に、ネクスト ホップからタグなし ARP 要求を除外することです。

  • 解決した問題 52628：VMware SD-WAN Edge の LAN インターフェイスから送信元が不明なパケットが許可されます。

    これが原因で、LAN サブネットとは異なるサブネットから送信されたパケットが Edge を通過できるようになってしまいます。これは、Edge LAN インターフェイスの逆方向のパス転送 (RPF) が有効になっていないために発生します。この修正により、すべての Edge LAN インターフェイスで RPF が有効になり、パケットが設定済み LAN サブネットから送信されている場合に限り LAN インターフェイスからのパケットが許可されます。

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

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

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

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

  • 解決した問題 54157：ユーザーは、Gateway から BGP over IPsec を介して広報された、データセンター サーバからレガシー クライアントへのトラフィックについて、VMware SD-WAN Gateway でトラフィックのドロップを確認する場合があります。

    リリース 4.4.x 以前では、プロバイダ Edge (PE) にバインドされたレガシー ルートを Gateway 経由の Non SD-WAN Destination (NDS) に、NSD ルートを PE に配布することはできません。リリース 4.5.0 では、PE バインドの宛先と Gateway 経由の NSD 間でデータ パイプラインがサポートされます。これには、PG-BGP と NSD-BGP 間のルート再配布機能も含まれます。

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

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

  • 解決した問題 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 に設定されます。

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

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

  • 解決した問題 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 はトンネルを再確立します。

  • 解決した問題 58453：一部の Office365 パケットが、VMware SD-WAN Edge によって SSL パケットとして誤って分類されます。

    VMware SD-WAN の詳細なパケット インスペクション (DPI) エンジンは、正しくは Office365 として分類されるべきパケットを誤って SSL として分類することがあります。その結果の影響として、これらのフローが Office365 フローではなく SSL フローとして扱われます。つまり、より低い優先順位で扱われ、ユーザー エクスペリエンスに影響を与える可能性があります。

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

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

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

    アクティブ Edge とスタンバイ Edge の両方で HA ハートビートが失われ、両方の Edge がアクティブ/アクティブ（「スプリット ブレイン」とも呼ばれる）になります。この関連付けを解除するために、新たに昇格したアクティブ Edge（以前のスタンバイ Edge）は、次のイベント ログを記録して再起動します。「アクティブ/アクティブ パニック」。この問題の修正には、HA 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 トンネルが発生しないなどの問題が発生します。

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

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

  • 解決した問題 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 が許可されなくなります。

    root@vc-client1:~# ping 10.0.2.1
PING 10.0.2.1 (10.0.2.1) 56(84) bytes of data.
64 bytes from 10.0.2.1: icmp_seq=1 ttl=62 time=1.37 ms
From 10.0.2.1 icmp_seq=2 Destination Net Unreachable
64 bytes from 10.0.2.1: icmp_seq=83 ttl=62 time=53.6 ms
From 10.0.2.1 icmp_seq=84 Destination Net Unreachable
64 bytes from 10.0.2.1: icmp_seq=173 ttl=62 time=126 ms
From 10.0.2.1 icmp_seq=174 Destination Net Unreachable
--- 10.0.2.1 ping statistics ---194 packets transmitted, 3 received, +3 errors, 98% packet loss, time 193216ms
rtt min/avg/max/mdev = 1.373/60.671/126.962/51.510 ms

     また、SNMP クエリに対する単一の応答も表示されます。

    $ snmpwalk -c public -v 2c 10.100.30.1
iso.3.6.1.2.1.1.1.0 = STRING: "VeloCloud EDGE5X0"
Timeout: No Response from 10.100.30.1

    pkt_tracker には、ドロップと許可されたパケットも表示されます。

    21/03/26 00:22:33.283011,072|7|27428/5|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:5201 <-> 10.0.4.25:44647 proto 6, app 1461, class 7, policy "User Default", reason "tun_send", count 20 path "2 3 5 11 20 47 48 49 54 58 60 65 74 "
 21/03/26 00:22:34.282824,192|7|27416/63|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:5201 <-> 10.0.4.25:44647 proto 6, app 1461, class 7, policy "User Default", reason "vcmp_inb_fw_drop", count 19 path "2 11 47 48 49 54 58 60 74 "
 21/03/26 00:22:35.283832,832|7|27416/64|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:5201 <-> 10.0.4.25:44647 proto 6, app 1461, class 7, policy "User Default", reason "vcmp_inb_fw_drop", count 18 path "2 11 47 48 49 54 58 60 74 "
 21/03/26 00:22:36.284884,480|7|27416/65|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:5201 <-> 10.0.4.25:44647 proto 6, app 1461, class 7, policy "User Default", reason "vcmp_inb_fw_drop", count 17 path "2 11 47 48 49 54 58 60 74 "
 21/03/26 00:22:37.286092,544|7|27416/66|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:5201 <-> 10.0.4.25:44647 proto 6, app 1461, class 7, policy "User Default", reason "vcmp_inb_fw_drop", count 16 path "2 11 47 48 49 54 58 60 74 "
 21/03/26 00:22:54.623312,128|7|27428/6|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:40125 <-> 10.0.4.25:53 proto 17, app 216, class 21, policy "User Default", reason "tun_send", count 15 path "2 3 5 11 20 47 48 49 54 58 60 65 72 74 "
 21/03/26 00:22:54.623384,576|7|27424/3196|vc_pkt_print_track:187 dir: lan_to_wan, 10.0.2.1:40125 <-> 10.0.4.25:53 proto 17, app 216, class 21, policy "User Default", reason "cloud_to_edge_drop", count 14 path "7 31 32 34 71 74 "
 21/03/26 00:22:55.622983,680|7|27416/68|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:40125 <-> 10.0.4.25:53 proto 17, app 216, class 21, policy "User Default", reason "vcmp_inb_fw_drop", count 13 path "2 11 47 48 49 54 58 60 74 "
 21/03/26 00:22:56.624076,544|7|27416/69|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:40125 <-> 10.0.4.25:53 proto 17, app 216, class 21, policy "User Default", reason "vcmp_inb_fw_drop", count 12 path "2 11 47 48 49 54 58 60 74 "

  • 解決した問題 61344：VMware SD-WAN Edge に 180Mbps を超えるトラフィックが流れると、Edge を介して開始される次の新しいトラフィックで速度が低下します。

    180Mbps を超えるトラフィックが Edge を通過すると、新しいトラフィックは VMware SD-WAN Gateway でバッファリングされ、予期された時間内に Gateway によって処理されないため、トラフィックに遅延が発生します。

  • 解決した問題 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 の電源を手動で入れ直す必要があります。

  • 解決した問題 61403：VMware SD-WAN Edge が LTE モデル（つまり、Edge 510-LTE または Edge 610-LTE）である高可用性トポロジで展開されたサイトでは、HA が有効な場合、スタンバイ Edge の LTE リンクでトンネルが形成されません。

    LTE リンクを持つアクティベーションされていないスタンバイ Edge に 3.4.4、4.0.1、または 4.2.0 イメージがあり、HA が有効になっている場合は、Edge を有効にして HA をアップグレードした後にスタンバイ Edge の LTE リンクでトンネルが形成されません。

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

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

  • 解決した問題 61583：サイトの高可用性を有効にすると、VMware SD-WAN Edge がオフラインになってサイトが停止し、すべてのカスタマーのトラフィックが中断します。

    HA を有効にすると、Edge は少なくとも約 5 分間オフラインになります。その間、カスタマーのトラフィックが中断されます。Edge は約 5 分後に以前の設定にロールバックして操作を再開できる可能性があります。しかし、その Edge は引き続き HA を使用できないスタンドアローンとして動作します。ただし、Edge が直前の設定に正常にロールバックされない場合は、ローカル ユーザーが工場出荷時の設定にリセットし、そのサイトで接続をリストアするために（HA を有効にせず）RMA の再アクティベーションを実行するまで停止します。

    詳細については、ナレッジベースの記事「Enabling High Availability on a VMware SD-WAN Edge using Release 4.3.0 GA or 4.4.0 GA may cause the Edge to go offline」を参照してください。(84396)

  • 解決した問題 61657：VMware SD-WAN Gateway の SNMP は、publicIpAddr、localIpAddr、nextHop、peerIp などの属性に対して IPv6 ルートが設定されている場合に影響を受け、その Gateway に対して SNMP ウォークを実行するとエラーが発生します。

    SNMP は、「.」を区切り文字として使用した IP アドレスの解析に依存しています。IPv6 アドレスの場合は、「:」も区切り文字となるため、SNMP ウォークが失敗します。この問題の修正により、SNMP の解析ロジックが変更されます。

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

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

  • 解決した問題 61759：VMware SD-WAN Edge ローカル ユーザー インターフェイス([概要 (Overview)] ページと [ルーテッド インターフェイスのプロパティ (Routed Interface Properties)] ページ)では、ISP 名と帯域幅が空と表示されます。

    ルーテッド インターフェイスに複数のオーバーレイがある場合、ローカル ユーザー インターフェイスには、最新の「最後のアクティブ」値を持つインターフェイスの詳細が表示されます(1 つだけの詳細を表示するように設計されているため)。ユーザーが [ローカル ユーザー インターフェイスの概要/詳細 (Local UI Overview/Details)] ページを開くと、複数のオーバーレイを持つルーティング インターフェイスの帯域幅と ISP の値が空と表示されます。

  • 解決した問題 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 設定を有効にすることです。

  • 解決した問題 62373：一意の MAC アドレス用に設定された高可用性サイトを起動する場合、vMAC はルーテッド インターフェイスからスイッチ インターフェイスにプログラミングされます。

    インターフェイス タイプが WAN インターフェイスからスイッチ インターフェイスに変更されると、一意の MAC アドレスは HA Edge 用にプログラミングされず、トラフィックが失われます。

    この修正を適用しない場合、この問題を解決するための回避策は HA Edge を再起動することです。これにより、スイッチ インターフェイスに適切な MAC アドレスがプログラミングされます。

  • 解決した問題 62897：オペレータ ユーザーが VMware SD-WAN Gateway にログインし、eth0 または eth1 のいずれかで tcpdump コマンドを実行すると場合に、結果が正しく配信されません。

    tcpdump は、オペレータにとって重要な Gateway デバッグ コマンドであり、正しい出力がないため、オペレータの作業が大幅に損なわれます。修正なしで正しい出力を取得する方法があります。これは、tcdump 出力を cat にパイプするコマンドを使用することです。以下に例を示します。tcpdump -nnplei eth0 | cat

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

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

    注：

    注：以前の問題 60130 も根本的な動作と原因は同じですが、62552 とは異なる解決策が含まれています。60130 は防御的な回避策による修正でしたが、62552 はこの問題が繰り返されることを防ぐ完全な修正になります。

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

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

  • 解決した問題 62736：ハードウェアベースの VMware SD-WAN Edge では、ユーザーがローカル ユーザー インターフェイスにアクセスしているときに、ローカル ユーザー インターフェイスの [ルーテッド インターフェイスのプロパティ (routed interface properties)] ページで、PPPoE インターフェイスの場合、[MAC アドレス (MAC address)] フィールドが空と表示され、[IP アドレス (IP address)] フィールドが正しくありません。

    リリース 4.3.x 以降では、アップデートを常にポーリングするのではなく、ローカル ユーザー インターフェイスのインターフェイスの詳細が NETLINK イベントから取得されるようになりました。PPPoE インターフェイス自体のインターフェイスには MAC アドレスがないため (基本インターフェイスにはある)、MAC アドレスは空と表示されます。また、NETLINK の誤ったパラメータが IP アドレスの報告に使用されていました（IFA_LOCAL ではなく IFA_ADDRESS）。DHCP/静的インターフェイスでは、両方のフィールドの値が同じであるため、この問題はありません。

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

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

  • 解決した問題 63645：VMware SD-WAN Edge で破損などのメモリの問題が発生し、Edge でトンネル フラップ中にデータプレーン サービスの障害が発生することがあります。

    参照カウントは、Edge のマルチスレッド システムがすでに解放されたメモリにアクセスしないようにするために使用されます。1 つのシナリオとして、Gateway 情報を含む内部データ構造の 1 つに参照カウントを追加すると、Edge のメモリが破損する可能性があります。

  • 解決した問題 63692：cloud-init で連邦情報処理標準 (FIPS) が有効になっている VMware SD-WAN Gateway で、BGP セッションが起動しません。

    ユーザーが cloud-init で Gateway で FIPS を有効にしてから BGP を設定すると、BGP ネイバーシップが起動しないことが確認されます。

  • 解決した問題 63725：カスタマーが Gateway 経由の Non SD-WAN Destination (NSD) を展開し、冗長な VMware SD-WAN Gateway も設定されている場合、NSD トラフィックがプライマリ Gateway からセカンダリ Gateway にフェイルオーバーすると、トラフィックが失敗します。

    この問題は、セカンダリ Gateway にピア宛先へのルートがないことが原因で発生します。セカンダリ Gateway には NSD のピア宛先へのルートがないため、トラフィックがセカンダリ Gateway にフェイルオーバーすると、Gateway はトラフィックを直接送信します。ピア宛先との接続を試みると、トラフィックは直接送信されるため、Gateway 経由の NSD トラフィックはすべて失敗します。

  • 解決した問題 63752：連邦情報処理標準 (FIPS) が有効になっている VMware SD-WAN Gateway で、ユーザーが診断バンドルを生成しようとすると、失敗するか、タイムアウトになります。

    FIPS モードの操作用に設定された Gateway は、アプリケーション セキュリティ プロファイルを適用します。これにより、一部の診断データがシステムで収集されなくなり、診断バンドルの生成が失敗します。

  • 解決した問題 63983：パートナーが VMware SD-WAN Gateway の CPU およびメモリ使用率メトリックを収集するために監視ツール（Prometheus など）を使用している場合、このツールのユーザーには Orchestrator の CPU およびメモリ使用率の出力も表示されます。

    CPU とメモリの統計情報を区別するためのプレフィックスが追加されていないため、監視ツールは Gateway と Orchestrator の両方の CPU とメモリ使用率を収集します。

  • 解決した問題 64078：パートナーが監視ツール（Prometheus など）を使用して VMware SD-WAN Gateway のスループット メトリックを収集し、特定の Gateway が結合インターフェイスを使用している場合、その Gateway のスループット統計は不正確になります。

    Gateway は eth インターフェイスのスループット カウンタのみをエクスポートし、結合インターフェイスの統計情報はエクスポートしません。多くの Gateway が結合インターフェイスを使用するので、これは大きな問題です。

  • 解決した問題 64184：ユーザーが 2 つの VMware SD-WAN ハードウェア Edge を使用してサイトで高可用性を有効にすると、スタンバイ Edge のソフトウェアのアップグレード ポイントに達しても Edge のアップグレードが行われず、スタンバイ Edge が非アクティブ状態のままになることがあります。

    この問題は、まれに上記の条件下で発生しますが、この問題が発生した場合、問題の原因は、HA が有効になった後、スタンバイ Edge イメージのアップグレードの呼び出し操作中にアクティブ Edge で HA ワーカー スレッドが終了することです。この HA ワーカー スレッドを終了すると、スタンバイ Edge が非アクティブ状態になります。

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

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

  • 解決した問題 64713：拡張された高可用性トポロジを使用しているカスタマーのサイトで、ユーザーが Edge サービスを再起動した場合、または設定変更を行って Edge サービスを再起動した場合、Edge がリカバリするまでの再起動に予想以上の時間がかかることがあります。

    この問題が発生すると、Edge プロセスと他の競合するプロセスとの間で競合状態が発生し、起動に遅延が生じます。ユーザーは、診断バンドルのログの行で「FATAL: Cannot get hugepage information」という表示を確認することになります。

  • 解決した問題 64951：カスタマーが Zscaler をクラウド セキュリティ サービス (CSS) として使用している場合、L7 健全性チェックの完了時に VMware SD-WAN Orchestrator イベント ページに ZSCALER_MONITOR_FAILED イベントが確認される場合があります。

    これらのイベントは誤って表示されたもので、Zscaler トンネルには実際には問題がないため、ユーザーが混乱します。

  • 解決した問題 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 バイト以上の顧客パケットをドロップします。

    1496B 未満のデータ サイズはドロップされません。ユーザーが 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 以降を使用する Gateway の 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 データプレーン サービスが失敗します。この問題は、ネットワーク トポロジやフローの数、スループットに依存しません。これはまれでランダムに発生する問題ですが、あらゆるタイプのカスタマー エンタープライズで発生する可能性があります。

  • 解決した問題 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)」イベントとアラート通知が大量に発生する可能性があります。

  • 解決した問題 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 にルーティングされます。

  • 解決した問題 65929：ユーザーが物理 Edge を使用しているカスタマー サイトの VMware SD-WAN Orchestrator UI で高可用性をオンにすると、Edge がすぐにオフラインになり、Edge によってトラフィックが通過しないことがあります。

    起動中、HA Edge は Edge のデータプレーン サービスが開始されるまでトラフィックをブロックします。ただし、データプレーンは開始するために管理プロセスからの情報を必要としますが、管理プロセス自体が Orchestrator の DNS 名を解決しようとする行為をブロックする可能性があります（上記によってクエリがブロックされるため）。Edge のデータプレーン サービスの起動をブロックしないように、Orchestrator アドレスの非同期解決を実行する必要があります。

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

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

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

  • 解決した問題 66119：cloud-init を使用すると、世界のリモート リージョンに展開された VMware SD-WAN 仮想 Edge がアクティベーションされないことがあります。

    Edge と VMware SD-WAN Orchestrator 間のネットワーク遅延が 1 秒を超える場合、仮想 Edge は最初の展開中に cloud-init による自動アクティベーションに失敗します。

  • 解決した問題 66325：カスタマー トラフィックが、BGP で学習したルートと一致する必要があるのに、カスタマー トラフィックを中断させる可能性があるビジネス ポリシーと一致してしまいます。

    カスタマー エンタープライズが、ルーティングされたクライアントの IP アドレスとして送信元を設定し、インターネットとして宛先を設定するビジネス ポリシーを使用している場合、BGP 学習ルートと一致するトラフィックは、そのポリシーのトラフィック分類（Real Time など）を含むビジネス ポリシーを使用します。これにより、カスタマー トラフィックが中断する可能性があります。

  • 解決した問題 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 サービスも失敗して、再起動が発生します。

  • 解決した問題 66636：送信元がループバック インターフェイスの場合、VMware SD-WAN Edge は RADIUS 認証トラフィックの送信元インターフェイス設定を考慮しません。

    ユーザーがプロファイルまたは Edge で RADIUS を設定し、送信認証トラフィックの目的の送信元インターフェイスとして、ループバック インターフェイスを設定すると、VMware SD-WAN Orchestrator からディスパッチされる認証サービスの「port」パラメータの想定されるタイプと実際のタイプの不整合に起因する解析エラーが原因で、Edge は想定された NAT ルールを作成することができません。この値は整数にする必要があり、それに応じて Orchestrator API 検証ロジックが変更されています。

  • 解決した問題 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 デバイスに対応する必要があります。

  • 解決した問題 66794：VMware SD-WAN Orchestrator をリリース 4.3.0 にアップグレードすると、VMware SD-WAN Edge のポート転送や 1:1 NAT ルールを設定できないことがあります。

    ファイアウォールがオンになっていても、ルールが設定されていない Edge の場合、Edge の [設定 (Configure)] > [ファイアウォール (Firewall)] ページで、ポート転送ルールまたは 1:1 NAT ルールを設定し、そのルールを保存しようとすると、VMware SD-WAN Orchestrator でルールが保存されず、代わりに「networkSegments is not iterable」というエラーがそのページに表示されます。この問題は、Orchestrator が配列 networkSegments の配列インデックスとして segmentID を使用していることが原因で発生します。

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

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

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

  • 解決した問題 66901：カスタマーが VMware SD-WAN Edge をリリース 3.2.2 にアップグレードすると、アップグレード後に一部の Edge が起動しないことがあります。

    この問題はごくまれに発生しますが、発生すると、ユーザープロセスの Edge の終了とシャットダウンの Orchestrator イベント メッセージ（およびログ メッセージ）が表示されるのに、Edge はシャットダウン後にオンになりません。Edge はパワーオフになり、Orchestrator が Edge の状態を「ダウン (Down)」として表示し、イベント メッセージに「Edge ダウン (Edge down)」と表示されます。 

    この修正を適用せずに問題を修正する方法は、Edge の電源を入れ直して手動で工場出荷状態にリセットすることです。Edge がリセットされると、Edge は以前と同様に機能し、そのカスタマー サイトに対して再アクティベーションする必要があります。

  • 解決した問題 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 に最適なネクスト ホップのみを送信するコマンドが含まれています。

  • 解決した問題 67191：クラウド セキュリティ サービス (CSS) を使用しているカスタマーの場合、レイヤー 7 健全性チェックは誤ったエラーを返し、CSS トンネルが破棄されます。

    VMware SD-WAN Gateway に多数の Non SD-WAN Destination (NSD) トンネルがある場合、仮想トンネル インターフェイス (VTI) の IP アドレスが、Gateway データプレーン サービスが処理するプローブ用に定義されている特定のサブネット マスク /24 の範囲外になることがあります。これにより、誤ったエラーで L7 健全性チェックが失敗します。この修正により、マスクが /16 に更新され、L7 を受け入れて Gateway のデータプレーン サービスで処理できるようになります。

    この修正を適用しない場合、唯一の修正は、Gateway にアクセス権を持つオペレータ向けで、/opt/vc/bin/gwd_ip_setup.sh ファイルをマスクの変更を反映するように手動で変更できます(169.254.0.0/24 から 169.254.0.0/16 へ)。その後、Gateway サービスが再起動します。

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

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

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

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

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

  • 解決した問題 68829：VMware SD-WAN Edge LTE モデル（Edge 510-LTE または Edge 610-LTE）の場合、IPv6 パスは LTE インターフェイス上で形成されません。

    udp6 パケットはチェックサム 0 で送信され、ネクスト ホップでドロップされます。これにより、SD-WAN 管理パスが INIT 状態になります。正しい動作では、udp6 パケットのチェックサムが入力されます。

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

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

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

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

  • 解決した問題 67694：L7 健全性チェック プローブが条件付きでバックホールされたことが原因で、クラウド セキュリティ サービス (CSS) トンネルの障害が発生することがあります。

    L7 健全性チェック プローブは条件付きでバックホールしないでください。条件付きでバックホールすると、バックホールに失敗し、その結果、CSS トンネルが誤ってダウンとマークされます。

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

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

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

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

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

  • 解決した問題 67869：VMware SD-WAN Hub Edge が以前にシングル スタック IPv4 として設定され、その後にデュアル スタック IPv6 優先に変更された場合、古い IPv4 トンネルが切断されません。

    この問題が発生すると、IPv4 トンネルが破棄されないため、誤ったトンネル数が表示されます。トンネルの数が実際の 2 倍になります。

  • 解決した問題 67889：複数の VMware SD-WAN Edge をポーリングしている場合、SNMPv3 ポーリングが正しく機能しないことがあります。

    この問題は、VMware SD-WAN により snmpd が各 Edge に対してランダムな engine_id を生成できることであり、多くの場合、この engine-id は複数の Edge に対して複製されます。この場合、同じ engine-id を持つ Edge の 1 つがコレクタに統計情報を報告しません。

  • 解決した問題 67947：LAN 側の NAT が設定されていると、ルート バージョンの更新後に VLAN 間トラフィックが機能しません。

    VLAN 間トラフィックの LAN 側の NAT ルールはスキップされますが、ルート バージョンが更新されると、ルート ルックアップが誤った IP アドレスで実行され、トラフィック障害が発生する可能性があります。

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

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

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

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

  • 解決した問題 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 の問題が発生します。

  • 解決した問題 69704：VMware SD-WAN Edge 6x0 プラットフォーム (610、620、640、680) を使用してサイトで高可用性を有効にすると、Edge と VMware SD-WAN Orchestrator の通信が切断されることがあります。

    HA を有効にすると、6x0 インターフェイスの起動に関連する特定のタイミング条件が原因で、Orchestrator の通信が切断されます。その結果、HA が表示されず、Edge は Orchestrator への接続を完全に失います。つまり、Orchestrator は Edge をダウンとしてマークし、これ以上設定を変更することはできません。

  • 解決した問題 70041：VMware SD-WAN Gateway をリリース 4.3.0 にアップグレードすると、ゲートウェイの VRF IP アドレスに ping を送信できなくなります。

    ping が失敗すると、route_drop カウンタが増加します。ハンドオフ インターフェイスからの VRF IP アドレスへの ping は 4.3.0 では無効になり、リリース 4.3.1 で見つかった修正でリストアされます。

  • 解決した問題 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 でサービス障害が発生します。

  • 解決した問題 70349：まれに、NAT されたトラフィックが VMware SD-WAN Gateway で動作を停止します。Gateway のサービスを再起動すると、状態がクリアされます。

    Gateway のデータプレーン プロセスの競合状態が原因で、Gateway が natd （NAT 割り当てを管理する Gateway 内のデーモン）との接続を確立できず、Gateway が NAT エントリを割り当てることができない場合があります。これにより、Gateway 経由の NAT されたすべてのフローが失敗します。

  • 解決した問題 70416：VMware SD-WAN Gateway で CPU 負荷が高くなり、VMware SD-WAN Gateway をプライマリ Gateway として使用する Edge で、遅延とパケット ロスが発生することがあります。

    この問題は、Gateway の高速パス スレッド（IKE、VCMP データなど）が、サイクルの 15 ～ 20% を InetNtop 操作に費やしていることによって発生します。この問題の修正により、InetNtop 操作が削除され、より効率的なデータ フォーマット プロセスに置き換えられます。

  • 解決した問題 70438：VMware SD-WAN Gateway をリリース 4.3.0 にアップグレードするか、または 4.3.0 の実行中に再起動すると、NAT に依存するトラフィックがある場合、このトラフィックが中断することがあります。

    Gateway の起動時に、NAT エントリがフロー (fc->nat_tup) で SEND_TO_WAN 方向にすでにキャッシュされていても、競合状態が発生して「gwd_cloud_read」から NAT エントリが削除されることがあります。NAT エントリが削除されても、フローはキャッシュされた nat_tup を使用して NAT を適用します。その間、別のフローが新しい NAT エントリで割り当てられた同じ送信元ポートを取得できます。

  • 解決した問題 70590：リリース 4.3.0 を使用して VMware SD-WAN Gateway で診断バンドルを生成しようとすると失敗することがあります。

    リリース 4.3.0 を実行している Gateway で生成された診断バンドルは、Orchestrator で設定されているサイズ制限を超えた診断バンドルとなり失敗します。 診断バンドルのサイズ超過は、時間の経過とともに監査ログが増大することが原因です。

    この修正を適用せずに Gateway で診断バンドルを正常に生成する唯一の方法は、オペレータ ユーザーが Gateway にログインすることです。また、Orchestrator で診断バンドルをトリガする前に、オペレータ ユーザーは Gateway の /var/log/audit ディレクトリにある監査ログ ファイルを削除する必要があります。

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

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

  • 解決した問題 70855：VMware SD-WAN Gateway は、VMware SD-WAN Orchestrator から送信されたトラフィックをドロップし、その結果、Orchestrator からの Gateway 設定の更新が失敗する可能性があります。

    Gateway の負荷が高い場合（たとえば、NAT オブジェクト数が約 80 万個 の Gateway で 160 万件のフロー）、システム内のパケット バッファの数が枯渇し、Orchestrator トラフィックが Gateway でドロップする場合があります。Gateway がこの状態になると、パケット バッファが使用可能になっても Orchestrator トラフィックは常にドロップされます。

    この修正を適用せずにこの問題を修正する唯一の方法は、Gateway を再起動することです。

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

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

  • 解決した問題 71052：VMware SD-WAN Gateway に接続しているカスタマー エンタープライズの数が 285 を超えると、Gateway でデータプレーン サービスの障害が発生します。Gateway リリース 4.3.0 以降では、カスタマー エンタープライズ レベルでパケットおよびフロー関連情報を追跡するための新しいカウンタを追加することで、Gateway のカスタマーを監視する機能が強化されました。これは、285 のカスタマー エンタープライズの後にカスタマー エンタープライズ用に初期化されたカウンタの数が枯渇し、それ以降の新しいカスタマーのカウンタ初期化が失敗して、Gateway のデータプレーン サービスの障害が発生し、サービスの再起動が強制されるという問題です。

    Gateway リリース 4.3.0 以降では、カスタマー エンタープライズ レベルでパケットおよびフロー関連情報を追跡するための新しいカウンタを追加することで、Gateway のカスタマーを監視する機能が強化されました。これは、285 のカスタマー エンタープライズの後にカスタマー エンタープライズ用に初期化されたカウンタの数が枯渇し、それ以降の新しいカスタマーのカウンタ初期化が失敗して、Gateway のデータプレーン サービスの障害が発生し、サービスの再起動が強制されるという問題です。

  • 71513：ユーザーが VMware SD-WAN Orchestrator ユーザー インターフェイスで [Gateway] > [監視 (Monitor)] タブを表示している場合に、リリース 4.3.0 を使用する VMware SD-WAN Gateway を確認すると、ハンドオフ キューのドロップ数の値が常に 0 として表示されます。

    リリース 4.3.0 以降を実行している Gateway では、フォーマットが正しくないため、Orchestrator にハンドオフ キューのドロップ数は報告されません。このため、オペレータはこの特定のトラブルシューティング データ ポイントを明確に把握できなくなります。

  • 解決した問題 71977：ユーザーが VMware SD-WAN Edge で VMware Edge Network Intelligence を有効にすると、Edge でデータプレーン サービスの障害が発生し、コアが生成されます。

    この問題は、Edge で動的に作成されたセッション数が最大許容数を超えると発生します。

  • 解決した問題 72100：VMware SD-WAN Edge 610 のペアが展開に使用される拡張高可用性トポロジを使用しているサイトの場合、スタンバイ Edge 610 の WAN リンク経由でトンネルが確立されません。

    この問題は、スタンバイ Edge 経由でトンネルが確立されていない Edge モデル 610 でのみ発生します。HA を有効にする前の時点で GE1 インターフェイスの VLAN に IP アドレスがない場合、HA が有効になったときに SD-WAN サービスはハードウェア スイッチ ポートを GE1 にマッピングしません。その結果、スタンバイ Edge でパケットがドロップします。

    この修正を適用しない場合、この問題の回避策は、VLAN に IP アドレスを追加して、インターフェイス GE1 がハードウェア スイッチのポートにマッピングされるようにすることです。

  • 解決した問題 72567：ユーザーが意図的に非対称ルーティングの設定を、fixed_link ビジネス ポリシーによるフォワード パスでアンダーレイ（WAN オーバーレイなしの MPLS）を経由してから、次にリバースパスでオーバーレイ（ハブ Edge など）経由で行うと、フローが中断し、そのフローのトラフィックは成功しません。

    これは、Edge がアンダーレイ (INTF_ROUTED) からフローを強制するビジネス ポリシーを持つ、クラウド フローの非対称ルーティングの場合です。リモート Edge は、ハブ Edge（オーバーレイ）経由で応答をルーティングします。リモート Edge は、フローをローカルで開始された新しいフローとして認識し、QoS 同期を送信してフロー ルーティング パラメータを更新します。これにより、フロー ルーティングが中断します。この修正では、設定された link_mode が上書きされないように QoS 同期が拒否されます。

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

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

  • 解決した問題 72703：サブインターフェイスで設定された VMware SD-WAN Edge ルーテッド インターフェイスでは、ルートがインターフェイスのサブインターフェイスに属しているフローが許可されます。

    サブインターフェイスに属するルートと一致するフローは、リバース パス フォワーディング (RPF) モードが「特定 (specific)」に設定されている親インターフェイスで正常に許可されます。根本原因は、一致セット内の VLAN を無視する source_route ルックアップです。

  • 解決した問題 72718：Edge 経由の Non SD-WAN Destination (NSD) を使用しているカスタマーのサイトで、Edge 経由の NSD によってトラフィックをルーティングするようにインターネット バックホールが設定されている場合、バックホール ルールを使用している宛先のトラフィックが失敗します。

    Edge 経由の NSD へのバックホールは、宛先 ID を上書きしないことによる問題が原因で失敗します。NSD にバックホールされなかった以前のトラフィックは、宛先が Gateway であるデフォルトのクラウド ルートを照合します。SD-WAN サービスが古いクラウド ルーティング先を新しい NSD 論理 ID で上書きできないため、バックホール ルールの照合時にトラフィックが失敗します。

  • 解決した問題 72939：VMware SD-WAN Gateway の古いフロー数が、Gateway 仕様でサポートされている最大フロー数に到達するまで着実に増加するため、その Gateway に接続しているユーザーを中断する新しいフローが作成されなくなることがあります。

    増加する古いフロー数は、Non SD-WAN Destination から Partner Gateway ハンドオフにトラフィックを送信するサイトに接続されます。ルックアップ後にフロー数が解放されない、「gw_nvs_to_pg_pkt」と「gw_send_nvs_pkt」の 2 つの関数が追加されました。

    この修正を適用せずにこの問題を修正する唯一の方法は、Gateway サービスを再起動することです。

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

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

  • 解決した問題 73320：VMware SD-WAN Edge インターフェイスが DHCP アドレス タイプで設定されている場合、インターフェイスに割り当てられた IP アドレスが更新されると、NAT 障害が原因で一部の直接フローが失敗することがあります。

    DHCP リースの有効期限が切れると、インターフェイスの IP アドレスが削除されます。新しい IP アドレスがインターフェイスに割り当てられるまでの一時的な期間において、新しいフローの NAT エントリが送信元 NAT IP アドレスとして「0.0.0.0」で作成され、パケットがドロップされます。有効な IP アドレスがインターフェイスに割り当てられると、既存の NAT エントリは削除されず、有効な IP アドレスを持つ新しい NAT エントリが作成されないため、トラフィックがドロップされます。

  • 解決した問題 73987：診断バンドルを生成しようとするときに、VMware SD-WAN Edge でデータプレーン サービスの障害が発生することがあります。

    この問題の原因となっている診断バンドルの重要な部分は、Edge が「vcdgbdump -r remote_routes」のログを必要とする場合です。このシナリオでは、多数のリモート ルートがあり、それらのルートを使用しているトラフィックが実行されていて、診断バンドルの収集がトリガされた場合、ロックの競合が発生する可能性があります。

  • 解決した問題 74313：VMware SD-WAN Edge の LTE モデル（Edge 510-LTE または Edge 610-LTE）を使用しているカスタマー サイトで、Edge に LTE WAN リンクしかない場合、Edge は再起動後に VMware SD-WAN Orchestrator との通信を失います。

    Edge の再起動後に LTE インターフェイス経由のデフォルトのルート到達可能性が false になるため、Orchestrator と Edge 間の接続が失われます。その結果、カスタマー トラフィックがまだ LTE WAN リンクを通過している場合でも、Edge は Orchestrator によってダウンとしてマークされます。

    この修正を適用しない場合、Edge の到達可能性を回復する唯一の方法は、Edge サービスの再起動を実行することです。

  • 解決した問題 74482：ハブ/スポーク ネットワーク トポロジを使用しているカスタマーでは、ハブ Edge が別のハブ Edge のスポークでもある場合、VMware SD-WAN スポーク Edge からのルートはハブ Edge で学習されません。

    この問題が発生する場合、カスタマーはハブ経由の Edge から Edge への接続も設定しています。カスタマーの展開に、特定のスポークのハブとして、および特定のハブのスポークとして展開された Edge がある場合、そのような Edge は、VMware SD-WAN Gateway からスポーク ルートを受信しません。この問題は、ルートが見つからないため、このトポロジのネットワークに大きな影響を与えます。

    この修正を適用せずにこの問題を回避する唯一の方法は、スポーク Edge 上でハブ経由の Edge から Edge への接続を無効にすることです。

  • 解決した問題 75309：VMware SD-WAN スポーク Edge で特定のグループのマルチキャスト トラフィックがドロップすることがあります。

    トラフィックがハブ Edge から送信されている場合、特定のグループのマルチキャスト トラフィックがスポーク Edge で受信されません。IGMP グループがスポーク Edge の IGMP グループ テーブルに入力されず、トラフィックが失われます。これは、IGMP のスポーク Edge の診断バンドル ログで確認できます。

  • 解決した問題 75968：ユーザーが VMware SD-WAN Gateway のローカル IP アドレスハンドオフを設定し、そのハンドオフを削除しても、Gateway からハンドオフが削除されず、トンネル パスがダウンします。

    Gateway が新しいトンネルを構築できないため、この問題によって大きな中断が発生する可能性があります。

    この修正を行わない場合、ユーザーは Gateway を再起動して問題をクリアする必要があります。

  • 解決した問題 76726：VMware SD-WAN Gateway でデータプレーン サービス障害が発生し、コアが生成されることがあります。

    Gateway サービスの障害とコアの原因は、Edge と Gateway 間の管理プロトコルの ctrl パケットが交換されることです。アサートが原因で Gateway が失敗することがあり、これにより複数のカスタマーで停止が発生する場合があります。この問題は、アサートを削除し、適切なエラー処理を行うことで修正されました。

Orchestrator で解決した問題

Orchestrator バージョン R431-20220715-GA で解決した問題

Orchestrator バージョン R431-20220715-GA は 2022 年 7 月 22 日にリリースされた、リリース 4.3.1 の 3 番目の Orchestrator ロールアップです。

この Orchestrator ロールアップ ビルドは、2 番目の Orchestrator ロールアップ、バージョン R431-20220429-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 OVA の修正は同じチケット #88796 で追跡されますが、Gateway ビルド R431-20220518-GA の「Edge/Gateway で解決した問題」セクションにリストされます。

  • 解決した問題 76016：VMware SD-WAN Orchestrator をリリース 4.3.0 以降にアップグレードした後に Partner Gateway ハンドオフを設定すると、パートナー管理者が、BGP/BFD/スタティック ルートなどのハンドオフ内のサブコンポーネントを Orchestrator のユーザー インターフェイスまたは API から削除できません。

    この問題は、Orchestrator のバックエンドでの削除のためのサブコンポーネント設定を処理するためのロジックの回帰が原因で発生しました。以前に、混合 Gateway プール（クラウド + Partner Gateway）の修正が追加されました。パートナー管理者が Partner Gateway を変更しても、Cloud Gateway のハンドオフ設定に影響しません。ただし、この修正では、サブコンポーネントの削除が含まれるケースは考慮されていません。

    この修正を含まない Orchestrator には、次の 2 つの回避策があります。

    1. この問題はパートナー ユーザーにのみ影響するため、パートナーはオペレータ ユーザー（VMware のサポートなど）に問題なく削除を実行するように要求できます。

    2. パートナー ユーザーは、Partner Gateway のハンドオフ全体を削除し、改訂された設定で再作成することができます。

Orchestrator バージョン R431-20220429-GA で解決した問題

Orchestrator バージョン R431-20220429-GA は 2022 年 5 月 5 日にリリースされた、リリース 4.3.1 の 2 番目の Orchestrator ロールアップです。

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

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

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

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

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

Orchestrator バージョン R431-20220222-GA で解決した問題

Orchestrator バージョン R431-20220222-GA は 2022 年 2 月 23 日にリリースされた、リリース 4.3.1 の 1 番目の Orchestrator ロールアップです。

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

また、この Orchestrator ロールアップ ビルドでは、元の Orchestrator GA ビルド、バージョン R431-20211217-GA 以降の以下の重大な問題にも対処しています。

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

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

  • 解決した問題 80613：ディザスタ リカバリ (DR) 用に設定された VMware SD-WAN Orchestrator で、アクティブ Orchestrator とスタンバイ Orchestrator 間のレプリケーションが失敗し、Orchestrator ユーザー インターフェイスにデータベースのコピーの状態が「失敗」と表示される場合があります。

    MySQL バージョン 8.0.26 以降、mysqldump コマンドの master-data オプションが廃止されました。これは source-data オプションに置き換えられました。Orchestrator DR プロセスでは master-data オプションを指定した mysqldump コマンドが使用されるため、この問題が発生します。ただし、MySQL を最新バージョンにアップグレードすると、このオプションは機能しなくなり、DR が中断します。この問題に対処するために、この修正を適用した Orchestrator では、DR プロセス中に mysqldump コマンドの master-data オプションではなく source-data オプションが使用されます。

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

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

Orchestrator バージョン R431-20211217-GA で解決した問題

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

Orchestrator バージョン R431-20211213-GA で解決した問題

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

  • 解決した問題 77116：VMware SD-WAN Orchestrator は 12 か月未満のログを保持します。

    現在、Orchestrator は 6 か月間ログを保持しますが、カスタマーによっては、少なくとも 12 か月のログ履歴が必要です。

  • 解決した問題 75879：VMware SD-WAN Orchestrator が VMware SD-WAN Edge のルーティング イベントに応答せず、Orchestrator の負荷が増加する場合があります。

    Orchestrator が Edge のルーティング イベントに応答しない場合、Edge がルートを継続的に再試行するため、Orchestrator の負荷が増加します。これは、この問題に対する永続的な修正です。

  • 解決した問題 75656：VMware SD-WAN Edge のルーティング イベントを処理した後、VMware SD-WAN Orchestrator が空の ACK （応答なしと同等の無効度）で応答し、Orchestrator の負荷が増加する場合があります。

    Orchestrator が Edge のルーティング イベントに空の ACK を送信すると、Edge が継続的にルートを再試行し、Orchestrator の負荷が増加します。

  • 解決した問題 74450：VMware SD-WAN Orchestrator がウォーターマーク カウンタを Telegraf や Prometheus などの外部アプリケーションにエクスポートしません。

    このチケットは、問題 #74446 と関連しています。その問題の修正では、Gateway ハンドオフ キューのドロップのウォーターマーク カウンタが作成されます。このチケットにより、Telegraf や Prometheus などのアプリケーションでこれらのメトリックを収集できるようになります。

  • 解決した問題 74446：VMware SD-WAN Orchestrator のユーザー インターフェイスで、Gateway ハンドオフ キュー ドロップ カウンタがトラフィック スパイクを識別する目的を果たしていません。

    Gateway ハンドオフ キューのドロップのきめ細かさが、トラフィック スパイクを特定するのに十分ではありません。この修正により、新しいウォーターマーク カウンタ（wmark_1min と wmark_5mins）が追加され、それぞれ 1 分以内と 5 分以内のハンドオフ キューの最大深度を指定します。

  • 解決した問題 72841：VMware SD-WAN Orchestrator で「Gateway が稼動中 (Gateway up)」イベントの生成に一貫性がありません。Gateway の状態が「オフライン (OFFLINE)」から「接続済み (CONNECTED)」に変更されるたびに、「Gateway が稼動中 (Gateway up)」イベントがすべてのインスタンスに記録されるわけではありません。

    この問題はランダムに発生しますが、2 つ以上の Gateway が存在し、両方の Gateway で updateStateChange が同時にトリガされます。同時に状態変更が発生する使用可能な Gateway が多いほど、問題が発生する可能性が高くなります。

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

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

  • 解決した問題 70018：リリース 4.3.0 以降を実行している VMware SD-WAN Orchestrator で、ディザスタ リカバリのペアを形成できない場合があります。

    根本原因により、Orchestrator がディザスタ リカバリを実行するために必要な空きディスク容量のサイズを取得できなくなり、その結果ディザスタ リカバリのペアリングが失敗する場合があります。

  • 解決した問題 69534：VMware Edge Network Intelligence を使用しているユーザーが、Orchestrator の新しいユーザーインターフェイスのメインの [監視 (Monitoring)] ページの任意の場所をクリックすると、[アプリケーション分析 (Application Analytics)] と [ブランチ分析 (Branch Analytics)] のリンクが表示されません。

    ユーザーがページを再ロードすると、ユーザーが同じページのどこかをクリックするまでこれらのリンクが再表示され、その後再び消えます。このため、ユーザーはページを再ロードするまで、[アプリケーションの分析 (Application Analytics)] と [ブランチ分析 (Branch Analytics)] の監視データを表示できません。

  • 解決した問題 69514：レポートの生成が「PDF の BLOB データの更新に失敗しました (Failed to update blob data for PDF)」というエラーで失敗することがあります。

    ユーザーがオフライン レポートを作成しようとすると、レポートの生成が内部エラーで失敗します。これは、チャート生成ライブラリのバージョンが正しくないために発生していました。

  • 解決した問題 69273：リリース 4.3.0 を使用している VMware SD-WAN Orchestrator で、カスタマーがクラウド セキュリティ サービス (CSS) を展開し、[監視 (Monitor)] > [ネットワーク サービス (Network Services)] ページを確認すると、CSS パブリック IP アドレスが切り詰められ、状態バブルにカーソルを合わせても、完全な IP アドレスが表示されません。

    パブリック IP アドレスの幅が完全な IP アドレス（例：255.255.255.255）を表示するのに十分ではありません。全体的な状態を表示すると、Orchestrator の UI パラメータに未定義のエラーが表示されます。

  • 解決した問題 69196：カスタマーに WAN リンクをバックアップとして設定し、クラウド セキュリティ サービス (CSS) も使用しているサイトがある場合、バックアップ リンクの CSS トンネル イベントが発生する場合があります。

    ユーザーに CSS トンネルが設定されているバックアップ WAN リンクがある場合、アクティブ リンクとホット スタンバイ リンクとともに、これらのリンクに関連するイベントが表示されます。バックアップ リンクは定義上非アクティブであるため、これらのイベントは偽りであり、カスタマーにとっては煩わしいものです。

  • 解決した問題 69181：ユーザーが VMware SD-WAN Orchestrator の [デバイス設定 (Device Settings)] > [ゲートウェイ ハンドオフ (Gateway Handoff)]セクションで、セカンダリの [IPsec Gateway が前面 (fronted by IPsec Gateway)] を設定した場合に、IPsec トンネルが セカンダリの [IPsec Gateway が前面 (fronted by IPsec Gateway)] で確立されません。

    debug.py --gateways を確認しても、IPsec 設定が適用されて存在することが確認されません。

  • 解決した問題 69162：パートナー管理者がテストを開始すると、Webhook アラートのサンプル テスト ペイロードにカスタマー名が表示されません。

    パートナー管理者ユーザーが、特別な「customer」キーワードを含むペイロード テンプレートを使用して、カスタマーの代わりに Webhook アラート テストを開始すると、VMware SD-WAN Orchestrator が誤ってカスタマー名を空の文字列に置き換えます。

  • 解決した問題 69046：VMware SD-WAN Orchestrator で、接続された VMware SD-WAN Edge がルーティングの更新を受信せず、その結果、古いルートの使用を引き続き試みることがあります。

    Edge が 15 秒の間に 250 個を超えるファイルをキューに登録し、登録されたファイルがすべて小さく、ファイルに 1 つまたは 2 つのルート イベントしか含まれない場合、ルーティング イベント ファイルをキューに登録するジョブにおいて、ユーザーが使用するためのジョブが作成されていません。その結果、ファイル数が多くなると、ファイル処理キューのファイル数が増え続け、キューに登録するジョブの実行時間が長くなります。この問題が発生すると、保留中のルーティング イベント ファイルの数が増え続けます。ルーティング要求を処理する Orchestrator のアップロード プロセスがすべてのルーティング イベントの ACK ですぐに応答しても、Edge が ACK を受信しません。代わりに、「接続がタイムアウトしました」というメッセージが Edge ログに表示されます。これにより、ルーティング イベントを取得しない Edge に影響するだけでなく、Orchestrator の処理に負荷が生じることにもなります。

  • 解決した問題 68702：リリース 4.3.0 を実行している VMware SD-WAN Orchestrator で、「プロファイル デバイスのマルチキャスト設定の更新 (Update Profile Device Multicast Settings)」または「カスタマーの Edge 設定の更新 (Update Customer Edge Settings)」権限のいずれかの権限を拒否するようにユーザー ロールを設定しても、Orchestrator によって実施されません。

    Orchestrator 4.3.0 には、「プロファイル デバイスのマルチキャスト設定の更新 (Update Profile Device Multicast Settings)」または「カスタマーの Edge 設定の更新 (Update Customer Edge Settings)」のいずれの権限も含まれていません。

  • 解決した問題 68531：スーパー ユーザー、標準、およびエンタープライズ ネットワークのロールを持つカスタマー管理者が、リリース 4.3.0 を使用して VMware SD-WAN Orchestrator の [Edge 監視 (Edge Monitoring)] ページで「Gateway の BGP ネイバー状態（Gateway 経由の IPsec 上の BGP）(BGP Gateway Neighbor State (for BGP on IPsec via Gateway))」を表示できません。

    リリース 4.5.0 では、[スーパー ユーザー (Superuser)]、[標準 (Standard)]、および [エンタープライズ ネットワーク (Enterprise Network)] のロールを持つカスタマー管理者に、[Edge の監視 (Edge Monitoring)] ページで「Gateway の BGP ネイバー状態（Gateway 経由の IPsec 上の BGP）(BGP Gateway Neighbor State (for BGP on IPsec via GW))」を表示する権限が追加されましたが、これはリリース 4.3.0 の Orchestrator には含まれていませんでした。

  • 解決した問題 68387：ユーザーが非ネイティブタイプで新しいオペレータ ユーザーまたはカスタマー管理者（つまり、ユーザー名/パスワードを使用せずに SSO または RADIUS 認証を使用するユーザー）を作成しようとする場合でも、VMware SD-WAN Orchestrator は、新しいユーザーのパスワードの入力を要求します。

    ユーザーが新しいカスタマーまたはオペレータ ユーザーを作成しようとしても、Orchestrator のユーザー インターフェイスでパスワード フィールドがクリアされません。また、バックエンドでは、ユーザー タイプがネイティブでないかどうかを最初に確認する代わりに、最初にパスワード強度チェックを実行して、エラーが発生します。

  • 解決した問題 68321：エンタープライズでハブ/スポーク トポロジを使用しているカスタマーの場合、そのエンタープライズが使用している VMware SD-WAN Orchestrator が 4.3.0 にアップグレードされると、1 分ごとに大量の「Edge ネイバーに BGP セッションが確立されました (BGP session established to edge neighbor)」イベントが発生します。

    ハブ Edge はこれらの BGP 状態変更イベントを 1 分間に数回送信しており、カスタマーの [イベント (Events)] ページがこれらのイベントでいっぱいになるため、そのカスタマーにとって意味のあるイベントを特定することが非常に困難になります。

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

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

  • 解決した問題 67496：リリース 4.3.0 にアップグレードされた VMware SD-WAN Orchestrator では、リソース使用率に関連するパフォーマンスがわずかに低下します。

    この問題はエンタープライズ レベルでは確認されませんが、Orchestrator 管理者は、4.3.0 へのアップグレード後にリソース使用率が最大 10％ 程度増加したことを確認できます。Orchestrator のパフォーマンスの問題は、いくつかのデータベース クエリによって発生していました。これらのクエリはそれぞれ若干効率が悪く、大規模な展開（6,000 台以上の Edge）における Orchestrator のパフォーマンスに影響を与えることがありました。この修正により、これらの問題が解決され、Orchestrator のパフォーマンスは、以前のリリースと比較して想定される程度またはそれを上回る程度に達しました。

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

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

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

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

  • 解決した問題 66679：4.3.0 にアップグレードした後、VMware SD-WAN Orchestrator ポータルが応答しなくなることがあります。

    Orchestrator の 4.3.0 へのアップグレード後、Redis が Bastion を確実に設定するための仲介として使用されている Bastion Orchestrator 機能の副作用により、バックエンド プロセスが想定どおりに起動しません。これにより、Orchestrator バックエンドは「Edge」チャンネル サブスクリプションで Pub/Sub メッセージを受信しているため、無限ループに入ります。

  • 解決した問題 66678：VMware SD-WAN Orchestrator をリリース 4.3.0 にアップグレードしたときに、Gateway 経由の Non SD-WAN Destination トンネルが破棄され、再構築されないことがあります。

    この問題は、リリース 4.3.0 に追加された機能で導入された検証の不具合が原因で発生します。この不具合により、VMware SD-WAN Gateway のハートビートが失敗し、Orchestrator が Gateway 設定をそれぞれの Gateway にプッシュしなくなります。設定が送信されないため、Gateway 設定の一部である NSD トンネルは Gateway に伝達されず、トンネルは最終的に停止し、リカバリされません。この問題は、長期間使用されていて、Orchestrator の一部の NSD ピアがどのセグメントにも関連付けられていない Orchestrator に影響します。ハートビート障害は Gateway に関連しているため、複数のカスタマーで Gateway 経由の NSD トンネルがダウンする問題が発生する可能性があります。

  • 解決した問題 66639：4.3.0 を使用している VMware SD-WAN Orchestrator で、高可用性トポロジを使用しているサイトにおいて HA フェイルオーバーが発生すると、Orchestrator が HA イベントを正常に処理できず、アラートの整合性が失われ、サイトが「ダウン」とマークされる可能性があります。

    Orchestrator はイベントに基づいてサイトの HA 状態を判断します。HA フェイルオーバーが発生すると、HA_GOING_ACTIVE イベントとともにパラメータで「HA 状態」が送信されます。Orchestrator がこれらを順不同で処理すると、ユーザーは誤ったアラートと HA ペアが「ダウン」としてマークされていることを確認できます。

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

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

  • 解決した問題 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 がダウンしているように表示されます。

  • 解決した問題 66177：一部のパートナー ユーザーが VMware SD-WAN Orchestrator でパス統計を表示できません。

    これは、ロール ID 5、6、または 8 が割り当てられているパートナー管理者に影響します。これらのロールは次のように変換されます。5 = IT スペシャリスト、6 = スーパー ユーザー、8 = カスタマー サポート。この問題の原因は、パス統計情報の表示が委任された権限であることです。この問題に対する完全な修正は、リリース 4.4.x 以降で対処されています。

    4.3.1 では、ロール ID 6（スーパー ユーザー）の問題は修正されましたが、5 または 8 の問題は修正されていません。

  • 解決した問題 66011：VMware SD-WAN Orchestrator ポータル API メソッド linkQualityEvent/getLinkQualityEvents は、非確定的に「詳細」モードで動作します。

    linkQualityEvent/getLinkQualityEvents Orchestrator API メソッドは「individualScores」オプションをサポートしています。このオプションを使用すると、クライアントはオプションで API 応答のリンク QoE に関する詳細情報を要求できます。このオプションのメソッドでは、時系列ごとの詳細なサンプル情報が結果に生成されます（生成には時間がかかり、集中的なパフォーマンスが要求されます）。このパフォーマンスの影響を回避するため、このパラメータのデフォルト値は false になっています。ただし、ここでは、クライアントが結果として生じるパフォーマンスへの影響の報告を明確に要求していない場合でも、サーバがこの情報を非確定的に報告します。

  • 解決した問題 65967：オンプレミスの VMware SD-WAN Orchestrator をリリース 4.3.0 にアップグレードするカスタマーの場合、アップグレードの完了後に Orchestrator サービスが起動せず、Orchestrator が停止しているように見えることがあります。

    この問題が発生するのは、アップグレード スクリプトで特定のバージョンの VMware SD-WAN Edge によって送信された無効なデータを処理できないためです。Orchestrator の一部の内部サービスが正常に起動せず、ポータルとアップロード サービスを再起動しても問題が解決されません。この問題の修正には、無効な設定をスキップし、すべての ID を持つオペレータ イベントをログに記録するように再設定されたパッチが含まれているため、オペレータは後でそれらの問題を修正できます。

  • 解決した問題 65760：オペレータ ユーザーが VMware SD-WAN Orchestrator ユーザー インターフェイスの Orchestrator 診断 (Orchestrator Diagnostics) ページを表示しているときに、[データベース ストレージ情報 (Database Storage Info)] セクションに複数のデータ グループの表示がありません。

    データベース ストレージに、データベース プロセス リスト (Database Process List)、データベース状態変数 (Database Status Variable)、データベース システム変数 (Database System Variable)、データベース エンジンの状態 (Database Engine Status) セクションが見つかりません。

  • 解決した問題 65558：リリース 4.3.0 を使用して VMware SD-WAN Orchestrator に展開されたカスタマーが、送信元インターフェイスが VLAN である Syslog を設定できません。

    送信元インターフェイスの VLAN を使用して Syslog を設定すると、Orchestrator のユーザー インターフェイスで「Syslog 送信元インターフェイスの VLAN-xxx がセグメント <セグメント名> に存在しません (Syslog source interface VLAN-xxx does not exist on Segment <segment name>)」というエラーが発生します。

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

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

  • 解決した問題 64716：ユーザーが VMware SD-WAN Orchestrator でレポートを生成できません。

    ユーザーがレポートを生成しようとすると失敗し、[レポート (Reports)] ページの [状態 (Status)] 列に「Error」と表示されます。この問題は、依存パッケージの 1 つが更新されるときに発生します。更新されたパッケージによって、生成されたすべてのレポートが失敗する原因となる不具合が発生します。

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

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

  • 解決した問題 63694：VMware SD-WAN Edge がリリース 4.2.x 以前を実行しており、4.3.0 以降を実行している VMware SD-WAN Gateway に接続されている、ハブおよびスポーク トポロジを使用するカスタマー エンタープライズの場合、Edge は適切なルート順序をインストールせず、その結果、トラフィックが中断します。

    VMware SD-WAN Orchestrator は、一方では 4.2.x より前の Edge からのアップリンク ルートを、もう一方では 4.2.x より後の Edge からのアップリンク ルートを適切に処理しません。それぞれのリリースでは、Edge が Orchestrator にアップリンク フラグを送信する動作が異なるため、Orchestrator が 4.2.x 以前の Edge に誤ったルート順序を送信します。

  • 解決した問題 63622：ユーザーが VMware SD-WAN Gateway を削除しても、VMware SD-WAN Orchestrator ユーザー インターフェイスで Gateway 削除イベントがログに記録されません。

    Orchestrator は、オペレータ レベルとパートナー レベル（削除される Partner Gateway の場合）の両方でイベントをログに記録する必要がありますが、そのようになりません。

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

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

  • 解決した問題 63518：リリース 4.3.0 にアップグレードされるリリース 3.3.x を使用しているカスタマー エンタープライズの場合、このカスタマーの Edge に接続された VMware SD-WAN Gateway が、学習した BGP ルートを広報しないことがあります。

    この問題は、VMware SD-WAN Orchestrator が学習済みルートへの確認の送信に失敗するために発生します。そのため、advertise - true で応答する代わりに、Orchestrator は Gateway に advertise - false を送信し、Gateway はルートを広報しません。

  • 解決した問題 62958：Zscaler クラウド セキュリティ サービス (CSS) の IPsec 自動化が有効になっている VMware SD-WAN Edge のパブリック WAN リンク IP アドレスが変更されると、Edge がパブリック IP アドレスの無効な値を一時的な状態として送信することがあります。

    パブリック IP アドレスの検証が想定どおりに動作せず、無効なパラメータが原因で Zscaler API エラーが発生することがあります。この問題は、Edge のパブリック WAN リンクが短い一時的な状態になると発生します。通常、これはパブリック WAN リンクからの既存の CSS トンネルには影響しません。

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

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

  • 解決した問題 62575：Edge 固有のルールを介してクラウド セキュリティ サービス (CSS) または Non SD-WAN Destination サイトの設定が非グローバル セグメントに対して有効化されている場合、VMware SD-WAN Edge で想定される設定が適用されません。

    一部のまれな設定シナリオ（たとえば、クラウド セキュリティ サービスが Edge 固有のルールを介して非グローバル セグメントでのみ有効にされた場合など）では、Orchestrator は、非グローバル セグメントの Edge 制御プレーン設定を誤って計算しました。

  • 解決した問題 62355：ユーザーは、Palo Alto Networks タイプの Non SD-WAN Destination の BGP オプションを設定できません。

    以前のチケットで、BGP をサポートしていない Non SD-WAN Destinations (NSD) から BGP を設定する機能が削除されました。ただし、Palo Alto Networks タイプの NSD は BGP をサポートし、BGP を設定する機能もこのタイプから誤って削除されました。この修正により、これらの BGP 設定フィールドが Palo Alto Networks タイプにリストアされます。

  • 解決した問題 62058：VMware SD-WAN Orchestrator に、Wi-Fi が搭載されていない VMware SD-WAN Edge 510-N および 6x0-N モデルの場合でも、WLAN インターフェイスが表示されます。

    Orchestrator のユーザー インターフェイスで、510-N および 6X0-N Edge モデルの WLAN インターフェイスを非表示にする必要があります。「-N」指定子の付いた Edge モデルは、Wi-Fi チップなしで構築されていることを示します。これらの Edge モデルがアクティベーションされると、Orchestrator でモデル番号を使用して、WLAN インターフェイスを非表示にする必要があります。カスタマーへの影響は最小限です。WLAN インターフェイスは表示されますが、設定しようとすると Orchestrator によって無視されます。

  • 解決した問題 59434：ユーザーが VMware SD-WAN Orchestrator ユーザー インターフェイスの [設定 (Configure)] > [Edge] > [デバイス (Device)] ページから移動すると、ユーザーが [デバイス設定 (Device Settings)] ページで変更を行っていないにもかかわらず、Web ページに「このページから移動すると、行った変更は失われます (The changes you made will be lost if you navigate away from this page)」というナビゲーション ポップアップが表示されます。

    Orchestrator には変更が加えられていないのに、変更が加えられたことを示すデータがあるため、カスタマーに保存を求めるポップアップが表示されます。これは、変更を確認するために既存のオブジェクトと比較されたオブジェクトが誤ったオブジェクトであったためです。比較が正しくないため、データが変更済みとみなされました。この修正により、誤ったオブジェクトが比較対象となる正しいオブジェクトに置き換えられ、誤った保存要求がなくなります。

  • 解決した問題 58070：VMware SD-WAN Orchestrator のユーザー インターフェイスで OFC ページを使用するときに、セグメントに基づいて OFC サブネットをフィルタリングできません。

    OFC サブネット検索フィルタはセグメントでは機能しないため、ユーザーが OFC ページでプレフィックスとビューを学習し、学習オプションを使用してセグメントを指定して検索する場合、結果が得られません。

  • 解決した問題 53751：cidrIp および cidrPrefix のない VLAN で、スタティック ルート設定の接続ルートの検証が失敗します。

    この問題は、ユーザーが cidrIp および cidrPrefix なしで VLAN を作成すると発生します。

  • 解決した問題 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 を切り替えることができないために発生します。

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

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

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

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

既知の問題

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

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

Edge/Gateway の既知の問題

  • 問題 14655：

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

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

  • 問題 25504：

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

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

  • 問題 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 の割合ではなくハンドオフ キューのドロップ数を使用する必要があります。

  • 問題 39608：

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

  • 問題 39624：

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

  • 問題 39753：

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

  • 問題 40096：

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

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

  • 問題 40421：

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

  • 問題 42872：

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

  • 問題 43373：

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

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

  • 問題 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 をハブとして使用することはできません。

  • 問題 45302：

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

  • 問題 46053：

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

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

  • 問題 42278：

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

  • 問題 42388：

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

  • 問題 42488：

    接続されているリンクがない VMware SD-WAN Edge インターフェイスの接続ルートのトラフィックが、ブラックホールになることがあります。Edge ポートのリンクが削除され、インターフェイスが無効になっていない場合、Edge は Gateway からルートを取り消しません。リンクが接続されていない Edge に他の Edge がトラフィックを転送します。

    回避策：接続されているリンクがない場合は、インターフェイスを無効にします。

  • 問題 44995：

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

  • 問題 45189：

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

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

    ピアが 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 で使用できます。

  • 問題 47681：

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

  • 問題 47355：

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

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

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

  • 問題 50518：

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

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

  • 問題 51036：

    SNMP 経由で Edge をポーリングすると、ifSpeed が動作中の VMware SD-WAN Edge インターフェイスに対して 0 の値をレポートします。これは、DPDK が有効なポートで想定される動作です。現在、DPDK が有効なポートの速度値を取得する唯一の方法は、「debug.py --dpdk_ports」コマンドを使用することです。ただし、Edge で実行されている SNMP モジュールは、DPDK が有効なポートの速度値を抽出するためにこのコマンドに依存しません。SNMP はカーネル インターフェイス経由でのみクエリを実行しますが、残念ながら dpdk_ports の速度値は入力されません。

  • 問題 51428：

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

    回避策：最初にサブインターフェイスを無効にしてから、サブインターフェイスを別のセグメントに移動します。移動したら、サブインターフェイスを再度有効にします。

  • 問題 52955：

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

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

  • 問題 53147：

    ルーター広報で広報されたデフォルト以外のホップ制限値は、VMware SD-WAN Edge に適用されません。トンネルのホップ制限値は常に 64 に設定されます。ホップ制限のデフォルト値は 64 です。デフォルト以外のホップ制限値をルーター広報を通じて広報しようとすると、Edge はパケット内のホップ制限フィールドを処理せず、値は 64 のままになります。

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

  • 問題 53219：

    デフォルトでは、Edge のホップ制限は 64 です。

    RA サーバのホップ制限がデフォルト以外の値に設定されている場合、トンネルのホップ制限は更新されません。

    次のチケットを提出して制限を追跡します

    edge:b2-edge1:~# edged -v VCE Info ======== バージョン：4.2.0 ビルド リビジョン：R420-20201119-DEV-69492a5ca4 ビルド日：2020-11-19_10-57-33 ビルド ハッシュ：69492a5ca4934d41a7ff9822f763312d014f1836

    該当なし

  • 問題 53219：

    VMware SD-WAN ハブ クラスタの再調整後、いくつかのスポーク Edge で RPF インターフェイス/IIF が正しく設定されていない場合があります。影響を受けるスポーク Edge では、マルチキャスト トラフィックが影響を受けます。クラスタの再調整後、一部のスポーク Edge が PIM join の送信に失敗します。

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

  • 問題 53337：

    スループットが 3200 Mbps を超えると、VMware SD-WAN Gateway の AWS インスタンスでパケットのドロップが発生することがあります。トラフィックが 3,200 Mbps 以上のスループットを超過し、パケット サイズが 1,300 バイトの場合、RX および IPv4 BH ハンドオフでパケットのドロップが発生します。

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

  • 問題 53687：

    VMware SD-WAN スポーク Edge に IPv6/v4 トンネルの優先度がある場合、優先されない v4/v6 トンネルの MTU は、優先されるトンネルで見られる MTU にも影響します。Edge（スポークまたはハブ）は、すべてのリンク MTU の最小値であるシステム レベルの MTU を維持し、この MTU は広報された MTU として交換されます。非優先リンクの MTU は、システム レベルの MTU を決定するために引き続き考慮されるため、実際のパス MTU よりも低い MTU を広報できます。

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

  • 問題 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)] オプションを実行します。ルートの [更新 (Refresh)] を実行すると、エンタープライズ内のすべての Edge からルートが再学習されることに注意してください。

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

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

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

  • 問題 54099：断片化された IPv6 パケットが VMware SD-WAN Edge によってドロップされます。

    断片化された IPv6 パケットはすべて Edge によってドロップされます。

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

  • 問題 54378：NA ドロップが原因で、IPv6 静的アドレスが有効になっているインターフェイスの重複アドレス検出 (DAD) チェックが失敗します。

    静的アドレスの DAD チェックは行われず、設定された静的アドレスに対してネットワーク内に重複アドレスがある場合、それは検出されません。

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

  • 問題 54536：VMware SD-WAN Edge の再起動後に、重複アドレス検出 (DAD) チェックがトリガされません。

    ネットワークに重複アドレスがあっても、再起動後にこの DAD チェックが実行されないと検出されません。

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

  • 問題 54687：サーバに T2 より大きい T1 値の設定が提供された後、DHCPv6 要請メッセージが VMware SD-WAN Edge によって送信されません。

    DHCPv6 サーバが最初に T2 より大きい T1 値を提供した場合、Edge は提供されたプレフィックスを受け入れませんが、サーバ上でこの設定が修正された後、3 回試行しても Edge は DHCPv6 要請メッセージを送信しません。その時点で、Edge のデータプレーン サービスが再起動された場合にのみ、問題が解決されます。

    回避策：Edge のサービスを再起動します。

  • 問題 54731：ユーザーがサーバの IPv6 アドレス範囲の値を変更すると、再バインド時間 (T2) に達するまで、更新メッセージが高い頻度で送信されます。

    VMware SD-WAN Edge に割り当てられた IP アドレスがサーバによって提供される有効なアドレス範囲から削除されると、クライアントは T2 時間に達するまでサーバに更新メッセージを送信し続けます。これにより、カスタマー ユーザーは大量の DHCPv6 トラフィックを確認することがあります。

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

  • 問題 56454：インターフェイスで IPv4 リンクと IPv6 リンクの両方を自動検出リンクとして設定すると、非優先リンクを介してトンネルが形成されます。リンク統計情報には、IPv4 および IPv6 リンクの統合情報は表示されません。

    インターフェイスに IPv4 と IPv6 の両方のオーバーレイが自動検出オーバーレイとして設定され、両方のリンク上でトンネルが形成されている場合、リンクの統計情報には優先リンクの状態のみが反映されます。非優先リンクのトラフィック情報や状態は正しく反映されません。その結果、帯域幅とスループットを含む [Edge] > [監視 (Monitoring)] ページのリンクに表示される統計情報は、優先 IP アドレス ファミリのみで形成されたトンネルのパフォーマンスを測定するためのガイドラインとして使用する必要があります。

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

  • 問題 57957：DPDK インターフェイスが「Autonegotiate=on」から「Autonegotiate=off」に変更された場合、Edge は KNI ドライバをアンロードし、Edge サービスの再起動シーケンス中にそのインターフェイスの Linux ドライバを（vc_dpdk.py から）ロードします。

    新しい Linux インターフェイスをロードして名前を付けた後、vc_dpdk.py は「set_interface_neg.py」を呼び出して自動ネゴシエーション設定を適用する必要もあります。ただし、新しい自動ネゴシエーション設定と Linux ドライバの再ロードにより、ベアメタル インターフェイスは DPDK で制御されなくなりました。

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

  • 問題 59970：プライマリ Gateway からセカンダリ Gateway に切り替えるときに、Zscaler IaaS を介して VMware SD-WAN Edge からデータセンターに送信されるトラフィックでドロップが確認されます。

    プライマリ Gateway が停止し、Orchestrator がセカンダリ Gateway に切り替わると、現在のトラフィック フローの Zscaler Enforcement Noted (ZEN) からのリバース パスが機能しません。

    回避策：回避策として、すべてのトラフィック フローを開始し直します。Zscaler はこの問題について通知を受け、リバース トラフィック パスが適切に機能していないことを確認しました。

  • 問題 61882：VMware SD-WAN Orchestrator からセキュリティ パラメータ設定の変更（たとえば、SA 有効期間の変更）が行われると、一定期間にわたってトラフィック ドロップが確認されます。

    これは、ハブ/スポーク トポロジに 1,000 台を超える Edge がある大規模な環境展開で確認されています。セキュリティ パラメータ（有効期間、暗号化アルゴリズム、認証モード）を変更すると、現在のトンネルが停止し、再構築されます。大規模な環境では、トラフィックの安定性の問題が発生する可能性があります。レスポンダ側（ハブ Edge）はすべてのトンネルを時間内に処理できず、トラフィック ドロップが発生する場合があります。最終的にトンネルが確立されますが、既存のトンネルの数によっては時間がかかる場合があります。

    回避策：既存のトンネル数に基づいた復旧時間が不明であるため、メンテナンス時間帯に設定変更を実行することをお勧めします。

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

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

    回避策：LAN サブネットごとに異なる外部 IP アドレスを使用します。

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

  • 問題 62725：BGP を使用するネットワーク内の VMware SD-WAN Edge では、特定のまれな条件下でメモリ使用率が高くなる場合があります。

    Edge がピア IP アドレスとは異なるネクスト ホップ IP アドレスを持つ BGP ルートを学習する場合、Edge のネクスト ホップ トラッキング (NHT) モジュールによって、ネクスト ホップの到達可能性が追跡されます。Edge 上で追跡された IP アドレスに到達できないときに BGP が無効になっていると、追跡された NHT エントリが削除されない場合があります。古い NHT エントリが大量にあるまれなケースでは、Edge のメモリ使用率が高くなることがあります。

    回避策：Edge を再起動して、メモリ リークが発生している NHT エントリを削除します。

  • 問題 62897：デバッグ コマンド tcpdump が、VMware SD-WAN Gateway で正しく機能しません。

    Gateway の eth0 または eth1 インターフェイスで tcpdump コマンドを実行すると正しく出力されません。tcpdump.sh と vctcdump も機能しません。修正が試みられ、tcpdump が vctcpdump の制限を継承できるようにする（tcpdump プロファイルに基づく）vctcpdump の AppArmor complain プロファイルが追加されましたが、tcpdump はまだ機能していません。基本的に、AppArmor は tcpdump に対する stdout の動作を停止します。これは AppArmor の既知の問題です。

    回避策：cat への tcpdump 出力をパイプ処理します。例：tcpdump -nnplei eth0 | cat

  • 問題 63125：VMware SD-WAN ハブ Edge のインターフェイス/リンクの MTU が増加しても、スポーク Edge のパス MTU にそれが反映されません（そのハブ Edge を持つパスの場合）。

    ユーザーがハブのインターフェイスまたはリンクの MTU を増やした場合、スポーク Edge パスは変更された MTU 設定を取得しません。

    回避策：スポーク Edge を再起動すると、増加した MTU がスポークのパス MTU に反映されます。

  • 問題 65885：Gateway 経由の Non SD-WAN Destination (NSD) をデプロイし、冗長 Gateway 設定を使用しているカスタマーの場合、プライマリ Gateway が停止すると競合状態になり、プライマリ Gateway の PG-BGP ピアシップが起動する前に、NSD は冗長 Gateway を介して学習したレガシー ルートをプライマリ Gateway にすでに広報しています。

    BGP マルチパスはサポートされていないため、プライマリ Gateway がハンドオフ インターフェイスを介して学習すべきルートは、NSD からデータセンターとして学習されているように見えます。これらは有効なルートですが、プライマリ Gateway が起動している場合、トラフィックは NSD > プライマリ Gateway > ハンドオフ インターフェイスを経由するため、この問題は発生すべきではありません。トラフィックは依然として宛先に到達するため、パフォーマンスの観点からはカスタマーへの影響はありませんが、カスタマーのネットワーク管理に悪影響を及ぼします。カスタマーは、トラフィックが 1 つのルートを経由することを想定しており、そのルートを管理するために QoS ポリシーをインストールしますが、トラフィックは、QoS ポリシーでは想定していない別のルートを経由しています。

    回避策：カスタマーは、Gateway 経由の Non SD-WAN Destination の送信ルートをフィルタリングして、冗長 Gateway を介して学習したルートをプライマリ Gateway に広報しないようにする必要があります。

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

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

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

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

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

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

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

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

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

  • 問題 74149：カスタマーが L7 健全性チェックが有効になっている Zscaler タイプのクラウド セキュリティ サービスを使用している場合、WAN リンクも停止しているときに VMware SD-WAN Edge が再起動すると、L7 健全性チェック プロセスは、Edge と WAN リンクの両方が完全にリストアされた後でも Zscaler サービスにプローブを送信しないことがあります。

    この問題には一貫性がなく、リストされた条件が満たされた場合でもまれにしか発生しません。Edge が再起動され、L7 健全性チェックが有効になっている場合、Edge WAN インターフェイスで「起動/停止」の状態移行が発生すると、Edge は再起動時と初期化時に L7 プローブの送信に失敗することがあります。

    回避策：この修正を適用しない場合、Edge で L7 プローブの送信を再開するには、L7 健全性チェックの切り替えを行う（オフにしてから変更内容を保存し、再度オンにして変更内容を保存する）必要があります。

  • 問題 76292：スポークとして設定された VMware SD-WAN Edge は、動的トンネルを形成した後でも、最適な BGP 属性を持つアップリンク ルートを優先しません。

    動的トンネルを介したアップリンク ルートがトラフィックの転送に使用された場合、カスタマーがこの動作の影響を受けることがあります。その場合、アップリンク ルートは機能せず、このルートのすべてのトラフィックはハブにルーティングされます。

    アップリンク ルートの目的は、ハブ Edge からブレークアウトするための特別なルートを作成することにあり、それ以外の場合には使用されません。これらは、VMware SD-WAN が他の VCRP ルートのように広報しない外部ルートです。これらは、ハブによってスポークにアドバタイズされます。つまり、スタティック トンネルを介してのみ通知されます。

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

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

    アクティブ Edge からスタンバイ Edge へのイベントが大量に発生すると、スタンバイ Edge 上の一部のスレッドが過負荷状態になり、ハートビート処理が遅延し、スタンバイ Edge が誤ってアクティブに昇格する可能性があります。アクティブ/アクティブ状態では、アクティブ Edge が実行され、スタンバイ Edge は再起動されて、適切なスタンバイ状態に降格されます。この問題が従来の HA トポロジで発生した場合、スタンバイ Edge はカスタマー トラフィックを渡さないため、カスタマーへの影響は最小限に抑えられます。拡張 HA 展開では、スタンバイ Edge もトラフィックを渡すため、再起動によって一部のカスタマー トラフィックが中断されます。

    このチケットでは、アクティブ Edge とスタンバイ Edge からのイベントをより効率的に処理し、また一部の無効なイベントがアクティブからスタンバイに同期されるのを回避することでイベントの数を最小限に抑えるように、Edge に対していくつかの最適化が行われます。

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

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

    HA フェイルオーバーで、OSPF 外部 LSA（リンク状態の広報）にルート タグがないため、ルーティングが正しく行われず、カスタマー トラフィックに悪影響を及ぼします。

    回避策：正しいルート タグを受信していない Edge で OSPF を再起動する必要があります。

  • 問題 81859：VMware SD-WAN Edge 610-LTE をアクティベーションすると、Edge のアクティベーション完了後に CELL インターフェイスが起動しないことがあります。

    この問題は一貫して発生するわけではありませんが、Edge 610-LTE の唯一のパブリック リンクがモバイル CELL リンクである場合にこの問題が発生すると多大な影響が及ぶ可能性があります。これにより、Edge が事実上停止状態になり、Edge の電源を入れ直してリカバリするためにローカルでの Edge に人が介在して操作を行う必要が生じます。

    回避策：この問題が発生し、610-LTE に他の有線パブリック WAN リンクがある場合、ユーザーは適切なメンテナンス期間中に [リモート アクション (Remote Actions)] > [サービスの再起動 (Service Restart)] を使用して、Orchestrator を介して Edge サービスを再起動するか、Edge のモデムを再起動して CELL インターフェイスをリストアする必要があります。

    610-LTE がインターネットに対して CELL インターフェイスのみを使用している場合、Orchestrator を介してアクセスできなくなるため、Edge のローカル ユーザーが Edge の電源を入れ直す必要があります。

    アクティベーション中の 610-LTE Edge がインターネットに対して CELL のみを使用している場合、アクティベーションの完了後にダウンした場合に電源を入れ直すため、Edge を他のユーザーと一緒にアクティベーションする必要があります。

  • 問題 82104：まれに、高可用性トポロジでアクティベーションされた VMware SD-WAN Edge が VMware SASE Orchestrator と通信できず、サイトが「ダウン」とマークされ、Orchestrator を介したサイトへの介入が妨げられることがあります。

    この問題は、異常で無効な設定が HA Edge に適用されている場合にのみ発生します。この設定では、HA ポートを（許可されない）「トランク」に設定し、VLAN をゼロにする（これも許可されない）ように指定しますが、実際には「すべての VLAN」が設定されています。Orchestrator は、この設定に対してエラーをスローし、ユーザーが Edge の HA を有効にするのを防ぐ代わりに、これを許可します。この設定によって HA Edge で管理プレーンの障害がトリガされるため、Orchestrator にハートビートが送信されなくなり、Orchestrator はサイトを「ダウン」としてマークします。

    回避策：上記の設定は使用しないでください。

  • 問題 84825：BGP が設定された高可用性トポロジを使用して展開されたサイトで、サイトに 512 個を超える BGPv4 の match/set ルールが設定されている場合、リカバリが実行されることなく HA Edge ペアが継続的にフェイルオーバーすることがあります。

    512 個を超える BGPv4 の match および set ルールがある場合は、カスタマーが受信フィルタと送信フィルタのそれぞれに 256 個を超えるこのようなルールを設定していることを意味します。フェイルオーバーが繰り返されると、音声通話などのリアルタイム トラフィックのフローが継続的にドロップされ、再作成されるため、この問題はカスタマーにとってサービスの中断となる可能性があります。HA Edge でこの問題が発生すると、Edge の CPU スレッドを同期するプロセスが失敗し、リカバリするために Edge が再起動されますが、昇格した Edge でも同じ問題が発生し、再起動されてもサイトでリカバリが行われません。

    回避策：この問題に対して修正を適用しない場合は、HA サイトに対して 512 個を超える BGPv4 の match および set ルールが設定されていないことを確認する必要があります。

    サイトでこの問題が発生しており、512 個を超える BGP/v4 の match および set ルールが設定されている場合は、サイトをリカバリするためにすぐにルールの数を 512 以下に減らす必要があります。

    または、512 個を超える BGPv4 の match および set ルールが必要な場合は、HA Edge をリリース 3.4.6 にダウングレードできます。ただし、この問題は発生しませんが、以降のリリースで導入された Edge 機能を使用することはできません。これは、Edge モデルが 3.4.6 でサポートされている場合にのみ実行できますが、ダウングレードする前に、そのことを確認する必要があります。

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

    TCP 経由で受信したデータに対するスタンバイ Edge の HA 制御データ同期処理ロジックにより、データが部分的にのみ読み取られることがあります。これにより、このような短いメッセージがスタンバイで複数回処理され、スタンバイ ノードの速度が低下する可能性があります。下位の Edge プラットフォーム（Edge モデル 510、520、610、620 など）では、この速度低下がアクティブとスタンバイ間のハートビート処理に大きな影響を与え、スタンバイ Edge が誤ってアクティブに昇格する可能性があります。アクティブ/アクティブ状態では、アクティブ Edge が実行され、スタンバイ Edge は再起動されて、適切なスタンバイ状態に降格されます。この問題が従来の HA トポロジで発生した場合、スタンバイ Edge はカスタマー トラフィックを渡さないため、カスタマーへの影響は最小限に抑えられます。拡張 HA 展開では、スタンバイ Edge もトラフィックを渡すため、再起動によって一部のカスタマー トラフィックが中断されます。 

    このチケットでは、Edge TCP メッセージ処理ロジックの機能が強化され、スタンバイ Edge のパフォーマンスが向上し、システムの速度低下を回避します。

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

  • 問題 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.x、4.5.x、および 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 を使用している場合：Gateway IP アドレスが指定されたルーティングされた LAN ポートのみを使用します。 

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

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

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

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

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

    回避策：Edge 経由の NSD を 1 つの WAN リンクに制限すると、この問題が発生する可能性が低くなります。

  • 問題 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 を電源に再接続します。

    プラットフォーム ファームウェアをアップグレードしない場合、ユーザーは 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 サービスの再起動をスケジュール設定して、メモリをクリアし、カスタマーへの影響を最小限に抑えるようにします。

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

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

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

  • 問題 91746：有線またはワイヤレスの 802.1x 認証（RADIUS、Cisco ISE など）を使用している VMware SD-WAN Edge で証明書の認証が失敗し、この認証を必要とするすべてのトラフィックが Edge でドロップすることがあります。

    この問題は、Edge による IP 断片化パケットの L4 ヘッダーの変更が不適切で、Edge を終了する前にパケットが破損することが原因で発生します。これは主に UDP パケットに影響し、これらのパケットは 802.1x 証明書認証に使用されるため、802.1x 有線クライアントまたはワイヤレス クライアントが失敗する可能性があります。

    回避策：この問題が発生した Edge では、a) 802.1x 認証を無効にする、または b) この問題が存在しておらず、802.1x 認証が正常に機能していた、以前の Edge ソフトウェア ビルドに Edge をロールバックすることが回避策となります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)] ページに表示されません。フェイルオーバーにより、この問題は解決されます。

  • 問題 35667：

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

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

  • 問題 35658：

    あるプロファイルから CSS 設定が異なる別のプロファイルに VMware SD-WAN Edge が移動されたときに（例：プロファイル 1 は IPsec で、プロファイル 2 は GRE）、Edge レベルの CSS 設定が、以前の CSS 設定（例：IPsec と 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 のデータプレーン サービスの障害を引き起こす可能性があります。

  • 問題 41691：

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

  • 問題 43276：

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

  • 問題 47820：

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

  • 問題 48085：

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

  • 問題 49225：

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

  • 問題 50531：

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

    注：

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

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

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

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

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

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