VMware SD-WAN バージョン 4.3.2 | 2022 年 11 月 30 日

  • VMware SD-WAN™ Orchestrator バージョン R432-20221108-GA

  • VMware SD-WAN™ Gateway バージョン R432-20221115-GA

  • VMware SD-WAN™ Edge バージョン R432-20221115-GA

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

リリース ノートの概要

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

対象ユーザー

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

重要:

リリース 4.3.2 には、4.3.0 または 4.3.1 リリース ノートに記載されているすべての Edge、Gateway、および Orchestrator の修正が含まれています。

互換性

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

注:

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

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

Orchestrator

Gateway

Edge

ハブ

ブランチ/スポーク

4.3.2

3.4.1

3.4.4

3.4.4

4.3.2

4.3.2

3.4.4

3.4.4

4.3.2

4.3.2

4.3.2

3.4.4

4.3.2

4.3.2

3.4.4

4.3.2

4.3.2

3.4.1

3.4.6

3.4.6

4.3.2

4.3.2

3.4.6

3.4.6

4.3.2

4.3.2

4.3.2

3.4.6

4.3.2

4.3.2

3.4.6

4.3.2

4.3.2

4.2.2

4.2.2

4.2.2

4.3.2

4.3.2

4.2.2

4.2.2

4.3.2

4.3.2

4.3.2

4.2.2

4.3.2

4.3.2

4.2.2

4.3.2

4.3.2

4.3.1

4.3.1

4.3.1

4.3.2

4.3.2

4.3.1

4.3.1

4.3.2

4.3.2

4.3.2

4.3.1

4.3.2

4.3.2

4.3.1

4.3.2

4.3.1

4.3.2

4.3.1

4.3.1

4.3.1

4.3.2

4.3.2

4.3.1

4.3.1

4.3.2

4.3.1

4.3.2

5.0.1.0

4.3.2

4.3.2

4.3.2

4.5.1

4.3.2

4.3.2

4.3.2

注:

注:リリース 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 および 4.2.x はサポート終了に近づいています。

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

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

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

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

重要な注意事項

高可用性での 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)を参照してください。

ドキュメントの改訂履歴

2022 年 11 月 16 日。第 1 版

2022 年 11 月 22 日。第 2 版

  • Edge ビルドを R432-20221109-GA から R432-20221115-GA に更新しました。Edge ビルド R432-20221109-GA は誤って最初の Edge GA ビルドとしてリストされていました。

  • Edge バージョン R432-20221109-GA の「Edge/Gateway で解決した問題」セクションに修正された問題 #51486 を追加しました。この問題は、元のエディションから誤って省略されました。

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

Edge/Gateway で解決した問題

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

Edge および Gateway バージョン R432-20221115-GA はともに 2022 年 11 月 16 日にリリースされ、Edge/Gateway バージョン R431-20220608-GA 以降の次の問題が解決されました。

注:

