NSX Advanced Load Balancer が仮想サービスのロード バランシング キャパシティを追加する方法の 1 つは、仮想サービスを追加のサービス エンジン (SE) に配置することです。
たとえば、必要に応じて仮想サービスのキャパシティを追加するには、仮想サービスを SE グループ内の追加の SE にスケール アウトし、不要になったときに追加の SE を削除(スケール イン)します。この場合、仮想サービスのプライマリ SE は、他の SE 間での仮想サービス トラフィックの分散を調整し、仮想サービスのトラフィックの一部の処理も続行します。
仮想サービスをスケーリングする別の方法として、レイヤー 3 ルーティング機能、等コスト マルチパス (ECMP) を備えた Border Gateway Protocol (BGP) 機能とルート ヘルス インジェクション (RHI) を使用することもできます。仮想サービスのスケーリングに ECMP を備えたルート ヘルス インジェクション (RHI) を使用すると、SE 間でスケール アウトされたトラフィックを調整するためにプライマリ SE に発生する管理オーバーヘッドを回避できます。
BGP は、レガシー(アクティブ/スタンバイ)高可用性モードと、柔軟性に優れた(アクティブ/アクティブおよび N+M)高可用性モードでサポートされます。
仮想サービスが健全性モニターまたはその他の理由で「停止」とマークされると、NSX Advanced Load Balancer SE は仮想 IP アドレス (VIP) へのルート アドバタイズを取り消し、仮想サービスが再び「稼動中」とマークされたときのみリストアします。
制限に関する注意事項
- サービス エンジン数:
-
デフォルトでは、NSX Advanced Load Balancer は仮想サービスごとに最大 4 つの SE をサポートします。これは最大 64 の SE まで増やすことができます。各 SE で RHI を使用して仮想サービスの VIP アドレスに
/32
ホスト ルートをアドバタイズすることで、トラフィックを受け付けることができます。アップストリーム ルーターは、ECMP を使用して SE の 1 つに対するパスを選択します。SE 数の制限は、アップストリーム ルーターの ECMP サポートによって適用されます。ルーターが最大 64 個の等コスト ルートをサポートしている場合、RHI に対して有効な仮想サービスは最大 64 個の SE でサポートされます。同様に、ルーターがサポートするパスの数が少ない場合、RHI に対して有効な仮想サービスの数は少なくなります。
- サブネットとピア:
-
NSX Advanced Load Balancer では、4 つの異なるサブネットと、その 4 つのサブネットに対応するピアの数が任意となることをサポートします。したがって VIP では、ピアが属しているサブネットが 4 つ以下の場合でも、5 つ以上のピアでアドバタイズできます。まとめると、次のようになります。
VIP は、すべて単一のサブネットに属する 8 つのピアにアドバタイズできます。
VIP は、個別のサブネットに属する 4 つのペアのピア(ここでも 8 つのピア)にアドバタイズできます。
サポート対象のエコシステム
BGP ベースのスケーリングは、次の環境でサポートされます。
VMware
Linux サーバ(ベアメタル)クラウド
OpenShift と Kubernetes
注:OpenStack ルーターとのピアリングはサポートされていません。ただし、外部ルーターとのピアリングは可能です。
BGP ベースのスケーリング
NSX Advanced Load Balancer では、次のルーティング機能を使用して、仮想サービスのロード バランシングとスケーリングを動的に実行できます。
- ルート ヘルス インジェクション (RHI):
-
RHI では、トラフィックが SE と同じサブネットにない VIP に到達することを許可します。仮想サービスが配置されている NSX Advanced Load Balancer サービス エンジン (SE) は、SE の IP アドレスをネクスト ホップ ルーター アドレスとして使用して、その仮想サービスの VIP にホスト ルートをアドバタイズします。この更新に基づいて、NSX Advanced Load Balancer SE に接続されている BGP ピアはそのルート テーブルを更新し、NSX Advanced Load Balancer SE を VIP に到達するためのネクスト ホップとして使用します。また、ピア BGP ルーターは、VIP に到達するためのネクスト ホップとして自分自身をアップストリーム BGP ピアにアドバタイズします。
- 等コスト マルチパス (ECMP):
-
SE への複数の物理リンク間でトラフィックを負荷共有することで、VIP の帯域幅が高くなります。NSX Advanced Load Balancer SE に BGP ピアへのリンクが複数存在する場合、NSX Advanced Load Balancer SE は各リンクで VIP ホスト ルートをアドバタイズします。BGP ピア ルーターは、仮想サービスの VIP への複数のネクスト ホップ パスを認識し、ECMP を使用してパス間でトラフィックのバランスを調整します。仮想サービスが複数の NSX Advanced Load Balancer SE にスケール アウトされると、各 SE はピア BGP ルーターへの各リンクで VIP をアドバタイズします。
BGP に対して有効になっている仮想サービスがその NSX Advanced Load Balancer SE に配置されると、その SE は各ネクスト ホップ BGP ピア ルーターとの BGP ピア セッションを確立します。次に、NSX Advanced Load Balancer SE は、VIP へのホスト ルート(/32 ネットワーク マスク)をアドバタイズして、仮想サービスの VIP に対して RHI を実行します。NSX Advanced Load Balancer SE は、各 BGP ピアに BGP ルートの更新としてアドバタイズを送信します。BGP ピアが NSX Advanced Load Balancer SE からこの更新を受信すると、ピアは SE をネクスト ホップとして使用する VIP へのルートを使用してルート テーブルを更新します。通常、BGP ピアは VIP ルートも他の BGP ピアにアドバタイズします。
BGP ピアの IP アドレスとローカル自律システム (AS) 番号、およびその他のいくつかの設定は、NSX Advanced Load Balancer Controller の BGP プロファイルで指定されます。RHI サポートは、個々の仮想サービスの構成内で無効(デフォルト)または有効になっています。NSX Advanced Load Balancer SE に同じ BGP ピアへのリンクが複数ある場合は、VIP に対する ECMP サポートも有効になります。NSX Advanced Load Balancer SE は、BGP ピアを持つ各 NSX Advanced Load Balancer SE インターフェイスの VIP に個別のホスト ルートをアドバタイズします。
NSX Advanced Load Balancer SE で障害が発生すると、BGP ピアは、NSX Advanced Load Balancer SE によってアドバタイズされたルートを取り消します。
BGP プロファイルの変更
BGP ピアの変更は次のように処理されます。
新しいピアが BGP プロファイルに追加されると、仮想サービスの IP は新しい BGP ピア ルーターにアドバタイズされます。仮想サービスを無効化したり有効化したりする必要はありません。
BGP プロファイルから BGP ピアが削除されると、BGP ピアにアドバタイズされていた仮想サービスの IP アドレスは取り消されます。
BGP ピアの IP アドレスは、更新されると、BGP ピアの追加/削除として処理されます。
BGP アップストリーム ルーターの構成
BGP 制御プレーンは、スケール設定の場合にルーターの CPU を大量に消費することがあります。ルーターに BGP パケットを追加するには、CoPP ポリシーを変更する必要があります。そうしないと、チャーンが発生したときに、ルーターで BGP パケットがドロップされる可能性があります。
一意の SE BGP ネクスト ホップが別の仮想サービス VIP のセットにアドバタイズされると、ルーター上の ECMP ルート グループまたは ECMP ネクスト ホップ グループが枯渇する可能性があります。このような枯渇が発生すると、ルーターが単一の SE ネクスト ホップにフォールバックし、トラフィックの問題が発生する可能性があります。
サンプル構成
Dell S4048 スイッチにネットワーク エントリ 5,000 個とパス 20,000 個を追加するというサンプル構成を次に示します。
w1g27-avi-s4048-1#show ip protocol-queue-mapping Protocol Src-Port Dst-Port TcpFlag Queue EgPort Rate (kbps) -------- -------- -------- ------- ----- ------ ----------- TCP (BGP) any/179 179/any _ Q9 _ 10000 UDP (DHCP) 67/68 68/67 _ Q10 _ _ UDP (DHCP-R) 67 67 _ Q10 _ _ TCP (FTP) any 21 _ Q6 _ _ ICMP any any _ Q6 _ _ IGMP any any _ Q11 _ _ TCP (MSDP) any/639 639/any _ Q11 _ _ UDP (NTP) any 123 _ Q6 _ _ OSPF any any _ Q9 _ _ PIM any any _ Q11 _ _ UDP (RIP) any 520 _ Q9 _ _ TCP (SSH) any 22 _ Q6 _ _ TCP (TELNET) any 23 _ Q6 _ _ VRRP any any _ Q10 _ _ MCAST any any _ Q2 _ _ w1g27-avi-s4048-1#show cpu-queue rate cp Service-Queue Rate (PPS) Burst (Packets) -------------- ----------- ---------- Q0 600 512 Q1 1000 50 Q2 300 50 Q3 1300 50 Q4 2000 50 Q5 400 50 Q6 400 50 Q7 400 50 Q8 600 50 Q9 30000 40000 Q10 600 50 Q11 300 50
BGP でサポートされる SE ルーター リンク タイプ
次の図は、NSX Advanced Load Balancer と BGP ピア ルーター間でサポートされるリンクのタイプを示しています。
BGP は、BGP ピアと NSX Advanced Load Balancer SE 間の次のタイプのリンクでサポートされます。
NSX Advanced Load Balancer SE をネクスト ホップとする VIP へのホスト ルート(マスク長
/30
または/31
)。ルーターにスイッチ仮想インターフェイス (SVI) という構成のネットワーク ルート(マスク長
/24
)サブネット。レイヤー 2 ポート チャネル(ネクスト ホップ スイッチまたはルーター上で単一の論理リンクとして構成された個別の物理リンク)。
個別のサブネット(SVI で
/31
または/24
)にある複数のレイヤー 3 インターフェイス。各 NSX Advanced Load Balancer SE レイヤー 3 インターフェイスと BGP ピアの間に個別の BGP ピア セッションが設定されます。
各 SE には、複数の BGP ピアを設定できます。たとえば、個別のレイヤー 3 サブネットにインターフェイスを持つ SE は、各インターフェイスで異なる BGP ピアとのピア セッションを持つことができます。NSX Advanced Load Balancer SE と、同じサブネットおよび同じ VLAN にある個別のレイヤー 3 インターフェイス上の BGP ピア間の接続はサポートされていません。
BGP ピアに複数のリンクを使用すると、VIP のスループットが向上します。仮想サービスをスケール アウトしてスループットを向上させることもできます。いずれの場合も、VIP への個別のホスト ルートが、NSX Advanced Load Balancer SE をネクスト ホップ アドレスとして、BGP ピアへの各リンクを介してアドバタイズされます。
この機能は、IPv6 でサポートされています。
デバッグを容易にするために、一部の BGP コマンドを NSX Advanced Load Balancer Controller シェルから表示できます。詳細については、「BGP/BFD の可視性」を参照してください。
仮想サービスが停止した場合のオプションの BGP ルートの取り消し
BGP を介して VIP をアドバタイズする仮想サービスが停止すると、その VIP は BGP から削除され、アクセスできなくなります。NSX Advanced Load Balancer バージョン 20.1 では、仮想サービスが停止したときにオプションで BGP ルートが取り消される機能が追加されました。
追加された機能は次のとおりです。
フィールド
VirtualService advertise_down_vs
構成
この機能をオンにするには、次のように構成します。
[admin:amit-ctrl-bgp]: virtualservice> advertise_down_vs [admin:amit-ctrl-bgp]: virtualservice> save
この機能をオフにするには、次のように構成します。
[admin:amit-ctrl-bgp]: virtualservice> no advertise_down_vs [admin:amit-ctrl-bgp]: virtualservice>save
仮想サービスがすでに停止している場合、構成の変更は影響しません。これらの変更は、今後仮想サービスが停止した場合に適用されます。このような場合は、仮想サービスを無効化してから有効化することで構成を適用する必要があります。
advertise_down_vs
が False の場合、remove_listening_port_on_vs_down
機能は動作しません。HTTP リダイレクト、エラー ページの表示などのカスタム アクションで、停止した仮想サービスを処理するには、
VirtualService.remove_listening_port_on_vs_down
を False にする必須があります。
異なる VRF に同じ BGP ピアを追加する使用事例
ブロックを追加して、次の操作を実行できないようにすることができます。
ピアの追加先の VRF とは異なる VRF を持つネットワークに属する BGP ピアを追加する
ネットワークが BGP プロファイルで使用されている場合にネットワーク VRF を変更する
show serviceengine backend_tp_segrp0-se-zcztm vnicdb
の出力:
| vnic[3] | | | if_name | avi_eth5 | | linux_name | eth3 | | mac_address | 00:50:56:86:0f:c8 | | pci_id | 0000:0b:00.0 | | mtu | 1500 | | dhcp_enabled | True | | enabled | True | | connected | True | | network_uuid | dvportgroup-2404-cloud-d992824d-d055-4051-94f8-5abe4a323231 | | nw[1] | | | ip | fe80::250:56ff:fe86:fc8/64 | | mode | DHCP | | nw[2] | | | ip | 10.160.4.16/24 | | mode | DHCP | | is_mgmt | False | | is_complete | True | | avi_internal_network | False | | enabled_flag | False | | running_flag | True | | pushed_to_dataplane | True | | consumed_by_dataplane | True | | pushed_to_controller | True | | can_se_dp_takeover | True | | vrf_ref | T-0-default | | vrf_id | 2 | | ip6_autocfg_enabled | False 11:46 | vnic[7] | | | if_name | avi_eth6 | | linux_name | eth4 | | mac_address | 00:50:56:86:12:0e | | pci_id | 0000:0c:00.0 | | mtu | 1500 | | dhcp_enabled | True | | enabled | True | | connected | True | | network_uuid | dvportgroup-69-cloud-d992824d-d055-4051-94f8-5abe4a323231 | | nw[1] | | | ip | 10.160.4.21/24 | | mode | DHCP | | nw[2] | | | ip | 172.16.1.90/32 | | mode | VIP | | ref_cnt | 1 | | nw[3] | | | ip | fe80::250:56ff:fe86:120e/64 | | mode | DHCP | | is_mgmt | False | | is_complete | True | | avi_internal_network | False | | enabled_flag | False | | running_flag | True | | pushed_to_dataplane | True | | consumed_by_dataplane | True | | pushed_to_controller | True | | can_se_dp_takeover | True | | vrf_ref | T-0-default | | vrf_id | 2 | | ip6_autocfg_enabled | False |
[T-0:tp_bm-ctlr1]: > show vrfcontext +-------------+-------------------------------------------------+ | Name | UUID | +-------------+-------------------------------------------------+ | global | vrfcontext-0287e5ea-a731-4064-a333-a27122d2683a | | management | vrfcontext-c3be6b14-d51d-45fc-816f-73e26897ce84 | | management | vrfcontext-1253beae-4a29-4488-80d4-65a732d42bb4 | | global | vrfcontext-e2fb3cae-f4a6-48d5-85be-cb06293608d6 | | T-0-default | vrfcontext-1de964c7-3b6b-4561-9005-8f537db496ea | | T-0-VRF | vrfcontext-04bb20ef-1cbc-498b-b5ce-2abf68bae321 | | T-1-default | vrfcontext-9bea0022-0c15-44ea-8813-cfd93f559261 | | T-1-VRF | vrfcontext-18821ea1-e1c7-4333-a72b-598c54c584d5 | +-------------+-------------------------------------------------+
[T-0:tp_bm-ctlr1]: > show vrfcontext T-0-default +----------------------------+-------------------------------------------------+ | Field | Value | +----------------------------+-------------------------------------------------+ | uuid | vrfcontext-1de964c7-3b6b-4561-9005-8f537db496ea | | name | T-0-default | | bgp_profile | | | local_as | 65000 | | ibgp | True | | peers[1] | | | remote_as | 65000 | | peer_ip | 10.160.4.1 | | subnet | 10.160.4.0/24 | | md5_secret | | | bfd | True | | network_ref | PG-4 | | advertise_vip | True | | advertise_snat_ip | False | | advertisement_interval | 5 | | connect_timer | 10 | | ebgp_multihop | 0 | | shutdown | False | | peers[2] | | | remote_as | 65000 | | peer_ip | 10.160.2.1 | | subnet | 10.160.2.0/24 | | md5_secret | | | bfd | True | | network_ref | PG-2 | | advertise_vip | False | | advertise_snat_ip | True | | advertisement_interval | 5 | | connect_timer | 10 | | ebgp_multihop | 0 | | shutdown | False | | keepalive_interval | 60 | | hold_time | 180 | | send_community | True | | shutdown | False | | system_default | False | | lldp_enable | True | | tenant_ref | admin | | cloud_ref | backend_vcenter | +----------------------------+-------------------------------------------------+
テナント(テナント VRF が有効)固有の SE は、PG-4 が構成されている実際の VRF コンテキスト(グローバル)ではなく、テナントに属する VRF コンテキスト (T-0-default) の PG-4 インターフェイスを使用して構成されます。
配置の観点から見ると、仮想サービスのサービス エンジンに対する vNIC の追加を開始すると、vNIC の VRF は常に仮想サービスの VRF になります。この変更により、BGP ピアが属しているネットワークの
vrfcontext
が異なる場合、BGP ピアをvrfcontext
に追加できなくなります。この構成によってトラフィックがドロップする可能性があるため、変更が必要です。VRF-B のネットワークに属する BGP ピアを持つ VRF-A の使用事例は特にないため、構成を変更することはできません。
また、既存のネットワークの VRF を変更でき、そのネットワークの VRF にこのネットワークに属する BGP ピアが存在すると、変更はブロックされます。
双方向の転送検出 (BFD)
BFD は、障害が発生したリンクの高速検出でサポートされます。BFD を使用すると、リンクの各端にあるネットワーク ピアがリンク障害を迅速に検出してリカバリできます。通常 BFD は、BGP がダウンリンクを検出するのを待機するよりも速く、破損したリンクを検出して修復します。
たとえば、NSX Advanced Load Balancer SE で障害が発生した場合でも、BGP ピア ルーターの BFD でリンク障害をすばやく検出して修正することができます。
BFD 機能では、BGP マルチホップの実装をサポートします。
スケーリング
仮想サービスのスケール アウト/スケール インがサポートされています。この例では、仮想サービスは 10.10.10.x ネットワークの NSX Advanced Load Balancer SE に配置され、3 つの追加 NSX Advanced Load Balancer SE にスケール アウトされます。
スケール アウト/スケール イン時のフローの回復性
フローは 5 タプル、src-IP、src-port、dst-IP、dst-port、protocol です。ルーターは 5 タプルのハッシュを実行して、使用する等コスト パスを選択します。SE スケール アウトが発生すると、ルーターには使用する別のパスが付与され、ハッシュ アルゴリズムが異なる選択を行い、既存のフローが中断される可能性があります。この BGP ベースのスケール アウトの問題にグレースフルに対処するため、NSX Advanced Load Balancer では IP-in-IP (IPIP) トンネルを使用した回復力の高いフロー処理をサポートします。この処理のシーケンスを以下に示します。
図 1 は、4 つの SE に配置され、クライアントと SE-A 間でフローが進行中の仮想サービスを示しています。図 2 では、SE-E へのスケール アウトがあります。これにより、ルーターのハッシュが変更されます。既存のフローが他の SE に再ハッシュされます。この特定の例では、SE-C であるとします。
NSX Advanced Load Balancer の実装では、SE-C は他のすべての SE にフロー プローブを送信します(図 4)。図 5 は、図に示すフローの所有権の要求に応答する SE-A を示しています。図 6 では、SE-C で IPIP トンネルを使用して、このフローのすべてのパケットを SE-A に送信します。
図 7 では、SE-A は引き続きフローを処理し、その応答をクライアントに直接送信します。
マルチホーミングされた BGP 仮想サービスのフローの回復性
フローの回復性は、VIP をフロントエンドの複数のピアにアドバタイズするように構成され、仮想サービスに関連付けられている SNAT IP アドレスをバックエンドの複数のピアにアドバタイズするように構成されている BGP 仮想サービスがある場合にサポートされます。
このような設定では、いずれかのリンクが停止すると、BGP は特定の NIC からのルートを取り消すため、そのフローは同じ SE の別のインターフェイスまたは別の SE 上に再ハッシュされます。フローを受信する新しい SE は、フロー プローブを使用してフローをリカバリしようとしますが、インターフェイスが停止しているために失敗します。
この問題は、フロントエンドとバックエンドの両方のフローで発生します。
フロントエンド フローをリカバリするには、フローがサービス エンジンの複数の NIC に配置されている BGP 仮想サービスに属している必要があります。
バックエンド フローをリカバリするには、仮想サービスに SNAT IP アドレスを設定し、BGP を介してバックエンドの複数のピアにアドバタイズする必要があります。
フロントエンド フローのリカバリ
- 同じ SE 内のフローのリカバリ:
-
インターフェイスが停止しても、FT エントリは削除されません。フローが別のインターフェイスに到達すると、フロー プローブがトリガされ、古いフロー テーブルからフローが到達した新しいインターフェイスにフローが移行されます。
インターフェイス停止イベントがコントローラに報告され、コントローラはインターフェイスから VIP 配置を削除します。これにより、プライマリ仮想サービス エントリがリセットされます。同じフローが新しいインターフェイスに到達すると、仮想サービスが最初に複数のインターフェイスに配置された場合はフロー プローブ、フロー移行がトリガされます。
- スケール アウトされた SE でのフローのリカバリ:
-
フローが新しい SE に到達すると、リモート フロー プローブがトリガされます。リレーと呼ばれる新しいフラグがフロー プローブ メッセージに追加されます。このフラグは、すべての受信インターフェイスが、フローが存在できる他のフロー テーブルにフロー プローブをリレーする必要があることを示します。このフラグは、仮想サービスが BGP スケール アウト仮想サービスとして検出された場合に、フロー プローブの送信者側で設定されます。
受信側 SE では、メッセージが他のフロー テーブルにリレーされ、フローが移行されます。そのため、新しい SE からの後続のフロー プローブは応答を取得します。これは、フローが実行中のインターフェイス上に存在するためです。
フロー プローブの受信側 SE に複数のインターフェイスがある場合、これらはすべてフロー移行をトリガします。
バックエンド フローのリカバリ
バックエンド フローは、SNAT IP アドレスがバックエンド接続に使用されている場合にのみ移行できます。バックエンドで複数の BGP ピアが構成され、サーバが複数のルートを介して到達可能な場合、SNAT IP アドレスはすべてのインターフェイスに配置されます。また、フロー テーブル エントリは、バックエンドのすべてのインターフェイスに作成されます。
その結果、インターフェイスに障害が発生し、フローがフロー テーブル エントリを持つ別のインターフェイスに到達すると、フローがリカバリされます。
Message Digest5 (MD5) 認証
BGP は、Message Digest 5 (MD5) アルゴリズムを使用した認証メカニズムをサポートしています。認証が有効になっている場合、ピア間で交換された BGP に属するすべての TCP セグメントが検証され、認証が成功した場合にのみ受け入れられます。認証を成功させるには、両方のピアを同じパスワードで構成する必要があります。認証に失敗すると、BGP ピア セッションは確立されません。BGP 認証は、悪意のあるユーザーがネットワーク ルーティング テーブルを簡単に中断できないようにするので非常に便利です。
BGP の MD5 認証の有効化
MD5 認証を有効にするには、それぞれの BGP ピア構成で md5_secret
を指定します。MD5 サポートは OpenShift クラウドに拡張され、サービス エンジンは Docker コンテナとして実行されますが、ホストになりすます他のルーターとピアリングされます。
Mesos サポート
BGP は、Mesos 展開の North-South インターフェイスでサポートされます。仮想サービスを処理している SE コンテナは、クラウドの BGP ピアリング プロファイルで構成された BGP ルーターとの BGP ピア セッションを確立します。次に、SE で、/64
を BGP ピアにアドバタイズして、/64
ルート(ホスト ルート)を VIP に挿入します。
BGP ピア ルーターには、次の要件が適用されます。
BGP ピアは、BGP ネイバー構成で SE の IP インターフェイスとサブネットを許可する必要があります。SE は BGP ルーターとのピア接続を開始します。
eBGP の場合、ピア ルーターは BGP セッションで減少した TTL 値を検出します。これにより、セッションが起動しなくなる可能性があります。eBGP マルチホップ TTL を設定すると、この問題を回避できます。たとえば、Juniper ルーターでは、eBGP マルチホップ TTL を 64 に設定する必要があります。
MD5 認証を有効にするには、それぞれの BGP ピア構成で md5_secret
を選択します。MD5 サポートは OpenShift クラウドに拡張され、サービス エンジンは Docker コンテナとして実行されますが、ホストになりすます他のルーターとピアリングされます。
NSX Advanced Load Balancer での BGP 機能の有効化
NSX Advanced Load Balancer での BGP 機能の構成は、BGP プロファイルを構成し、仮想サービスの構成で RHI を有効にすることで行います。
BGP プロファイルを構成します。BGP プロファイルは、NSX Advanced Load Balancer SE および各ピア BGP ルーターが存在するローカル自律システム (AS) ID と、各ピア BGP ルーターの IP アドレスを指定します。
仮想サービスの構成の [詳細] タブで、[BGP を使用して VIP をアドバタイズ] オプションを有効にします。このオプションは、NSX Advanced Load Balancer SE をネクスト ホップとして、ホスト ルートを VIP アドレスにアドバタイズします。
LSC インバンドのグローバル VRF で BGP が構成されている場合、SE で仮想サービスが構成されている場合にのみ、BGP 構成が SE に適用されます。それまでは、SE とピア ルーター間のピアリングは発生しません。