2022 年 10 月 3 日更新

VMware SD-WAN™ Orchestrator バージョン R430-20211221-GA
VMware SD-WAN™ Gateway バージョン R430-20211020-GA-VCG
VMware SD-WAN™ Edge バージョン R430-20211007-GA-61583-69704-59629-72423

各リリース ノートへの追加および更新を定期的にご確認ください。

リリース ノートの概要

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

対象ユーザー

今回のリリースで初めて利用可能になった機能を必要とする、すべてのカスタマーにこのリリース 4.3.0 をお勧めします。

互換性

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

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

Orchestrator

Gateway

Edge

ハブ

ブランチ/スポーク

4.3.0

4.2.0

4.2.0

4.2.0

4.3.0

4.3.0

4.2.0

4.2.0

4.3.0

4.3.0

4.3.0

4.2.0

4.3.0

4.3.0

4.2.0

4.3.0

4.3.0

4.0.1

4.0.1

4.0.1

4.3.0

4.3.0

4.0.1

4.0.1

4.3.0

4.3.0

4.3.0

4.0.1

4.3.0

4.3.0

4.0.1

4.3.0

4.3.0

3.4.2

3.4.4

3.4.4

4.3.0

4.3.0

3.4.4

3.4.4

4.3.0

4.3.0

4.3.0

3.4.4

4.3.0

4.3.0

3.4.4

4.3.0

4.3.0

3.4.2

3.4.2

3.4.2

4.3.0

4.3.0

3.4.2

3.4.2

4.3.0

4.3.0

4.3.0

3.4.2

4.3.0

4.3.0

3.4.2

4.3.0

4.3.0

  3.3.2 P2 *

  3.3.2 P2 *

  3.3.2 P2 *

4.3.0

4.3.0

  3.3.2 P2 *

 3.3.2 P2 *

4.3.0

4.3.0

4.3.0

 3.3.2 P2 *

4.3.0

4.3.0

  3.3.2 P2 *

4.3.0

4.3.0

  3.2.2 *

  3.2.2 *

  3.2.2 *

4.3.0

4.3.0

  3.2.2 *

  3.2.2 *

4.3.0

4.3.0

4.3.0

  3.2.2 *

4.3.0

4.3.0

   3.2.2 *

4.3.0

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

警告:VMware SD-WAN リリース 3.4.x は、Orchestrator および Gateway のサポート終了に近づいています。

  • Orchestrator および Gateway のリリース 3.4.x は、2022 年 3 月 30 日にジェネラル サポートの終了 (EOGS) となりました。2022 年 9 月 30 日にはテクニカル ガイダンスの終了 (EOTG) となります。
  • 注:これは、Orchestrator および Gateway のみが対象です。Edge のリリース 3.4.x は、2022 年 12 月 31 日からサポート終了への移行期間に入ります。
  • 詳細については、ナレッジベースの記事を参照してください。お知らせ:VMware SD-WAN リリース 3.x のサポート期間の終了 (84151)

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

  • リリース 4.0.x は、2022 年 9 月 30 日にジェネラル サポートの終了 (EOGS) となり、2022 年 12 月 31 日にテクニカル ガイダンスの終了 (EOTG) を迎えます。 
  • リリース 4.2.x の Orchestrator および Gateway は、2022 年 12 月 30 日にジェネラル サポートの終了 (EOGS) となり、2023 年 3 月 30 日にテクニカル ガイダンスの終了 (EOTG) を迎えます。   
  • リリース 4.2.x の Edge は、2023 年 6 月 30 日にジェネラル サポートの終了 (EOGS) となり、2023 年 9 月 30 日にテクニカル ガイダンスの終了 (EOTG) を迎えます。
  • 詳細については、ナレッジベースの記事を参照してください。お知らせ:VMware SD-WAN リリース 4.x のサポート期間の終了 (88319)

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

重要な注意事項

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

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.1 で Edge 3400 または 3800 がそのファームウェアをアップグレードしていた場合は、Edge は予想時間内にアップグレードされます。詳細については、「解決した問題 53676」を参照してください。

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

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

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

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

新機能

Edge からの Azure Virtual WAN の自動化

カスタマーは、Edge 経由の Non SD-WAN Destination (NSD) を有効にして、IPsec 接続を使用して Azure vWAN Hub に接続できます。

注:Edge から Azure vWAN への接続を自動化するときにはスタティック ルートのみがサポートされます。

Azure Private MEC (Multi-Access Edge Compute)

Azure Private MEC で SD-WAN Edge をサポートすることにより、オンプレミスに展開されたコンピューティング サービスおよびストレージ サービスへの低遅延アクセスを実現し、CNF、VNF、およびサードパーティ製アプリケーションを展開できます。

Edge および Gateway 上の BGP over IPsec

BGP over IPsec を使用すると、ユーザーは Non SD-WAN Destination トンネルで BGP を有効にできます。これにより、サードパーティの IPsec エンドポイントを使用してルートを動的に学習および広報する機能により、現在提供されているスタティック ルーティングを強化できます。

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

WAN 上の IPv6

VMware SD-WAN は、WAN 転送側でデュアル スタック (IPv4/IPv6) または IPv6 のみをサポートするようになりました。WAN 上の IPv6 は、IPv6 WAN 経由での IPv4 ユーザー トラフィックの転送、IPv4/IPv6 混在環境経由での IPv4 の転送、デュアル スタック経由での IPv4 の転送などのユースケースに対応します。

マルチセグメント ループバック インターフェイス

この機能は、常に稼動していて到達可能な論理インターフェイスであるループバック インターフェイスを導入します。ループバック インターフェイスの IP アドレスは、Orchestrator 管理トラフィック、認証、DNS、NetFlow、Syslog、TACACS、BGP、NTP など、各種サービスの送信元 IP アドレスとして使用できます。ループバック インターフェイスは常に稼動していて到達可能であるため、Edge 用に設定された少なくとも 1 つの物理インターフェイスにレイヤー 3 の到達可能性があれば、これらのサービスは応答パケットを受信できます。ループバック インターフェイスは、BGP の送信元インターフェイスとして使用することもできます。これにより、BGP のインターフェイス状態がフラップしたときに、使用可能なレイヤー 3 接続が少なくとも 1 つある場合、BGP メンバーシップはフラップしないようになります。

Bastion Orchestrator

厳格なセキュリティ要件(金融機関や行政機関など)が求められるお客様の場合、セキュリティ ポリシーにより、本番環境の Orchestrator をインターネットに公開することはできません。VMware SD-WAN Bastion Orchestrator は「自身を犠牲にする」Orchestrator であり、侵害されてもお客様の機密情報が失われたり、SD-WAN システムに脆弱性が生じたりすることはありません。Bastion Orchestrator を使用すると、お客様はデバイスを本番環境サービスに登録する前にデバイス設定を「事前ステージング」できます。

外部認証局

オンプレミスの Orchestrator の導入を計画している大規模企業や政府機関のお客様は、VMware SD-WAN がデフォルトの自己署名 Orchestrator 認証局ではなくお客様独自の外部認証局 (CA) を使用する必要があると規定しています。外部 CA 機能を使用すると、Orchestrator は、SD-WAN Edge および Gateway の証明書発行をお客様自身の外部認証局にオフロードできます。

Orchestrator および Gateway の FIPS モード サポート

Cloud-Init を使用して Orchestrator と Gateway の両方を Federal Information Processing Standard (FIPS) モードで起動できるようになりました。  FIPS モードでは、FIPS 以外の承認済み暗号スイートは無効になります。MD5 が無効になり、SHA-1 が使用されます。FIPS モードは新規インストールでのみ使用できます。既存の Orchestrator または Gateway をこの機能にアップグレードすることはできません。

イメージの署名と検証

お客様は、VMware SD-WAN デバイス上で実行されるソフトウェアとファームウェアの整合性と信頼性を確保したいと思っています。イメージの署名によって、インストールするソフトウェアの真正性、改ざんされていないこと、および追跡可能性が保証されます。また、ソフトウェアのアップグレード プロセス中に、デバイスは、安全にデバイスに保存されている信頼ルートに基づいて、すべてのソフトウェア アップグレード イメージが VMware によって署名されたことを検証します。

Virtual WAN の VMware SD-WAN

この機能により、お客様は Azure Virtual WAN Hub で管理対象アプリケーションを使用して VMware SD-WAN Edge を展開できます。カスタマーは VMware SD-WAN ファブリックをブランチの Edge から Azure Virtual WAN Hub 内に直接拡張し、動的マルチパス最適化 (DMPO) を使用して Azure Virtual WAN のカスタマイズ可能なルーティング インテリジェンスと VMware SD-WAN のラスト マイル最適化をペアリングすることで、強化されたエンド ユーザー エクスペリエンスを体験しながら Azure リージョン全体のワークロードにシームレスにアクセスできます。

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

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

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

リリースの制限事項:リリース 4.3.0 では、Wi-Fi がサポートされていない場合でも、VMware SD-WAN Orchestrator は非 Wi-Fi Edge デバイスの WLAN インターフェイスを引き続き表示します。 

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

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

機能強化

128 セグメント

VMware SD-WAN は、大規模企業やサービス プロバイダのニーズに対応するために、最大で 128 セグメントをサポートするようになりました。

すべての Edge 6x0 モデルでの ADSL2/2+ および VDSL2 のサポート

リリース 3.4.0 では、Edge 610 および 610-LTE に ADSL と VDSL SFP のサポートが追加されました。  リリース 4.3.0 では、このサポートが Edge 620、640、および 680 を含む Edge 6x0 モデル ラインの残りにも追加されています。Edge 610/610-LTE と同様に、サポートされている SFP モジュールは、VDSL2 および ADSL2/2+ 仕様に従って動作する Metanoia SFP-V5311-T-R xDSL SFP アダプタです。

さらに、DSL パラメータはアクティベーション プロセスの一部として VMware SD-WAN Orchestrator に含まれるようになりました。これにより、DSL リンクのみを使用して Edge 6x0 をアクティベーションできます。  ADSL2/2+ のサポートは、SFP インターフェイスの設定時に PVC 設定のパラメータを追加することで拡張されます。

Azure 高速ネットワークのサポート

VMware SD-WAN vVCE には、Azure (Hyper-V) ベースの SR-IOV のサポートが追加されています。

パブリック無線リンクのサービス クラス

パブリック無線リンクでサービス クラスのマッピングを設定できるようになりました。

ファイアウォールの機能強化

ファイアウォールの機能が 2 つの方法で強化されました。

  • ファイアウォール ログの Syslog メッセージ形式の更新。
  • ファイアウォール ルールで監査コメントを設定する機能。

高可用性 (High Availability)

ESXi での高可用性を備えた uCPE 展開で仮想 Edge を使用できるようになりました。これは、次の 2 つの機能強化の成果です。

  • 高可用性インターフェイスでの一意の MAC アドレスのサポート。HA では、共通の、または共有された仮想 MAC を生成する代わりに、この機能はハードウェア Edge に対して物理 MAC アドレスを使用し、仮想 Edge に対して割り当て済みの MAC アドレスを使用します。
  • HA インターフェイスでの Loss of Signal (LoS) 検出のサポート。これにより、ESXi 展開で仮想スイッチが使用されている場合でも HA フェイルオーバーが確実に行われます。

Orchestrator のローカリゼーション

VMware SD-WAN Orchestrator の UI は、スペイン語、日本語、韓国語、繁体字中国語、ポルトガル語でもご利用いただけるようになりました。Orchestrator の言語を選択するには、ブラウザの言語設定を使用してください。

パートナー ロールの強化

このパートナー管理者ロールが拡張され、次のことができるようになりました。

  • Partner Gateway 診断バンドルを生成してダウンロードする。
  • Partner Gateway イベントを表示し、認証モードを設定する。
  • カスタマー設定を行い、カスタマーのアカウントを表示および変更する。
  • 統合されたカスタマー インベントリをエクスポートする。

ロールのカスタマイズ

カスタマー管理者のロールが強化され、カスタマイズが追加されました。これらの新しいカスタマイズのユースケースには、次のようなものがあります。

  • セキュリティ管理者:[ファイアウォール (Firewall)] タブの設定のみを変更できるようにカスタマイズされた標準管理者です。
  • ネットワーク管理者: [デバイス (Device)] タブと [ビジネス ポリシー (Business Policy)] タブの設定のみを変更できるようにカスタマイズされた標準管理者です。  
  • エンタープライズ読み取り専用:このユースケースでは、セキュリティ/プライバシー上の理由から、個々の送信元 IP アドレスを表示する代わりに、読み取り専用ユーザーが OS ソース(iOS、Linux、Windows など)のロールアップのみを表示できるようにします。
  • Telco/Customer Co-Managed モデルの場合、LAN 設定は変更でき、WAN 設定は変更できないロールをカスタマイズできるようになりました。

パスワード ポリシーのセキュリティ強化