リリース 4.3.2 には、4.3.0 または 4.3.1 リリース ノートに記載されているすべての Edge および Gateway の修正が含まれています。

  • 解決した問題 34234:VMware SD-WAN Edge 上の WAN リンクでは Orchestrator ユーザー インターフェイスに誤った帯域幅キャパシティ値が表示されることがあり、WAN リンクが実際の帯域幅キャパシティに使用されていないことが確認される場合があります。

    この問題があると、WAN リンクは、指定された頻度で最新の帯域幅キャパシティの値に対して再測定されません。これは、WAN リンクでトンネルの破棄/構築(フラップなど)が発生するたびに、サービスが帯域幅値キャッシュの日付をリセットすることが原因で発生します。キャッシュされた帯域幅の値がリセットされるため、SD-WAN サービスはこれが新しい値であり、追加の帯域幅テストは必要がないと誤解します。トンネル フラップが頻繁に発生する WAN リンクでは、この WAN リンク帯域幅の値がかなり古く、現在の WAN リンク帯域幅の値をまったく表していない可能性があります。これにより、SD-WAN サービスが WAN リンクを実際のキャパシティまで使用しないため、カスタマー トラフィックの問題が発生します。

  • 解決した問題 35807:インターフェイスが無効になっていて、VMware SD-WAN Orchestrator から再度有効になると、DPDK ルーテッド インターフェイスが完全に無効になります。

    ルーティングされたポートを無効にすると、DPDK 制御ハードウェアからネットワーク デバイスのバインドが解除され、Edge サービスが再起動した後に Edge の Linux ドライバに再バインドされます。Edge の DPDK ファイルが更新され、このインターフェイスが削除されます。再度有効にした場合、ファイルは Linux からバインド解除し、DPDK 制御ドライバに再バインドするように更新されません。

    この修正が適用されていない Edge で問題を修正する方法は、Edge を再起動して状態をクリアし、デフォルトの起動状態に戻してデバイスを Edge の DPDK レイヤーに再度追加することです。

  • 解決した問題 37813:拡張された高可用性トポロジを使用しているカスタマー サイトの場合、リモート診断の「インターフェイスの状態」を実行すると、スタンバイ Edge のインターフェイスに速度と自動ネゴシエーションが表示されません。

    アクティブ ロールの VMware SD-WAN Edge は、インターフェイスが起動しているスタンバイ Edge から速度と自動ネゴシエーションの詳細を取得しないため、詳細を表示できません。

  • 解決した問題 45545:VMware SD-WAN Edge のインターフェイスの SNMP ポーリングの情報が正確でない可能性があります。

    SNMP MIB-IF に対する Edge のプロセスでは、Linux OS からインターフェイス統計情報を取得しますが、debug.py --interfaces コマンドを実行してインターフェイス統計情報を取得することもできます。debug.py --interfaces コマンドは常に正確なインターフェイス情報を提供しますが、Linux の結果が正確でない可能性があります。

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

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

  • 解決した問題 49165:GCP (Google Cloud Platform) に展開された VMware SD-WAN 仮想 Edge の場合、インターフェイスで [広報 (Advertise)] オプションがオンになっていると、DHCP 対応のコネクト ルートが広報されません。

    GCP タイプの仮想 Edge でコネクト ルートを設定した後、プレフィックスがオーバーレイ フロー制御 (OFC) に存在せず、そのルートのトラフィック フローが破損していることをユーザーが確認することがある。

    この修正を適用していない仮想 Edge では、唯一の回避策として、ローカルで設定されたインターフェイスにスタティック ルートを設定し、インターフェイスで [広報済み (Advertised)] チェックボックスをオンにし、ルートを広報します。

  • 解決した問題 50920:接続されたトンネルの数が、当該 Edge モデルで定義されているハードウェア制限の 60% に達したときに、VMware SD-WAN Edge が警告を送信しません。

    接続されたトンネルの数がそのハードウェア制限に達すると、Edge は「確立されたトンネル数がデバイス容量を超えています (Established tunnel count exceeds the device capacity)」という警告を送信します。この制限に達すると、Edge は既存のトンネルが破棄されるまで、追加の動的トンネルを許可しません。ただし、このトンネル制限に達する可能性があることをカスタマーに警告する中間警告は送信されないため、カスタマーにはネットワークを管理するための十分なリードタイムがありません。

  • 解決した問題 51036:Edge インターフェイスが DPDK を使用するように設定されている場合、SNMP 経由で VMware SD-WAN Edge をポーリングするときに ifStats が誤った値を報告します。

    これは、ハードウェアと仮想 Edge の両方で DPDK が設定されたポートで想定される動作です。DPDK が設定されたポートの速度値を取得する唯一の方法は、debug.py --dpdk_ports コマンドを使用することです。ただし、Edge の SNMP モジュールは、DPDK が設定されたポートの速度値を抽出する際にこのコマンドに依存しません。SNMP は Edge の Linux カーネル インターフェイス経由でのみクエリを実行しますが、残念ながら dpdk_ports の速度値は入力されません。この問題を修正した Edge ビルドでは、SNMP は debug.py --dpdk_ports コマンドを使用して DPDK が設定されたポートの統計情報を収集します。

  • 解決した問題 51486:ループバック インターフェイスを使用して VMware SD-WAN Edge に SSH 接続することができません。

    管理インターフェイスを削除し、Edge にループバック インターフェイスを導入した後、Edge 仮想インターフェイス(常に稼動中)への SSH 接続はサポートされません。

    Edge リリース 4.3.2 以降では、ユーザーはループバック インターフェイスを使用して Edge に SSH 接続できます。

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

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

  • 解決した問題 63577:Zscaler タイプのクラウド セキュリティ サービス (CSS) を使用しているカスタマー エンタープライズの場合、プライマリ トンネルがダウンし、トラフィックがセカンダリ トンネルにフェイルオーバーしてからプライマリ トンネルが復旧した場合、セカンダリ トンネルのトラフィックはすぐにプライマリ トンネルに戻ります。

    このシナリオでは、Zscaler プライマリ トンネルが復旧すると、プライマリ トンネルにフェイルバックする前に、セカンダリ トンネル上の既存のフローが少なくとも 30 分間維持されることを想定しています。この問題では、既存のフローはプライマリ トンネルの復旧後にすぐにフェイルオーバーします。この動作は、IPsec と GRE を含むすべてのトンネル タイプで有効です。

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

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

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

    この問題はまれに発生しますが、Gateway がルート クリーンアップ プロセスを実行し、想定されていなかった null 値を持つローカル AS 文字列が発生するとトリガされます。

  • 解決した問題 68335:ハブがクラスタであるハブ/スポーク トポロジを使用しているカスタマー エンタープライズの場合、ハブ クラスタに接続できない VMware SD-WAN スポーク Edge が、SD-WAN 制御トラフィックとして分類される大量の帯域幅を消費する可能性があります。

    スポーク Edge がデータセンター ハブ クラスタとのオーバーレイを確立できない場合、Edge はコントローラに別のクラスタ メンバーの再割り当てを要求するため、コントローラは継続的に制御イベントを送信することになり、リンク帯域幅を消費します。

    この修正が適用されていない Edge で、この問題を回避するには、到達不能なハブ クラスタをプロファイルに割り当てずに、一時的なプロファイルを作成して割り当てます。

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

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

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

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

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

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

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

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

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

  • 解決した問題 71785:リリース 4.3.0 以降を実行している Edge で SNMP ウォークが適切に機能しないことがあります。

    Edge をリリース 4.3.0 にアップグレードすると、SNMP が使用する一部の IP アドレスがブロックされ、ポート 161 でトラフィックを許可するようにファイアウォール設定を変更する必要があります。 

  • 解決した問題 71788:高可用性トポロジを使用して展開されたカスタマーの場合、カスタマー トラフィックの中断を含む予期しない HA フェイルオーバーがサイトで発生する可能性があります。

    これは一貫性のない問題であり、すぐには再現されませんが、この問題が発生すると、HA Edge の定期的なハンドラ スレッドがアクティブ Edge とスタンバイ Edge 間のフロー同期中に 180 ミリ秒を超えて実行されます。これにより、デッドロックが発生して、アクティブ Edge の mutex mon スレッドで SIGKILL メッセージがトリガされ、その結果、コアが発生して、Edge が再起動します。

  • 解決した問題 71977:VMware Edge Network Intelligence を使用しているカスタマーの場合、VMware SD-WAN Edge で分析を有効にすると、複数のデータプレーン サービスの障害が発生し、その障害ごとに Edge サービスが再起動することがあります。

    この問題は、Edge で動的に作成されたセッション数が最大許容数を超えているときに、ユーザーが分析を有効にするとトリガされます。サービスの障害によってカスタマーのトラフィックが中断され、障害が 3 回連続して発生すると、その Edge ではデータプレーン サービスがシャットダウンされます。カスタマー トラフィックは引き続き通過し、Orchestrator を介して Edge を設定できますが、カスタマー トラフィックには Dynamic Multipath Optimization (DMPO) のメリットはありません。DMPO がないことにより、トラフィックの優先順位付け、リンク ステアリング、またはエラー修正が行われないため、カスタマー トラフィックの品質が影響を受ける可能性があります。

    データプレーン サービスをリカバリするには、ユーザーが Edge を再起動する必要があります。この操作は、[リモート アクション (Remote Actions)] > [Edge の再起動 (Reboot Edge)] を使用して Orchestrator から実行できますが、実行することでカスタマー トラフィックの中断がさらに 2 ~ 3 分続くため、メンテナンス期間中にのみ実行する必要があります。

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

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

  • 解決した問題 72270:高可用性で展開された Edge の場合、ファームウェア アップグレードを含むソフトウェア アップグレードを行うと、HA Edge が予期せずにアップグレードと再起動を同時に実行し、カスタマー トラフィックの中断と OSPF または BFD ルートの学習がトリガされる場合があります。

    これは、CPLD ファームウェア アップグレードを含むビルドにアップグレードする Edge 3x00 モデルに当てはまります。設計上、スタンバイ Edge は最初にアップグレードしてから、アクティブにフェイルオーバーし、アクティブがアップグレードできるようにしますが、アクティブはフェイルオーバーを待機しているか、フェイルオーバーがない場合は、アップグレード前に 5 分間の遅延が発生します。スタンバイ Edge は、OS カーネルを含むファームウェアもアップグレードします。これには 5 分以上かかる場合があり、スタンバイ Edge とアクティブ Edge の両方が同時にアップグレードおよび再起動し、カスタマー トラフィックが中断し、それ自体中断している OSPF または BFD ルートの再学習を強制するシナリオが発生します。この修正により、スタンバイのタイマーが延長され、一度に 1 つの Edge のみがアップグレードされるようになります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    この問題は、高可用性フェイルオーバーの後で、新しく昇格したアクティブ Edge でのトークン エラーが原因で発生する可能性があり、その結果 Orchestrator へのハートビート障害が発生します。ハートビートがないと、Orchestrator は Edge をダウンしているとしてマークし、Orchestrator への接続がリストアされるまで、ユーザーはこの HA Edge に対していかなる設定の変更もプッシュすることができませんでした。

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

  • 解決した問題 74306:VMware SD-WAN Edge の背後で Skype 通話を行うユーザーの場合、通話品質が予想よりも低くなる可能性があります。

    デフォルトでは、VMware SD-WAN サービスは、通話パケットを含むすべての Skype パケットと MS Teams パケットを APP_CLASS_INTERNET_INSTANT_MESSAGING (10) クラスに分類します。インスタント メッセージ クラスの優先度は低いため、通話の帯域幅とリンク品質の優先度が下がり、通話に影響を与える可能性があります。この修正により、Skype と MS Teams に一致するパケットが APP_CLASS_BUSINESS_COLLABORATION (5) に変更されます。これは、通話が期待された高優先度/リアルタイム品質レベルの処理を受けることを意味します。

    この修正を適用しない場合の回避策は、アプリケーション マップをカスタマイズして、Skype と MS Teams がビジネス コラボレーションとして分類されるようにすることでした。

  • 解決した問題 75186:VMware SASE Orchestrator または VMware SD-WAN Gateway でソフトウェア ボンディングが設定されている場合、ボンディング インターフェイスの MAC アドレスがシステム全体で一意でないため、ネットワークにおいて MAC アドレスの競合が発生する可能性があります。

    この問題は、ソフトウェア ボンディングが有効になっている同じサブネット上にシステムが展開されている場合にのみ発生します。ソフトウェア ボンディング インターフェイスの MAC アドレスは、/etc/machine-id から取得されます。このファイルは、リリース 4.2.1 より前のバージョンの Orchestrator および Gateway での展開中にはランダム化されません。

    4.2.1 より前のソフトウェア イメージの同じサブネット上に展開されたシステムで Orchestrator または Gateway のソフトウェア ボンディングを使用している場合の解決方法については、VMware のサポートにお問い合わせください。

  • 解決した問題 75578:リモート診断の「インターフェイスの状態 (Interface Status)」を実行すると、高可用性が有効になっているインターフェイスの速度とモードが出力に表示されません。

    リモート診断のインターフェイスの状態に、HA が有効になっているインターフェイスの速度とモードが表示されません。2 台の Edge を接続する HA インターフェイスは、通常、ほとんどの Edge プラットフォームで GE1 です。

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

    ログに、de2e_info_reply_msg_recieved で Gateway プロセスの失敗が示されます。根本原因は、Gateway プロセスで処理されない NULL ポインタ例外で、これにより、例外がトリガされ、サービス障害と再起動が発生することです。

  • 解決した問題 75890:VMware SD-WAN スポーク Edge のループバック IP アドレスは、これらのハブ Edge とスポーク Edge の間にパスがない場合でも、データセンターのハブ Edge を介して地域ハブ Edge において約 2 分間到達可能として表示されます。

    ルートは 2 分間 true のままで、2 分間が経過したらにピア到達不能ルートのクリーンアップの一部として最終的にクリーンアップされます。これはループバック IP アドレスでのみ発生し、他のすべてのスポーク Edge IP アドレスはこのシナリオでは False として正しくマークされます。

  • 解決した問題 75989:VMware SD-WAN Gateway の Telegraf エージェントが、vcg_metrics.sh から収集されたメトリックのエクスポートに失敗することがあります。

    Gateway の Telegraf ログに、指定されたタイムアウト時間内にスクリプトを実行できなかったことを意味する vcgCommand timeout エラーが表示されます。

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

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

  • 解決した問題 76140:Non SD-WAN Destination (NSD) と Partner Gateway の両方に接続されている VMware SD-WAN Edge でデータプレーン サービスの障害が発生し、サービスをリカバリするために再起動する可能性があります。これにより、カスタマーのトラフィックが短時間中断する場合があります。

    プレフィックスのルートを NSD と Partner Gateway の両方から取得できるカスタマー エンタープライズ トポロジでは、NSD と Partner Gateway の間にタイミングの問題が発生し、Edge サービスが失敗して再起動する原因となる例外が発生する可能性があります。

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

    Edge が多数のルート(例:約 2 万個のルート)を持っているエンタープライズの一部である場合、診断バンドルが収集されると、ログの生成プロセス中に Edge CPU が枯渇し、それが原因のサービス障害による再起動が発生することがあります。

  • 解決した問題 76173:AWS ベースの VMware SD-WAN Virtual Edge を使用しているカスタマーの場合、Virtual Edge を再起動または再開すると、接続されたルートが見つからないため、カスタマーのトラフィックに影響を与える可能性があります。

    ルートが Edge の FIB(転送情報ベース)に表示されないため、カスタマーのトラフィックに大きく影響します。これはタイミングの問題が原因で発生します。AWS ベースの Edge を再起動または再開して起動すると、接続されているすべてのルートでインターフェイスが使用可能になる前に netlink メッセージが表示され、その結果、接続されたルートが失われます。

  • 解決した問題 76196:VMware SD-WAN Edge 上の WAN リンクでは Orchestrator ユーザー インターフェイスに誤った帯域幅キャパシティ値が表示されることがあり、WAN リンクが実際の帯域幅キャパシティに使用されていないことが確認される場合があります。

    WAN リンク帯域幅の測定には、この問題に関連する 2 つの主要なデフォルト動作があります。1 つ目は、WAN リンク帯域幅テストの結果が現在の帯域幅の値の 90% 未満である場合、測定値がアノマリではなく、実際に新しい小さい値であることを確認するために、Edge は 2 番目のテストを自動的にトリガします。もう 1 つは、WAN リンク帯域幅テストが失敗した場合(何らかのリンクが不安定なためテストが完了しない場合)、リンクの不安定性が解消されたときに、後で帯域幅テストが再スケジュールされます。

    ここでの問題は、帯域幅テストが失敗し、後で新しいテストが再スケジュールされ、そのテストが現在の値の 90% 未満の結果を返した場合、Edge はこの新しい小さい値の有効性を確認するための再テストをトリガしないことです。その結果、リンクの実際のキャパシティを表していない低い WAN リンク値になる可能性があります。結果として、SD-WAN サービスはリンクを実際よりも少ないキャパシティとして扱うため、カスタマー トラフィックの問題が発生します。

  • 解決した問題 76315:オペレータ ユーザーが VMware SD-WAN Gateway が送信するすべてのフローで最初の数パケットのドロップを観察する場合があります。

    ドロップの理由は、gwrouting_vpn_unreachable と表示されます。この問題は、管理プロトコルの QoS(サービス品質)同期メッセージの処理遅延が原因で発生します。これにより、すべてのフローの最初の数パケットが誤って分類されてドロップされます。

  • 解決した問題 76586:ハブ/スポーク トポロジを使用している場合、WAN オーバーレイが有効になっているインターフェイスのハブ Edge から応答を受信すると、VMware SD-WAN スポーク Edge が「ダイレクト (Direct)」から「Gateway」に移行し、フローが停止することがあります。その結果、そのフローのカスタマー トラフィックは中断します。

    これは、カスタマーの目的が、固定リンク ビジネス ポリシーを介した転送パス上のアンダーレイ(WAN オーバーレイなしの MPLS)経由で、またはリバース パスのオーバーレイ(ハブ Edge)経由でフローを非対称にルーティングすることであるシナリオです。

    このフローが停止する原因は、リモート エンドのルートがハブ Edge(オーバーレイ)を介して応答すると、リモート Edge がそのフローを新しいローカルで開始されたフローと見なし、QoS 同期要求を送信してフロー ルーティング パラメータを更新することです。これは、フロー ルーティングでの中断の発生につながります。設定済みのリンク モードが上書きされないように、QoS 同期要求は拒否されます。

  • 解決した問題 76589:LAN 側で障害が発生した後、VMware SD-WAN Edge クラスタでスポーク Edge の再調整が実行されないことがあります。

    ハブ クラスタは、ハブ クラスタ上の IPv4 または IPv6 BGP ネイバーシップのいずれかで LAN 側に障害が発生した後、他のすべてのハブ クラスタのスポーク Edge に関する不正確なデータを取得するハブがあるために、スポーク Edge の再調整を実行できない場合があります。

  • 解決した問題 76661:高可用性トポロジを使用して展開されたサイトの場合、VMware SD-WAN HA Edge がアクティブ/アクティブ状態になり、Orchestrator との接続が失われ、サイトがダウンとしてマークされることがあります。

    この問題は、両方の HA Edge の WAN オーバーレイ インターフェイスで Orchestrator へのデフォルト ルートが削除され、両方の Edge で送信元ルートのリバース パス フォワーディング (RPF) の障害が発生することに起因します。これにより、Edge からサイトに到達している管理トラフィックがないため、Orchestrator はサイトをダウンしているとマークします。また、両方の HA Edge がともに他方の Edge がダウンしていると見なすため、アクティブ/アクティブ状態を引き起こします。

    Edge に修正が適用されていない場合にこの問題を修正する唯一の方法は、両方の Edge を再起動して Orchestrator へのデフォルト ルートをリストアすることです。

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

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

  • 解決した問題 76864:VMware SD-WAN Edge が、「edged サービス」が無効であることを示す Edge イベントでトラフィックの通過を停止する場合があります。

    edged サービスは、カスタマーのトラフィックに関連している、Edge のデータプレーン サービスです。この問題では、設定の変更が原因で Edge データプレーン サービスが再起動する期間中に 3 回連続して失敗した後、サービスが無効になります。この期間において、子プロセスは、再初期化された親プロセスが必要とする Huge Page への参照を保持します。Edge がこの状態にあるときに、Edge をリカバリするには、再起動/電源の入れ直しが唯一の方法です。

  • 解決した問題 77357:日本で展開されている VMware SD-WAN Edge 3400 または 3800 が、何もしていないのにロック アップして再起動することがあります。

    Edge 3400 および 3800 では、システムのベースボード管理コントローラ (BMC) に正しくない電圧警告しきい値 (100V) が設定されており、これが日本の 100V 電源に一致しています。この領域での Edge 3400 または 3800 の結果は、連続した一連の電源アラームです。アラームの回数が頻繁になると、Edge がロックして再起動します。

    注:

    これは Edge の問題 51291 のフォローアップです。この問題は、リリース 3.4.5、4.0.1、4.2.0、およびすべてのバージョンの 4.3.x で修正されました。この修正により問題の解決に成功しましたが、手動で設定した電圧しきい値が CPLD アップグレードによってクリアされたため、修正は持続しませんでした。症状と説明は同じですが、ここでの修正により、後続の Edge アップグレードで電圧しきい値が維持されます。

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

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

    注:

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

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

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

  • 解決した問題 77732:デュアル トランスポート レイヤー(インターネット + MPLS)を使用する拡張高可用性トポロジで展開されたサイトでは、スタンバイ Edge のサブインターフェイスに接続されたリンクのパブリック IP アドレスは表示されません。

    IPv4 管理トンネルの場合、送信元 IP アドレスは 0.0.0.0 に設定されています。これは、誤った HA インターフェイスの FSM (Finite State Machine) アクションが原因です。具体的には、HA の wait_for_peer タイマーが期限切れになると、インターフェイスの同期情報を適用して、スタンバイ Edge から発生した IP アドレス更新イベントがあるかどうかを判断し、IP アドレス/ネクスト ホップに変更がない場合でも IP アドレスを更新するため、この問題が発生します。 

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

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

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

  • 解決した問題 78212:VMware SD-WAN Gateway でルート サマリ デバッグ コマンド debug.py --rsummary を実行すると、BGP ルート数の表示が不正確になることがあります。

    カスタマー エンタープライズでブランチ間 VPN が無効になっている場合、VMware SD-WAN Edge からの BGP ルートが Gateway から取り消されます。しかしながら、Gateway は、ルート テーブルから削除されたルートを含めた BGP ルート数をデバッグ コマンド debug.py --rsummary に表示します。

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

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

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

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

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

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

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

  • 解決した問題 78637:VMware SD-WAN Gateway で、SIGXCPU メッセージとともにデータプレーン サービスの障害が発生し、その結果サービスが再起動することがあります。

    Gateway もコアを生成します。この問題は、オプションの TLV 長を 0 としてパケットを受信すると、Gateway が無限ループに陥り、SIGXCPU とそれに伴うサービスの再起動とコアが発生することに起因しています。

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

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

  • 解決した問題 79437:Intel X710 NIC を使用してサーバー上に展開した VMware SD-WAN Gateway で、インターフェイスの SR-IOV が有効になっていると展開が失敗することがあります。

    この問題が発生すると、オペレータは、DPDK から X710 SR-IOV インターフェイスが削除されていることと、debug.py --dpdk_ports_d を実行しても表示されないことを確認できます。さらに、/opt/vc/etc/dpdk.json は SR-IOV インターフェイスを表示しません。Gateway を 4.3.2 リリースに展開することにより、この問題は発生しなくなります。

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

    この問題は、スタンバイ Edge でのみ発生し、アクティブ Edge では発生しません。この問題は、パイプライン内でまだパケットが処理中の間に詳細なパケット インスペクション エンジンがクリーンアップを呼び出したときの競合状態により発生します。これは、いつでも発生する可能性があります。

    スタンバイ Edge はトラフィックを渡さないため、標準の HA 設定を使用しているユーザーには影響はありませんが、拡張 HA 展開ではスタンバイ Edge もトラフィックを渡すため、スタンバイ Edge サービスを再起動すると、スタンバイを通過するカスタマー トラフィックが約 15 秒間中断されます。 

  • 解決した問題 80068:VMware SD-WAN Edge でデータプレーン サービスの障害が発生し、リカバリするために再起動すると、10 ~ 15 秒、カスタマーのトラフィックが中断することがあります。

    この問題は、BGP ネイバー ルートが解放される必要があるがロックされていて、Edge サービスで例外をトリガする BGP を使用しているカスタマー エンタープライズで発生する可能性があります。

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

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

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

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

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

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

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

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

  • 解決した問題 81196:ユーザーが工場出荷時のデフォルト パスワードを使用して、無効化された VMware SD-WAN Edge のローカル ユーザー インターフェイスにログインできません。

    ユーザーは、ローカル ユーザー インターフェイスで [設定のリセット (Reset Setting)] > [設定のリセット (Reset Configuration)] を使用するか、VMware SASE Orchestrator で Edge の [リモート アクション (Remote Actions)] > [Deactivate (アクティベーション解除)] を選択して、Edge を「アクティベーション解除」できます。ユーザーが Edge を「無効化」した後、すべての設定がクリアされ、ローカル ユーザー インターフェイスのログイン認証情報がデフォルト値に戻るはずですが、そうではありません。認証情報はアクティベーション解除前と同じままであり、ユーザーがローカル ユーザー インターフェイスのデフォルト認証情報を他の値に変更した場合、その新しい値は Edge のアクティベーション解除後も維持されます。ローカル ユーザー インターフェイスの認証情報が更新されなかった場合、アクティベーション解除の前後の認証情報はデフォルトのままであるため、この問題はありません。

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

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

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

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

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

    Edge にこの問題の修正が適用されていない場合の HA サイトでは、正しいルート タグを受信していない Edge で OSPF を再起動する必要があります。

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

    この問題は一貫して発生するわけではありませんが、Edge 610-LTE の唯一のパブリック リンクがモバイル CELL リンクである場合にこの問題が発生すると多大な影響が及ぶ可能性があります。これにより、Edge が事実上停止状態になり、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 を他のユーザーと一緒にアクティベーションする必要があります。

    回避策:この問題が発生し、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 への管理トラフィックを中断することなく、HA Edge ペアでこの無効な設定が機能するようになります。

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

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

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

  • 解決した問題 82188:VMware SD-WAN LTE モデル(Edge 510-LTE、610-LTE)の場合、IPv6 設定をオフに切り替えると、CELL インターフェイス経由のトンネルが失敗することがあります。

    • [デバイス設定 (Device Settings)] の [IPv6] チェックボックスをオフにすると、CELL インターフェイスの内部状態が「不明 (UNKNOWN)」になります。これは、CELL インターフェイスの IPv6 設定がオンに切り替えられても更新されません。このため、CELL インターフェイス経由のトンネルは失敗します。LTE Edge がトラフィックに CELL インターフェースのみを使用している場合は、これにより Edge がオフラインになり、Edge トラフィックがすべてドロップして、カスタマーに大きな混乱をきたす可能性があります。

      この修正を適用しない場合、ユーザーは IPv6 設定をオフにした後、Edge サービスを再起動する必要があります。Edge が帯域幅のために CELL インターフェースのみを使用していることによりオフラインになっている場合、ローカル ユーザーは Edge をリカバリさせるために Edge の電源入れ直しを行う必要があります。

  • 解決した問題 82432:VMware SD-WAN Edge でデータプレーン サービスの障害が発生し、リカバリするために再起動すると、カスタマーのトラフィックで 10 ~ 15 秒の中断が発生することがあります。

    (RADIUS トラフィックで見られるように)常に多数の断片化されたパケットを処理する場合、Edge のサービスに障害が発生することがあります。これらの断片化されたパケットは、断片化されたパケットを処理するために割り当てられたメモリを超えてしまい、Edge サービスで例外をトリガする可能性があります。

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

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

  • 解決した問題 83040:Partner Gateway と Non SD-WAN Destination (NSD) の両方を使用するハブ/スポーク トポロジを使用しているカスタマー エンタープライズにおいて、NSD を使用すべきトラフィックがハブを使用している場合があります。

    スポーク Edge には、NSD にトラフィックをバックホールするビジネス ポリシーがあり、Partner Gateway のハンドオフも設定されている場合、スポークは、NSD を使用する必要があるトラフィックを代わりにハブ Edge に送信します。それに対し、ハブはトラフィックをインターネットに直接送信します。Partner Gateway ハンドオフが無効になっている場合、この NSD トラフィックは適切にルーティングされます。

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

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

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

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

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

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

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

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

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

  • 解決した問題 84439:VMware SD-WAN Edge 上の Partner Gateway ルートにセキュア フラグ(「S」フラグとも呼ばれる)がない場合があります。

    同じサブネット ルートが [Partner Gateway] ページから設定されており、[Partner Gateway ハンドオフ (Partner Gateway Handoff)] ページでも設定されている場合、Edge へのルートの広報に一貫性がなくなる可能性があります。たとえば、セキュアなスタティック ルートが使用可能な場合でも、優先されていない非セキュア ルートを広報します。

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

    Edge (Authenticator) から RADIUS または ISE サーバに送信される RADIUS または ISE パケットでは、NAS IP アドレスがデフォルトでループバック IP アドレスとして設定されているため、認証パケットが NAS に到達せず、認証に失敗する可能性があります。

    この問題を修正するには、この修正を適用したビルドで、NAS IP アドレスを、802.1x 認証設定を使用して選択および設定された送信元インターフェイス IP アドレスとして設定します。送信元インターフェイスとして [自動] が選択されている場合、ループバック IP アドレスはデフォルトで NAS IP アドレスとして設定されます。

  • 解決した問題 84741:[監視 (Monitor)] > [トランスポート (Transport)] 画面で、不正確なスループット統計が表示されます。

    WAN オーバーレイでリバース パス フォワーディング (RPF) が無効になっているインターフェイスで直接送信されるトラフィックの場合、RX(受信)パケットとリンク統計情報は Orchestrator にインクリメントされません。

  • 解決した問題 84790:VMware SD-WAN Edge を再起動したときに、Edge は誤って重大イベント「サービス wifihang を起動できません (Unable to launch service wifihang)」を VMware SASE Orchestrator に報告してしまいます。

    このエラーにより、プロセスが正常に機能している場合でも、Edge の Wi-Fi に問題があるとカスタマーが誤認する可能性があります。この問題が発生しない Edge モデルは Edge 510 および Edge 6x0 モデルのラインで、それ以外のすべてのモデルはこの問題の影響を受けます。

  • 解決した問題 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 でサポートされている場合にのみ実行できますが、ダウングレードする前に、そのことを確認する必要があります。

  • 解決した問題 84828:VMware SD-WAN Edge でデータプレーン サービスの障害が発生し、リカバリするために再起動すると、カスタマーのトラフィックが 10 ~ 15 秒中断することがあります。

    Edge は SIGXCPU イベントでコアを生成します。この問題は、Edge がコマンドの実行のタイムアウト値を超えた場合に発生します。これにより、ミューテックス監視はスレッドが停止していると断定し、コアをトリガして再起動します。VMware サポート エンジニアは、ミューテックス監視のタイムアウト値を増やすことができますが、Edge サービスは増加した値を考慮しません。

  • 解決した問題 85154:AWS 上のインスタンス タイプが C4.xlarge の VMware SD-WAN 仮想 Edge を古い Edge リリースからより新しいリリース(リリース 4.3.1 も対象)にアップグレードしてから、古い Edge リリースにダウングレードすると、Edge はアクティベーション解除済み状態になり、Gateway と Orchestrator で管理トンネルを形成しません。

    この問題の原因は、Orchestrator がシリアル番号の不一致として検出したために、誤って Edge をアクティベーション解除したことです。

    AWS 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 がこの問題に対する修正が適用されていないビルドを使用する場合、この問題の回避策は、Edge を使用して DNS を転送しないこと、またはリリース 4.3.x または 4.5.x を使用する場合には Gateway IP アドレスが指定されているルーティングされた LAN ポートのみを使用することです。 

  • 解決した問題 85679:GDB ツールを使用して VMware SD-WAN Edge をリモートでデバッグすることができません。

    一部のサポート シナリオでは、VMware テクニカル サポート エンジニアがカスタマーと連携して、SSH セッションを介して Edge のリモート トラブルシューティングを行う場合があります。エンジニアが使用する可能性のあるツールの 1 つに、GNU Project Debugger (GDB) があります。この問題では、GDB ツールを使用すると SSH セッションが終了するため、エンジニアリング部門がライブで Edge のトラブルシューティングを行うことが制限されます。

  • 解決した問題 85752:Partner Gateway を使用する VMware SD-WAN Edge が、同じプレフィックスの Partner Gateway スタティック ルートを 2 回受信することがあります。

    Edge は、任意の時点で Gateway から 1 つのルートのみを受信しなくてはなりません。この問題は、同じプレフィックス ルートが [Gateway] ページで NAT として設定されていて、[Gateway ハンドオフ (Gateway Handoff)] ページで LAN タグ付きとして設定されている場合に発生します。

  • 解決した問題 85892:NSD エンドポイントで冗長性が有効になっている場合、メトリック ツール Wavefront が Non SD-WAN Destination (NSD) エンドポイントの一貫性のないメトリックを報告します。

    冗長性が有効な NSD エンドポイントに接続している間、VMware SD-WAN Gateway サービスは、両方のエンドポイント(プライマリとセカンダリ)に同じ名前の内部カウンタを作成します。これにより、Wavefront で一貫性のないレポートが作成されます。

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

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

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

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

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

    LAN 側 NAT:[送信元] 内部アドレス:10.0.2.25/32 外部アドレス:7.0.2.25/32 スタティック ルート:7.0.2.25/32 [広報] ネクスト ホップ:10.0.2.1

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

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

  • 解決した問題 86719:VMware SD-WAN Edge を 3.4.x から 4.3.1 にアップグレードすると、Edge の OSPF セッションが起動せず、Edge がルートを受信しないことがあります。

    Orchestrator と Edge 間の OSPF エリア フォーマットの不一致が原因で、Edge のアップグレード後に OSPF ネイバーシップがダウンする可能性があります。

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

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

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

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

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

  • 解決した問題 86885:高可用性トポロジを使用してサイトを展開し、HA Edge を 1 つのプロファイルから別のプロファイルに移動すると、HA アクティブ Edge はフェイルオーバーせず、別のプロファイルへの移行を完了しないため、カスタマーのトラフィックが中断する可能性があります。

    想定されるのは、HA Edge を別のプロファイルに割り当てた後、フェイルオーバーによってアクティブ Edge が変更され、それから割り当てが完了することです。これにより、各 Edge は設定を適用し、サービスを順次再起動して、カスタマーのトラフィックが中断されないようにします。この問題は、プロファイルの移行(変更)中にアクティブ Edge からハートビートが抑制され、両方の Edge が同時に設定を適用し、個別に再起動することになり、フェイルオーバーが発生しないことが原因です。

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

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

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

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

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

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

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

    この問題の修正が適用されていない Edge では、回避策として、Edge 経由の NSD を 1 つの WAN リンクに制限します。これにより、この問題が発生する可能性が低くなります。

  • 解決した問題 87565:ハブ/スポーク トポロジで設定されたカスタマー エンタープライズの場合、VMware SD-WAN スポーク Edge が想定外のハブ Edge にトラフィックを転送し、その Edge からのクライアント トラフィックに問題が発生する可能性があります。

    いくつかのシナリオにおいて、リモート BGP ルートの AS パス長が正しく計算されません。このため、想定外のハブ Edge からのルートの AS パス長がより長くなり、想定されるハブ Edge よりも優先されます。

    この修正が適用されていない Edge の場合、優先されるルートを取り下げてから再広報することで、この問題は一時的に修正されます。

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

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

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

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

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

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

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

  • 解決した問題 88148:拡張された高可用性トポロジを使用して展開されたサイトの場合、HA スタンバイ Edge 上の WAN リンクが起動せず、「初期」状態のままになることがあります。

    この問題は、「USE_PEER」インターフェイスのインターフェイス IP アドレスがゼロにされている競合状態が原因で発生します。HA インターフェイスの同期の一環として、iface->ip_addr がサニティ チェックを行いますが、インターフェイス IP アドレスはチェックしません。このため、スタンバイ Edge の WAN リンクは IP アドレスがないため、初期状態のままになります。

  • 解決した問題 88152:VMware SD-WAN Edge のサブインターフェイスに対する SNMP 要求が機能しません。

    これは初日の動作で、Edge のサブインターフェイスへの SNMP 要求はすべてタイムアウトになります。この問題の修正により、Edge のサブインターフェイスにこれらの SNMP 要求のサポートが追加されました。

  • 解決した問題 88317:パブリック リンクとプライベート リンクの両方を使用し、SD-WAN 到達可能 (SD-WAN Reachable) が設定されている VMware SD-WAN Edge において、パブリック リンクが停止した場合、ダイレクト トラフィックは想定どおりにプライベート リンクを使用しません。

    パブリック リンクを優先するようにビジネス ポリシーが設定されている場合、優先パブリック リンクが停止している間、フローは SD-WAN 到達可能プライベート リンクを使用しません。この問題の修正により、ダイレクト リンク選択が最後の手段としてプライベート リンクを見つけ出そうとするときに、SD-WAN 到達可能リンクを許可するロジックが追加されました。

  • 解決した問題 88450:IPv4 アドレスを介した SSH が VMware SD-WAN Edge で機能しません。

    WAN 側クライアント(VCMP サーバなど)からの SSH パケットを許可するように IP テーブル ルールを変更した場合、ルールが存在しない状態になります。その結果、オーバーレイ設定の変更後、WAN 側クライアントから IPv4 アドレス経由での Edge への SSH が失敗します。

  • 解決した問題 88550:Edge Network Intelligence を使用しているカスタマーにおいて、DNS が明示的に設定されていない場合、VMware SD-WAN Edge が Edge Network Intelligence サービスと通信できません。

    DNS が明示的に設定されていない場合、Edge Network Intelligence サービスはデフォルトで Google DNS を使用します。DNS が送信元インターフェイスとしてループバック インターフェイスを選択すると、DNS ルックアップの失敗が原因でサービスへの到達可能性が失われます。

    この問題が修正された Edge ビルドを使用しないカスタマー エンタープライズの場合の回避策は、Orchestrator で DNS を明示的に設定し、送信元インターフェイスとして仮想ループバック インターフェイスではなく実際のインターフェイスを選択することです。

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

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

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

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

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

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

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

  • 解決した問題 89364:拡張された高可用性トポロジを使用しているサイトで、ユーザーが [リモート診断 (Remote Diagnostics)] > [インターフェイスの状態 (Interface Status)] を実行している場合、スタンバイ Edge インターフェイスのリンク速度が 0 Mbps/半二重と表示されます。

    インターフェイスが稼動中のスタンバイ Edge から速度と自動ネゴシエーションの詳細が取得されず、詳細情報が正しく表示されません。

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

    この問題は、カスタマーが NAT を設定している場合に発生する可能性があります。NAT を使用する新しいフローが確立されると、極めてまれな競合状態が発生し、Edge サービスで例外がトリガされ、障害が発生して再起動になることがあります。

    この問題に対する修正を行わない場合、この問題を回避する唯一の方法は NAT を無効にすることです。

  • 解決した問題 89627:Telegraf サービスが使用されている VMware SD-WAN Gateway では、メモリ使用量が増大し、最終的にメモリをクリアするために Gateway サービスが再起動する場合があります。

    Telegraf が使用されている場合、一連のメトリックが Gateway サービスから取得され、エクスポートされます。データの取得操作中に、少量のメモリがリークし、メトリックの格納に使用されるメモリが解放されません。

    この修正を適用しない場合の回避策は、Telegraf サービスをオフにしてメモリ リークを防ぐか、Gateway でメモリ使用率を慎重に監視することです。メモリ使用率が最大 60% に達した場合は、予防的な Gateway サービスの再起動をスケジューリングしてメモリをクリアします。2 番目の回避策は、Telegraf を使用しながら、この問題が修正されたビルドに Gateway を更新するまでの時間を稼ぐことです。

  • 解決した問題 89722:SNMP サーバがパブリック インターネット上にある場合に、SNMP ポーリングが機能しません。

    リリース 4.3.x 以降のルーティングの変更は、パブリック インターネット上の SNMP サーバから VMware SD-WAN Edge をポーリングする際に SNMP を使用しようと考えているカスタマーに悪影響を及ぼします。重要な点は、SNMP 要求がパブリック WAN リンクに入ると、その応答は要求を受け取ったインターフェイスとは異なるインターフェイスを使用するだけではなく、SD-WAN Gateway を介して送信されることになり、そのため、このシナリオでは SNMP が実質的に切断されてしまいます。

  • 解決した問題 89725:Edge ソフトウェア リリース 4.3.1 を使用している VMware SD-WAN Edge の場合、リモート診断ユーティリティの WAN リンク帯域幅テストと Traceroute が機能しません。

    WAN リンク帯域幅テストおよび Traceroute ユーティリティでは、インターフェイス(BW テストの場合)または IP アドレス(Traceroute の場合)について追加の入力が必要です。この問題により、ドロップダウン メニュー オプションが表示されないためユーザーはこれらの入力を設定できません。このため、いずれかのインスタンスのテストでエラーが発生します。

  • 解決した問題 89861:VMware SD-WAN Edge でオブジェクト グループを使用するビジネス ポリシーを設定すると、メモリ リークが発生し、最終的にメモリをクリアするために Edge サービスが予定外に再起動することがあります。

    オブジェクトグループが更新されるたびに、少量の Edge メモリがリークされます。オブジェクト グループを使用する十分な数のビジネス ポリシー(たとえば、約 400 個)がある程度の頻度で設定および更新されると、Edge メモリが大幅に消費されることになります。メモリの量が 60% 以上に達すると、Edge は防御的に Edge サービスの再起動をトリガしてメモリをクリアします。これによりカスタマー トラフィックが 10 ~ 15 秒中断します。

    この問題に対する修正が適用されていないリリースを使用している 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 サービスの再起動を行うと、カスタマー トラフィックが一時的に中断する可能性があります。

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

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

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

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

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

  • 解決した問題 90216:トラフィック フローがクライアント > スポーク Edge > ハブ > サーバからの場合、Traceroute が VMware SD-WAN ハブ Edge の正しい IP アドレスを表示しないことがあります。

    トランスポート グループ[プライベート 有線 (Private Wired)][必須 (Mandatory)] を使用するように設定されたハブ Edge にトラフィックをバックホールするように設定されたビジネス ポリシーをスポーク Edge が持っている場合、Traceroute のパケットがハブ Edge に到達すると、ハブ Edge は Traceroute に対して誤った IP アドレス(この場合、プライベート IP アドレスではなくパブリック IP アドレス)で応答します。

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

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

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

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

  • 解決した問題 90513:SSH 接続が許可された IP アドレスを設定しているにもかかわらず、ユーザーは VMware SD-WAN Edge に SSH 接続できない場合があります。

    リモートで Edge に SSH 接続できる IP アドレスを追加すると、競合状態になる可能性があり、コマンド エラーで IP テーブルが更新されなくなることがあります。その結果、SSH が Edge に対してブロックされます。

  • 解決した問題 90797:VMware SD-WAN Edge でデータプレーン サービスの障害が発生し、リカバリするために再起動すると、再起動ごとにカスタマーのトラフィックで 10 ~ 15 秒の中断が発生することがあります。

    この問題は、Edge の DPI(詳細なパケット インスペクション)エンジンで無効なメモリ アクセス イベントが発生するとトリガされます。DPI エンジンのフローが定期的にクリーンアップされず、そのモジュールでのメモリの破損につながります。この問題の修正により、パケット分類が完了するとすぐに各 DPI エンジン フローのフローが削除されます。

    ハブ クラスタのメンバーである Edge でこの問題が発生した場合は、各クラスタ メンバーの再起動後にトラフィックの再調整が行われるため、カスタマーのトラフィックも中断します。

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

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

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

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

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

  • 解決した問題 91203:ハブ/スポーク トポロジを使用しているカスタマー エンタープライズで、VMware SD-WAN スポーク Edge が 1 台のハブ Edge を介してトラフィックをバックホールするように設定されている場合、バックホールされたフローに対するトラフィックのパフォーマンスが低下することがあります。

    ハブ Edge のバックホール レグは、送信元と宛先のルート タイプ(送信元 = エンタープライズ、宛先 = クラウド)によって決まりますが、この方法ではルート変更に基づくインシデントに依存するため、動作に一貫性がなく、バックホール フローのパケットがドロップする可能性があります。この問題の修正では、スポーク Edge のメッセージングに基づいてバックホール レグを決定します。

  • 解決した問題 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 の分析機能が記録している情報の量によって異なります。

    この問題に対する修正が適用されていない Edge では、カスタマーには次の 2 つの選択肢があります。a) 修正された Edge ビルドが提供されるまで、Edge の分析を一時的にオフにする。b) 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 では、回避策として 802.1x 認証を無効にします。

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

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

  • 解決した問題 92216:VMware SD-WAN Edge が指定されたトンネル制限の 60% を使用しているというアラートが表示されることがあります。

    Edge トンネルに対するこの「ソフト上限アラーム」は、実際の使用率 60% の上限がないため、カスタマーに混乱をきたす可能性があります。上限として意味があるのは、Edge モデルに対して指定されたトンネルの上限のみです。すべての Edge モデルの Edge トンネル制限については、「VMware SD-WAN Edge プラットフォーム仕様」データシートを参照してください。最新のデータシートのダウンロード リンクは、VMware SD-WAN Hardware Guide ページの下部にあります。

  • 解決した問題 92454:IPv4 アドレスにのみ解決されるドメイン名を [宛先 (Destination)] フィールドに入力すると、[リモート診断 (Remote Diagnostic)] > [Traceroute] が機能しません。

    ドメイン名が IPv4 アドレスにのみ解決される場合、リモート診断を介して実行される Traceroute コマンドは機能しません。これは、VMware SD-WAN Edge は常に IPv6 レコードのドメイン名を解決しようとし、IPv4 アドレスを見つけられないためです。

    この問題が修正されていない Edge では、回避策として、Traceroute コマンドでドメイン名に対応する IPv4 アドレスを直接使用します。IPv4 アドレスは、[リモート診断 (Remote Diagnostic)] > [DNS テスト (DNS Test)] にドメイン名を指定することで取得できます。

  • 解決した問題 92964:VMware SD-WAN Edge が DHCP リレー エージェントとして設定されている場合、DHCP NACK パケットがサブインターフェイスを介してクライアントに転送されません。

    ホストが現在の IP アドレス範囲内にない IP アドレスを要求すると、DHCP サーバはホストからの DHCP 要求に対して NACK(否定応答)メッセージを送信する必要があります。しかしながら、DHCP サーバが DHCP NACK パケットを送信すると、DHCP リレーとして設定されている Edge はパケットを転送せずにドロップします。

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

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

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

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

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

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

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

    この問題が修正されていない Edge では、カスタマーは、Edge の HA インターフェイス(通常は GE1)で発生したアップストリーム スイッチからの L2 ループ検出イベントを無視できます。 

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

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

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

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

  • 解決した問題 93853:高負荷状態の VMware SD-WAN Gateway で、SIGXCPU コードとともにデータプレーン サービスの障害が発生し、リカバリするためにサービスが再起動することがあります。

    高負荷状態においては、ルーティングやログ作成などのさまざまなアクティビティを実行する複数の Gateway スレッドで CPU リソースが枯渇し、規定の期間内にタスクを完了できません。Gateway サービスは、これらの遅延しているスレッドをデッドロックになっていると解釈し、SIGXCPU シグナルを発生させて Gateway データプレーン プロセスを終了します。

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

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

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

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

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

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

  • 解決した問題 94401:ステートフル ファイアウォールが有効になっている VMware SD-WAN Edge で、TCP が確立済みのフローが短時間でタイムアウトし、フラッシュされることがあります。

    TCP が確立済みのフローが、TCP が未確立のフローとして扱われ、より短いタイムアウト期間を適用されます。TCP フローで TCP リセット (RST) が発生し、続いて TCP 3 ウェイ ハンドシェイクが発生すると、TCP 状態が確立済みとして表示されていても、確立されていない TCP フローのタイムアウトが適用されてしまい、その後にフローがフラッシュされます。

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

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

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

  • 解決した問題 94775:ハブ/スポーク トポロジを使用しているカスタマー エンタープライズで、VMware SD-WAN スポーク Edge が 1 台のハブ Edge を介してトラフィックをバックホールすると、クライアント ユーザーはトラフィックのパフォーマンスの問題を確認する場合があります。

    これは、バックホールされたトラフィックに誤ったフラグが設定されているために発生します。バックホールされたパケットは、ハブ Edge 上にあるかのようにスポーク Edge で処理されます。これにより、ハブでルート参照の問題が発生し、バックホール パケットがドロップします。

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

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

  • 解決した問題 95073:ハブ/スポーク トポロジを使用しているカスタマー エンタープライズで、VMware SD-WAN スポーク Edge が複数のハブ Edge を介してトラフィックをバックホールすると、クライアント ユーザーはバックホール トラフィックの重大な問題を確認する場合があります。

    この問題は、バックホール ルールに一致するトラフィックに対するスポーク Edge でのルート参照の失敗が原因で発生します。スポーク Edge は、ハブ Edge へのルートを取得できなかったバックホールされたフローをドロップします。

  • 解決した問題 95121:VMware SD-WAN Edge モデル 510-LTE または 610-LTE で「ロックされた SIM」(パスワード ロックされている SIM)を使用すると、ネットワークでの接続の確立に失敗します。

    Edge 510-LTE および 610-LTE モデルの SIM スロットでロックされた LTE SIM カードを使用すると、パスの確立に失敗します。これは、Edge の ModemManager スクリプトでロックされた SIM をサポートしていないために、Orchestrator からの SIM ロック解除が機能しないことが原因です。

  • 解決した問題 95501:ルーティングにハブ/スポーク トポロジと BGP を使用しているカスタマー エンタープライズの場合、VMware SD-WAN スポーク Edge のクライアント ユーザーはトラフィックのパフォーマンスの低下を確認する場合があります。

    スポーク Edge が、そのスポーク Edge に使用するように設定されたハブ Edge よりも、プロファイルに含まれていないハブからのアップリンク コミュニティでマークされたルートを優先することを、管理者が確認する場合があります。これは、スポーク Edge トラフィックがアップリンク プレフィックスの動的なブランチ間パスを取っているためです。

    この問題は、SD-WAN がハブ Edge から受信したルーティング メッセージのアップリンク フラグをリセットすることが原因で発生します。その結果、動的なブランチ間トンネルが形成されると、これらのアップリンク プレフィックスに対してダイレクト ルートがインストールされ、ルーティングが最適化されなくなり、トラフィックのパフォーマンスが劣化します。

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

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

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

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

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

  • 解決した問題 96626:VMware SD-WAN Edge インターフェイスにセカンダリ IP アドレスが割り当てられている場合、セカンダリ IP アドレスを介した接続が失敗します。

    別のブランチからセカンダリ ネットワーク内の IP アドレスに入ってくる要求が、セカンダリ IP アドレスからではなくプライマリ IP アドレスから ARP を生成します。その結果、ARP は未解決のままになり、セカンダリ IP アドレスを通過するトラフィックで障害が発生します。

  • 解決した問題 96739:ユーザーが VMware SASE Orchestrator の VMware SD-WAN Edge の [監視 (Monitor)] > [アプリケーション (Application)] タブを表示すると、画面にドメイン名が正しくない宛先 FQDN が表示されることがあります。

    この問題は、Edge の統計値が上限に達した(オーバーフロー状態となる)ときに発生する可能性があるもので、その場合、Orchestrator は、それらの統計値をオーバーフローと表示する代わりに、[アプリケーション (Application)] タブの [宛先 FQDN (Destination FQDN)] にランダムなドメイン名を表示することになります。

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

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

  • 解決した問題 96994:VMware SD-WAN Edge で SNMP ウォークを実行中に、一部のインターフェイスが表示されないことがあります。

    欠落しているインターフェイスは、snmpwalk で表示されることが想定された有効なインターフェイスである可能性があります。しかしながら、Edge のハードウェア リストに無効なインターフェイスが表示されるため、リスト内の無効なインターフェイスの後に表示される有効なインターフェイスが snmpwalk によって表示されない、または返されないことになります。ハードウェア リストに表示されているが、Edge で ifconfig コマンドを実行しても表示されないインターフェイスは、ここでは無効になります。

    この問題は、どの Edge でも発生する可能性がありますが、Azure を使用して展開された仮想 Edge において発生する可能性がより高いです。これは、Edge で ifconfig を使用して識別されるインターフェイスの数よりも多くのインターフェイスが、Azure Edge のハードウェア リストに掲載される傾向があることが原因です。

  • 解決した問題 97152:カスタマー エンタープライズで、サービス グループを有線として、リンク モードを「使用可能 (Available)」として設定しているビジネス ポリシーがある場合、有線リンクがダウンしたときにトラフィックが無線リンクに誘導されず、サイトのクライアント ユーザーは、そのルールに一致するトラフィックが失敗していることを確認する場合があります。

    ビジネス ポリシーのルールに、リンク モードが [使用可能 (Available)] の有線 WAN リンクのサービス グループの使用が含まれ、1 つまたは複数の無線 WAN リンクがサイトで使用されている場合、サービス グループの有線リンクがダウンすると(使用不可の状態になると)、そのルールを使用しているトラフィックは、そのルールに一致するトラフィックのシームレス フローを確保するために、無線 WAN リンクにフェイルオーバーすることが想定されます。この問題では、無線 WAN リンクへのトラフィックのステアリングは発生していません。

  • 解決した問題 97225:プライマリ IP アドレスとセカンダリ IP アドレスを切り替えた後、プライマリ ネットワークとセカンダリ ネットワークが他の Edge のルートにインストールされないため、IPv6 アドレスに関連するいくつかの問題が発生します。

    この問題は、次のような形でカスタマーに影響を与えます。

    • インターフェイスで IPv6 アドレスが見つからない。

    • IPv6 アドレスでトンネルが形成されない。

    • Edge と Orchestrator 間の通信が切断され、Orchestrator は Edge をオフラインとしてマークし、Orchestrator ユーザー インターフェイスを介した Edge の制御や設定を行うことができなくなるため、重大な影響が生じる。

    この問題は、VLAN IP アドレスの変更により Edge データプレーン プロセスと Edge のネットワーク インターフェイス デーモン (netifd) が再起動した際に、それらの間の競合状態によって発生するもので、これによりインターフェースから IPv6 アドレスが削除されてしまい、上記の影響が発生することになります。

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

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

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

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

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

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

  • 解決した問題 97691:BGP を使用し、Edge 経由の Non SD-WAN Destination が設定されているカスタマー エンタープライズでは、Edge 上の NSD から BGP へのネイバーシップが起動しないことがあります。

    BGP ネイバーシップを確立するためのパケットが、理由from_cloud_to_direct_dc_drop によりドロップされます。これは、Edge のローカル ルーティング テーブルではなく、FIB(転送情報ベース)で送信元ルートの参照が誤って実行されるためです。FIB は BGP ローカル IP アドレスの自己ルートがないため、プライマリ クラウド ルートと一致します。このため、Edge によって開始された BGP トラフィックがドロップされます。

  • 解決した問題 97743:高可用性トポロジを使用して展開されたカスタマー エンタープライズで、HA Edge ペアが VMware SD-WAN Edge モデル 610 の場合、LAN または WAN インターフェイスがフラップすると、アクティブ Edge が応答しなくなることがあります。

    アクティブ Edge は、スタンバイ Edge のピアの LAN/WAN インターフェイスの数が多いことを検出すると、スタンバイ状態に移行して応答しなくなるか、CPU 使用率 100% の状態によりデッドロックされます。再起動することが、影響を受ける HA Edge をリカバリする唯一の方法です。

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

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

  • 解決した問題 99718:SVI(スイッチ仮想インターフェイス)でセカンダリ IP アドレスが使用されている場合、BGP ネイバーが確立されません。

    Edge が入力方向パケットを処理するときに、入力方向パケットの宛先アドレスが入力方向インターフェイスの IP アドレスと一致するかどうかを検証します。プライマリ IP アドレスのみが比較されるため、セカンダリ IP アドレスとして宛先 IP アドレスを持つパケットはドロップされます。その結果、このセカンダリ IP アドレスでは BGP セッションが形成されません。

  • 解決した問題 100089:VMware SD-WAN Edge の OSPF ネイバーまたは BGP ネイバーのいずれかで、想定外のルーティングが発生することがあります。

    Edge は、プレフィックスが (169.254.129.x) である内部管理ルートを BGP/OSPF に再配布します。これらのルートは、Edge に接続されている OSPF/BGP ネイバーそれぞれによって受信されます。

    この問題が修正されていない Edge では、ユーザーがこれらの (169.254.129.x) プレフィックスのために BGP/OPSF アウトバウンド フィルタを設定できます。

  • 解決した問題 100363:VMware SD-WAN Gateway でデータプレーン サービスの障害が発生し、サービスの再起動がトリガされ、トラフィックが 1 ~ 5 秒中断することがあります。

    この問題はストレス テスト中に、futex_abstimed_wait で発生する障害と、サービスの障害と再起動をトリガするデッドロック状態になったスレッドの結果として発生したものです。

  • 解決した問題 100796:拡張された高可用性トポロジを使用して展開されたカスタマー エンタープライズの場合、ユーザーが HA Edge ペアの [リモート診断 (Remote Diagnostic)] > [インターフェイスの状態 (Interface Status)] を実行すると、VMware SASE Orchestrator が「テスト用のデータ読み取りエラー (Error reading data for test)」というエラー メッセージを返します。

    これは、拡張 HA の Edge でのみ発生する特有の問題です。この問題は、スタンドアローン Edge や、レガシー HA トポロジで設定された Edge では発生しません。この問題は、拡張 HA リンクの状態を取得しなくてはならない API に不具合があるために原因で発生します。

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

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

