今回はTier-0 GWのSRを使用して、物理ネットワークとNSX-Tの仮想ネットワーク間を接続する方法についてまとめました。
- 概要
- 検証結果
- 検証内容、構成
- ネットワーク機器のCLIの設定
- NSX EdgeのvNICを収容するvDSの作成
- NSX Edge用のIP Address Poolの作成
- NSX Edge用のUplink Profileの作成
- VLAN Transport Zoneの作成
- Uplink用のSegmentの作成
- NSX Edgeのデプロイ
- NSX Edgeデプロイ後の状態確認
- Edge Clusterの作成
- Edge Cluster作成後の状態確認
- Tier-0 GWへのEdge Clusterの割り当て
- Tier-0 GWへのEdge Cluster割り当て後の状態確認
- Tier-0 GWにUplinkを追加
- Tier-0 GWにUplink追加後の状態確認
- 疎通確認
概要
SRについて
過去の記事で解説したTier-1 GWやTier-0 GWのDRは、仮想マシン間の通信であるEast-West Trafficをルーティングすることは可能です。しかし、DRだけでは、物理ネットワークと仮想ネットワーク間を接続し、仮想マシンと物理ネットワーク間の通信であるNorth-South Trafficをルーティングすることはできません。
DRはハードウェアベースの処理のみサポートしており、BGPやLBなどのソフトウェアベースの処理はサポートしていません。物理ネットワークと仮想ネットワークを接続する際は、物理ネットワーク側のルータとNSX-T側のルータ間でBGPを動作させるケースも存在します。つまり、物理ネットワークとの境界となるNSX-T側のルータではソフトウェアベースの処理が必要になる場合もあります。
そのため、物理ネットワークと仮想ネットワークを接続する際は、ソフトウェアベースの処理をサポートしているSR(Service Router)を配置する必要があります。
Tier-0 GWとTier-1 GW共にDRに加えて、SRもサポートしていますが、Tier-0 GWのSRとTier-1 GWのSRでは使用可能な機能に差異があります。今回の記事で扱う仮想ネットワークと物理ネットワークを接続する機能はTier-0 GWのSRでみ使用可能です。
SRはNSX Edgeと呼ばれるNSX-T専用の仮想マシン上に配置されます。ESXiホスト上にはSRは配置されません。(NSX EdgeにはSRに加えて、DRも配置されます。また、ベアメタルサーバをNSX Edgeとして使用することも可能ですが、ここでは省略します。)
NSX Edgeについて
NSX EdgeはSRを配置するためのNSX-T専用の仮想マシンになります。NSX Edgeには4個のvNICが存在し、eth0は管理通信、fp-eth0～fp-eth2はGeneveのトラフィックや仮想ネットワークと物理ネットワーク間のトラフィックの転送で使用されます。
ESXiホストと同様に、NSX EdgeもTransport Nodeとして動作しており、NSX Edge内にもN-VDSやTEPが生成されます。NSX EdgeをOverlayタイプのTransport Zoneに参加させることで、NSX EdgeとESXiホスト間でGenveを使用したオーバレイネットワークを構築可能です。
また、NSX Edgeには物理ネットワークと仮想ネットワークを接続するためのSRも配置されます。そして、このSRを物理ネットワークに直接接続する際にVLANタイプのTransport Zoneを使用します。(VLAN Transport Zoneについては、次の章で自分なりにかみ砕いて理解した内容をまとめています。)
Overlay Transport ZoneとVLAN Transport Zoneについて
以前の記事でも少し解説しましたが、Transport ZoneはGeneveを使用したL2オーバレイネットワークを展開する範囲を制限するためのコンポーネントで、SegmentやESXiホスト等に関連付けられます。
ESXiホストは自身が所属しているOverlayタイプのTransport Zoneと同じものが割り当てられたSegmentのみ認識可能です。つまり、ESXiホストは自身が所属いしてるOverlayタイプのTransport Zoneと同じものが割り当てられたSegmentに対してのみ、仮想マシンのvNICを接続可能です。
実は、Transport ZoneにはOverlay Transport ZoneとVLAN Transport Zoneの2種類が存在します。今まで使用していたTransport ZoneはOverlay Transport Zoneになります。
Overlay Transport Zoneに関連付けられたSegmentでは、仮想マシンから受信したフレームを物理ネットワークに転送する際、フレームをGeneveでカプセル化します。
一方、VLAN Transport Zoneに関連付けられたSegmentでは、仮想マシンから受信したフレームを物理ネットワークに転送する際、フレームにVLANタグを付加します。(もちろん、VLANタグを付加せず、物理ネットワーク側にフレームを転送することも可能です。)
また、VLAN Transport Zoneでは、Geneveでのカプセル化を実施するためのTEPは生成されません。
(実際は、下図のような使い方はしませんが、このような設定を投入して、異なるESXiホストに存在する仮想マシン間で通信することも可能です。)
ここで言いたいことは、Transport Zoneは、Segmentを認識できるESXiホストを制限する、すなわち、オーバレイネットワークを展開する範囲を制限する役割の他に、オーバレイネットワークを構築する際に使用するプロトコル(Geneve or VLAN)を制御する役割も果たします。
VLAN Transport Zoneを使用することで、物理ネットワークに転送されるフレームにはVLANタグのみ付加されます。VLANタグは物理スイッチ側で削除可能なため、下図のように、NSX-Tの仮想ネットワークに存在する仮想マシンと物理ネットワーク側に存在するホスト間で通信可能です。
上記で説明したVLAN Transport Zoneは、Tier-0 GWのSRのUplinkを収容するSegmentに割り当てます。これにより、N-VDSは、Tier-0 GWのSRから受信したフレームに対して、Geneveによるカプセル化を実施せずに、VLANタグを付加して、物理ネットワーク側に転送することが可能です。この結果、外部の物理ネットワークとNSX-Tで構築した仮想ネットワーク間で通信できるようになります。
(詳細な通信フローは検証証跡の方で説明します。)
NSX Edgeとネットワークの接続
NSX Edgeは仮想マシンなので、ESXiの仮想スイッチに接続されます。NSX Edgeを収容する仮想スイッチでは、NSX Edge用に以下のポートグループを用意する必要があります。
- Geneve通信用のvNICを収容するポートグループ
- 仮想ネットワーク⇔物理ネットワーク間の通信用のvNICを収容するポートグループ
- 管理通信用のvNICを収容するポートグループ
(補足として、上手ではNSX Edgeの全vNICを同じ仮想スイッチに収容していますが、vNIC毎に異なる仮想スイッチに収容しても問題有りません。)
上記では、ESXiホストがNSX-Tのオーバレイネットワークの構築に使用しているvDSと、NSX Edgeを収容するvDSを分けましたが、同じvDSを併用することも可能です。
ただし、この構成の場合、ESXiホストのTEPとNSX EdgeのTEPを同じサブネットに配置することはできません。以下のように、ESXiホストのTEPを収容するポートグループとNSX EdgeのTEPを収容するポートグループに同じVLAN IDを割り当て、同じセグメントに配置した場合、ESXiホストのTEPとNSX EdgeのTEP間ではGeneveの通信が失敗します。(これはNSX-Tの仕様なので、致し方ありません。)
ESXiホストとNSX EdgeでvDSを併用する場合は、ESXiホストのTEPを収容するポートグループとNSX EdgeのTEPを収容するポートグループに異なるVLAN IDを割り当て、ESXiホストのTEPとNSX EdgeのTEPを異なるセグメントに配置する必要があります。
SRとDR間の接続
Tier-1 GWとTier-0 GWの接続の際と同様に、SRとDRを配置した際、自動的に、SRとDR間を接続するTransit BP(Back Plane)と呼ばれるSegmentが生成されます。また、Transit BPには169.254.0.0/24のアドレスが割り当てられます。(ドキュメントには169.254.0.0/28を使用すると記載がありましたが、バージョン3.0では169.254.0.0/28が使用されました。)
SRの冗長化について
SRは配置するNSX Edgeが1台の状況で、NSX Edgeに障害が発生した場合、物理ネットワークとNSX-Tの仮想ネットワーク間で通信不可に、また、SRで提供しているDHCPやLBなどのサービスが利用できなくなります。
そのため、冗長性を確保するために、特定のTier-1 GWやTier-0 GWのSRを複数のNSX Edgeに配置し、SRでHA(High Availability)を構成することが可能です。
SRのHA方式は2種類存在します。1つ目はActive/Active方式で、複数(最大8台)のNSX Edge上に配置したSRを同時に使用可能です。Active/Active方式はTier-0 GWでのみサポートしています。
2つ目はActive/Standby方式で、2台のNSX Edge上にSRを配置し、一方のSRをActive、もう一方のSRをStandbyとして使用します。正常時は、Active状態のSRのみ使用してトラフィックの転送やサービスを提供します。Active状態のSRで障害が発生した場合、Standby状態のSRがActve状態に遷移し、処理を継続します。Active/Standby方式はTier-1 GWとTier-0 GWの両方でサポートしています。
Active/Active方式とActive/Standby方式の大きな違いはセッション情報の同期の有無になります。Active/Standby方式でのみ、NSX Edge間でセッション情報が同期されます。Active/Active方式では、NSX Edge間でセッション情報は同期されません。
そのため、SRでStateful FWやNATなどを使用したい場合は、Active/Standby方式を選択する必要があります。
冗長化に関しては、別の記事で詳しく検証したいと思います。
Edge Clusterについて
NSX Edgeをデプロイ後、最初にEdge Clusterを構成する必要があります。(NSX Edgeが1台の場合でも、Edge Clusterの構成は必須です)
Tier-1 GWやTier-0 GWにはNSX Edgeを直接割り当てるのではなく、Edge Clusterを割り当てます。
Acitve/Active方式の場合は、Edge Clusterに属する全NSX EdgeにSRが配置されます。一方、Active/Standby方式の場合は、Edge Clusterの中から2台のNSX Edgeを選択し、SRを配置します。
検証結果
検証内容、構成
ESXi1にNSX Edge1をデプロイします。
ESXi1にデプロイしたNSX Edge1にTier-0 GWのSRを配置し、NSX-Tの仮想ネットワークに存在するR1と物理ネットワークに存在するR2間で通信できるようにします。
アンダーレイの物理スイッチではGeneveの通信をVLAN 100、物理ネットワークとNSX-Tの仮想ネットワーク間の通信をVLAN 200に収容します。
ネットワーク機器のCLIの設定
vlan 100,200
!
interface GigabitEthernet1/0/1
switchport access vlan 100
switchport mode access
!
interface GigabitEthernet1/0/11
switchport trunk allowed vlan 100,200
switchport mode trunk
!
interface GigabitEthernet1/0/12
switchport access vlan 200
switchport mode access
interface GigabitEthernet2
ip address 10.1.1.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 10.1.1.254
interface GigabitEthernet2
ip address 20.1.1.100 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 20.1.1.1
NSX EdgeのvNICを収容するvDSの作成
事前にNSX Edge1のvNICを収容するvDSを作成します。
NSX Edge用のIP Address Poolの作成
IP Address Poolを作成し、NSX Edge1のTEP用のアドレスを定義します。
NSX Edge用のUplink Profileの作成
Uplink Profileを作成し、NSX Edge1のN-VDSのUplinkを定義します。
VLAN Transport Zoneの作成
NSX Edge1のUplinkを収容するSegmentに割り当てるVLAN Transport Zoneを定義します。
Uplink用のSegmentの作成
Uplink用のSegmentを作成し、上記で作成したVLAN Transport Zoneを割り当てます。今回、NSX Edge1が送信するフレームにVLANタグを挿入させないために、VLANに0を指定します。
NSX Edgeのデプロイ
NSX Manager上からESXi1に対して、仮想マシンとしてNSX Edge1をデプロイします。
NSX Edge1の名前、FQDN、リソースを指定します。
ログイン用のユーザ名とパスワードを指定します。また、SSHの有効/無効を指定します。
NSX Edge1のデプロイ先のESXiホスト、データストアを指定します。
管理通信用のvNICであるeth0のアドレスや接続先のESXiホスト側のポートグループを指定します。
次に、NSX Edge1がGeneveを使用したオーバレイネットワークを構築する際に使用するN-VDSを定義します。
Overlay Transport Zone、Uplink Profile、TEP用のアドレスを定義したIP Address Poolを指定します。また、N-VDSのUplinkの接続先のESXiホスト側のポートグループを指定します。
NSX Edge1上に配置されたTier-0 GWのSRのUplinkを収容するN-VDSを作成します。
VLAN Transport Zone、Uplink Profileを指定します。また、N-VDSのUplinkの接続先のESXiホスト側のポートグループを指定します。
NSX Edgeデプロイ後の状態確認
NSX Edgeの状態確認(NSX ManagerのGUI)
NSX Edge1が稼働していることが確認出来ます。
NSX Edgeの状態確認(NSX ManagerのCLI)
NSX Edge1がTransport Nodeとして登録されていることが確認できます。
nsx-manager1> get nodes
UUID Type Display Name
c58b27c7-d7bb-4037-98da-f8cb3d1b9456 edg Edge1
a5497ecf-37c0-4b69-a573-a8c17c2d9419 esx 192.168.1.101
94fe3942-0a81-563e-a720-49b161498cf4 mgr nsx-manager3
16c13942-a612-2ed7-390d-337a9c6bba70 mgr nsx-manager2
f84a3942-dd41-cf11-f1c8-f25201f67c33 mgr nsx-manager1
nsx-manager1> get transport-nodes status
TransportNode-ID Remote-Address Controller SSL-Enabled Connection-State Supported-Versions
a5497ecf-37c0-4b69-a573-a8c17c2d9419 192.168.1.101:49985 bd394c3a-7f09-4242-9c13-92b43b9808c7 true OPENED [3.0, 2.5, 2.4]
c58b27c7-d7bb-4037-98da-f8cb3d1b9456 2907f2d8-ae0a-4f61-b900-9d6b873f2d46 true CLOSED []
NSX Edgeの状態確認(NSX EdgeのCLI)
NSX Edgeに存在するN-VDSはget host-switchesコマンドで確認可能です。NSX Edge1に2個のN-VDSが存在していることが確認できます。またN-VDS1のTEP用のアドレスが172.16.1.121であることが確認できます。
edge1> get host-switches
Host Switch : 4425e713-bd85-4abb-9b5b-d026598f40f7
Switch Name : N-VDS1
Transport Zone : 729bb008-56fb-4ad6-bac9-16dab19ceb4d
Physical Port : fp-eth0
Uplink Name : edge-uplink0
Transport VLAN : 0
Default Gateway : 0.0.0.0
Subnet Mask : 255.255.255.0
Local VTEP Device : fp-eth0
Local VTEP IP : 172.16.1.121
Host Switch : d93351b9-9c5b-4ef3-8476-334e9caba16f
Switch Name : N-VDS2
Transport Zone : b944630e-d65d-4f69-a361-cac547293bc5
Physical Port : fp-eth1
Uplink Name : edge-uplink0
NSX Edge用のvDSの状態確認(vCenterのGUI)
NSX Edge1がvDSのポートグループに接続していることが確認できます。
Edge Clusterの作成
Edge Clusterを作成し、先程デプロイしたNSX Edge1を所属させます。
Edge Cluster作成後の状態確認
Edge Clusterの状態確認(NSX ManagerのGUI)
Edge ClusterにNSX Edge1が追加されていることが確認できます。
NSX Edgeの状態確認(NSX EdgeのCLI)
NSX EdgeがEdge Clusterに参加しているかはget edge-cluster statusコマンドで確認可能です。
edge1> get edge-cluster status
High Availability State : Active
Since : 2020-08-13 07:32:15.83
Edge Node Id : c58b27c7-d7bb-4037-98da-f8cb3d1b9456
Edge Node Status : Up (Routing Down)
Admin State : Up
Vtep State : Up
Configuration : applied
Health Check Config :
Interval : 1000 msec
Deadtime : 3000 msec
Max Hops : 255
Service Status :
Datapath Config Channel : Up
Datapath Status Channel : Up
Routing Status Channel : Up
Routing Status : Down
Peer Status :
Tier-0 GWへのEdge Clusterの割り当て
Tier-0 GWにEdge Clusterを割り当てます。
Tier-0 GWへのEdge Cluster割り当て後の状態確認
NSX Edgeの状態確認(NSX ManagerのGUI)
Tier-0 GWにEdge Clusterを割り当てただけでは、NSX EdgeにSRが生成されていないことが確認できます。
NSX Edgeの状態確認(NSX EdgeのCLI)
NSX Edge上に生成されたDRやSRはget logical-routersコマンドで確認可能です。現在はTier-0 GWのSRが生成されていないことが確認出来ます。(下記のVRF 0のコンポーネントはGeneve通信用の仮想ルータになります。)
edge1> get logical-routers
Logical Router
UUID VRF LR-ID Name Type Ports
736a80e3-23f6-5a2d-81d6-bbefb2786666 0 0 TUNNEL 3
Tier-0 GWにUplinkを追加
物理ネットワークとNSX-Tの仮想ネットワークを接続するために、Tier-0 GWにUplinkを追加します。Uplinkを追加したタイミングで、NSX EdgeにTier-0 GWのSR等が生成されます。
事前に定義したUplink用のSegment、Uplinkのアドレス、Uplinkを持たせるNSX Edgeを指定します。
Tier-0 GWにUplink追加後の状態確認
NSX Managerの状態確認(NSX ManagerのGUI)
Tier-0 GWが物理ネットワークと接続していることが確認できます。
NSX Edge1にTier-0 GWのSRが生成されていることが確認できます。
NSX Managerの状態確認(NSX ManagerのCLI)
Tier-0 GWのSRが生成されていることが確認できます。
nsx-manager1> get logical-routers
LR-ID LR-Name Router-Type ClusterId UUID
0xc02 DR-Tier-0_GW DISTRIBUTED_ROUTER_TIER0 031757a6-06d8-44bb-9e06-1ba1ac0e78c1
0xc04 SR-Tier-0_GW SERVICE_ROUTER_TIER0 00002000-0000-0000-0000-000000000c02 e75612f1-c47a-497f-b747-692d2c1071c2
0xc01 DR-Tier-1_GW DISTRIBUTED_ROUTER_TIER1 a25aa19c-faf7-4598-9ea4-4239599e3495
Tier-0 GWのDRとSRを接続するためのTransit BP用のSegmentが生成されていることが確認できます。
nsx-manager1> get logical-switches
VNI UUID Name Type
65536 aed9a131-8547-43a4-b747-72d21de2da77 Segment1 DEFAULT
65538 221a7d12-c45b-4589-94c9-85401b1744ca transit-bp-031757a6-06d8-44bb-9e06-1ba1ac0e78c1 TRANSIT
65537 1548cf7e-c69a-4813-839a-2c5794c1b533 transit-rl-a25aa19c-faf7-4598-9ea4-4239599e3495 TRANSIT
Tier-0 GWのDRとSRがTransit BPに接続していることが確認できます。また、Transit BPのアドレスが169.254.0.0/24であることが確認できます。
#Transit BPの状態
nsx-manager1> get logical-switch 221a7d12-c45b-4589-94c9-85401b1744ca ports
LogSwitchPort-ID LogSwitch-ID Child-UUID Child-EntityType TransportNode-ID
2318bc16-54ba-44d3-bbe0-d7ef50fdf752 221a7d12-c45b-4589-94c9-85401b1744ca efa2a0a3-5dc9-4a43-9c02-9ba5e760fbfa LogicalRouterPort a5497ecf-37c0-4b69-a573-a8c17c2d9419
c58b27c7-d7bb-4037-98da-f8cb3d1b9456
bea48d48-20e0-47bf-a694-0b93f932a6b3 221a7d12-c45b-4589-94c9-85401b1744ca c677d6f1-9dc1-40c6-9c61-0cbf45ff1efa LogicalRouterPort c58b27c7-d7bb-4037-98da-f8cb3d1b9456
#Tier-0 GWのDRの状態
nsx-manager1> get logical-router 031757a6-06d8-44bb-9e06-1ba1ac0e78c1 interfaces
Interface IP Urpf-Mode Admin-State-Up UUID
bp-dr-port 169.254.0.1/24 PORT_CHECK true efa2a0a3-5dc9-4a43-9c02-9ba5e760fbfa
fe80::50:56ff:fe56:4452/64
Tier-0_GW-Tier-1_GW-t0_lrp 100.64.128.0/31 PORT_CHECK true 5117fa5c-029d-49e4-958f-344b56b0d4ed
fcc3:7c30:4fbf:b800::1/64
fe80::50:56ff:fe56:4452/64
#Tier-0 GWのSRの情報
nsx-manager1> get logical-router e75612f1-c47a-497f-b747-692d2c1071c2 interfaces
Interface IP Urpf-Mode Admin-State-Up UUID
Ext_Uplink1 20.1.1.1/24 STRICT_MODE true 8d96d39b-ff32-48d8-9857-52d660fff25b
bp-sr0-port 169.254.0.2/24 NONE true c677d6f1-9dc1-40c6-9c61-0cbf45ff1efa
fe80::50:56ff:fe56:5300/64
system-loopback-port 127.0.0.1/8 NONE true d5b5b688-bb71-4d6d-af41-cdc5d1fad93e
::1/128
Tier-0 GWのDRのルーティングテーブルを見ると、Tier-0 GWのUplinkの20.1.1.0/24が投入されていることが確認できます。
nsx-manager1> get logical-router 031757a6-06d8-44bb-9e06-1ba1ac0e78c1 route
Router/Cluster-UUID Destination Next-Hop LR-Port-Id Blackhole Blackhole-Action Route-Type Admin-Distance Admin-State-Up Route-UUID
031757a6-06d8-44bb-9e06-1ba1ac0e78c1 100.64.128.0/31 N/A 5117fa5c-029d-49e4-958f-344b56b0d4ed false N/A CONNECTED 0 true 0af964e3-1873-4cf2-8b06-a38214d031cd
031757a6-06d8-44bb-9e06-1ba1ac0e78c1 ::/0 fe80::50:56ff:fe56:5300 efa2a0a3-5dc9-4a43-9c02-9ba5e760fbfa false N/A NSX_CONNECTED 250 true 3e8393c3-2b67-416e-b469-930d6b0f1c51
031757a6-06d8-44bb-9e06-1ba1ac0e78c1 fe80::/64 N/A 5117fa5c-029d-49e4-958f-344b56b0d4ed false N/A CONNECTED 0 true bf36db6d-05d3-4e83-90ab-0208f1077629
N/A efa2a0a3-5dc9-4a43-9c02-9ba5e760fbfa false N/A CONNECTED 0 true
031757a6-06d8-44bb-9e06-1ba1ac0e78c1 20.1.1.0/24 169.254.0.2 efa2a0a3-5dc9-4a43-9c02-9ba5e760fbfa false N/A NSX_CONNECTED 0 true 646125d9-ab2e-422e-a6b2-9546a1f7478d
031757a6-06d8-44bb-9e06-1ba1ac0e78c1 20.1.1.1/32 169.254.0.2 efa2a0a3-5dc9-4a43-9c02-9ba5e760fbfa false N/A NSX_CONNECTED 0 true 6e6dfa96-0040-44fe-8730-17c71cb74f63
031757a6-06d8-44bb-9e06-1ba1ac0e78c1 fcc3:7c30:4fbf:b800::/64 N/A 5117fa5c-029d-49e4-958f-344b56b0d4ed false N/A CONNECTED 0 true 4f4baa36-4df1-4c8a-a3e8-20cece774d20
031757a6-06d8-44bb-9e06-1ba1ac0e78c1 169.254.0.0/24 N/A efa2a0a3-5dc9-4a43-9c02-9ba5e760fbfa false N/A CONNECTED 0 true f7abf229-707e-4abe-97a6-217d28ff28b1
031757a6-06d8-44bb-9e06-1ba1ac0e78c1 169.254.0.0/25 N/A efa2a0a3-5dc9-4a43-9c02-9ba5e760fbfa false N/A CONNECTED 0 true df580895-7d5f-4976-b014-565d2884e283
031757a6-06d8-44bb-9e06-1ba1ac0e78c1 0.0.0.0/0 169.254.0.2 efa2a0a3-5dc9-4a43-9c02-9ba5e760fbfa false N/A NSX_CONNECTED 250 true a63b25b0-0f84-4393-9b3f-8d5154b7dbcf
031757a6-06d8-44bb-9e06-1ba1ac0e78c1 10.1.1.0/24 100.64.128.1 5117fa5c-029d-49e4-958f-344b56b0d4ed false N/A T1_DOWNLINK 3 true 8cbab775-5b82-4f92-a1d6-4ad76bebbb2b
ESXiホストの状態確認(ESXiのNSX-T CLI)
ESXiホストにはTier-0 GWのSRは生成されていないことが確認できます。
esxi1.local.com> get logical-routers
Logical Routers Summary
------------------------------------------------------------
VDR UUID LIF num Route num
031757a6-06d8-44bb-9e06-1ba1ac0e78c1 2 6 <-- Tier-0 GWのDR
a25aa19c-faf7-4598-9ea4-4239599e3495 2 65534 <-- Tier-1 GWのDR
NSX Edgeの状態確認(NSX EdgeのCLI)
NSX Edge上に生成されたSegmentはget logical-swithesコマンドで確認可能です。NSX Edge1にSegmentが追加されていることが確認できます。
edge1> get logical-switches
Logical Switch
UUID : 221a7d12-c45b-4589-94c9-85401b1744ca
Name : transit-bp-031757a6-06d8-44bb-9e06-1ba1ac0e78c1
VNI : 65538
device : fp-eth0
ENCAP : GENEVE
Replication : mtep
routing-domain: 031757a6-06d8-44bb-9e06-1ba1ac0e78c1
Enable Hub : False
Logical Switch
UUID : aed9a131-8547-43a4-b747-72d21de2da77
Name : Segment1
VNI : 65536
device : fp-eth0
ENCAP : GENEVE
Replication : mtep
routing-domain: 031757a6-06d8-44bb-9e06-1ba1ac0e78c1
Enable Hub : False
Logical Switch
UUID : c851f3ac-51fa-43a6-81e9-8fd6ca3ee73b
Name : Ext_Segment1
VLAN : untagged
device : fp-eth1
IFUID : 1
Enable Hub : False
Logical Switch
UUID : 1548cf7e-c69a-4813-839a-2c5794c1b533
Name : transit-rl-a25aa19c-faf7-4598-9ea4-4239599e3495
VNI : 65537
device : fp-eth0
ENCAP : GENEVE
Replication : mtep
routing-domain: 031757a6-06d8-44bb-9e06-1ba1ac0e78c1
Enable Hub : False
Logical Switch
UUID : e21d35f1-31bf-5c90-9aee-ca57f1cbb73d
VLAN : untagged
device : fp-eth0
IFUID : 0
Enable Hub : False
Segmentに加え、Tier-1 GWのDR、Tier-0 GWのSRとDRが追加されたことが確認出来ます。
edge1> get logical-routers
Logical Router
UUID VRF LR-ID Name Type Ports
736a80e3-23f6-5a2d-81d6-bbefb2786666 0 0 TUNNEL 3
e75612f1-c47a-497f-b747-692d2c1071c2 9 3076 SR-Tier-0_GW SERVICE_ROUTER_TIER0 5
a25aa19c-faf7-4598-9ea4-4239599e3495 11 3073 DR-Tier-1_GW DISTRIBUTED_ROUTER_TIER1 5
031757a6-06d8-44bb-9e06-1ba1ac0e78c1 12 3074 DR-Tier-0_GW DISTRIBUTED_ROUTER_TIER0 4
Tier-0 GWやTier-1 GWのSRのルーティングテーブルはget logical-router <UUID> routeコマンドで確認可能です。Tier-0 GWのSRのルーティングテーブルに10.1.1.0/24(Tier-1 GWが収容されているセグメント)と20.1.1.0/24(Uplinkのセグメント)が存在していることが確認できます。
edge1> get logical-router e75612f1-c47a-497f-b747-692d2c1071c2 route
Flags: t0c - Tier0-Connected, t0s - Tier0-Static, b - BGP,
t0n - Tier0-NAT, t1s - Tier1-Static, t1c - Tier1-Connected,
t1n: Tier1-NAT, t1l: Tier1-LB VIP, t1ls: Tier1-LB SNAT,
t1d: Tier1-DNS FORWARDER, t1ipsec: Tier1-IPSec, isr: Inter-SR,
> - selected route, * - FIB route
Total number of routes: 6
t1c> * 10.1.1.0/24 [3/0] via 100.64.128.1, linked-333, 22:20:37
t0c> * 20.1.1.0/24 is directly connected, uplink-325, 22:20:38
t0c> * 100.64.128.0/31 is directly connected, linked-333, 22:20:38
t0c> * 169.254.0.0/24 is directly connected, downlink-327, 22:20:38
t0c> * fcc3:7c30:4fbf:b800::/64 is directly connected, linked-333, 22:20:38
t0c> * fe80::/64 is directly connected, linked-333, 22:20:38
(補足)
NSX ManagerではSRのルーティングテーブル全体が確認できないため、NSX Edge側でSRのルーティングテーブルを確認しています。(正確に言えば、onコマンドを使用することで、NSX ManagerのCLI上で、NSX Edgeのコマンドを実行可能です。しかし、かなり遅く、ストレスを感じるので、NSX Edgeに直接ログインして、コマンドを実行しています。)
NSX ManagerでSRに対して、get logical-router <UUID> routeコマンドを実行した場合、以下のエラーが表示されます。(NSX Managerでは、SRに設定されているスタティックルートのみ確認可能です。)
nsx-manager1> get logical-router e75612f1-c47a-497f-b747-692d2c1071c2 route
There are no static routes configured on the T0 SR. To view the dynamic routes please use "get route" on the Edge VM VRF.
疎通確認
R1の10.1.1.1からR2の20.1.1.100へPingを実施します。
R1の10.1.1.1からR2の20.1.1.100へのPingが成功することが確認できます。これより、NSX Edgeを使用することで、物理ネットワークとNSX-Tの仮想ネットワーク間を接続し、通信できることが確認できます。
R1#ping 20.1.1.100 source 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.1.1.100, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
以下は物理ネットワーク側でキャプチャしたR1の10.1.1.1からR2の20.1.1.100へのICMP Echoになります。GeneveヘッダにTransit BPのVNI 65538が格納されていることが確認できます。
トレースフローの結果を見ると、ESXi1において、Tier-0 GWのDRまでパケットをルーティングしてから、Geneveでパケットをカプセル化し、NSX Edge1に転送していることが確認できます。
Asymmetric IRBの動作を確認するために、R2の20.1.1.100からR1の10.1.1.1への戻りのトラフィックの状態を確認します。
以下は物理ネットワーク側でキャプチャしたR2の20.1.1.100からR1の10.1.1.1へのICMP Echo Replyになります。GeneveヘッダにSegment 1のVNI 65536が格納されていることが確認できます。これより、NSX Edge1で、Tier-1 GWのDRまでパケットをルーティングしてから、Geneveでパケットをカプセル化し、ESXi1に転送していることが確認できます。(トレースフローでは、必ず、送信元には仮想マシンを指定する必要があるため、物理ネットワークから仮想マシンへの通信フローはシミュレートできません。)
補足として、以下はR1の10.1.1.1からR2の20.1.1.100へのTracerouteの実行結果になります。Tracerouteの結果にTransit BPのアドレスが含まれていないことが確認できます。
R1#traceroute 20.1.1.100 source 10.1.1.1
Type escape sequence to abort.
Tracing the route to 20.1.1.100
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.1.254 0 msec 0 msec 1 msec
2 100.64.128.0 0 msec 0 msec 0 msec
3 20.1.1.100 1 msec * 1 msec
また、R1からR2にPingを実施しつつ、パケットのTTLを確認したところ、Transit BPを経由する際、TTLはディクリメントされないことが分かりました。(上 : ESXi1からNSX Edge1へのパケット、下 : NSX Edge1上のTier-1 GWのSRからR2へのパケット)
コメント