パスワードの強度は次のように設定できます。

  • パスワードの最小文字数と最大文字数を設定します。パスワードのデフォルトの最小文字数は 8 文字で、最大文字数は 32 文字です。
  • パスワードに、数字、英小文字、英大文字、特殊文字を組み合わせて、またはすべてを使用する必要があります。デフォルトでは、数字と英小文字を使用する要件が有効になっています。
  • 最もよく使用されているパスワードのリストと一致しないパスワードにする必要があります。
  • パスワードには、同じ文字の繰り返しや、連続する文字(例:「aaaaaa」、「1234abcd」)は使用できません。この機能は、デフォルトで無効になっています。
  • パスワードに、ユーザー ID の全部または一部を含めることはできません。この機能は、デフォルトで無効になっています。
  • 新しいパスワードには、古いパスワードと異なる文字を設定可能な文字数含める必要があります。この機能は、デフォルトで無効になっています。
  • パスワードの有効期限を設定できます。この機能は、デフォルトで無効になっています。有効にすると、デフォルトの有効期限が 30 日になります。
  • 古いパスワードは使用できません。保持できる古いパスワードの数を設定できます。この機能は、デフォルトで無効になっています。有効にすると、デフォルトで、新しいパスワードに 5 つ前までのパスワードを使用できなくなります。

注:これらの設定は、SD-WAN Orchestrator のシステム プロパティでオペレータ ユーザーによって設定され、その Orchestrator のオペレータと、Orchestrator のすべてのカスタマー全体に適用できます。

VMware Horizon

VMware SD-WAN サービスでは、Horizon Blast プロトコルを含む VMware Horizon アプリケーションの完全なカバレッジがデフォルトのアプリケーション マップに含まれるようになりました。これにより、すべてのビジネス ポリシーが VMware Horizon トラフィックと一致し、フロー診断によって VMware Horizon トラフィックが正しく識別されるようになります。

ゼロタッチ プロビジョニング (ZTP) - プッシュ アクティベーション

以前の ZTP では、Orchestrator から E メールの形式で取得されたアクティベーション リンクを使用して Edge をアクティベーションするときに、展開の担当者は物理的に Edge に対してローカルである必要がありましたが、大規模な展開ではスケーリングが不十分でした。ZTP 機能にプッシュ アクティベーションが追加されたことで、カスタマーは Edge を電源とインターネットに接続するだけでアクティベーションできます。

Zscaler の統合

カスタマー エクスペリエンスを向上するための VMware の継続的な Zscaler パートナーシップの一環として、リリース 4.3.0 には、Zscaler シングル サインオン (SSO) の統合とレイヤー 7 健全性チェックのサポートが含まれています。

リリース 4.2.x 以降の Orchestrator API の変更

4.3.0 Orchestrator ソフトウェア リリースの時点で、VMware は、すべてのパブリック VMware SD-WAN Orchestrator API で次の TLS 暗号スイートをサポートしています。

  • TLS_AES_256_GCM_SHA384

  • TLS_AES_128_GCM_SHA256

  • ECDHE-RSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES128-GCM-SHA256

Orchestrator ポータル API(「API v1」)の変更

完全な 4.3.0 VCO Portal API リファレンスは code.vmware.com から参照できます。

以前のリリース ノートでは、API セクションを使用して、Orchestrator ポータル API への変更の広範なリストを列挙していました。ポータル API に影響を与えるリリース間の変更の数が増加し、まったく新しいパブリック API(SD-WAN API v2 など)が継続的に導入されているため、このセクションをより簡潔にするために、このアプローチを再検討することにしました。

リリース 4.3.0 以降、リリース ノートでは、既存の API クライアントに何らかの混乱をもたらすリスクがあるとエンジニアリング チームが特定した変更のサブセットのみをハイライトします。一方 API チームは、ポータル API の包括的な変更ログを、ダウンロード可能なアーティファクトとして API リファレンスとともに code.vmware.com で今後も提供し続けます。他の API についても同様に対応する予定です。

既存の API クライアントの保守担当者は、次のソフトウェアの変更により API の動作に変化が見られることに気づくかもしれません。

  • 問題 53798:enterprise/insertOrUpdateEnterpriseGatewayHandoff への API 呼び出しに対する、より厳密な要求構文の検証の実施。この検証は、API Swagger のドキュメントに表示されるものとまったく同じ要求スキーマに基づいています。
  • 問題 58407:ページ分割された結果セットを生成するすべての API メソッドの「制限」要求パラメータに対して最小値 0 を強制する増分要求検証ロジックの追加(たとえば、event/getOperatorEvents、monitoring/getAggregateEnterpriseEvents、monitoring/getEnterpriseEdgeStatus など)。
  • オブジェクト グループに関連する「CRUD」(作成、読み取り、更新、削除)API メソッドの呼び出しに必要な権限の変更。これらのメソッドには、以前は NETWORK_SERVICE エンティティを管理するための権限が必要でしたが、現在は OBJECT_GROUP リソースを管理するための権限が必要です。標準の Orchestrator ロールが割り当てられているユーザーは、この変更の結果として API の動作が変更されたことに気づくことはありません。 

ドキュメントの改訂履歴

2021 年 6 月 3 日。第 1 版

2021 年 6 月 7 日。第 2 版

  • 新しい Gateway ビルドを追加しました。R430-20210605-GA を最新の Gateway GA ビルドとして追加しました。  このビルドは、このエディションにも追加されている問題 64633 の修正を追加します。

2021 年 6 月 15 日。第 3 版。

  • Orchestrator と Gateway の両方がリリース 4.3.0 にアップグレードされた後、Zscaler タイプの Non SD-WAN Destination ではトンネルが IKEv1 から IKEv2 に変更されるという「重要な注意事項」が追加されました。

2021 年 6 月 16 日。第 4 版。

  • Microsoft による製品の名前変更の結果、2021 年 6 月 16 日より、新機能「Azure Private Edge Zones」が「Azure Private MEC (Multi-Access Edge Compute)」に変更されました。

2021 年 6 月 30 日。第 5 版。

  • 新しいセクション「新しいハードウェア プラットフォームのサポート」を追加しました。このセクションには、次のテキストが追加されました。
    「VMware は、統合された Wi-Fi を含まない新しい SD-WAN Edge ハードウェア モデルを導入する予定です。これには、Edge 510N、Edge 610N、Edge 620N、Edge 640N、および Edge 680N が含まれます。これらの Edge モデルは、Orchestrator ビルド R430-20210615-GA 以降のリリースでサポートされます。VMware SD-WAN/SASE Orchestrator の設定に含まれる Wi-Fi 設定は、これらの Edge モデルに影響を与えません。」
  • 「解決した問題」セクションに新しい Orchestrator ビルド R430-20210615-GA を追加しました。  これは、リリース ノートの一番最初にある新しいデフォルト ビルドでもあります。
  • この新しいビルドによって解決した 2 つの新しい解決済みチケットを追加しました:62355 および 64716

2021 年 7 月 2 日。第 6 版

  • 「解決した問題」セクションに新しい Edge GA ビルド R430-20210702-GA-61583 を追加しました。この Edge ビルドは、新しく解決した問題 #61583 に対応します。

2021 年 7 月 8 日。第 7 版

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

2021 年 7 月 13 日。第 8 版

  • 「Orchestrato で解決した問題」セクションに新しい Orchestrator GA ビルド R430-20210709-GA を追加しました。 
  • この Orchestrator ビルドは、R430-20210709-GA セクションに含まれている解決した問題 #59434、#65526、#65967、#66678、#66679 に対応します。

2021 年 7 月 28 日。第 9 版

  • 「Edge/Gateway で解決した問題」セクションに新しい Gateway GA ビルド R430-20210727-GA-65293-67191 を追加しました。
  • この Gateway ビルドについては、解決した問題 #65293 および #67191 を追加し、該当するセクションで説明しています。
  • 「Orchestrator で解決した問題」セクションに新しい Orchestrator GA ビルド R430-20210719-GA を追加しました。
  • この Orchestrator ビルドについては、解決した問題 #66203 および #67496 を追加し、該当するセクションで説明しています。

2021 年 8 月 5 日。第 10 版

  • 「Orchestrator で解決した問題」セクションに新しい Orchestrator GA ビルド R430-20210729-GA を追加しました。
  • この Orchestrator ビルドについては、解決した問題 #66794 および #68577 を追加し、該当するセクションで説明しています。

2021 年 8 月 17 日。第 11 版

  • 「Orchestrator で解決した問題」セクションに新しい Orchestrator GA ビルド R430-20210810-GA を追加しました。
  • この Orchestrator ビルドについては、解決した問題 #65253 および #69046 を追加し、該当するセクションで説明しています。
  • パスワード ポリシーのセキュリティ強化の文言を修正しました。

2021 年 9 月 8 日。第 12 版。

  • 「Edge/Gateway で解決した問題」セクションに新しい Gateway ビルド R430-20210903-GA-68994-65293-71052 を追加しました。
  • この Gateway ビルドについては、解決した問題 #68994 および #71052 を追加し、該当するセクションで説明しています。
  • 4.3.0 ビルドで見つからないため、未解決の問題 49738 を削除しました。

2021 年 9 月 16 日。第 13 版。 

  • 重要な注意事項」に次の注意事項を追加:AS-PATH プリペンドの BGPv4 フィルタ設定の区切り文字の変更

2021 年 9 月 24 日。第 14 版。

  • 「Edge/Gateway で解決した問題」セクションに新しい Gateway ビルド R430-20210916-GA-VCG を追加しました。
  • この Gateway ビルドについては、解決した問題 #70416、#70590、#70855、#71052、#71513 を追加し、該当するセクションで説明しています。

2021 年 9 月 30 日。第 15 版。

  • 互換表の下に、3.2.x および 3.3.x リリースがサポート終了に近づいているという警告を追加し、ナレッジベースの記事へのリンクを追加しました。  また、その警告を示す表の 3.2.x リリースと 3.3.x リリースのそれぞれに * を付けました。

2021 年 10 月 8 日。第 16 版。

  • 「Edge/Gateway で解決した問題」セクションに新しい Edge ビルド R430-20211007-GA-61583-69704-59629-72423 を追加しました。
  • この Edge ビルドについては、解決した問題 #59629、#69704、#72423 を追加し、該当するセクションで説明しています。

2021 年 10 月 23 日。第 17 版。

  • 「Edge/Gateway で解決した問題」セクションに新しい Gateway ビルド R430-20211020-GA-VCG を追加しました。
  • この Gateway ビルドについては、解決した問題 #63725 を追加し、該当するセクションで説明しています。
  • 4.2.x で解決した未解決の問題 #52104 と、このリリースの前に終了した未解決の問題 #52483 を削除しました。

2021 年 11 月 19 日。第 18 版。

  • 「Orchestrator で解決した問題」セクションに新しい Orchestrator GA ビルド R430-20211112-GA を追加しました。
  • この Orchestrator ビルドでは、追加の解決済みチケットは追加されていませんが、VMware エンジニアリングが必要とするパフォーマンスとトラブルシューティングの変更が含まれています。

2022 年 1 月 4 日。第 19 版。

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

2022 年 3 月 2 日。第 20 版

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

2022 年 3 月 17 日。第 21 版

  • 新機能」に、Edge および Gateway 上の BGP over IPsec に対する次の注意事項が追加されました。この機能は、Edge または Gateway からの Azure Virtual WAN の自動化と互換性がありません。Edge または Gateway から Azure vWAN への接続を自動化するときには、スタティック ルートのみがサポートされます。」
  • 互換性」セクションに、Orchestrator および Gateway のリリース 3.4.x ソフトウェアが 2022 年 3 月 30 日にジェネラル サポートの終了 (EOGS) となり、2022 年 6 月 30 日にテクニカル ガイダンスの終了 (EOTG) を迎えるという新しい警告を追加しました。これは、Orchestrator および Gateway のみが対象です。3.4.x Edge ソフトウェアは、2022 年 12 月 31 日からサポート終了への移行期間に入ります。

2022 年 3 月 24 日。第 22 版

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

2022 年 6 月 7 日。第 23 版

  • Edge/Gateway で解決した問題」セクションに解決した問題 #54493 を追加しました。この問題は、4.3.0 リリース ノートの元のエディションから誤って省略されていました。

2022 年 10 月 3 日。第 24 版。

  • 解決した問題 #59920 を元の GA ビルドR430-20210528-GA の「Edge/Gateway で解決した問題」セクションに追加しました。

解決した問題

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

Gateway で解決した問題

Gateway バージョン R430-20211020-GA-VCG で解決した問題

Gateway バージョン R430-20211020-GA-VCG は 2021 年 10 月 21 日にリリースされ、Gateway バージョン R430-20210916-GA-VCG 以降の以下の重大な問題に対処しています。

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

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

___________________________________________________________________

Edge バージョン R430-20211007-GA-61583-69704-59629-72423 で解決した問題