Orchestrator で解決した問題

Orchestrator バージョン R432-20221108-GA で解決した問題

Orchestrator バージョン R432-20221108-GA は 2022 年 11 月 16 日にリリースされ、Orchestrator バージョン R431-20220715-GA 以降の次の問題に対処しています。 

注:

リリース 4.3.2 には、4.3.0 または 4.3.1 リリース ノートに記載されているすべての Orchestrator の修正が含まれています。

  • 解決した問題 71490:カスタマーが多数の学習済みルート イベントを持つ多数の Edge をホストする VMware SD-WAN Orchestrator を使用している場合、処理される送信要求の速度が低下することがあります。Orchestrator 管理者は、CPU 使用率が高くなると、Orchestrator のパフォーマンスが影響を受けることを確認する場合があります。

    この問題は、各 Edge が 30 秒ごとに約 20 個の学習済みルート イベントをプッシュしていた、約 5,000 台の Edge を持つ Orchestrator に影響を与えます。この問題は、Orchestrator がこれらの Edge の学習済みルーティング イベントを処理する方法の非効率性が原因で発生しました。このビルドには、この問題が繰り返し発生するのを防ぐため、ルート処理ロジックの最適化が含まれています。

  • 解決した問題 73234:動的コスト計算 (DCC) を使用しておらず、大量の学習済みルートが存在するカスタマー エンタープライズでは、BGP の開始または再起動後に、VMware SASE Orchestrator が BGP ルートを広報するのに時間が長くかかることがあります。

    この問題は、少なくとも数百の学習済みルートを持つ企業に影響し、より多くのルート(たとえば、2000 個程度のルート)がある場合は、Orchestrator がすべてのルートを広報するのに 10 分以上かかる可能性があります。この問題の修正により、DCC がない場合のルートのコンバージェンス速度が向上します。

  • 解決した問題 75895:一部の CSS トンネル イベントで、Edge クラウド セキュリティ サービス (CSS) トンネル アラートの生成がスキップされることがあります。

    カスタマーがクラウド セキュリティ サービスを使用して Edge を設定していて、Edge にトンネルのアップ/ダウン イベントが同時に存在する場合、VMware SASE Orchestrator ですべてのイベントのアラートを生成できないことがあります。

  • 解決した問題 76442:カスタマーの割り当てられた Gateway プールから Gateway を削除した後に、カスタマーの Partner Gateway ハンドオフ設定を更新すると、偽の API 検証エラーが発生します。

    以前にハンドオフ設定が行われている Partner Gateway が Gateway プールから削除されたとき、Orchestrator はその Gateway のハンドオフ設定をカスタマーレベルのハンドオフ設定から消去しません。その結果、API クライアントが古い Gateway 設定を意図的に削除しない限り、その後に API を介してカスタマーレベルのハンドオフ設定の更新を試みても失敗します。

    この修正を適用しない場合、カスタマーは次の手順を実行してこの問題を回避できます。カスタマーの Gateway ハンドオフ設定を更新するときに、API クライアントは、設定に示されているすべての Gateway がカスタマーの Gateway プールに現存することをプロアクティブに確認できます。

  • 解決した問題 78684:Azure タイプの Gateway 経由の Non SD-WAN Destination を使用しているカスタマー エンタープライズでは、再同期によって設定内のスタティック ルートが想定どおりに伝達されないことがあります。

    Orchestrator のユーザー インターフェイスから、サブネットが追加または削除されると、API を介して一連のパラメータが渡されます。ただし、再同期中のパラメータは、API が想定しているパラメータとは異なります。このため、再同期オプションは正しく機能しません。サブネットが Azure 環境から更新された場合でも、この問題が発生すると、設定の他の場所に適切に伝達されないことがあります。

  • 解決した問題 82835:Edge 610N(Wi-Fi 以外のモデル)が、VMware SASE Orchestrator で Edge 610(Wi-Fi 対応)として表示されます。

    これは純粋に表示上の問題であり、Orchestrator では Edge 610N の Wi-Fi インターフェイスが公開されません。ただし、Edge モデルを把握することを望んでいるカスタマーには混乱が生じます。ユーザーがローカル ユーザー インターフェイスで Edge 610N をチェックすると、正しいモデル タイプの表示を確認できます。

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

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

  • 解決した問題 83694:ユーザーが VMware SD-WAN Edge のローカル ユーザー インターフェイスにログインしたときに、そのアクションは VMware SASE Orchestrator で記録されず、[監視 (Monitor)] > [イベント (Events)] にも表示されません。

    カスタマー管理者が、Edge のローカル ユーザー インターフェイスへのローカル ユーザー ログインを認識できないことがあります。

  • 解決した問題 88120:VMware SASE Orchestrator で、クラシック ユーザー インターフェイスと新しいユーザー インターフェイスの [監視 (Monitor)] > [Edge] > [概要 (Overview)] ページを比べると、「ライブ モード」で表示されるリンク状態に不一致があります。

    この特定の不一致は、新しいユーザー インターフェイスで WAN リンクに「安定 (Stable)」状態が表示される必要がある場合に「スタンバイ (Standby)」状態が表示されるために発生します。クラシック ユーザー インターフェイスでは、リンク状態が正しく表示されます。 

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

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

  • 解決した問題 93846:ZTP を使用して Edge インベントリを管理するパートナーおよびオペレータの場合、あるカスタマーに以前割り当てられていた VMware SD-WAN Edge を別のカスタマーに再割り当てして削除しようとすると、VMware SASE Orchestrator から「Edge が見つかりません (Edge is not found)」というエラーが返されます。

    Orchestrator は、論理 Edge がカスタマー エンタープライズから削除された後、論理 Edge が表示されなくなるため、Edge が存在しないものと判断します。このため、ユーザーは Edge を別のカスタマーに再割り当てできません。

