2022 年 6 月 8 日更新 VMware SD-WAN™ Orchestrator バージョン R421-20211216-GA 各リリース ノートへの追加および更新を定期的にご確認ください。 |
リリース ノートの概要
このリリース ノートには、次のトピックが含まれています。対象ユーザー
本リリースは、リリース 4.2.0 で初めて提供される機能を必要とするすべてのカスタマーおよびリリース 4.2.0 以降に解決した以下の問題の影響を受けるカスタマーに推奨されます。
互換性
リリース 4.2.1 の Orchestrator、Gateway、およびハブ Edge では、VMware SD-WAN Edge の以前のバージョンのうちリリース 3.0.0 以降がすべてサポートされます。
注:3.0.0 より前のリリースはサポートされません。
次の相互運用性の組み合わせは、明示的にテストされています。
Orchestrator |
Gateway |
Edge |
|
ハブ |
ブランチ/スポーク |
||
4.2.0 |
4.2.0 |
4.2.0 |
4.2.1 |
4.2.0 |
4.2.0 |
4.2.1 |
4.2.1 |
4.2.1 |
3.4.2 |
3.4.2 |
3.4.2 |
4.2.1 |
4.2.1 |
3.4.2 |
3.4.2 |
4.2.1 |
4.2.1 |
4.2.1 |
3.4.2 |
4.2.1 |
4.2.1 |
3.4.2 |
4.2.1 |
4.2.1 |
4.2.1 |
3.4.5 |
3.4.5 |
4.2.1 |
4.2.1 |
4.2.1 |
3.4.3、3.4.4、3.4.5 |
4.2.1 |
4.2.1 |
3.4.3、3.4.4、3.4.5 |
4.2.1 |
4.2.1 |
3.3.2 P3 |
3.3.2 P3 |
3.3.2 P3 |
4.2.1 |
4.2.1 |
3.3.2 P3 |
3.3.2 P3 |
4.2.1 |
4.2.1 |
4.2.1 |
3.3.2 P2、3.3.2 P3 |
4.2.1 |
4.2.1 |
3.3.2 P2 |
4.2.1 |
4.2.1 |
3.2.2 |
3.2.2 |
3.2.2 |
4.2.1 |
4.2.1 |
3.2.2 |
3.2.2 |
4.2.1 |
4.2.1 |
4.2.1 |
3.2.2 |
4.2.1 |
4.2.1 |
3.2.2 |
4.2.1 |
4.2.1 |
4.0.0 |
4.0.0 |
4.0.0 |
4.2.1 |
4.0.0 |
4.0.1 |
4.2.1 |
4.2.1 |
4.2.1 |
4.0.0 |
4.0.1 |
警告: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 プリペンド設定を編集して「カンマをスペースに置き換える」必要があります。
Edge 3x00 モデルのアップグレード時間の延長
Edge 3x00 モデル(3400、3800 および 3810 など)では、このバージョンへのアップグレードに通常よりも時間がかかる場合があります(3 ~ 5 分)。これは、問題 53676 を解決するファームウェアのアップグレードが原因で発生します。リリース 3.4.5 または 4.0.2 で 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)」を参照してください。
ドキュメントの改訂履歴
2021 年 4 月 9 日。第 1 版。
2021 年 4 月 13 日。第 2 版。
- 「解決した問題 53676」を「Edge/Gateway で解決した問題」セクションに追加しました。 この問題は、元のリリース ノートから誤って省略されました。
- 53676 の修正の一環としてファームウェアをアップグレードする必要がある場合に 3x00 で発生するアップグレード時間の延長に関する「重要な注意事項」セクションを追加しました。
2021 年 4 月 21 日。第 3 版。
- 新しい Orchestrator ビルドR421-20210415-GA を最新のビルドとして追加しました。 「Orchestrator で解決した問題」セクションに R421-20210415-GA の新しいセクションを追加しました。
- Orchestrator の「R421-20210415-GA で解決した問題」セクションにチケット #61312 を追加しました。
2021 年 5 月 7 日。第 4 版。
- 「互換性」の表を修正し、2 つの新しいテスト済みの組み合わせを追加しました。
- リリース 4.2.0 の Orchestrator と Gateway は、4.2.0 を使用するハブ Edge および 4.2.1 を使用するスポーク Edge と互換性があることがテスト済みです。
- リリース 4.2.0 の Orchestrator と Gateway は、4.2.1 を使用するハブ Edge および 4.2.1 を使用するスポーク Edge と互換性があることがテスト済みです。
- 解決した問題 55949 および 56149 を「Edge/Gateway で解決した問題」セクションに追加しました。これらのチケットは、オリジナルの GA リリース ノートに含まれている必要があります。
2021 年 6 月 15 日。第 5 版。
- Edge/Gateway で修正した問題 56876 を訂正しました。これは、この問題の修正によって解決する 2 番目のシナリオに対応するためです。また、Edge カーネルのパニックと再起動につながるメモリ管理も考慮します。
- 以前のエディションから誤って省略された Edge/Gateway で解決された問題 54001 を追加しました。
2021 年 8 月 5 日。第 6 版。
- 「Edge/Gateway の未解決の問題」セクションに、既知の 6 個の問題(#60006、#60225、#61361、#62552、#63359、#67790)を追加しました。
2021 年 8 月 11 日。第 7 版。
- 新しい Edge バージョン R421-20210624-GA-57011-60130 を追加し、既存のチケット 57011 および 60130 を該当する Edge ビルド用に新設したセクションに移動しました。
2021 年 9 月 16 日。第 8 版。
- 「重要な注意事項」に次の注意事項を追加:AS-PATH プリペンドの BGPv4 フィルタ設定の区切り文字の変更
2021 年 12 月 21 日。第 9 版。
- 「Orchestrator で解決した問題」に新しい Orchestrator ビルド R421-20211216-GA を追加しました。Orchestrator ビルドは、Log4j バージョン 2.16.0 に更新することで、Apache Log4j の脆弱性 CVE-2021-44228 を修正します。Apache Log4j の脆弱性の詳細については、VMware セキュリティ アドバイザリ VMSA-2021-0028.5 を参照してください。
- 「重要な注意事項」に次の注意事項を追加:VMware SD-WAN Edge モデル 520、540、620、640、680、3400、3800、および 3810 で自動ネゴシエーションを無効にする場合の制限事項。このリリース ノートでは、ここで示されている Edge モデルの一部のイーサネット ポートで強制速度を設定するときに発生する可能性のある問題について説明します。
2022 年 3 月 24 日。第 10 版
- 「Edge/Gateway の既知の問題」セクションに問題 #84825 を追加しました。
2022 年 6 月 7 日。第 11 版
- 「Edge/Gateway で解決した問題」セクションに解決した問題 #54493 を追加しました。この問題は、4.2.1 リリース ノートの元のエディションから誤って省略されていました。
解決した問題
解決した問題は、以下のとおり分類されています。
Edge で解決した問題バージョン R421-20210624-GA-57011-60130 で解決した問題
Edge バージョン R421-20210407-GA 以降で解決した問題は次のとおりです。
- 解決した問題 57011:高可用性トポロジで設定されたサイトの場合、そのサイトでセグメントが追加されてから削除されると、HA Edge の 1 台でデータプレーン サービスの障害が発生する可能性があります。サービスの障害がアクティブ Edge にある場合、サイトでは HA フェイルオーバーも発生します。
HA サイトにセグメントが追加されてから削除されると、古いセグメントが残る(つまり、削除されたセグメントが HA ペアの 1 台の Edge に表示される)ことがあります。この HA Edge 間のセグメント情報の不一致により、古いセグメントを対象としたイベントが他の Edge に送信することがあり、データプレーン サービスの障害が発生します。サービスの障害がアクティブ Edge にある場合は HA フェイルオーバーが発生し、フェイルオーバー後に取得された診断バンドルでコア ダンプの生成が確認されます。この問題の回避策はありません。
- 解決した問題 60130:サイトでは、断続的に高いパケット ロスと接続の問題が発生することがあります。
これは、ARP 解決をチェックする API が、00:00:00:00 の MAC アドレスを配信しているときにデバイスの ARP 解決が成功したことを Edge に通知することが原因です。 このアドレスは ARP キャッシュに保持され、MAC がゼロとしてリストされているデバイス宛てのパケットはすべてドロップされます。この状況では、このような MAC アドレスがゼロの正常な ARP の多くのインスタンスが配信され、高いパケット ロスと接続の問題が発生します。
この修正を適用すると、フロー内の MAC アドレスのキャッシュ値に関する問題(この問題の最も一般的な原因)が解決されます。ただし、この修正は ARP がそれ自体をキャッシュし、MAC アドレスをゼロとして返す、まれな状況には対処していません。この問題は 62552 で対処する予定です。この修正を適用した Edge イメージを使用すること以外に、この問題の回避策はありません。
バージョン R421-20210407-GA で解決した問題
Edge バージョン R420-20201218-GA および Gateway バージョン R420-20210208-GA-53243-54800 以降で解決した問題は次のとおりです。
- 解決した問題 51025:VMware SD-WAN Edge で WAN リンクがフラップする(アップ状態とダウン状態が急速に切り替わる)場合、ルーティング インターフェイスのデフォルト ゲートウェイのルート テーブル エントリが削除され、再適用されない場合があります。
Edge でこの問題が発生すると、リンク フラップが発生し、そのリンクを使用するインターフェイスのデフォルト ゲートウェイのルート エントリが削除され、インターフェイスのルート テーブルが空になります。ただし、空のルート テーブルが残っている場合、Linux 接続トラッキング (conntrack) はデフォルトで次のテーブルにルーティングし、すべてのパケットが誤ったルーテッド インターフェイスを介して出力されます。
- 解決した問題 52102:ハブ/スポーク トポロジを使用しているエンタープライズでは、特定のタプルでハブ Edge のフェイルオーバーから復旧するときに、既存のフローが VMware SD-WAN スポーク Edge でドロップします。
プライマリ Hub Edge がフェイルオーバーから復旧するときに、一連のイベントによってこの問題が発生します。
1.プライマリ Hub Edge が停止すると、そのルートは、RIB のルートを保持したまま、そのプライマリ Hub Edge の FIB から削除されます。
2.ここで、既存のフローがセカンダリ ハブ Edge に切り替わります。
3.プライマリ Hub が復旧すると、プライマリ Hub とスポーク Edge 間ですぐにトンネルが確立されます。
4.以前に Gateway を介してプライマリ Hub から学習した RIB 内のルートがスキャンされ、このプライマリ Hub を指す FIB にルートがインストールされます。
5.プライマリ Hub が BGP ネイバーからルートを学習していない場合、トラフィックはプライマリ Hub に戻ります。
6.これにより、デフォルトのルート上でルート参照が一致し、リターン トラフィックにバックホール フラグが設定されます。
7.スポーク Edge はバックホール フラグが設定されたリターン トラフィックを予測していないため、トラフィックがドロップされます。この修正を行わない場合の回避策は、ハブ Edge に移動し、指定されたタプルのリモート診断「フローのフラッシュ」を実行することです。これにより、トラフィックがリストアされます。
- 解決した問題 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 アドレスが取得されます。
- 解決した問題 53477:高可用性トポロジで設定された VMware SD-WAN Edge を別の設定プロファイルに移動すると、Edge で Edge サービスの再起動が繰り返されます。
この問題では、HA Edge の 1 台が他の HA Edge よりも多くの LAN または WAN インターフェイスを持つ設定になっています(WAN ポートが Edge の 1 台で無効になっているなど)。これらの Edge を別のプロファイルに移動すると、Edge で Edge サービスの再起動が繰り返されます。
- 解決した問題 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 を使用することです。
- 解決した問題 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 のログを参照するときに、より重要なメッセージがローテーションされ、失われてしまいます。
- 解決した問題 53929:拡張高可用性トポロジを使用しているカスタマー サイトで、HA フェイルオーバーが発生すると、「Gateway 経由のクラウド」フローが「クラウドに直接」パスに切り替わります。
HA フェイルオーバー後、トラフィックが VMware SD-WAN Edge に到達したときに VMware SD-WAN Gateway へのパスが稼動していない場合、トラフィックは「Gateway 経由のクラウド (Cloud via Gateway)」ではなく「クラウドに直接 (Direct to Cloud)」になります。ダイレクト トラフィックはこれらの最適化を使用しないため、これはリアルタイム トラフィック(音声やビデオなど)などの動的マルチパス最適化に依存するフローに大きな影響を与える可能性があります。
- 解決した問題 54001:Tx キューが SFP インターフェイスでハングした後、VMware Edge はトラフィックを送信できません。
まれに、Edge が無効なサイズのパケット(17 バイト未満または 1526 バイトを超える)を DPDK に送信すると、送信キューが停止し、それ以上のトラフィックが Edge によって転送されない場合があります。Edge を再起動すると一時的に問題が修正されますが、無効なサイズのパケットが Edge サービスから DPDK に送信されると問題が再び発生する可能性があります。この問題は、修正後のレベルにアップグレードすることでのみ回避できます。
- 解決した問題 54493:オペレータ管理者やパートナー管理者が、VMware SD-WAN Gateway 上の Edge トラフィックでハンドオフ キューのドロップ数が増加していることを確認する場合があります。
この問題において、Gateway での CPU 使用率の問題や DPDK ドロップはありません。この問題は、制御プレーン イベント(ルートの再計算など)によってトリガされ、Gateway での Edge パケットのドロップが、Gateway のパイプライン内の異なるスレッドへのハンドオフ中に発生します。この問題の原因は、パケット バッファリングのキュー サイズの大きさが不十分であることです。
- 解決した問題 54694:カスタマーが SNMP ポーリングを使用すると、SNMP 監視は送信トラフィックに不正確な測定を提供します。
IF-MIB::ifHCOutOctets の SNMP 呼び出しは TX バイトではなく TX パケットを提供します。このため、送信オクテット数が不正確となり、エンタープライズを監視する機能に影響します。この問題は、TX パケットと TX バイトの snmpagent プロセスの監視が原因で発生します。
- 解決した問題 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)] の履歴統計情報は正しく表示されます。この問題は「ライブ モード」統計情報にのみ影響します。
- 解決した問題 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% です。
- 解決した問題 56876:VMware SD-WAN Edge では、メモリ管理に関連する問題が発生し、カーネル パニックをトリガする可能性があります。その結果 Edge が再起動します。
この解決された問題には、カーネル パニックをトリガする Edge でのメモリ管理を含む 2 つの異なるシナリオの修正が含まれています。
- Edge が動的ブランチ間を使用している最初のシナリオでは、動的トンネルが作成され、ピアごとのカウンタを格納するために少量のメモリが予約されます。動的トンネルが破棄されると、このメモリはクリーンアップされず、次に同じピアが接続されるときに起動時間が最適化されます。その結果、時間の経過とともに多数の異なる宛先に接続する小規模の Edge(Edge 500、510、520、610 など)では、最終的に使用可能なメモリが使い果たされ、カーネル パニックと Edge の再起動がトリガされる可能性があります。 この修正を行わないと、VMware SD-WAN Orchestrator で Edge の [監視] > [システム] 画面のメモリ使用率が健全性統計の 90% を超える場合、ユーザーは Edge のサービスを事前に再起動する必要があります。
- 動的ブランチ間によって引き起こされたメモリ リークを修正するプロセスで、malloc_trim(フラグメントされたメモリをクリアするプロセス)が適切に呼び出されていないことが確認され、この修正のためにこのプロセスも変更されました。malloc_trim を適切に呼び出さないと、別の問題が発生し、任意の Edge(小さい Edge だけでなく)に影響を与える可能性があります。その場合、Edge が動的ブランチ間を使用することは要求されなくなり、[監視] > [システム] 画面には 90% を超えるメモリ使用量が表示されなくなります。このシナリオは、Edge に多数のフローがある場合に発生する可能性が高くなります。
- 解決した問題 56931:Edge 経由の Non SD-WAN Destination (NSD) を設定したカスタマー サイトで、VMware SD-WAN Orchestrator ユーザー インターフェイスに表示される Edge の健全性統計が正しくない場合があります。
NSD が Edge から設定されている場合、SD-WAN サービスは再起動後に初めて開始時刻が 0 の健全性統計情報を Edge から Orchestrator に送信します。その結果、Edge の再起動後に Orchestrator に誤ったデータが表示されます。
- 解決した問題 57063:API 呼び出しの開始時刻と終了時刻が、VMware SD-WAN Edge が VMware SD-WAN Orchestrator にデータをエクスポートした時刻と完全に重複する場合、次の 2 つの動作が発生します。a) Orchestrator ユーザー インターフェイスまたは SDK クライアントから発行されたリンク メトリック API 呼び出しで、応答に通常の値よりも大きい値が返される。b) Orchestrator UI または SDK クライアントから発行されたリンク シリーズ API 呼び出しで、前回の時系列値が通常の値よりも大きくなる。
ユーザーが Orchestrator ユーザー インターフェイスの [監視] > [トランスポート] タブを参照するか、SDK クライアントが getEdgeLinkMetrics、getEdgeLinkSeries、または getAggregateLinkMetrics API 呼び出しを実行するときに、この問題が確認されます。 どちらの場合も、「症状」の説明に記載されている要件を考えると、この問題が実際に発生するのはまれです。
Orchestrator バージョン R421-20211216-GA
Orchestrator バージョン R421-20211216-GA は 2021 年 12 月 20 日にリリースされました。Orchestrator ビルドは、Log4j バージョン 2.16.0 に更新することで、Apache Log4j の脆弱性 CVE-2021-44228 を修正します。Apache Log4j の脆弱性の詳細については、VMware セキュリティ アドバイザリ VMSA-2021-0028.5 を参照してください。
___________________________________________________________________
バージョン R421-20210415-GA で解決した問題
Orchestrator バージョン R421-20210326-GA 以降で解決した問題は次のとおりです。
- 解決した問題 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 は、ルートが処理される直前に拒否されます。
______________________________________
バージョン R421-20210326-GA で解決した問題
Orchestrator バージョン R420-20210306-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 は正常にアクティベーションされます。
- 解決した問題 49997:VMware SD-WAN Orchestrator で VMware Edge Network Intelligence 分析モードが有効になっている場合、新しいオペレータ ユーザーが作成されると、そのオペレータは Orchestrator ユーザー インターフェイスの分析セクションに接続できなくなります。
分析モードのアクティベーション後に作成されたオペレータ ユーザーは、サポート アクセスを有効にしているすべてのエンタープライズ カスタマーの VMware Edge Network Intelligence ユーザー インターフェイスにアクセスできる必要がありますが、これは、この問題には当てはまりません。
- 解決した問題 52379:VMware SD-WAN Edge が設定された遅延間隔内にリカバリした場合、VMware SD-WAN Orchestrator が「Edge 停止 (Edge Down)」アラート E メールを送信します。
管理者は、アラートをトリガする前に Edge が一定期間ダウンするように遅延を設定したにもかかわらず、ネットワーク内の Edge が停止しているという誤ったアラートを受け取る可能性があります。
- 解決した問題 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 をサポートしていなかったため、これが移行の失敗の原因となりました。
- 解決した問題 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 バックエンドで受信されません。
- 解決した問題 55259:管理者が VMware SD-WAN Orchestrator ユーザー インターフェイスで新しい VMware SD-WAN Edge を作成するときに、[場所の設定 (Set Location)] フィールドが表示されません。
この問題では、管理者は Edge を作成できますが、位置情報がなく、Orchestrator は Edge の自動位置情報を実行して正しい Gateway を割り当てることができません。 Edge の作成後、管理者は追加の手順を実行し、[設定 (Configure)] > [Edge (Edges)] > [Edge の概要 (Edge Overview)] ページに移動して、Edge の位置情報を入力する必要があります。
- 解決した問題 55871:REST APIv2 (/sdwan) HTTP に対する API 呼び出しによって、サーバが HTTP 500 エラーを生成する場合があります。
カスタマーのデータが API が想定するスキーマに正確に準拠していない場合、API は文書化された API スキーマと不整合であるデータを返すのではなく、HTTP 500 エラーを生成します。この動作は、その後に再検討された設計上の判断として発生したものとなります。「GET /enterprises」、「GET /enterprises/{enterpriseLogicalId}/edges」、および「GET /enterprises/{enterpriseLogicalId}/clientDevices」への呼び出しが影響を受けることがわかっています。
- 解決した問題 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 を使用している場合、バックアップ リンクが含まれているとレポートの生成に失敗することがあります。
リンクにリンク統計レコードがない場合、レポートの生成でエラーが発生します。 バックアップに設定されたリンクは、レポート用に選択された期間中に厳密にバックアップのままである場合、リンク統計を生成しません。この修正が行われない場合、レポートを生成する唯一の方法は、レポートの生成中にバックアップリンクの選択を解除して、リンクにそのレコードの統計データが含まれるようにすることです。
- 解決した問題 57087:ユーザーが [設定 (Configure)] > [Edge (Edges)] 画面から VMware SD-WAN Edge のプロファイルを切り替えようとすると、実際の理由ではなく、一般的なエラー メッセージを表示する通知ボックスを含む検証エラーが表示されます。
一般的なエラーとして表示されるのは、「Error processing item.再試行してください」です。実際の検証エラーの理由から、ユーザーは Web ブラウザのデバッグ コンソールを確認する必要があります。修正後に、この問題について適切な検証エラー/失敗理由が表示されます。
- 解決した問題 58627:アラートを受信するように設定されたユーザーが、リンクがダウンしたままであるのにリンク アップ アラートを受信する場合があります。
リンクが「ダウン (Down)」とマークされた後、リンクがダウンする前に生成されたリンクの統計情報がイベント後最大 1 分間、VMware SD-WAN Orchestrator に送信されない場合があります。 Orchestrator がこのような遅延リンク統計を受信すると、リンクがバックアップされていると誤解し、アラート設定が厳しい場合(たとえば、0 分の遅延)にリンク アップ アラートをトリガします。 この修正により、Orchestrator は、遅延リンク統計をリンクが起動していることを示すものとして解釈しないようになります。
- 解決した問題 59094:オペレータが VMware SD-WAN Orchestrator をアップグレードしようとするときに、スキーマの更新要件に関する適切な警告メッセージが更新スクリプトで表示されません。
オペレータがより大きなテーブルにスキーマ変更を適用する手順を行わなかった場合、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)] ページにアクセスするために必要な権限を持つオペレータを認識しません。
既知の問題
リリース 4.2.1 での未解決の問題
既知の問題は、以下のとおり分類されています。
Edge/Gateway の既知の問題- 問題 14655:
SFP アダプタを接続または取り外すと、Edge 540、Edge 840、Edge 1000 でデバイスが応答を停止し、物理的な再起動が必要になる場合があります。
回避策:Edge を物理的に再起動する必要があります。 これは、Orchestrator で [リモート アクション (Remote Actions)] > [Edge の再起動 (Reboot Edge)] を使用するか、Edge の電源を入れ直すことで実行できます。
- 問題 25504:
コストが 255 より大きいスタティック ルートで、ルートの順序設定が予期しない結果になる可能性があります。
回避策:0 と 255 の間のルート コストを使用します。
- 問題 25595:
WAN オーバーレイ上の静的 SLA への変更を適切に機能させるために、再起動が必要になる場合があります。
回避策:WAN オーバーレイからの静的 SLA の追加と削除後、Edge を再起動します。
- 問題 25742:
VMware SD-WAN Gateway に対する最大容量が Gateway に接続されていないプライベート WAN リンクの容量よりも少ない場合でも、アンダーレイが考慮されたトラフィックの上限がこの最大容量に制限されます。
- 問題 25758:
USB WAN リンクが、ある USB ポートから別の USB ポートにスイッチされると、VMware SD-WAN Edge が再起動されるまで、正常に更新されない場合があります。
回避策:1 つのポートから別のポートに USB WAN リンクを移動した後に Edge を再起動します。
- 問題 25855:
Partner Gateway(200 BGP 対応 VRF など)で大規模な設定の更新があると、VMware SD-WAN Gateway を経由する一部のトラフィックで遅延が約 2 ~ 3 秒増加する可能性があります。
回避策:回避策はありません。
- 問題 25921:
ハブに 3,000 個のブランチ Edge が接続されている場合、VMware SD-WAN ハブの高可用性のフェイルオーバーにかかる時間が予想よりも長くなります(最大 15 秒)。
- 問題 25997:
スイッチ ポートに変換されたルーテッド インターフェイスでトラフィックを適切に渡すために、VMware SD-WAN Edge で再起動が必要になる場合があります。
回避策:設定を変更した後で、Edge を再起動します。
- 問題 26421:
クラスタへのトンネルを確立するには、すべてのブランチ サイトのプライマリ Partner Gateway も VMware SD-WAN ハブ クラスタに割り当てる必要があります。
- 問題 28175:
NAT IP アドレスが VMware SD-WAN Gateway インターフェイスの IP アドレスと重複していると、ビジネス ポリシー NAT が失敗します。
- 問題 31210:
VRRP:ARP が VRRP の仮想 IP アドレスに対して LAN クライアントで解決されません。これは、VMware SD-WAN Edge がプライマリで LAN インターフェイスでグローバルでない CDE セグメントが実行されている場合に発生します。
- 問題 32731:
ルートをオフにすると、OSPF 経由で広報された条件付きデフォルト ルートが正しく戻されないことがあります。ルートを再度有効にして無効にすると、正常に取り消されます。
- 問題 32960:
アクティベーション済みの VMware SD-WAN Edge のローカル Web ユーザー インターフェイスで、インターフェイスの「自動ネゴシエーション」と「速度」のステータスが誤って表示されることがあります。
- 問題 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 の割合ではなくハンドオフ キューのドロップ数を使用する必要があります。
- 問題 39374:
VMware SD-WAN Edge に割り当てられた VMware SD-WAN Partner Gateway の順序を変更すると、帯域幅のテストに使用されるローカル ゲートウェイとしてゲートウェイ 1 が正しく設定されない場合があります。
- 問題 39608:
リモート診断「Ping テスト」の出力で、正しい結果が表示される前に、無効な内容が一時的に表示されることがあります。
- 問題 39624:
親インターフェイスが PPPoE で設定されている場合、サブインターフェイス経由の ping が失敗することがあります。
- 問題 39659:
高可用性を強化するように設定されたサイトで、各 VMware SD-WAN Edge に 1 つの WAN リンクがあり、スタンバイ Edge には PPPoE しか接続されておらず、アクティブには非 PPPoE 接続がある場合に、HA ケーブルで障害が発生するとスプリット ブレイン状態(アクティブ/アクティブ)が可能になることがあります。
- 問題 39753:
動的なブランチ間 VPN を無効にすると、現在、動的なブランチ間を使用して送信されている既存のフローが停止する可能性があります。
- 問題 40096:
アクティベーション済みの VMware SD-WAN Edge 840 が再起動された場合、リンク ライトと VMware SD-WAN Orchestrator でポートが「稼動中」と表示されていても、Edge に接続されている SFP モジュールがトラフィックの通過を停止する可能性があります。
回避策:SFP モジュールを取り外して、ポートに再度接続します。
- 問題 40421:
スイッチ ポートとして設定されたインターフェイスを使用して VMware SD-WAN Edge を通過するときに、traceroute でパスが表示されません。
- 問題 42278:
特定のタイプのピアの設定ミスにより、VMware SD-WAN Gateway が IKE 初期化メッセージを非 SD-WAN ピアに継続的に送信することがあります。この問題により、Gateway へのユーザー トラフィックが中断されることはありません。ただし、Gateway のログに IKE エラーが大量に記録されて、有用なログ エントリが確認しづらくなる可能性があります。
- 問題 42388:
VMware SD-WAN Edge 540 で、VMware SD-WAN Orchestrator からインターフェイスを無効にして再度有効にすると、SFP ポートが検出されません。
- 問題 42488:
スイッチ ポートまたはルーティング ポートに対して VRRP が有効になっている VMware SD-WAN Edge で、ケーブルがポートから切断されて、Edge サービスが再起動された場合、LAN に接続されたルートが広報されます。
回避策:この問題の回避策はありません。
- 問題 42872:
ハブ クラスタが関連付けられているハブ プロファイルでプロファイルの隔離を有効にしても、ルーティング情報ベース (RIB) からハブ ルートが取り消されません。
- 問題 43373:
複数の VMware SD-WAN Edge から同じ BGP ルートを学習していて、このルートをオーバーレイ フロー制御で優先から対象終了に移動すると、その Edge が広報 リストから削除されず、広報されたままになります。
回避策:VMware SD-WAN Orchestrator の分散コスト計算を有効にします。
- 問題 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 をハブとして使用することはできません。
- 問題 44832:
Edge 経由の Non SD-WAN Destination から別の Edge 経由の Non SD-WAN Destination へのトラフィック(「ヘアピニング」または「NAT ループバック」)が VMware SD-WAN Edge 上でドロップされます。
- 問題 44995:
ルートがハブ クラスタから戻された場合に、OSPF ルートが VMware SD-WAN Gateway および VMware SD-WAN スポーク Edge から取り消されません。
- 問題 45189:
送信元 LAN 側 NAT が設定されている場合、NAT サブネットのスタティック ルートを設定しなくても、VMware SD-WAN スポーク Edge からハブ Edge へのトラフィックが許可されます。
- 問題 45302:
VMware SD-WAN ハブ クラスタで、1 つのハブが、そのハブとその割り当てられているスポーク Edge の間で共通のすべての VMware SD-WAN Gateway への接続が 5 分より長い間失われた場合、まれに、スポークがハブ ルートを 5 分後に保持できなくなるという状態になることがあります。この問題は、ハブが Gateway との接続を回復したときに自動的に解消されます。
- 問題 46053:
ネイバーがアップリンク ネイバーに変更されても、BGP プリファレンスがオーバーレイ ルートに対して自動修正されません。
回避策:Edge サービスを再起動すると、この問題は修正されます。
- 問題 46137:
3.4.x ソフトウェアを実行している VMware SD-WAN Edge で、Edge が GCM 用に設定されていても、AES-GCM 暗号化を使用したトンネルが開始されません。
- 問題 46216:
ピアが AWS インスタンスの Gateway または Edge 経由の Non SD-WAN Destination で、フェーズ 2 の再キー化をピアが開始すると、フェーズ 1 の IKE も削除されて再キー化が強制されます。 これは、トンネルが破棄されてから再構築されることを意味し、その結果トンネルの再構築中にパケット ロスが発生します。
回避策:トンネルの破棄を回避するには、Gateway または Edge 経由の Non SD-WAN Destination または CSS IPsec の再キー化タイマーを 60 分未満に設定します。 これにより、AWS が再キー化を開始できなくなります。
- 問題 46391:
VMware SD-WAN Edge 3800 の場合、SFP1 および SFP2 のインターフェイスそれぞれにマルチレート SFP (1/10G) の問題があり、これらのポートで使用できなくなります。
回避策:ナレッジベースの記事「VMware SD-WAN Supported SFP Module List (79270)」に従って、単一レートの SFP を使用してください。 マルチレート SFP は、SFP3 と SFP4 で使用できます。
- 問題 46918:
3.4.2 リリースを使用する VMware SD-WAN スポーク Edge で、クラスタ ハブ ノードのプライベート ネットワーク ID が適切に更新されません。
- 問題 47084:
4,000 個のスポーク Edge が接続されている場合に、VMware SD-WAN ハブ Edge が、750 個を超える PIM(プロトコルに依存しないマルチキャスト)ネイバーを確立できません。
- 問題 47244:
アクティベーション済みの、DPDK が有効な VMware SD-WAN Edge 6x0 で、一部の Copper SFP の Edge に、VMware SD-WAN Orchestrator ユーザー インターフェイスにケーブルが挿入されていない場合でも、リンクが「稼動中」と表示されます。
回避策:ケーブルを接続して取り外すと、誤った状態が削除されます。
- 問題 47355:
同じルートがローカルのアンダーレイ BGP、ハブ BGP を経由して学習された場合、または Partner Gateway で静的に設定されている場合、またはそのすべての状況で、ルートのソート順序が、アンダーレイ BGP で優先されるハブ BGP と一致しません。
- 問題 47664:
ハブを介したブランチ間 VPN が無効になったハブとスポークの設定では、L3 スイッチ/ルーターのサマリ ルートを使用してブランチ間トラフィックを戻そうとすると、ルーティング ループが発生します。
回避策:ブランチ間 VPN を有効にするようにクラウド VPN を設定し、[VPN にハブを使用 (Use Hubs for VPN)] を選択します。
- 問題 47681:
VMware SD-WAN Edge の LAN 側のホストが、Edge の WAN インターフェイスと同じ IP アドレスを使用している場合、LAN ホストから WAN への接続が機能しません。
- 問題 47787:
ハブ Edge から、バックホール ビジネス ポリシーで設定された VMware SD-WAN スポーク Edge にフローが開始された場合、このスポーク Edge が VMware SD-WAN Gateway パスを経由してトラフィックを誤って送信します。
- 問題 48166:
Ciena の仮想化 OS を使用している場合、KVM 上の VMware SD-WAN 仮想 Edge がサポートされず、Edge では、データプレーン サービスの障害が繰り返し発生します。
- 問題 48175:
非グローバル セグメントにグローバル セグメントで設定されたインターフェイスと同じ IP アドレス範囲で設定されているインターフェイスがある場合、リリース 3.4.2 を実行している VMware SD-WAN Edge が、非グローバル セグメントに OSPF の隣接関係を形成します。
- 問題 48530:
VMware SD-WAN Edge 6x0 モデルで、3 つの速度 (10/100/1000 Mbps) の Copper SFP の自動ネゴシエーションが実行されません。
回避策:Edge 520/540 は 3 つの速度の Copper SFP をサポートしていますが、このモデルは 2021 年の第 1 四半期に販売終了としてマークされています。
- 問題 48597:ピアへの 2 つのパスのいずれかが停止した場合、マルチホップ BGP ネイバーシップは稼動状態ではなくなります。
複数のパスがあり、そのうちの 1 つが停止しているピアを持つマルチホップ BGP ネイバーシップがある場合、ユーザーは BGP ネイバーシップが停止して、他の使用可能なパスを使用していないことに気付きます。これには、ローカルの IP ループバック ネイバーシップも含まれます。
回避策:この問題の回避策はありません。
- 問題 48666:
IPsec を使用したゲートウェイ パス MTU の計算で、61 バイトの IPsec オーバーヘッドが考慮されていないため、LAN クライアントに対する MTU 広報が多くなり、その後 IPsec パケットの断片化が発生します。
回避策:この問題の回避策はありません。
- 問題 49172:
2 つの異なる VMware SD-WAN Edge に同じ NAT サブネットを使用して設定されたポリシー ベースの NAT ルールが機能しません。
- 問題 49738:
状況によっては、VMware SD-WAN スポーク Edge が複数のハブ Edge を使用するように設定されている場合に、ハブ リストで設定されたハブの 1 つに対して、スポーク Edge がトンネルを形成しないことがあります。
- 問題 50518:
PKI が有効になっている VMware SD-WAN Gateway で、6,000 個より多い PKI トンネルが Gateway に接続しようとすると、受信 SA が削除されないため一部のトンネルが起動しない場合があります。
注:プリシェアード キー (PSK) 認証を使用するトンネルには、この問題はありません。
- 問題 51428:マルチキャスト トラフィックの損失が、VMware SD-WAN Edge に PIM で設定されたサブインターフェイスがあるサイトで発生する場合があります。
PIM を使用して設定されたサブインターフェイスをオンザフライであるセグメントから別のセグメントに移動すると、pimd (PIM を管理するプロセス)が再起動し、サイトで断続的なマルチキャスト トラフィックの損失が発生する可能性があります。
回避策:最初にサブインターフェイスを無効にしてから、サブインターフェイスを別のセグメントに移動します。移動したら、サブインターフェイスを再度有効にします。
- 問題 51436:LTE モデムを使用して VMware SD-WAN Edge を展開しているときに、拡張された高可用性トポロジを使用しているサイトでは、サイトが「スプリット ブレイン」状態になった場合、高可用性のフェイルオーバーに 5~6 分かかります。
スプリット ブレイン状態からのリカバリの一環として、アクティブ Edge 上で LAN ポートが停止し、ポートが停止している間、およびサイトがリカバリできるようになるまで LAN トラフィックに影響が生じます。
回避策:この問題の回避策はありません
- 問題 52483:インターフェイスでアンダーレイ アカウンティング が有効になっている場合、VMware SD-WAN Edge は、トラフィックをオーバーレイに転送するのではなく、誤って同じインターフェイスに転送します。
この動作は、アンダーレイ アカウンティングと再帰的なルート解決の問題が原因で発生します。
回避策:影響を受けるインターフェイスのアンダーレイ アカウンティングを無効にします。
- 問題 53219:VMware SD-WAN ハブ クラスタの再調整後、いくつかのスポーク Edge で RPF インターフェイス/IIF が正しく設定されていない場合があります。
影響を受けるスポーク Edge では、マルチキャスト トラフィックが影響を受けます。クラスタの再調整後、一部のスポーク Edge が PIM join の送信に失敗します。
回避策:この問題は、影響を受けるスポーク Edge が、Edge サービスを再起動するまで続きます。
- 問題 53337:スループットが 3200 Mbps を超えると、VMware SD-WAN Gateway の AWS インスタンスでパケットのドロップが発生することがあります。
トラフィックが 3200 Mbps 以上のスループットを超過し、パケット サイズが 1300 バイトの場合、RX および IPv4 BH ハンドオフでパケットのドロップが発生します。
回避策:この問題の回避策はありません。
- 問題 53359:一部の DDoS 攻撃のシナリオで、BGP/BFD セッションが失敗することがあります。
経路指定されたインターフェイスに接続されているクライアントから LAN クライアントにトラフィックが集中している場合、BGP/BFD セッションが失敗することがあります。また、優先順位の高いリアルタイム トラフィックがオーバーレイの宛先に集中している場合、BGP/BFD セッションが失敗することがあります。
回避策:この問題の回避策はありません。
- 問題 53830:VMware SD-WAN Edge では、DCC フラグが有効になっている場合、BGP ビューの一部のルートに正しい設定および広報値がなく、Edge の FIB で誤った並べ替え順序が発生する場合があります。
Edge 上に多数のルートがあるスケーリングされたシナリオで分散コスト計算 (DCC) が有効になっている場合、ログ bgp_view の Edge 診断バンドルを確認すると、一部のルートが設定および広報値で適切に更新されていないことがあります。 この問題は、検出されるとすれば、大規模なエンタープライズ(ハブ Edge またはハブ クラスタに接続された 100 以上のスポーク Edge)の一部であるいくつかの Edge で検出されます。
回避策:この問題を解決するには、アンダーレイ BGP ルートを再学習するか、影響を受けるルートの VMware SD-WAN Orchestrator の [OFC] ページで [更新] オプションを実行します。ルートの [更新] を実行すると、エンタープライズ内のすべての Edge からルートが再学習されることに注意してください。
- 問題 53934:VMware SD-WAN ハブ クラスタが設定されているエンタープライズで、プライマリ ハブに LAN 側のマルチホップ BGP ネイバーシップが含まれている場合、LAN 側で障害が発生した場合、またはすべてのセグメントで BGP が無効になっている場合、カスタマーはスポーク Edge でトラフィックのドロップを経験することがあります。
ハブ クラスタでは、プライマリ ハブにピア デバイスとのマルチホップ BGP ネイバーシップがあり、ルートを学習します。BGP ネイバーシップが確立されているハブの物理インターフェイスが停止した場合、BGP ビューが空になっているにもかかわらず BGP LAN ルートがゼロにならない場合があります。これにより、ハブ クラスタの再調整が行われなくなる可能性があります。この問題は、BGP がすべてのセグメントで無効になっていて、1 つ以上のマルチホップ BGP ネイバーホップがある場合にも発生する可能性があります。
回避策:LAN 側に障害がある(または BGP が無効になっている)ハブを再起動します。
- 問題 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 を再起動してリカバリします。
- 問題 60006:620 や 640 などのハードウェア ベースの VMware SD-WAN Edge で HA が有効になっている場合、スタンバイ Edge が再起動する場合があります。
620 または 640(この問題が確認されているモデル)で HA が有効になっている場合、スタンバイ Edge はアクティブ/アクティブ パニックを検出することがあります。その場合、スタンバイ Edge は再起動してアクティブ/アクティブ状態を修正します。この問題は、Edge の初期化中に、HA インターフェイスの初期化と HA 状態のマシンの初期化が競合状態になった場合に発生します。つまり、HA 状態のマシンが、HA インターフェイス ドライバの初期化が完了するよりもはるかに早く起動し、その結果、HA 状態のマシンがピア Edge からのハートビートを検出せず、アクティブ状態に移行します。 この問題は滅多に発生しないため、特定のサイトで発生した場合、同じセッションで 2 回発生することはほとんどありません。つまり、サイトでスタンバイ Edge の再起動が無限に繰り返されることはないと考えられます。
回避策:この問題の回避策はありませんが、通常、スタンバイ 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 プローブを無効にすることでした。
回避策:ICMP プローブを無効にします。
- 問題 61361:VMware SD-WAN Edge 3400、3800、および 3810 を Edge リリース 3.4.5、4.0.2、または 4.2.1 にアップグレードするためにソフトウェア アップデートを適用すると、アップデートの直後に Edge モデルが起動しないことがあります。
リリース 3.4.5、4.0.2、および 4.2.1 には、コンプレックス プログラマブル ロジック デバイス (CPLD) の特定のファームウェア アップデートが含まれています。このアップデートにより再起動がトリガされ、「スタック」することがあります。システムを再起動するには手動で電源を入れ直す必要があります。
回避策:手動で Edge の電源を入れ直して、アップデートを完了します。
- 問題 61543:複数の 1:1 NAT ルールが同じ内部 IP を持つ異なるインターフェイス上で設定されている場合、インバウンド トラフィックは 1 つのインターフェイスで受信でき、同じフローの送信パケットは異なるインターフェイス経由でルーティングできます。
外部から内部への NAT フローの場合、1:1 NAT ルールは、パケットが受信される外部 IP およびインターフェイスに対して照合されます。同じフローの送信パケットの場合、VMware SD-WAN Edge は、内部 IP を比較して NAT ルールを再度照合しようとします。送信トラフィックは、「送信トラフィック」が有効になっている最初の一致したルールで設定されたインターフェイスを介してルーティングできます。
回避策:特定の内部 IP アドレスを使用して 1:1 NAT ルールを 1 つのみ設定する以外に、この問題の回避策はありません。
- 問題 62552:サイトでは、断続的に高いパケット ロスと接続の問題が発生することがあります。
これは、ARP 解決をチェックする API が、00:00:00:00 の MAC アドレスを配信しているときにデバイスの ARP 解決が成功したことを Edge に通知することが原因です。 このアドレスは ARP キャッシュに保持され、MAC がゼロとしてリストされているデバイス宛てのパケットはすべてドロップされます。 この状況では、このような MAC アドレスがゼロの正常な ARP の多くのインスタンスが配信され、高いパケット ロスと接続の問題が発生します。
注:問題 60130 とこの問題はどちらも根本的な動作と原因は同じですが、各チケットで想定される修正は異なります。60130 が防御的な回避策による修正である一方、62552 はこの問題が繰り返されることを防ぐ完全な修正になります。
回避策:この問題の回避策はありません。
- 問題 63359:高可用性トポロジと OSPF で設定され、VMware SD-WAN Edge が管理 IP アドレスを使用する Edge 構築のサイトの場合、これらの Edge を 3.4.x から 4.2.x の管理 IP アドレスの構築にアップグレードすると、アップグレード後に OSPF 接続が切断されることがあります。
HA Edge を 4.2.x の管理 IP アドレスの構築にアップグレードすると、HA システムでルーター ID が 169.254.2.2 と定義されることがあります。これは想定外の動作です。Edge でのルーター ID の選択においては、HA インターフェイスの IP アドレスが考慮されないことになっています。このルーター ID は OSPF 接続を切断し、ルート交換が行われなくなるため、完全に切断されます。
回避策:Edge サービスを再起動します(HA フェイルオーバーをトリガします)。これにより、再起動後にルーター ID が再び選択され、正しい ID になります。
- 問題 67790:BGP または OSPF のいずれかを使用し、特定のルートを無視するように受信フィルタを設定しているカスタマー エンタープライズの場合、このエンタープライズで動的コスト計算 (DCC) を有効にすると、受信フィルタは無効になり、トラフィックはこれらのルートを使用しようとします。
DCC が有効になる前は、転送情報ベース (FIB) には、BGP/OSPF 受信フィルタで IGNORE に設定されたルートは含まれません。 DCC を有効にすると、FIB にこのようなルートが含まれるようになり、トラフィックはこれらのルートを使用しようとしますが、カスタマー エンタープライズにおいて重大なトラフィックの中断が発生する可能性があります。
回避策:受信フィルタを正しく適用するために、OSPF/BGP を再起動する必要があります。
- 問題 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 でサポートされている場合にのみ実行できますが、ダウングレードする前に、そのことを確認する必要があります。
- 問題 19566:
高可用性のフェイルオーバー後、スタンバイ VMware SD-WAN Edge のシリアル番号が Orchestrator でアクティブなシリアル番号として表示されることがあります。
- 問題 21342:
セグメントごとに Partner Gateway を割り当てると、VMware SD-WAN Edge の監視リストで、ゲートウェイ割り当ての適切なリストがオペレータ オプションのゲートウェイの [表示 (View)] に表示されない場合があります。
- 問題 24269:
観測された WAN リンクの損失が、QoE グラフには反映されても、[監視 (Monitor)] > [トランスポート (Transport)] > [ロス (Loss)] に反映されません。
- 問題 25932:
VMware SD-WAN Orchestrator で、使用中であっても VMware SD-WAN Gateway を Gateway プールから削除できます。
- 問題 32335:
ユーザーが契約に同意しようとすると、[エンド ユーザー サービス契約 (End User Service Agreement)] (EUSA) ページでエラーが発生します。
回避策:エンタープライズ名の先頭または末尾にスペースが含まれていないことを確認してください。
- 問題 32435:
ポリシーベースの NAT 設定に対する VMware SD-WAN Edge のオーバーライドが、すでにプロファイル レベルで設定されているタプルで許可されます(その逆も可能)。
- 問題 32856:
ハブ クラスタを使用してインターネット トラフィックをバックホールするようにビジネス ポリシーが設定されていても、リリース 3.2.1 からリリース 3.3.x にアップグレードされた VMware SD-WAN Orchestrator 上のプロファイルから、ユーザーがハブ クラスタを選択解除できます。
- 問題 32913:
高可用性を有効にした後、VMware SD-WAN Edge のマルチキャストの詳細が [監視 (Monitoring)] ページに表示されません。フェイルオーバーにより、この問題は解決されます。
- 問題 33026:
契約を削除した後、[エンド ユーザー サービス契約 (End User Service Agreement)] (EUSA) のページが適切に再ロードされません。
- 問題 34828:
リリース 2.x を使用する VMware SD-WAN スポーク Edge と、リリース 3.3.1 を使用するハブ Edge の間で、トラフィックを送受信できません。
- 問題 35658:
あるプロファイルから CSS 設定が異なる別のプロファイルに VMware SD-WAN Edge が移動されたときに(例:プロファイル 1 は IPsec で、プロファイル 2 は GRE)、Edge レベルの CSS 設定が、以前の CSS 設定(例:IPsec と GRE)を引き続き使用します。
回避策:問題を解決するには、Edge レベルで GRE を無効にしてから再度有効にします。
- 問題 35667:
あるプロファイルから、CSS 設定は同じでも GRE CSS 名は異なる(同じエンドポイントの)別のプロファイルに VMware SD-WAN Edge が移動されたときに、一部の GRE トンネルが監視に表示されません。
回避策:問題を解決するには、Edge レベルで GRE を無効にしてから再度有効にします。
- 問題 36665:
VMware SD-WAN Orchestrator がインターネットにアクセスできない場合、Google Maps API へのアクセスを必要とするユーザー インターフェイスのページが完全にはロードされない場合があります。
- 問題 38056:
Edge ライセンスの export.csv ファイルにリージョン データが表示されません。
- 問題 38843:
アプリケーション マップをプッシュするときに、オペレータ イベントがなく、Edge イベントは制限付きのユーティリティになります。
- 問題 39633:
ユーザーが Super Gateway として代替 Gateway を割り当てた後、Super Gateway のハイパー リンクが機能しません。
- 問題 39790:
VMware SD-WAN Orchestrator を使用すると、サポートされている 32 個のサブインターフェイスを超えてユーザーが VMware SD-WAN Edge のルーテッド インターフェイスを設定できます。これにより、ユーザーは、インターフェイス上で 33 個以上のサブインターフェイスを設定できるようになり、Edge のデータプレーン サービスの障害を引き起こす可能性があります。
- 問題 40341:
Skype アプリケーションがリアルタイム トラフィックとしてバックエンドで適切に分類されていても、VMware SD-WAN Orchestrator で Skype ビジネス ポリシーを編集すると、サービス クラスで誤って [トランザクション (Transactional)] と表示されることがあります。
- 問題 41691:
[設定 (Configure)] > [Edge] > [デバイス (Device)] ページで DHCP プールが枯渇していないにもかかわらず、ユーザーが [アドレスの数 (Number of addresses)] フィールドを変更できません。
- 問題 43276:
VMware SD-WAN Edge またはプロファイルに Partner Gateway が設定されている場合に、ユーザーがセグメント タイプを変更できません。
- 問題 44153:
VMware SD-WAN Orchestrator が、[アラートと通知 (Alerts and Notifications)] セクションで設定されたメール アドレスに、アラートの E メールを継続して送信しません。
- 問題 46254:
VMware SD-WAN Edge のアクティベーション中に、VMware SD-WAN Orchestrator が、WAN リンクの MTU が変更されたことや、DHCP が設定されたインターフェイスに VLAN ID が存在することを検出しません。
- 問題 47269:
LTE インターフェイスがサポートされていない Edge モデルに、VMware SD-WAN 510-LTE インターフェイスが表示されることがあります。
- 問題 47713:
クラウド VPN が無効な間にビジネス ポリシー ルールが設定された場合、クラウド VPN を有効にするときに NAT を再設定する必要があります。
- 問題 47820:
プロファイル レベルで無効に設定されている 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 週間以上のデータを表示できます。
- 問題 60039:VMware SD-WAN Edge モデルの変更時に RMA の再アクティベーションが機能しません。
Edge モデルも変更されているサイトで RMA の再アクティベーションを実行すると、VMware SD-WAN Orchestrator はモデルの変更を保存しないため、再アクティベーション リンクが無効になります。この問題は、Edge モデルが変更された RMA の再アクティベーションにのみ影響し、Edge モデルが同じままの RMA の再アクティベーションは、想定どおりに機能します。
回避策:サイトで別の Edge モデルを使用する場合、ユーザーは新しい Edge を作成して、すべての Edge 固有の設定を手動で適用する必要があります。