Edge バージョン R430-20211007-GA-61583-69704-59629-72423 は 2021 年 10 月 8 日にリリースされ、Edge バージョン R430-20210702-GA-61583 以降の以下の重大な問題に対処します。

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

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

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

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

  • 解決した問題 72423:VMware SD-WAN Edge のパブリック DNS サーバが Google DNS でない場合は、Edge が VMware SD-WAN Orchestrator でオフラインになり、アクセスできません。

    このシナリオでは、Orchestrator の Edge 用に設定された DNS サーバは Google DNS ではありませんが、特定のドメイン(*.nyansa.com & *.velocloud.net など)の DNS パケットは引き続き Google DNS サーバ (8.8.8.8 / 8.8.4.4) に送信されます。(これは、想定どおりの動作です。) 

    DNS パケットがカーネルから受信されると、宛先 IP アドレスが Orchestrator で設定されている IP アドレスと同じ場合にのみ転送されます。宛先 IP アドレスが Orchestrator で設定されたものと一致しない場合、Edge はそのパケットを無視します。ただし、Edge はそのパケットを解放しないため、メモリ バッファ リークが発生します。このメモリ バッファ リークは、最終的に Edge が応答しなくなる原因となります。

    この修正を適用せずにカスタマーが実行できる回避策は、Google DNS がすべての Edge のパブリック DNS サーバとして確実に設定されるようにすることです。  アクセスできない状態の Edge の場合、カスタマーは Edge を再起動してリカバリする必要があります。

___________________________________________________________________

Gateway バージョン R430-20210916-GA-VCG で解決した問題

Gateway バージョン R430-20210916-GA-VCG は 2021 年 9 月 24 日にリリースされ、Gateway バージョン R430-20210903-GA-68994-65293-71052 以降の重大な問題に対処します。

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

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

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

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

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

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

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

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

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

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

___________________________________________________________________

Gateway バージョン R430-20210903-GA-68994-65293-71052 で解決した問題

Gateway バージョン R430-20210903-GA-68994-65293-71052 は 2021 年 9 月 4 日にリリースされ、Gateway バージョン R430-20210727-GA-65293-67191 以降の以下の重大な問題に対処します。

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

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

  • 解決した問題 71052:VMware SD-WAN Gateway に接続しているカスタマー エンタープライズの数が 285 を超えると、Gateway でデータプレーン サービスの障害が発生します。

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

___________________________________________________________________

Gateway バージョン R430-20210727-GA-65293-67191 で解決した問題

Edge バージョン R430-20210727-GA-65293-67191 は 2021 年 7 月 28 日にリリースされ、Edge バージョン R430-20210605-GA 以降の以下の重大な問題に対処しています。

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

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

  • 解決した問題 67191:クラウド セキュリティ サービス (CSS) を使用している場合に、その CSS のレイヤー 7 健全性チェックも有効にすると、L7 健全性チェックで誤ったエラーが返され、CSS トンネルが破棄されることがあります。

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

___________________________________________________________________

Edge バージョン R430-20210702-GA-61583 で解決した問題

Edge バージョン R430-20210702-GA-61583 は 2021 年 7 月 2 日にリリースされ、Edge バージョン R430-20210528-GA 以降の以下の重大な問題に対処しています。

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

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

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

___________________________________________________________________

Gateway バージョン R430-20210605-GA で解決した問題

Gateway バージョン R430-20210605-GA は 2021 年 6 月 6 日にリリースされ、Gateway バージョン R430-20210528-GA 以降の以下の重大な問題に対処しています。

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

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

Edge/Gateway で解決した問題

バージョン R430-20210528-GA で解決した問題