既知の問題

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

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

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 リンクごとに、異なるインターフェイスを使用します。

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

  • 問題 39659:

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

  • 問題 39753:

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

  • 問題 40096:

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

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

  • 問題 40421:

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

  • 問題 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 と一致しません。

  • 問題 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) 認証を使用するトンネルには、この問題はありません。

  • 問題 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: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 サービスを再起動すると、フル トンネル接続がリストアされます。

  • 問題 75668:内部 LAN 宛先にルーティングされると、LAN 側トラフィックの DSCP タグがリセットされます。

    ルーティングされた/ダイレクト ユーザー トラフィックの場合に、Edge は DSCP タグを 0 にリセットします。これにより、同じ Edge で出入りする(すなわち、Edge に対してローカルのままとなる)トラフィックでは、DSCP タグが CSP=0DSCP とマークされるように変更され、Edge を通過する際のアンダーレイ トラフィックに対して CS0 にリセットされます。

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

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

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

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

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

  • 問題 76837:BGP を使用している場合、ピア ルーターがネットワーク内の VMware SD-WAN Edge にトラフィックを送信していないことがあります。

    この問題をトラブルシューティングすると、デフォルトの発信元を経由するデフォルト ルートが Edge によって広報されていないことが明らかになります。この問題は、デフォルト ルートに関連付けられているルート マップ文字列が切り詰められ、Edge のデフォルト ルートがルート マップのどれとも一致しないために発生します。その結果、ピア ルーターはトラフィックをドロップするか、トラフィックがブラックホールになっている無効なルートを使用して送信します。

    回避策:修正を含む Edge バージョンにアップグレードできるまで、ユーザーはデフォルト ルートのピア ルーターにスタティック ルートを設定する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 問題 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 を選択するのに役立ちます。

  • 問題 97041:マルチホップ BGP 設定を使用しているカスタマー エンタープライズで、アウトバウンド フィルタを変更した後に BGP ルートのフラッピングが発生することがあります。

     マルチホップ BGP の一例としては、BGP が MPLS ルーターで確立されている場合などが考えられます。アウトバウンド フィルタを変更してその変更内容を保存すると、BGP セッションが終了してすべてのルートを再構築しなくてはならなくなり、カスタマーのトラフィックが中断してしまう、という状況になることがあります。

    回避策:カスタマー トラフィックの中断を防ぐには、メンテナンス期間中にのみ、BGP アウトバウンド フィルタの変更を行うようにします。

  • 問題 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 リンクが起動します。

  • 問題 101703:拡張された高可用性トポロジを使用しているカスタマー サイトの場合、DHCP が有効化されているサブインターフェイスのカスタム送信元 IP アドレスでユーザー定義の WAN オーバーレイが設定されている場合、このサブインターフェイスに関連付けられているトンネルが安定していても、パブリック IP アドレスの値がゼロと表示されることがあります。

    この問題は、DHCP 割り当てとパスの作成間で発生する可能性のある競合状態から発生します。トンネルは安定したままですが、パブリック IP アドレスがゼロで示されます。

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

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

  • 問題 35658:

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

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

  • 問題 35667:

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

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

  • 問題 36665:

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

  • 問題 38056:

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

  • 問題 38843:

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

  • 問題 39633:

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

  • 問題 39790:

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

  • 問題 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 の制限が適用されません。

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