Edge バージョン R420-20201218-GA および Gateway バージョン R420-20210208-GA-53243-54800 以降で解決した問題は次のとおりです。

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

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

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

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

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

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

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

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

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

  • 解決した問題 39374:VMware SD-WAN Orchestrator UI で Partner Gateway の順序を変更し、帯域幅テストを手動でトリガすると、プライマリとセカンダリの両方の Gateway パスで帯域幅テストがトリガされます。

    最初に、Partner Gateway の設定変更が実行されると、プライマリ Gateway パスで帯域幅テストがトリガされます。Partner Gateway の順序が変更され、帯域幅テストが手動でトリガされると、帯域幅テストはプライマリ Gateway とセカンダリ Gateway の両方のパスでトリガされます。  割り当てられたすべての Edge の両方のパスの帯域幅テストは、Partner Gateway に大きな負荷をかけ、データプレーン サービスの障害を引き起こす可能性があります。

  • 解決した問題 39501:高可用性トポロジで VMware SD-WAN Edge のペアを使用しているサイトで、HA インターフェイス(GE1 または LAN1 など)が停止すると、Edge はスプリット ブレイン状態になり、両方がアクティブのままになります。

    サイトが回復するまでの 3 ~ 4 分間、カスタマー トラフィックがルーティングされないため、スプリット ブレイン状態の HA サイトは深刻な結果をもたらします。

  • 解決した問題 39654:  高可用性トポロジで VMware SD-WAN Edge のペアを使用しているサイトでは、Edge がアクティブからスタンバイに移行すると、フローの作成中にデータプレーン サービスの障害が発生する可能性があります。

    フローはアクティブ Edge でのみ作成されます。ただし、フロー作成プロセス中に HA 状態がアクティブからスタンバイに移行すると、Edge がスタンバイ状態のときにはソフトウェアがフローの作成を許可しないため、新しいスタンバイ Edge のデータプレーン サービスが失敗します。問題があるのは新しいスタンバイ Edge であるため、カスタマーへの影響は最小限ですが、この問題に関するログがイベントに記録されます。

  • 解決した問題 40124:ユーザーが VMware SD-WAN Orchestrator から VMware SD-WAN Edge 510-LTE の CELL1 インターフェイスを無効にすると、CELL1 インターフェイス トンネルは稼動したままになります。

    Orchestrator から CELL1 を無効にしても、完全には無効にされず、トンネルは稼動したままです。[監視 (Monitor)] ページには、CELL1 インターフェイスも引き続き表示されます。

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

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

  • 解決した問題 43257:VMware SD-WAN Edge の Partner Gateway の割り当てに対して一連の変更が行われると、VMware SD-WAN Partner Gateway からのルートが失われます。

    Partner Gateway が割り当て済み Gateway のリストから削除されると、対応する route_event_queue も削除されます。しかし、Partner Gateway が再度追加されると、対応するセグメントの route_event_queue は作成されません。VeloCloud Routing Protocol (VCRP) ルート イベント ウィンドウの作成がエラーで失敗するため、それ以降のルート分散は適切に行われず、Partner Gateway から Edge へのルート更新が失われます。

    この修正なしでこの問題を解決する唯一の方法は、すべてのセグメントから Partner Gateway を削除し、Gateway を再度追加することです。これにより、特定のピアのセグメント情報が適切に更新されるので、対応する VCRP ウィンドウの再作成に役立ちます。

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

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

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

  • 解決した問題 44832:Edge 経由の Non SD-WAN Destination (NSD) から別の Edge 経由の Non SD-WAN Destination へのトラフィック(「ヘアピニング」または「NAT ループバック」)が VMware SD-WAN Edge 上でドロップされます。

    VMware SD-WAN Edge を介した NSD 間のトラフィックは、リリース 4.3.0 までサポートされていませんでした。Edge を介した BGP over IPsec という新機能の追加により、Edge は他のトラフィックとともに NSD-NSD ヘアピン ルート交換をサポートできるようになりました。

  • 解決した問題 46365:高可用性トポロジで VMware SD-WAN Edge のペアを使用しているサイトでは、ユーザーが SNMP ウォークを実行している場合、スタンバイ Edge の WAN インターフェイスで失敗した結果が表示される場合があります。

    ユーザーがアクティブ デバイスに接続されていない WAN インターフェイスで SNMP ウォークを試みても、ローカル カーネルが WAN リンクを認識していないため、応答が返されません。

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

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

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

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

    Spoke1 <-vcmp-> ハブ <-GEx-> 外部ファイアウォール <-GEx-> ハブ Edge <-vcmp-> Spoke2

    このトポロジでは、Spoke1 からのトラフィックは VeloCloud Management Protocol (vcmp) を介してハブに送信され、次に物理ポートを介して外部ファイアウォールに送信され、その後ハブに戻り、vcmp を介して Spoke2 に到達します。Spoke1 から Spoke2 へのパケットはハブ Edge を 2 回通過する必要があることに注意してください(最初は Spoke1 からファイアウォールに移動し、2 回目はファイアウォールから Spoke2 に移動します)。リリース 3.4.0 以前では、ハブ Edge がハブ内のパケットを処理するための 2 つの個別のフロー(つまり、Spoke1 と外部ファイアウォール間のパケットを処理するフローと、Spoke2 と外部ファイアウォール間のパケットを処理するフロー)を作成するため、このシナリオは適切に機能していました。

    フローが作成され、パケットがフローに分類される方法が変更されたため(リリース 3.4.0 で導入)、このシナリオではハブ Edge で 1 つのフローのみが作成されます。これにより、外部ファイアウォールからのリターン トラフィックが、送信元のスポークに返されます。

    この修正を適用しない場合、この問題の唯一の回避策は、クラウド VPN を設定してブランチ間 VPN を有効にし、[VPN にハブを使用 (Use Hubs for VPN)] を選択することです。

  • 解決した問題 48211:ファイアウォールが有効になっている VMware SD-WAN Edge では、Edge のデータプレーン サービスの再起動中に、「リソースが利用できません」エラーが原因で一部の iptable ルールがインストールされない場合があります。

    iptable ルールの挿入を -w オプションを指定せずに呼び出すと、「リソースが利用できません」エラーが発生する可能性があります。この障害に対する再試行メカニズムがないため、iptable ルールが欠落します。

    この修正を適用しない場合、「リソースが利用できません」エラーが表示されたときに問題を解決する唯一の方法は、手動で -w オプションを指定して iptable ルールをインストールすることです。

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

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

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

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

  • 解決した問題 51025:VMware SD-WAN Edge で WAN リンクがフラップする(アップ状態とダウン状態が急速に切り替わる)場合、ルーティング インターフェイスのデフォルト ゲートウェイのルート テーブル エントリが削除され、再適用されない場合があります。

    Edge でこの問題が発生すると、リンク フラップが発生し、そのリンクを使用するインターフェイスのデフォルト ゲートウェイのルート エントリが削除され、インターフェイスのルート テーブルが空になります。ただし、空のルート テーブルが残っている場合、Linux 接続トラッキング (conntrack) はデフォルトで次のテーブルにルーティングし、すべてのパケットが誤ったルーテッド インターフェイスを介して出力されます。

  • 解決した問題 51165:API は、無効なエンタープライズ プロファイル ID を使用して VMware SD-WAN Edge を作成しようとすると、「500 Server Error」を返します。

    ユーザーが、configurationId として Edge 固有のプロファイル ID を持つペイロードを使用して「POST /sdwan/enterprises/{logicalId}/edges/」を送信するか、最初のエンタープライズに属する configurationId を使用して「POST /sdwan/enterprises/{logicalId of the second enterprise}/edges/」を送信すると、「500 Internal Server Error」が返されます。このシナリオで期待される結果は、API が「422 Unprocessable Entity」または一般的な「400 Bad Request」という無効なエンタープライズ設定 ID を示すエラー メッセージで応答することです。

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

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

  • 解決した問題 51502:動的なブランチ間トンネルは、ブランチ間 VPN が有効になっていない VMware SD-WAN Edge によって受け入れられます。

    Edge は、ブランチ間 VPN が有効になっていない場合でも、常に動的トンネルに応答します。一方の側が [プロファイル内の Edge へ (To Edges within Profile)] に設定され、もう一方の側が [すべての Edge へ (To All Edges)] に設定されている場合でも、トンネルを形成できます。  受信トンネルは制御できないため、フィールドへの影響があります。あるフィールド ケースでは、ブランチ Edge が他のリージョンのハブ Edge への動的トンネルを形成し、エンタープライズのバックボーンで他のルーティングの問題を引き起こします。

  • 解決した問題 51837:ユーザーが一部の DHCP オプションに数値/整数値を設定すると、VMware SD-WAN Edge で dnsmasq が失敗します。

    この問題は DHCP オプション 43 に固有のものであり、このオプションの設定時に数値が機能することを確認するための検証が追加されています。

  • 解決した問題 52710:VMware SD-WAN Orchestrator に表示される高可用性の状態が正確でない場合があります。

    VMware SD-WAN Edge が Orchestrator にプッシュしない 1 つの状態は「失敗」です。スタンバイ Edge が停止したり、アクティブ Edge がスタンバイ Edge と通信できないなどのシナリオでは、HA 状態が Orchestrator に正しく表示されません。これは、「失敗」が使用可能な状態ではないため、Edge から Orchestrator に送信されるデータが正しくないことが原因です。

  • 解決した問題 52991:VNF も展開されている高可用性用に設定された VMware SD-WAN Edge のペアは、VNF がパワーオフされたときに誤った HA 状態を出力します。

    VNF がパワーオフされた後、VNF がアクティブでないため VNF HA の状態は 0 として表示されます。VNF がパワーオフされると VNF HA の状態は監視されないため、Orchestrator には VNF がパワーオンされたときの前回の状態が表示されます。

  • 解決した問題 53159:高可用性トポロジに展開され、VNF も使用するサイトでは、DHCP サーバの IP 範囲がスタンバイの VNF と一致する場合、スタンバイ VNF に割り当てられた IP アドレスは、VMware SD-WAN Edge 上の DHCP サーバによって、接続された LAN 側のクライアントに割り当てられる可能性があります。

    スタンバイ VNF の IP アドレスは、予約済み、またはすでに使用されている IP アドレスには追加されません。その結果、DHCP サーバがスタンバイ VNF の IP アドレスをクライアント デバイスに提供する可能性があります。

  • 解決した問題 53518:VMware SD-WAN Gateway で snmpwalk をローカルで実行すると、正常に動作しません。

    Gateway で snmpwalk を実行すると、次の問題が発生します。

    1. 不正なパス インデックス。{vcgVceUUID, vcgPathIfIntId, vcgPathGwAddrType, vcgPathGwAddr } で構成されている必要があります。
    2. 一貫性のないパス カウンタ。パス カウンタは debug.py --v --path で見つかったすべての ALIVE パスを表すことが期待されます。
    3. 一貫性のない ARP カウンタ。Gateway の snmpagent は、ALIVE エントリと DEAD ARP エントリの両方を含むカウンタをレポートしますが、ALIVE エントリの詳細のみを表示します。ALIVE のみのエントリまたはすべてのエントリのいずれかをレポートすることが期待されます。
    4. デフォルトで他のすべての IP アクセスを許可するように snmpd.conf を更新します。
  • 解決した問題 53415:Edge Network Intelligence (ENI) が有効になっているカスタマー エンタープライズにおいて、エンタープライズの VMware SD-WAN Edge で Wi-Fi が有効になっている場合、ENI ページに Wi-Fi アクセス ポイントの誤った MAC アドレスが表示されることがあり、アクセス ポイントの IP アドレスは 160.254.3.1 と表示されます。

    この問題は、Wi-Fi アクセス ポイントの MAC アドレスが「selfMacAddress」と呼ばれる値に設定され、アクセス ポイントの IP アドレスが ENI ページで常に 160.254.3.1 に設定されている場合に発生します。この修正により、Wi-Fi インターフェイス wlan0 から MAC アドレスが取得され、分析インターフェイスの IP アドレスが取得されます。

  • 解決した問題 53551:コマンドラインの activate.py ツールを使用して VMware SD-WAN Gateway をアクティベーションすると、アクティベーションが正常に進行している間、「zmq という名前のモジュールがありません」というメッセージが表示されます。

    この誤ったメッセージは、すべての Gateway アクティベーションに対して表示されます。ただし、アクティベーション プロセスに影響を与えることはありません(表示されるだけです)。

  • 解決した問題 53651:拡張高可用性トポロジを使用しているカスタマーのサイトで、Edge サービスの再起動が必要な VMware SD-WAN Edge デバイス設定を変更すると、連続して 2 回の HA フェイルオーバーが発生する場合があります。

    デバイスの設定を変更するために Edge サービスの再起動が必要な場合に、設定の処理中に Edge サービスが再起動される前に、HA モジュールが LAN/WAN 数を誤って VMware SD-WAN Gateway に更新します。その結果、最初の HA フェイルオーバーが発生し、スタンバイへの降格の一環として現在のアクティブ Edge のサービスが再起動すると、Gateway は新しいスタンバイ Edge の LAN/WAN 数が多いと誤解し、新しく昇格したアクティブ Edge にフェイルオーバー コマンドを送信して、2 回目のフェイルオーバーが発生します。

    注:サービスの再起動をトリガする可能性がある Edge 設定の変更のリストについては、ナレッジ ベースの記事「VMware SD-WAN Edge configuration changes that can trigger a service restart (60247)」を参照してください。

  • 解決した問題 53676:VMware SD-WAN Edge 3x00 プラットフォームでは、入力電圧が 4 ミリ秒という非常に短い時間不安定になると、Edge が再起動する可能性があります。

    この問題は通常、ラインからバッテリに切り替えるときに、出力電圧がわずかに不安定になる無停電電源装置 (UPS) を使用している場合に発生します。この問題の修正により、Edge の再起動前に 20 ~ 30ms の電圧の不安定さを許容するように Edge のファームウェアがアップグレードされます。

    注:リリース 3.4.5 または 4.0.2 を使用したときに Edge のファームウェアがアップグレードされていなかった場合に、3x00 のファームウェアをアップグレードすると、Edge のアップグレード時間が 3 ~ 5 分に延長されます。

    Edge 3x00 モデルでこの修正を適用しない場合、カスタマーの唯一の選択肢は、出力電圧が不安定になることなく入力を切り替えることができる、より高度な UPS を使用することです。 

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

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

  • 解決した問題 53789:ESXi で実行している VMware SD-WAN Virtual Edges で、/var/log/messages に 30 秒ごとに誤ったエラー メッセージが表示されます。

    誤ったエラー メッセージが「GuestInfoGetDiskDevice: Missing disk device name; VMDK mapping unavailable for "/", fsName: "/dev/root" 」と表示され、常に /var/log/messages のログに記録され、/var/log/messages およびそれに対応する保存済みの /velocloud/log/messages* がいっぱいになります。このため、影響を受ける Edge のログを参照するときに、より重要なメッセージがローテーションされ、失われてしまいます。

  • 解決した問題 53828:高可用性のフェイルオーバー後、「Gateway 経由のクラウド (Cloud via Gateway)」トラフィックは、「クラウドに直接 (Direct to Cloud)」トラフィックに切り替わります。

    HA フェイルオーバー後、トラフィックが VMware SD-WAN Edge に到達したときに VMware SD-WAN Gateway へのパスが稼動していない場合、トラフィックは「Gateway 経由のクラウド (Cloud via Gateway)」ではなく「クラウドに直接 (Direct to Cloud)」になります。  「クラウドに直接 (Direct to Cloud)」トラフィックは動的マルチパス最適化と DMPO で利用可能な付随する拡張機能を使用しないため、これは機密性の高いカスタマー トラフィックにとっては好ましくありません。

  • 解決した問題 53929:拡張高可用性トポロジを使用しているカスタマー サイトで、HA フェイルオーバーが発生すると、「Gateway 経由のクラウド」フローが「クラウドに直接」パスに切り替わります。

    HA フェイルオーバー後、トラフィックが VMware SD-WAN Edge に到達したときに VMware SD-WAN Gateway へのパスが稼動していない場合、トラフィックは「Gateway 経由のクラウド (Cloud via Gateway)」ではなく「クラウドに直接 (Direct to Cloud)」になります。ダイレクト トラフィックはこれらの最適化を使用しないため、これはリアルタイム トラフィック(音声やビデオなど)などの動的マルチパス最適化に依存するフローに大きな影響を与える可能性があります。

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

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

  • 解決した問題 54493:オペレータ管理者やパートナー管理者が、VMware SD-WAN Gateway 上の Edge トラフィックでハンドオフ キューのドロップ数が増加していることを確認する場合があります。 

    この問題において、Gateway での CPU 使用率の問題や DPDK ドロップはありません。この問題は、制御プレーン イベント(ルートの再計算など)によってトリガされ、Gateway での Edge パケットのドロップが、Gateway のパイプライン内の異なるスレッドへのハンドオフ中に発生します。この問題の原因は、パケット バッファリングのキュー サイズの大きさが不十分であることです。

  • 解決した問題 54694:カスタマーが SNMP ポーリングを使用すると、SNMP 監視は送信トラフィックに不正確な測定を提供します。

    IF-MIB::ifHCOutOctets の SNMP 呼び出しは TX バイトではなく TX パケットを提供します。このため、送信オクテット数が不正確となり、エンタープライズを監視する機能に影響します。この問題は、TX パケットと TX バイトの snmpagent プロセスの監視が原因で発生します。

  • 解決した問題 55182:Non SD-WAN Destination のルートは、refresh-route を選択せずに変更されます。

    OFC(オーバーレイ フロー制御)のグローバル設定の順序または NSD-global-advertise フラグが変更されると、ルートの更新オプションがオンになっていない場合でも、NSD ルートに影響を与える変更が適用されます。これは、IPsec トンネルのフラッピングが原因で発生しました。

  • 解決した問題 55349:サイトが以前に HA で VNF を展開し、VNF がアクティブなときにユーザーが HA を無効にした場合、高可用性トポロジで VNF を展開しているサイトで HA フェイルオーバーが発生し、VNF イメージはダウンロードされません。

    VNF HA が VMware SD-WAN Edge の HA ペアに展開されている場合、以前に展開され、同じ Edge で稼動している VNF HA を展開解除した後、展開の進行中(すなわちイメージのダウンロード フェーズ)に、HA フェイルオーバーが発生します。これは、スタンバイ Edge が VNF が稼動していると想定しているためです。この突然のフェイルオーバーにより、アクティブ Edge は VNF イメージのダウンロードを停止し、VNF は両方の Edge で展開されません。この修正を適用しない場合、ユーザーは HA Edge を再起動する必要があります。

  • 解決した問題 55827:BGP ネイバー関係に MD5 認証が含まれる BGP セッションの確立が失敗する場合があります。

    特殊文字で設定された BGP MD5 パスワード(たとえばパスワード「$123」の「$」)に問題があり、ピアとの BGP セッションを形成しません。  この修正を適用しない場合、推奨されるアクションは、BGP MD5 パスワードをプレーン テキストで設定することです。

  • 解決した問題 55949:Gateway 経由の Non SD-WAN Destination (NSD) トンネルが停止し、一定期間リカバリされない場合があります。

    VMware SD-WAN Gateway が他の NSD 宛先で IKE(インターネット キー交換)の再キー化をトリガし、ネゴシエーションの途中でネットワークの問題が原因で再キー化の試行が成功しない場合、IKE の再キー化は再試行を続けます。リンクが再度確立されると、Dead Peer Detection (DPD) イベントによって、新しく作成されたフェーズ 1 の Security Association (SA) が削除される可能性があります。これにより、一部のピア(特に Zscaler)では IPsec SA も削除されます。ピアが IPsec SA を削除すると、Gateway によって検出できなくなり、トンネルは次の再キー化時間まで停止します。  この修正なしで、この再キー化を強制する唯一の方法は、影響を受ける NSD を VMware SD-WAN Orchestrator を介して無効にし、再び有効にすることでトンネルをバウンスすることです。

  • 解決した問題 56149:BGP を使用しているカスタマー エンタープライズで動的コスト計算 (DCC) を有効にした後、アンダーレイ ルートの BGP ルートがフラップすると、VMware SD-WAN Edge に自動修正ルートのルート設定値が正しく表示されないことがあります。

    カスタマーへの影響としては、リモート ルートの設定が正しくないためにルーティングが非対称になります。これにより、すべてのカスタマー アプリケーションで待ち時間が長くなり、パフォーマンスが低下します。DCC を有効にした後、ルート上で新しいルーティング情報ベース (RIB) 設定値を更新し、新しい RIB 設定値を使用してルートを VMware SD-WAN Gateway に再広報して、すべての Edge に通知する必要があります。この問題の原因は、ルートが自動修正されたときに、この RIB 設定がピア Edge の FIB テーブルで更新されず、DCC 有効化以前の古い値が保持されることです。 

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

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

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

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

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

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

  • 解決した問題 56876:動的なブランチ間 VPN を実行する VMware SD-WAN Edge は、Edge メモリが実際にリークしていない場合でも、使用可能なメモリを使い果たしてカーネル パニックを引き起こす可能性があります。

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

  • 解決した問題 56931:Edge 経由の Non SD-WAN Destination (NSD) を設定したカスタマー サイトで、VMware SD-WAN Orchestrator ユーザー インターフェイスに表示される Edge の健全性統計が正しくない場合があります。

    NSD が Edge から設定されている場合、SD-WAN サービスは再起動後に初めて開始時刻が 0 の健全性統計情報を Edge から Orchestrator に送信します。その結果、Edge の再起動後に Orchestrator に誤ったデータが表示されます。

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

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

  • 解決した問題 57169:マルチホップ BGP ピアに到達できない場合でも、ユーザーは宛先のない BGP ルートの存在を確認します。

    非グローバル セグメントの場合、ネクスト ホップ トラッキング (NHT) のアップデート メッセージは、到達不能になったときに BGP プロセスによって処理されません。その結果、マルチホップ BGP ピアが到達不能になったときに、BGP で学習したルートがすぐに削除されない場合があります。それらは、BGP ホールド タイマーが期限切れになり、ネイバーシップが停止した場合にのみ削除されます。

  • 解決した問題 57644:ネクスト ホップが到達不能になっても、BFD セッションは停止しません。

    非グローバル セグメントの BFD セッションは、BFD ピア IP アドレスに到達するためのスタティック ルートが削除されたときに停止しません。これは、ピア IP アドレスに到達するために使用できるルートがないことを意味します。

  • 解決した問題 58061:PPPoE インターフェイスの情報を SNMP 経由で取得できません。

    IFMIB SNMP ウォークでは、PPPoE が設定されている WAN インターフェイスに関する情報は表示されません。

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

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

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

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

  • 解決した問題 58282:デフォルト ルートに一致するプライベート IP アドレス範囲を宛先とするフローは、ビジネス ポリシーでネットワーク サービスが「直接 (Direct)」、リンク ステアリングが「必須 (Mandatory)」に設定されている場合にのみ許可されます。

    プライベート IP アドレス範囲へのパケットは、それがデフォルト ルートと一致し、宛先がマルチパスである場合、VMware SD-WAN Edge でドロップされます。宛先が「直接 (Direct)」の場合、パケットはドロップされません。パケットは、ビジネス ポリシーでリンク ステアリングが「必須 (Mandatory)」として設定されている場合にのみ許可されます。

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

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

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

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

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

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

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

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

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

  • 解決した問題 58985:BGP および BFD セッションが同じ local_ip で設定されている場合。BFD/BGP の local_ip が変更されると、local_ip を使用している他のセッションが停止します。

    BGP と BFD は、別々の local_ip テーブルを使用します。local_ip BFD 設定が変更されると、BFD local_ip がチェックされます。BFD が IP アドレスを使用しなくなったため、対応するエントリが共通の local_routes テーブル(BGP および BFD によって使用される)から削除されます。これは、BGP が引き続き local_ip を使用しているため、BGP に影響を与えます。この修正により、BFD/BGP の local_ip が更新されたときに、他のプロセスがまだ local_ip を使用しているかどうかを確認するためのチェックが実行されます。
    使用されている場合、削除は無視されます。

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

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

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

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

  • 解決した問題 59820:一部のシナリオでは、VMware SD-WAN スポーク Edge が状態劣化したプライマリ ハブ Edge とのトンネルを形成する場合があります。

    この問題は、スポーク Edge が 3.X リリースを実行し、ハブ Edge と VMware SD-WAN Gateway が 4.X リリースを実行する相互運用性のシナリオで発生します。DCE 制御メッセージが誤って解釈され、その結果、スポーク Edge が状態劣化したプライマリ ハブ Edge とのトンネルを形成します。これは、Gateway によってスポーク Edge に送信されるこの DCE メッセージの形式が正しくないことが原因です。

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

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

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

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

    この問題が修正されていないビルドを使用している Edge では、メンテナンス期間中にのみ Edge インターフェイスを変更する必要があります。

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

    620 または 640 で HA が有効になっている場合、スタンバイ Edge はアクティブ/アクティブ パニックを検出し、アクティブ/アクティブ状態から回復するために再起動する場合があります。

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

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

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

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

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

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

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

  • 解決した問題 61388:BGP ピアリングに使用される SNP ルートは、そのプレフィックスがいずれかの BGP ピアから受信された場合、リモート Edge に広報されます。

    カスタマーが BGP 経由で BGP ピアシップに使用される local_ip を広報すると、BGP 動的ルートの代わりに、他のピアに広報されるのと同じプレフィックスのデータセンター スタティック ルートが作成されます。

  • 解決した問題 61400:[Gateway 経由の Edge 間 (Edge-to-Edge via Gateway)] または [動的な Edge 間 (Dynamic Edge-to-Edge)] のいずれかが有効になっているカスタマー エンタープライズでは、ユーザーが ICMP パケットを送信すると、2 つの異なる MTU 値が表示される場合があります。

    ユーザーがインターフェイスの MTU 値を設定し、DF ビットが設定されたパケットを VMware SD-WAN Edge に送信すると、Edge は 2 つの異なる MTU 値を持つ 2 つの異なる ICMP エラー メッセージを返す場合があります。異なる値は、インターフェイス MTU とトンネル MTU を表します。  これは 1 日目の問題であり、カスタマーへの影響はありません。

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

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

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

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

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

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

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

  • 解決した問題 61739:VMware SD-WAN Edge は、誤った IP アドレスを VMware SD-WAN Orchestrator にレポートしているため、[監視 (Monitor)] ページに間違った IP アドレスが表示されます。

    これは、[監視 (Monitor)] > [Edge] > [送信元/宛先 (Sources/Destinations)] および新しいクライアント デバイス イベントの Edge イベントで確認できます。リース タイマーを延長しようとする Edge に接続されたクライアント デバイスは、リース延長を要求するパケットを送信します。Edge がこのパケットを受信するとすぐに、[監視 (Monitor)] ページの [送信元 (Source)] タブでクライアント デバイスの送信元 IP アドレスが反転します。これは表面的な問題と見なされており、不正確なデータによる混乱はあっても、基盤となる機能に影響を与えることはありません。

  • 解決した問題 62004:VMware SD-WAN Edge は、Edge で実行されているプロセスの実際のメモリ使用率が少ない場合でも、高いメモリ使用率を VMware SD-WAN Orchestrator にレポートします。

    Edge は、/proc/meminfo ファイルを読み取ってシステム メモリ使用率を計算します。計算では、空きメモリ、バッファ、およびキャッシュされたメモリが合計メモリから除外されてメモリ使用率が求められます。Edge はスラブの再利用可能なメモリを合計メモリから除外しないため、再利用可能なメモリが多い場合、レポートされるメモリ使用率が高くなることがあります。  これにより、実際には有効ではない Edge の高いメモリ使用率がユーザーに表示されます。

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

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

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

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

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

Orchestrator で解決した問題

Orchestrator バージョン R430-20211221-GA

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

    ___________________________________________________________________

    Orchestrator バージョン R430-20211112-GA

    Orchestrator バージョン R430-20211112-GA は 2021 年 11 月 16 日にリリースされました。この Orchestrator ビルドでは、Orchestrator バージョン R430-20210810-GA 以降に解決した新しい問題は追加されていませんが、VMware エンジニアリングが必要とするパフォーマンスとトラブルシューティングの変更が含まれています。

      ___________________________________________________________________

      Orchestrator バージョン R430-20210810-GA で解決した問題

      Orchestrator バージョン R430-20210810-GA は 2021 年 8 月 12 日にリリースされ、Orchestrator バージョン R430-20210729-GA 以降の 1 件の新しい重大な問題に対処しています。

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

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

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

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

      ___________________________________________________________________

      バージョン R430-20210729-GA で解決した問題

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

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

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

      • 解決した問題 68577:VMware SD-WAN Orchestrator をリリース 4.3.0 にアップグレードすると、ユーザー インターフェイスが機能しなくなり、IPv6 のデフォルト値が失われることがあります。

        Orchestrator のユーザー インターフェイスで、プロファイルをロードできなくなり、Orchestrator の Web ページが無期限にハングした状態で他の設定が保存されません。この問題は、アップグレード中に Orchestrator によって無効な設定が検出された場合に発生し、「パッチ アプリケーションの障害」がトリガされます(Orchestrator イベントに記録されます)。無効な設定によってパッチ障害がトリガされると、IPv6 オブジェクトを含むパッチ キュー内の他の設定がスキップされます。  不明な IPv6 関連オブジェクトが投入されていることが想定されるため、Orchestrator のユーザー インターフェイスがページのロードに失敗します。

      ___________________________________________________________________

      バージョン R430-20210719-GA で解決した問題

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

      • 解決した問題 66203:パートナー管理者が、VMware SD-WAN Orchestrator のパートナー管理 Gateway とクラウド ホスト Gateway の両方を含む Gateway プールが割り当てられているカスタマーの Partner Gateway Hand Off を編集できません。

        Gateway のハンドオフは、Orchestrator の [設定 (Configure)] > [カスタマー (Customer)] ページで設定します。パートナー管理 Gateway とクラウド ホスト Gateway (VMware によって管理される Gateway)を含む混合 Gateway プールがカスタマーに割り当てられている場合、パートナー管理者は管理対象 Gateway の Gateway ハンドオフ設定を変更できません。

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

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

      ___________________________________________________________________

      バージョン R430-20210709-GA で解決した問題

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

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

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

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

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

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

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

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

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

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

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

      ___________________________________________________________________

      バージョン R430-20210615-GA で解決した問題

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

      • VMware SD-WAN Edge モデル 510N、610N、620N、640N、および 680N のサポート。

        Orchestrator ビルド R430-20210615-GA は、Edge モデル 510N、610N、620N、640N、および 680N をサポートします。これらのモデルには統合された Wi-Fi は含まれません。詳細については、リリース ノートの前述の「新しいハードウェア プラットフォームのサポート」セクションを参照してください。 

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

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

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

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

      ___________________________________________________________________

      バージョン R430-20210527-GA で解決した問題

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

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

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

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

      • 解決した問題 29701:ユーザーは、VMware SD-WAN Orchestrator ユーザー インターフェイスを使用するときに、ルーティングされたインターフェイスの IP アドレスをネットワーク ID 形式で設定できます。

        ユーザーがネットワーク ID タイプの形式(「1.2.3.0」など)を使用してルーティングされたインターフェイスの IP アドレスを設定した場合、Orchestrator はチェックを行わず、エラーもスローしません。このエラーが捕捉されないと、カスタマーのトラフィック フローで問題が発生する場合があります。この問題の修正により、ルーティングされたインターフェイスの IP アドレスに対して検証が確実に実行され、形式が正しくない場合はエラーがスローされます。

      • 解決した問題 30066:カスタマーの [Gateway] ページでは、Partner Gateway が割り当てられているにもかかわらず、Partner Gateway の数がゼロとして表示されます。 

        VMware SD-WAN Orchestrator は、間違ったパラメータを使用して、Partner Gateway が割り当てられているかどうかを判断します。その結果、条件は常に「false」と表示され、カウントはゼロとして表示されます。  この修正は、正しいパラメータを使用して Partner Gateway が割り当てられているかどうかを確認し、正しい Partner Gateway の数が表示されるようにします。

      • 解決した問題 31416:大規模なカスタマー エンタープライズでは、設定の更新が完了するまでに 6 分以上かかり、その結果、タイムアウトになる場合があります。 

        大規模なカスタマー エンタープライズとは、少なくとも 16 のセグメント、少なくとも 50 台のハブ Edge と 10K のスポーク Edge を持つものと理解されています。ユーザーは、10K のスポーク Edge にスポーク プロファイルを割り当て、50 台のハブ Edge にハブ プロファイルを割り当て、Edge 間は、スポーク プロファイルの各セグメントで 5 台のハブ Edge を介して設定されます。  このようなエンタープライズでは、設定の更新に時間がかかり、タイムアウトが発生して、管理者がネットワークを設定する能力に大きな影響を及ぼす場合があります。この修正により、この規模のエンタープライズであっても設定の更新を正常に完了することが保証されます。

        この修正を適用せずにユーザー インターフェイスでタイムアウトを防ぐ唯一の方法は、非同期 API (session.options.asyncPollingMaxCount: 50) を有効にするか、vco.enterprise.events.configuration.diff.enable を「False」に設定することでした。後者は設定の差分イベントを無効にしますが、設定関連の API の全体的なパフォーマンスが向上します。

      • 解決した問題 33026:ユーザーが VMware SD-WAN Orchestrator ユーザー インターフェイスの [ユーザー契約書 (User Agreements)] ページからエンド ユーザー サービス契約 (EUSA) を削除すると、ページが正しく更新されません。

        ユーザーが EUSA の最後のエントリを削除すると、ページを更新する必要がありますが、Orchestrator は更新をトリガしません。この修正により、ページ更新の検証ロジックが書き換えられ、期待どおりの結果が得られます。

      • 解決した問題 38536:VMware SD-WAN Orchestrator を使用しているときに、「アイテムの処理中にエラーが発生しました。再試行してください」というエラーが発生し、VMware SD-WAN Edge を削除できません。

        この問題は、Edge のネットワーク割り当てがデータベースに存在しないために発生し、これにより Edge を削除するプロセスが中断されます。

      • 解決した問題 39035:多数の Edge、プロファイル、およびセグメントを持つカスタマー エンタープライズの場合、管理者がセグメント タイプを変更しようとすると、設定の適用が完了するまでに時間がかかるため、プロセスがタイムアウトし、設定の変更が適用されません。

        大規模なカスタマー エンタープライズとは、3K を超える Edge を持ち、「Gateway 経由の Edge 間」が有効になっている単一のプロファイルで 1K を超える Edge がアクティベーションされ、各 Edge が 16 セグメントで設定されているものと理解されています。  このような状況では、セグメントの変更が所定の時間枠(6 分)以内に完了せず、タイムアウトになる場合があります。

      • 解決した問題 42243:ユーザーは、IP アドレスとドメイン名の両方を含むファイアウォール ルールを編集できません。

        [ファイアウォール ルール (Firewall Rule)] ページで確認できる IP アドレスとドメイン名の両方を使用してファイアウォール ルールを作成すると、ユーザーはこのルールを変更できなくなります。  たとえば、ドメイン名を削除すると、「以下の問題を修正して、再試行してください」というエラーがスローされます。ここでの問題は、そのドメイン名を削除したことです。

      • 解決した問題 44755:Edge がパワーオンされ、VNF 挿入が実行された VMware SD-WAN VNF Edge を使用しているサイトの場合、ユーザーが [Edge] > [監視 (Monitor)] リストから CSV をダウンロードすると、状態が [パワーオン (挿入が有効になっていません) (Powered On (Insertion Not Enabled))] と誤って表示されます。

        この問題は、ダウンロードされた CSV レポートにのみ影響します。  VMware SD-WAN Orchestrator のユーザー インターフェイスには、有効になっている VNF Edge の正しい状態 [パワーオン (挿入が有効) (Powered On (Insertion Enabled))] が表示されます。

      • 解決した問題 45293:VMware SD-WAN Edge で Edge 上書きを使用して VLAN オプション [ICMP エコー応答 (ICMP Echo Response)] がオフになっている場合、その後 Edge 上書き自体がオフになると、Edge はこのオプションのプロファイル設定を使用するように強制されますが、Edge はプロファイルの [ICMP エコー応答 (ICMP Echo Response)] 設定を使用せず、プロファイルでオンになっている場合でも、このオプションはオフのままです。

        これは、特定の Edge VLAN が ICMP パケットに ping を返すことを期待しているカスタマーに影響を与え、VMware SD-WAN Orchestrator は、Edge がプロファイルから設定をプルする必要があるためそのように設定されていることを示します。 

      • 解決した問題 46254:新たにアクティベーションされた VMware SD-WAN Edge では、1 つ以上のルーティング インターフェイスに DHCP および VLAN 設定が存在しない場合があります。

        E メールのアクティベーション URL には、アクティベーション E メールの送信時にユーザーがその Edge 用に作成した Edge 固有の設定全体を含める必要があります。この問題により、Edge に DCHP 対応インターフェイスの VLAN 設定がある場合、E メール リンクに Edge の DHCP および VLAN 設定が含まれていない可能性があり、Edge がアクティベーションされると、ユーザーは VMware SD-WAN Orchestrator 上でその Edge に対するこれらの設定が欠落していることを確認します。

      • 解決した問題 46996:ユーザーが VMware SD-WAN Orchestrator を使用して VMware SD-WAN Edge をあるプロファイルから別のプロファイルに切り替えると、ブラウザ画面がフリーズし、続行するにはブラウザの更新が必要になる場合があります。

        [設定 (Configure)] > [Edge] を使用してプロファイルの切り替えを確認すると、Orchestrator ユーザー インターフェイス画面が灰色になり、更新が実行されるまでそのままになります。  プロファイルを変更するアクションは実際には成功しており、ブラウザの更新を実行すると確認できます。 

      • 解決した問題 47990:VMware SD-WAN Orchestrator でスタティック ルートを設定しているときに、ユーザーには [インターフェイス (Interface)] オプションが表示されない場合があります。

        ユーザーが IP アドレスを使用して VLAN インターフェイスを設定し、後でその IP アドレスを削除した場合、スタティック ルートを作成しようとすると、Orchestrator はルートが VLAN インターフェイス用であると見なし、スタティック ルート エントリの [インターフェイス (Interface)] オプションを選択することができません。ユーザーは設定を保存でき、ルートはルート テーブルに表示されますが、到達可能性フラグは「FALSE」として表示されます。

      • 解決した問題 48068:ビジネス ロールを持つオペレータには、VNF が使用されている場合でも、その VNF を削除するオプションがあります。

        ビジネス ロールを持つオペレータが使用中の VNF を削除した結果、Orchestrator はユーザー インターフェイスに「予期しないエラーが発生しました」というメッセージをスローします。

      • 解決した問題 48131:ビジネス ロールを持つオペレータが、ディザスタ リカバリ (DR) を使用するように設定された VMware SD-WAN Orchestrator のスタンバイ インスタンスにログインすると、ブラウザ ページを読み込み中と表示されますが、実際には読み込まれていません。

        ブラウザを更新してもこの問題は解決されません。この問題に対するこの修正には、ビジネス ロールを持つオペレータに、Orchestrator の正しいインスタンス(つまり、ペアのアクティブ インスタンス)にログインするように指示するエラー メッセージが含まれています。

      • 解決した問題 48459:カスタマー サポートのロールを持つカスタマー管理者が、VMware SD-WAN Orchestrator で Non SD-WAN Destination (NSD) の [ローカル認証 ID (Local Auth ID)] セクションを表示できません。

        カスタマー サポート ユーザーは、Orchestrator の [設定 (Configure)] > [ネットワーク サービス (Network Services)] セクションを参照して、NSD の詳細を確認します。この問題は、Orchestrator の読み取り専用ファイルにローカル認証 ID の詳細を表示するためのコードが欠落しているために発生します。  この修正により、サポート ユーザー向けにローカル認証 ID を読み取り専用モードで表示するための対応するコードとファイルが追加されます。

      • 解決した問題 48461:ユーザーが Edge レベルでアラートをオフにした場合、その設定はコンピュータ セキュリティ サービス (CSS) トンネル アラートに適用されません。

        [設定 (Configure)] > [Edge] > [概要 (Overview)] に移動し、[アラートの有効化 (Enable Alerts)] ボックスをオフにすることで、特定の VMware SD-WAN Edge のアラートをオフにすることができます。このボックスをオフにすると、Edge はいかなる理由があっても、どのタイプのアラートも送信しないことが期待されます。ただし、Edge が CSS を使用するように設定されている場合、アラートを受信するように設定されているユーザーは、この Edge での CSS トンネル イベント(つまり、CSS トンネルの起動または停止)についてアラートを受信します。

      • 解決した問題 48633:カスタマー サポートのロールを持つカスタマー管理者が、VMware SD-WAN Orchestrator で Non SD-WAN Destination (NSD) のいくつかの設定の詳細を表示できません。

        これは問題 48459 と実質的に同じですが、ユーザー名やホスト名など、NSD 設定の異なるパラメータをカバーしています。カスタマー サポート ユーザーは、Orchestrator の [設定 (Configure)] > [ネットワーク サービス (Network Services)] セクションを参照して、NSD の詳細を確認します。この問題は、Orchestrator の読み取り専用ファイルにローカル認証 ID の詳細を表示するためのコードが欠落しているために発生します。  この修正により、サポート ユーザー向けにローカル認証 ID を読み取り専用モードで表示するための対応するコードとファイルが追加されます。

      • 解決した問題 48641:サポート ロールを持つオペレータが、VMware SD-WAN Orchestrator ユーザー インターフェイスの [Gateway] ページに VMware SD-WAN Gateway の [Gateway 認証モード (Gateway Authentication Mode)] を表示できません。

        サポート オペレータは設定に対して読み取り専用であるため、そのようなオペレータが少なくとも Gateway の認証モードを表示できるようにすることができず、代わりに、設定権限を持つオペレータのみがこのフィールドを表示できました。

      • 解決した問題 48642:サポート ロールを持つオペレータが、VMware SD-WAN Orchestrator の [設定 (Configure)] > [Edge] > [Edge の概要 (Edge Overview)] セクションに [ライセンス (License)] フィールドを表示できません。

        以前は、[ライセンス (License)] フィールドを読み取り専用で表示するためのコードがなかったため、サポート オペレータはフィールドを表示できませんでした。この修正により、[ライセンス (License)] フィールドも読み取り専用で表示されるようになりました。

      • 解決した問題 48645:サポート ロールを持つオペレータが、Edge ソフトウェア イメージの [廃止 (Deprecated)] フィールドを設定できます。

        サポート オペレータは、VMware SD-WAN Orchestrator ユーザー インターフェイスの [ソフトウェア イメージ (Software Images)] セクションに移動すると、検査する Edge イメージを選択できます。オペレータの権限は読み取り専用のため、[廃止 (Deprecated)] フィールドは灰色で表示されるはずです。この問題は、オペレータがチェックボックスを編集する権限を持っているかどうかを確認するための条件/検証チェックが欠落していることの結果です。

      • 解決した問題 48915:[クラウド セキュリティ サービス (CSS) イベント (Cloud Security Service (CSS) Events)] ページで、CSS タイプが正しく表示されません。

        CSS イベントは、VMware SD-WAN Orchestrator の [ネットワーク サービス (Network Services)] ページにあります。  ページ タイトルには、実際のタイトル文字列ではなく、生のコード(例:「UIPlugins.genericCloudSecurityService.title」)が表示されます。この修正により、以前表示されていた生のコードにタイトル文字列が追加されます。

      • 解決した問題 49395:VMware SD-WAN Edge では、Edge が最初にアクティベーションされたときではなく、デバイスが最初にプロビジョニングされたときに systemUpSince タイムスタンプが表示されます。

        この問題は、[監視 (Monitor)] > [Edge] > [Edge の概要 (Edge Overview)] で [Edge 情報 (Edge information)] ドロップダウンを選択することで確認できます。Edge のアクティベーションの前に示された systemUpSince 時間には意味がなく、Edge のトラブルシューティングを妨げます。

      • 解決した問題 49997:VMware SD-WAN Orchestrator で VMware Edge Network Intelligence 分析モードが有効になっている場合、新しいオペレータ ユーザーが作成されると、そのオペレータは Orchestrator ユーザー インターフェイスの分析セクションに接続できなくなります。

        分析モードのアクティベーション後に作成されたオペレータ ユーザーは、サポート アクセスを有効にしているすべてのエンタープライズ カスタマーの VMware Edge Network Intelligence ユーザー インターフェイスにアクセスできる必要がありますが、これは、この問題には当てはまりません。

      • 解決した問題 50082:API を使用するか、検査要素を介して VMware SD-WAN Orchestrator ユーザー インターフェイスの値を変更することによって DHCP リース時間を変更すると、ユーザー インターフェイスは 900、3600、14400、43200、86400、および 604800 のデフォルト値のみをサポートするため、Orchestrator ユーザー インターフェイスが破損します。

        この問題は、次の手順で確認できます。

        1.新しいプロファイルを作成します。
        2.デフォルトの VLAN DHCP リース時間を 900、3600、14400、43200、86400、604800 以外に変更します。
        3.そのプロファイルを Edge に割り当てます。
        4.Edge 内の VLAN の [編集 (Edit)] ボタンを選択します。
        5.何も起こりません。

        この修正により、DHCP リース タイマーの検証が追加されます。これは、[900、3600、14400、43200、86400、604800] のいずれかの値である必要があります。  ユーザーは、API または Orchestrator ユーザー インターフェイスを介して、無効な DHCP リース時間の値を持つプロファイルを作成することはできません。

      • 解決した問題 51608:リモート診断の [DNS テスト (DNS Test)] は、アンダースコア「_」文字を含むドメイン名を受け入れません。

        DNS テストの目的でアンダースコア記号を含むドメイン名(例:_test.com)を入力しようとすると、VMware Orchestrator は次のようなエラーを返します:「_test.com が無効です」。  この修正により、ドメイン名の検証にアンダースコア記号が追加されます。

      • 解決した問題 51620:スイッチ ポートがルーテッド インターフェイスに変換されたときに、スタティック ルートの VMware SD-WAN Edge インターフェイスが [なし (none)] にリセットされません。

        問題は、インターフェイス モードをルーティングからスイッチに変更した後、スタティック ルート ドロップダウンのリセットが発生しないことです。この修正により、インターフェイス モードの変更時にドロップダウンのリセット機能がトリガされます。  この問題は、スイッチからルーティングに変更する場合に発生しません。

      • 解決した問題 51707:ユーザーが名前なしで VLAN を設定すると、VMware SD-WAN Orchestrator が間違ったエラーをスローします。

        名前なしで VLAN を作成すると、Orchestrator には次のエラーが表示されます:「名前には < および > を含めることはできません」。表示すべき正しいエラーは次のとおりです:「VLAN には名前が必要です」。

      • 解決した問題 51714:ユーザーは DHCP で [時間オフセット (Time offset)] フィールドを小数値として設定できます。これにより、dnsmasq が失敗します。

        VMware SD-WAN Orchestrator で、ユーザーが [設定 (Configure)] > [Edge] > [デバイス (Device)] 設定に移動し、DHCP を有効にするルーテッド インターフェイスを選択し、オプションで、たとえば 0.11 の値で時間オフセットを追加し、変更を保存するとします。ユーザーは [イベント (Events)] ページをチェックして、以下を確認できます:「dnsmasq[20245] が見つかりました:起動の失敗エラー」。  この修正には、[時間オフセット (Time offset)] フィールドで小数が許可されていないことを確認するための検証チェックが含まれています。

      • 解決した問題 52034:ユーザーは、VMware SD-WAN Orchestrator のローカル ユーザー インターフェイス ポートに整数以外の値を設定できます。

        これは、Edge またはプロファイルの [設定 (Configure)] > [ファイアウォール (Firewall)] ページの [Edge アクセス (Edge Access)] セクションにあります。  ユーザーは 99.99 などの整数以外の値をローカル ユーザー インターフェイス ポートとして設定でき、Orchestrator はエラーをスローせず、それを受け入れます。Edge データプレーンがこのパラメータを処理していたため、カスタマーへの影響は軽減されました。整数以外の値の場合は、デフォルトのポート 443 が割り当てられます。  この修正により、この値が整数であることを確認するための検証が含まれるようになりました。

      • 解決した問題 52107:サポート ロールを持つオペレータが、VMware SD-WAN Orchestrator で VNF 設定の [リージョン (Region)] フィールドを表示できません。

        サポート オペレータが [VNF サービス管理の設定 (VNF Service Management Configuration)] ボックスを表示すると、[リージョン (Region)] フィールドが一連のセキュリティ ドットとして表示されます。この修正により、[リージョン (Region)] フィールドが読み取り専用として表示されるようになりました。

      • 解決した問題 52293:複数のトンネルがある場合、[監視 (Monitor)] > [Edge 経由の Non SD-WAN Destination (Non SD-WAN Destinations via Edge)] でトンネル状態のツールチップに間違ったインターフェイス名が表示されます。

        VMware SD-WAN Orchestrator で、ユーザーが Edge 経由の NSD に複数のトンネルを設定している場合、ユーザー インターフェイスにはすべてのトンネルに対して同じインターフェイス名が表示されます。すべてのエントリに対して最初のインターフェイス名がコピーされます。

      • 解決した問題 52317:[カスタマー設定 (Customer Configuration)] ページの Gateway プール モジュールの下にある Gateway のパートナー オフ フィールド名が切り詰められます。

        パートナーまたはオペレータ ユーザーが VMware SD-WAN Orchestrator で [設定 (Configure)] > [カスタマー (Customer)] に移動し、[Gateway プール (Gateway Pool)] までスクロールすると、Partner Gateway 名の代わりに省略された名前(「Pa...」や「C...」など)が表示されます。 

      • 解決した問題 52329:VMware SD-WAN Orchestrator の新しいユーザー インターフェイスで、[カスタマー (Customer)] ビューの円グラフにカーソルを置いても、[Edge の概要 (Edge Overview)] ページの円グラフのように数値が表示されません。

        [カスタマーの合計数 (Total Customers)] または [Edge の合計 (Total Edges)] の円グラフでシリーズの上にカーソルを置いたときに、特定の状態のアイテムの数を表示できません。

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

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

      • 解決した問題 52729:VNF を設定するときに、必須フィールドに正しい値を含めないと、VMware SD-WAN Orchestrator ユーザー インターフェイスに「予期しないエラーが発生しました」と表示されますが、設定が必要なフィールドに関するガイダンスは提供されません。

        ユーザーが無効なホスト名を指定する可能性があり、エラー メッセージは、ホスト名が無効であることを明示的に示すものではなく、「予期しないエラーが発生しました」という曖昧なものになります。この修正により、これらの VNF フィールドの適切な検証と、より明示的なエラー メッセージが追加されます。

      • 解決した問題 52820:多数の VMware SD-WAN Edge を持つ VMware SD-WAN Orchestrator では、ユーザー インターフェイスを介して設定を変更すると、タイムアウト エラーがスローされる場合があります。

        設定要求が 90 秒以内に Orchestrator に伝達されない場合、タイムアウト エラーがスローされます。  この修正により、非対称 API システムが自動的に設定され、大規模な Orchestrator(2,000 以上の Edge)が管理されます。

      • 解決した問題 52835:新しいユーザー インターフェイスを使用する VMware SD-WAN Orchestrator で、Edge 経由の Non SD-WAN Destination トンネル サービス名が [Edge の監視 (Monitor Edge)] 画面で正しく更新されません。

        [監視 (Monitor)] > [Edge (Edges)] リストを開くと、[Edge トンネル (Edge tunnels)] 列のツールチップにユーザー フレンドリな表示名ではなく技術サービス名が表示されます。たとえば、Edge 経由の Non SD-WAN Destination トンネル名「Generic IKEv2 router」は、「Generic ik v2 router」として誤って更新されます。

      • 解決した問題 52851:VMware SD-WAN Gateway アクティベーション イベントが、VMware SD-WAN Orchestrator ユーザー インターフェイスに「Edge アクティベーション」という誤った説明とともに表示されます。

        これは、新しい Gateway がアクティベーションされるたびに [オペレータ イベント (Operator Events)] に表示されます。

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

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

      • 解決した問題 52885:パートナーまたはカスタマー管理者は、最初のフィールドに入力するだけでログイン パスワードを変更でき、確認フィールドに入力する必要はありません。

        これは、パートナー レベルまたはカスタマー レベルのすべてのユーザー ロールに当てはまります。  これにより、管理者は 1 つのパスワードが入力されたものと考えますが、これは実際には意図されたものとは一致せず、確認フィールドによって拒否されるものです。

      • 解決した問題 52903:ユーザーが正しい API トークンなしで新しいクラウド セキュリティ サービス (CSS) プロバイダを追加しようとすると、VMware SD-WAN Orchestrator ユーザー インターフェイスは「無効なユーザー名またはパスワードです」というメッセージを返します。

        これは、最も一般的な CSS であるZscaler で確認されています。このチケットには、他に関連する 2 つの問題があります:パスワードとトークンのフィールドは、クリア テキストの場合入力を受け付けません。  また、正しいプレフィックスが付いたトークンは、正しくない場合でも正しいトークンとして扱われます。これらすべての問題に対する修正は、CSS API 認証情報の検証を改善することです。

      • 解決した問題 52918:少なくとも 1 つの VNF を展開しているカスタマー エンタープライズで、ある時点で VNF 展開の詳細が実際の展開の詳細と一致しない場合、新しいユーザー インターフェイスを使用する VMware SD-WAN Orchestrator は不一致に関する警告を発行しません。

        このシナリオでは、古いユーザー インターフェイスが適切に機能します。  表示すべきエラー メッセージは「現在の VNF 展開がこの Edge で設定されている状態と一致しません。  これは通常、Edge において最近の変更の適用が保留中である場合に発生し、通常は数回のハートビート サイクル後に解決されます。  詳細については、Edge イベントを参照してください」です。

      • 解決した問題 52934:Gateway 経由の Non SD-WAN Destination または Edge 経由の Non SD-WAN Destination のいずれかのネットワーク サービスに対して Azure 自動化が開始されません。

        Azure タイプの NSD-via-GW または NSD-via-Edge の追加/削除を設定すると、この問題が発生します。またユーザーは、WAN リンク IP アドレスが変更されたときに、Azure への更新アクションが処理されないことを確認することもあります。  修正を適用せずにこの問題を解決する唯一の方法は、VMware SD-WAN Orchestrator のバックエンド プロセスを再起動することです。

      • 解決した問題 53076:VMware SD-WAN Orchestrator で、ユーザーは正しく機能しない数値形式で携帯電話番号を管理者アカウントに入力できます。

        この問題により、ユーザーは 2FA を完了するための SMS テキストを取得できないため、2 要素認証ユーザーがロックアウトされる場合があります。携帯電話番号が 00xxxxxxxx の形式で入力された場合、VMware SD-WAN Orchestrator はフィールドをチェックせずにその番号を受け入れます。「+-+00」などの明らかに間違った番号も受け入れます。しかし、誰かがそのユーザーでログインしようとすると、次のエラーが発生します:「SMS サービスで次のエラーが発生しました:[object Object]」。番号を「+<country_code>xxxxxxxxxx」に変更すると、正しく動作します。  この修正には携帯電話番号の検証チェックが含まれており、Orchestrator は機能しない電話番号を許可しません。

      • 解決した問題 53428:ユーザーが同じアカウント番号で 2 つのカスタマー エンタープライズを設定すると、VMware SD-WAN Orchestrator は「内部エラー」メッセージを表示します。

        ユーザーが [システム設定 (System Setting)] ページでエンタープライズのアカウント番号を提供し、そのアカウント番号が他のエンタープライズにすでに存在する場合、変更を保存すると、ユーザー インターフェイスに内部エラーが表示されました。エラー メッセージは曖昧で、何を修正すべきかを正しく伝えません。  

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

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

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

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

      • 解決した問題 53752:3.4.x リリースを使用する VMware SD-WAN Orchestrator からリリース 4.2.0 を使用する Orchestrator に移行しようとすると、カスタマー エンタープライズの移行が失敗します。

        最新のエンタープライズ移行ツールがリリース 4.2.x をサポートしていなかったため、これが移行の失敗の原因となりました。

      • 解決した問題 53767:カスタマーが VMware SD-WAN Edge ユーザー インターフェイスでビジネス ポリシーを確認すると、HTML コードが表示される場合があります。

        動的メッセージは変数に割り当てられ、変数は文字列に追加されるため、変数の値全体が HTML タグを含む文字列として表示されます。この修正によって、変数がテキストを表示する場所が新しいタグに移動されます。

      • 解決した問題 53798:カスタマーが、無効なプロパティ タイプまたは値を設定して Partner Gateway ハンドオフを作成できます。

        VMware SD-WAN Orchestrator には、エンタープライズ Gateway ハンドオフの挿入または更新のための構文検証がありませんでしたが、このビルドで修正されました。

      • 解決した問題 53882:カスタマーが、Edge 上書きがオフになっている場合でも VMware SD-WAN Edge で BFD ルールを編集できます。

        VMware SD-WAN Orchestrator には、BFD ルールを編集しようとするときに Edge 上書きがオフになっているかどうかを確認するための検証チェックがありません。

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

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

      • 解決した問題 53987:VMware SD-WAN Orchestrator で、Edge イベント「リンク MTU が検出されました (Link MTU Detected)」を Orchestrator ユーザー インターフェイスで検索できません。

        この問題は、リリース 4.0.x 以上を使用している Orchestrator で確認されています。  Orchestrator ユーザー インターフェイスの [イベント (Events)] ページでイベント検索を実行するときに、フィルタのイベント リストで「リンク MTU が検出されました (Link MTU Detected)」を使用できないため、トラブルシューティングの一環としてそのイベントを分離することが困難になります。

      • 解決した問題 54035:VMware Edge Network Intelligence の分析モードが有効になっている場合、syslog デーモン、daemon デーモン、snmptrap デーモン宛てのパケットが VMware SD-WAN Edge でドロップし、このデータは Edge Network Intelligence ビューアに表示されません。

        Edge Network Intelligence デーモン (syslogd、amond、snmptrapd) に送信されるパケットは、対応する iptable ルールが見つからない場合、Edge データプレーン プロセスでドロップします。その結果、対応する統計情報が Edge Network Intelligence バックエンドで受信されません。

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

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

      • 解決した問題 54861:手動の IPsec プロバイダから切り替えた後、クラウド セキュリティ サービス (CSS) Zscaler の自動プロバイダを有効にすると、古い VPN 認証情報が VMware SD-WAN Orchestrator のデバイス設定からクリアされないため、自動化が開始されません。

        ユーザーは手動の CSS IPsec プロバイダを VMware SD-WAN Edge に割り当て、その VPN 認証情報を設定します。次にユーザーは自動化された CSS プロバイダに切り替えますが、古い VPN 認証情報はユーザー インターフェイスによってクリアされません。その結果、自動化は開始されません。修正を適用せずにこの問題を解決する唯一の方法は、すべての既存の VPN 認証情報を Orchestrator ユーザー インターフェイスから手動でクリアすることです。

      • 解決した問題 55205:ユーザーが VMware SD-WAN Orchestrator の [監視 (Monitor)] > [QoE] ページで QoE グラフにカーソルを合わせると、ツールチップにパケット遅延の値が間違った順序でリストされます。

        値が表示される現在の順序は、ジッター、次に遅延です。  ただし、ジッターはパケット遅延のバリエーションであり、遅延はパケット遅延の直接的な表現であるため、ジッターを遅延の後に適切にリストする必要があります。

      • 解決した問題 55259:管理者が VMware SD-WAN Orchestrator ユーザー インターフェイスで新しい VMware SD-WAN Edge を作成するときに、[場所の設定 (Set Location)] フィールドが表示されません。

        この問題では、管理者は Edge を作成できますが、位置情報がなく、Orchestrator は Edge の自動位置情報を実行して正しい Gateway を割り当てることができません。  Edge の作成後、管理者は追加の手順を実行し、[設定 (Configure)] > [Edge (Edges)] > [Edge の概要 (Edge Overview)] ページに移動して、Edge の位置情報を入力する必要があります。

      • 解決した問題 55294:キーボードのみを使用するユーザーが VMware SD-WAN Orchestrator ユーザー インターフェイスの新しいページに移動する場合、すべてのナビゲーション リンクを順に切り換える必要があります。

        各ページに [メイン コンテンツにスキップ (Skip to main content)] リンクがありません。キーボードのみを使用するユーザーがアプリケーションを操作する場合、タブ キーを使用してリンク間を移動します。ユーザーは、メイン コンテンツにアクセスだけのために、新しいページに移動するたびに、すべてのナビゲーション リンクをタブ キーで移動する必要があります。

      • 解決した問題 55367:VMware SD-WAN Orchestrator の新しいユーザー インターフェイスの [監視 (Monitor)] > [アプリケーション (Applications)] ページに、ラベルの付いていない印刷ボタンがあります。

        この印刷ボタンは印刷ボタンの外観に視覚的に適合していますが、このボタンの機能や使用方法をユーザーに明示的に伝えるテキストがありません。

      • 解決した問題 55861:Check Point タイプの Gateway 経由の Non SD-WAN Destination では、VMware SD-WAN Orchestrator に間違った NSD タイプが保存されている可能性があり、これによりトンネル障害が発生します。

        Check Point NSD の正しいトンネル タイプは [その他 (Other)] です。  ただし、Orchestrator のアップグレード後、Orchestrator に保存されている NSD タイプが [その他 (Other)] ではなく [Check Point] と表示される場合があり、この場合、[Check Point] は実際には正しくありません。  Orchestrator が Gateway に間違った NSD タイプを送信しているため、トンネルが形成されない可能性があります。

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

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

      • 解決した問題 56545:VMware SD-WAN Edge が DHCP リレー エージェントとして設定され、DHCP サーバも同じブランチに配置されている場合、DHCP 否定応答 (NAK) パケットがクライアントに転送されません。

        Edge が DHCP リレー エージェントとして設定され、DHCP サーバが同じブランチにある場合、DHCP サーバの範囲外の IP アドレスが要求されると、DHCP リレー エージェントとして機能する Edge によって DHCP サーバからの DHCP NAK パケットがドロップされます。

      • 解決した問題 56763:レポートが有効になっているリリース 4.x 以降を使用する VMware SD-WAN Orchestrator で、何らかの理由でレポートの生成に失敗した場合、Orchestrator を使用するすべてのカスタマーの以降のすべてのレポートも、Orchestrator のバックエンド サービスが再起動されるまで生成されません。

        Orchestrator を使用しているすべてのカスタマーは、Orchestrator バックエンド サービスが再起動されるまでレポートを取得できないため、この問題は関連する Orchestrator に重大な影響を与えます。この問題は、1 つのレポート障害が原因でレポート サービスが不良状態になるために発生し、Orchestrator でバックエンド サービスを再起動する以外にリカバリできなくなります。  これは、新しいレポートの生成が、以前のレポートの生成とは別個のものとして行われていないためです。  今回の修正により、レポート サービスは、レポート生成の失敗に関係なく、引き続き新しいレポートを生成することが保証されます。

      • 解決した問題 56824:リリース 4.2.x を使用する VMware SD-WAN Orchestrator では、受信者の URL に明示的なポート番号が含まれていると、Webhook 受信者へのアラートの配信が失敗します。

        明示的なポート番号を含む Webhook 受信者 URL を以前に設定したユーザーは、それらの受信者へのアラート配信が無期限に失敗することに気付くことがあります。このビルドで修正が行われない場合、管理者はリバース プロキシを設定して元の Webhook 受信者に要求を渡し、Webhook 受信者の URL を更新してリバース プロキシを参照する必要があります。

      • 解決した問題 56896:API の障害や Gateway のタイムアウトが発生する可能性があります。

        この問題は、ファイルの蓄積により VMware SD-WAN Orchestrator のディスク ストレージがいっぱいになった結果です。この蓄積は、VMware SD-WAN Edge またはブロック リスト/拒否リスト機能に似た Edge のリストのフロー統計処理を無効にする方法があるために発生します。これらの Edge でフロー処理はスキップされますが、問題は、ファイルが削除されることなく Orchestrator のディスクに残っているという点です。実際にあったこの問題の事例では、問題を把握してユーザー エクスペリエンスの問題を防ぐために十分な監視が行われていましたが、監視が少ない Orchestrator では、これがカスタマー トラフィックに影響を与える可能性がありました。この修正が行われない場合、Orchestrator オペレータは、タイムスタンプが 24 時間を超える Orchestrator のディスク ストレージ上のファイルを手動で削除する必要があります。

      • 解決した問題 56909:VMware SD-WAN Orchestrator でリリース 4.x を使用している場合、バックアップ リンクが含まれているとレポートの生成に失敗することがあります。

        リンクにリンク統計レコードがない場合、レポートの生成でエラーが発生します。  バックアップに設定されたリンクは、レポート用に選択された期間中に厳密にバックアップのままである場合、リンク統計を生成しません。この修正が行われない場合、レポートを生成する唯一の方法は、レポートの生成中にバックアップリンクの選択を解除して、リンクにそのレコードの統計データが含まれるようにすることです。

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

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

      • 解決した問題 57087:ユーザーが [設定 (Configure)] > [Edge (Edges)] 画面から VMware SD-WAN Edge のプロファイルを切り替えようとすると、実際の理由ではなく、一般的なエラー メッセージを表示する通知ボックスを含む検証エラーが表示されます。

        一般的なエラーとして表示されるのは、「Error processing item.再試行してください」です。実際の検証エラーの理由から、ユーザーは Web ブラウザのデバッグ コンソールを確認する必要があります。修正後に、この問題について適切な検証エラー/失敗理由が表示されます。

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

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

      • 解決した問題 57193:VMware SD-WAN Orchestrator でレポートを設定する場合、オプション [昨年 (Last Year)] を使用するときに定期レポートをスケジュール設定できません。

        これを試みると、Orchestrator は検証エラーをスローします。これは、ブラウザ ウィンドウ サイズに対するユーザー インターフェイス制限です。

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

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

      • 解決した問題 58288:VMware SD-WAN Orchestrator で新しいユーザー インターフェイスを使用すると、状態ごとのトンネルの誤った数が [Edge の監視 (Monitor Edges)] > [Edge トンネル (Edge tunnels)] 列に表示されます。

        ユーザーが [Edge の監視 (Monitor Edges)] リストを開くと、[Edge トンネル (Edge tunnels)] 列に状態ごとのトンネルの誤った数が表示されます。

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

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

      • 解決した問題 58996:VMware SD-WAN Orchestrator ユーザー インターフェイスから BFD フィールドを更新すると、検証が処理され、問題なく動作します。ただし、対応する API 要求に検証がありません。また、BFD フィールドに JSON スキーマがありません。

        API 要求には、API のドキュメントの生成に使用される JSON スキーマ情報がありません。また、API 要求には、ユーザー インターフェイスから適切に検証された対応するフィールドのサーバ側の検証がありません。

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

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

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

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

      • 解決した問題 59967:VMware SD-WAN Orchestrator を 4.2.x 以降のリリースにアップグレードした後、オペレータ ユーザーが [設定 (Configure)] > [ビジネス ポリシー (Business Policy)] または [設定 (Configure)] > [ファイアウォール ポリシー (Firewall policy)] ページにアクセスしようとすると、ページがロードされず、ユーザーにエラーが表示されます。

        このエラーは「An unexpected error has occurred」と表示されます。これはオペレータ ユーザーに影響するもので、パートナー管理者やカスタマー管理者には影響しません。オペレータの [READ: OBJECT_GROUP] 権限が見つからないため、ページがロードされません。つまり、Orchestrator が [ビジネス ポリシー (Business Policy)] ページおよび [ファイアウォール (Firewall)] ページにアクセスするために必要な権限を持つオペレータを認識しません。

      • 解決した問題 59987:Edge アクティベーション メールで、カスタム メッセージに実際のテキストの代わりに ***** が表示されます。

        サニタイズ リストには以前のメッセージ キーが追加されました。そのため、Edge のアクティベーション、パスワードのリセット(たとえば E メールの本文内、イベントの作成中)などの E メールの送信中にメッセージ キーが不明瞭になっていました。ただし、アクティベーション メールの場合のみ、メッセージ キーを表示する必要があります。このフィールドは、いくつかの有用なカスタム情報をユーザーに送信するために使用されるためです。

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

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

      • 解決した問題 60366:トークン ベースの認証を使用しているユーザーは、VMware SD-WAN Orchestrator で診断バンドルを生成できません。

        トークン ベースの認証を使用している場合、ユーザーは診断バンドルを生成できません。

      • 解決した問題 60405:4.3.x にアップグレードされた VMware SD-WAN Orchestrator に、pathType データ フィールドがありません。

        PathStats テーブルに新しいフィールド「pathType」が導入されました。このフィールドは、新しく展開された Orchestrator でのみ確認され、アップグレードされた Orchestrator では確認されませんでした。この修正により、新しく展開された Orchestrator とアップグレードされた Orchestrator の両方に「pathType」データ フィールドが確実に存在するようになります。

      • 解決した問題 60444:ユーザーがカスタマー/パートナーに対して特定のレート制限を設定している場合、「enabled: false」属性を使用してそのポリシーを無効にすると、レート制限の数値に影響する場合があります。

        この問題は、ユーザーがポリシーを定義した後にポリシー自体でそれを無効にするという、特定のユースケースで発生します。  修正を適用せずにこの問題を回避する方法は、ポリシーを無効にする場合は、レート制限ポリシー アレイにそのポリシーを追加しないことです。基本的に、無効になっているすべてのポリシーをスキップします。このように、既存のレート制限ポリシーのみが適用されます。

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

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

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

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

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

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

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

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

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

      • 解決した問題 62038:VMware SD-WAN Orchestrator でクライアントの可視化が MAC モードに設定されているときに、[Edge] > [監視 (Monitoring)] > [送信元 (Sources)] ページに特定の MAC アドレスの最新の IP が表示されません。

        特定のブランチでクライアントがその IP アドレスを変更すると、ユーザーは [Edge 監視 (Edge Monitoring)] ページでそのクライアントの最新の IP アドレスを確認できなくなります。代わりに、ユーザーに古い IP アドレスが表示されます。この問題は、ビジネス ロジックが誤ったデータベースをクエリした結果です。

      既知の問題

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

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

      Edge/Gateway の既知の問題
      • 問題 14655:

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

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

      • 問題 25504:

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

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

      • 問題 25595:

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

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

      • 問題 25742:

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

      • 問題 25758:

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

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

      • 問題 25855:

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

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

      • 問題 25921:

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

      • 問題 25997:

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

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

      • 問題 26421:

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

      • 問題 28175:

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

      • 問題 31210:

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

      • 問題 32731:

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

      • 問題 32960:

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

      • 問題 32981:

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

      • 問題 34254:

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

      • 問題 35778:

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

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

      • 問題 35807:

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

      • 問題 36923:

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

      • 問題 38682:

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

      • 問題 38767:

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

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

      • 問題 39134:

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

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

      • 問題 39608:

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

      • 問題 39624:

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

      • 問題 39659:

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

      • 問題 39753:

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

      • 問題 40096:

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

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

      • 問題 40421:

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

      • 問題 42278:

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

      • 問題 42388:

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

      • 問題 42488:

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

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

      • 問題 42872:

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

      • 問題 43373:

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

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

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

      • 問題 44995:

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

      • 問題 45189:

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

      • 問題 45302:

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

      • 問題 46053:

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

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

      • 問題 46137:

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

      • 問題 46216:

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

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

      • 問題 46391:

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

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

      • 問題 46918:

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

      • 問題 47084:

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

      • 問題 47355:

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

      • 問題 47681:

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

      • 問題 47787:

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

      • 問題 48166:

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

      • 問題 48175:

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

      • 問題 48502:

        一部のシナリオで、インターネット トラフィックのバックホールに使用されている VMware SD-WAN ハブ Edge で、バックホールのリターン パケットの誤った処理が原因でデータプレーン サービスの障害が発生することがあります。

      • 問題 48530:

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

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

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

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

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

      • 問題 48666:

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

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

      • 問題 49172:

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

      • 問題 50518:

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

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

      • 問題 51036:SNMP 経由で Edge をポーリングすると、ifSpeed が動作中の VMware SD-WAN Edge インターフェイスに対して 0 の値をレポートします。

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

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

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

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

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

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

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

      • 問題 53147:ルーター広報で広報されたデフォルト以外のホップ制限値は、VMware SD-WAN Edge に適用されません。トンネルのホップ制限値は常に 64 に設定されます。

        ホップ制限のデフォルト値は 64 です。デフォルト以外のホップ制限値をルーター広報を通じて広報しようとすると、Edge はパケット内のホップ制限フィールドを処理せず、値は 64 のままになります。

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

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

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

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

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

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

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

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

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

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

      • 問題 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)] を実行すると、エンタープライズ内のすべての 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 トラフィックを確認することがあります。

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

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

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

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

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

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

        回避策:スタンバイ Edge を再起動してリカバリします。

      • 問題 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 で制御されなくなりました。

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

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

      • 問題 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)はすべてのトンネルを時間内に処理できず、トラフィック ドロップが発生する場合があります。最終的にトンネルが確立されますが、既存のトンネルの数によっては時間がかかる場合があります。 

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

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

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

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

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

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

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

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

      • 問題 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 に反映されます。

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

        拡張された HA 設定では、プロキシ インターフェイスで DHCP/PPPoE が有効になっている場合(つまり、HA リンク状態が USE_PEER に設定されている場合)、スタンバイ Edge の再起動または電源の入れ直し後にサーバからアドレスを取得できません。

        回避策:動的アドレスを静的アドレス タイプに変更するか、HA の強制フェイルオーバーを実行してサーバから IP アドレスを取得します。

      • 問題 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 に広報しないようにする必要があります。

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

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

      • 問題 34828:

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

      • 問題 35658:

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

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

      • 問題 35667:

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

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

      • 問題 36665:

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

      • 問題 38056:

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

      • 問題 38843:

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

      • 問題 39633:

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

      • 問題 39790:

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

      • 問題 40341:

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

      • 問題 41691:

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

      • 問題 43276:

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

      • 問題 47269:

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

      • 問題 47713:

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

      • 問題 47820:

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

      • 問題 48085:

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

      • 問題 48737:

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

      • 問題 49225:

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

      • 問題 49790:

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

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

      • 問題 50531:

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

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

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

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

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

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

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