Skip navigation
1 2 3 Previous Next

にほんごVMware

394 posts

NSX-T による DHCP サービス機能で、MAC アドレスと IP アドレスの静的な割り当て(static-bindings)を設定してみます。

前回の投稿では、NSX Manager の Web インターフェースから設定しました。

NSX-T 2.4 で DHCP の static-bindings を使用してみる。(GUI 編)

 

今回は、REST API から同様の設定をしてみます。

 

環境の説明。

以前の投稿と同様に、下記の環境を利用しています。

自宅ラボで NSX-T 2.4 環境を構築する。まとめ

 

REST API へのアクセスには、下記の投稿のように curl + jq コマンドを利用しています。

NSX-T 2.4 を REST API で操作してみる。Part.1

この投稿でのコマンドライン中にある $CRED には「ユーザ:パスワード」、

$MGR には NSX Manager のアドレスを格納しています。

 

IP アドレスを割り当てる MAC アドレスの確認。

DHCP の static-bindings では、MAC アドレスに IP アドレスを割り当てます。

今回は、NSX-T を利用している vSphere(ESXi)上の VM がもつ vNIC に IP アドレスを設定します。

そのため、NSX Manager からでも VM / vNIC とその MAC アドレスが確認できます。

nsxt-dhcp-bind-02.png

 

REST API では、この情報を virtual-machines と vifs の情報を GET することで確認できます。

今回は、例をシンプルにするため下記を前提としています。

  • 環境内の VM 名に重複がない。
  • VM の vNIC は 1つだけ。

 

VM の名前(vm01)から MAC アドレスを確認してみます。

vm01 の情報は、下記のように取得できます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/fabric/virtual-machines | jq -r '.results[] | select(.display_name == "vm01")'

{

  "host_id": "c33ad1aa-f3b4-4a24-98da-bc32eeff1f31",

  "source": {

    "target_id": "c33ad1aa-f3b4-4a24-98da-bc32eeff1f31",

    "target_display_name": "c33ad1aa-f3b4-4a24-98da-bc32eeff1f31",

    "target_type": "HostNode",

    "is_valid": true

  },

  "external_id": "501f7750-8d29-8c53-2d5e-e5b88b06f812",

  "power_state": "VM_RUNNING",

  "local_id_on_host": "1",

  "compute_ids": [

    "moIdOnHost:1",

    "hostLocalId:1",

    "locationId:564d7a4c-fa5e-33bf-1c3e-ca12ebd75f6f",

    "instanceUuid:501f7750-8d29-8c53-2d5e-e5b88b06f812",

    "externalId:501f7750-8d29-8c53-2d5e-e5b88b06f812",

    "biosUuid:421fa276-d1a6-c34a-2dc6-ea0de1d2ace5"

  ],

  "type": "REGULAR",

  "guest_info": {

    "os_name": "Oracle Linux 7 (64-bit)",

    "computer_name": "localhost.localdomain"

  },

  "resource_type": "VirtualMachine",

  "display_name": "vm01",

  "_last_sync_time": 1563839902208

}

 

ここから、下記のように VM の ID だけを取得することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/fabric/virtual-machines | jq -r '.results[] | select(.display_name == "vm01") | .external_id'

501f7750-8d29-8c53-2d5e-e5b88b06f812

 

そして、VM ID をもとに、vNIC の MAC アドレスを確認します。

※ちなみにこの VM は、前回の投稿で DHCP による IP アドレス / ホスト名が設定がされた状態です。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/fabric/vifs | jq -r '.results[] | select(.owner_vm_id == "501f7750-8d29-8c53-2d5e-e5b88b06f812")'

{

  "external_id": "501f7750-8d29-8c53-2d5e-e5b88b06f812-4000",

  "owner_vm_id": "501f7750-8d29-8c53-2d5e-e5b88b06f812",

  "host_id": "c33ad1aa-f3b4-4a24-98da-bc32eeff1f31",

  "vm_local_id_on_host": "1",

  "device_key": "4000",

  "device_name": "Network adapter 1",

  "mac_address": "00:50:56:9f:fa:ac",

  "lport_attachment_id": "5ccf3507-1001-419e-81be-3f197bf583f4",

  "ip_address_info": [

    {

      "source": "VM_TOOLS",

      "ip_addresses": [

        "172.16.1.101",

        "fe80::1b24:4d58:f0b4:bfe8"

      ]

    }

  ],

  "resource_type": "VirtualNetworkInterface",

  "display_name": "Network adapter 1",

  "_last_sync_time": 1563839902211

}

 

MAC アドレスだけを取得することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/fabric/vifs | jq -r '.results[] | select(.owner_vm_id == "501f7750-8d29-8c53-2d5e-e5b88b06f812") | .mac_address'

00:50:56:9f:fa:ac

 

DHCP static-bindings の設定。

IP アドレスの静的割り当て(static-bindings)は、NSX-T による DHCP サーバに対して設定します。

まず、DHCP サーバの ID を確認します。

今回も、DHCP サーバ名は「dhcp-sv-001」にしています。

$ DHCP_SV_ID=`curl -ks -u $CRED -X GET https://$MGR/api/v1/dhcp/servers | jq -r '.results[] | select(.display_name=="dhcp-sv-001") | .id'`

$ echo $DHCP_SV_ID

73445136-5ab5-459a-a357-d736e534a467

 

静的割り当てのための JSON ファイル「dhcp-bind_vm01.json」を作成しておきます。

今回は、下記のパラメータのみ指定しています。

  • 表示名(display_name)
  • MAC アドレス ※必須
  • IP アドレス ※必須
  • ホスト名

JSON ファイルのパラメータは、前回の GUI での設定時と同じものです。

同じ静的割り当て設定が存在するとエラーになるので、

すでに設定がある場合は、NSX Manager などから削除しておきます。

$ cat ./dhcp-bind_vm01.json

{

  "display_name": "00:50:56:9f:fa:ac",

  "mac_address": "00:50:56:9f:fa:ac",

  "ip_address": "172.16.1.101",

  "host_name": "vm01"

}

 

作成した JSON ファイルを指定して POST メソッドを実行すると、DHCP の静的割り当てを作成できます。

curl を実行すると、作成された設定の情報が表示されます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./dhcp-bind_vm01.json https://$MGR/api/v1/dhcp/servers/$DHCP_SV_ID/static-bindings

{

  "mac_address" : "00:50:56:9f:fa:ac",

  "ip_address" : "172.16.1.101",

  "host_name" : "vm01",

  "resource_type" : "DhcpStaticBinding",

  "id" : "bb2cd277-20f3-4184-81c5-250f20f71f7a",

  "display_name" : "00:50:56:9f:fa:ac",

  "lease_time" : 86400,

  "_create_user" : "admin",

  "_create_time" : 1564095298669,

  "_last_modified_user" : "admin",

  "_last_modified_time" : 1564095298669,

  "_system_owned" : false,

  "_protection" : "NOT_PROTECTED",

  "_revision" : 0

}

 

これで、対象 MAC アドレスに IP アドレスが設定されるようになります。

 

DHCP static-bindings の削除。

一方、 静的割り当ての削除は、DELETE メソッドで実施できます。

 

静的割り当て設定の ID は、作成時にも表示されていましたが、

下記のように VM 名などから取得することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/dhcp/servers/$DHCP_SV_ID/static-bindings | jq -r '.results[] | select(.host_name == "vm01") | .id'

bb2cd277-20f3-4184-81c5-250f20f71f7a

 

そして、削除は DELETE メソッドで削除できます。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/dhcp/servers/$DHCP_SV_ID/static-bindings/bb2cd277-20f3-4184-81c5-250f20f71f7a

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/dhcp/servers/$DHCP_SV_ID/static-bindings

{

  "results" : [ ],

  "result_count" : 0

}

 

うまく工夫をすると、NSX-T で IPAM(IP アドレス管理)を実現することもできそうかなと思います。

 

以上、NSX-T での DHCP static-bindings 設定でした。

NSX-T による DHCP サービス機能では、一般的な DHCP サーバと同様に

MAC アドレスと IP アドレスの静的な割り当て(static-bindings)が可能です。

 

ドキュメントだと、下記のあたりに説明がありますが、

あまり詳しくは触れられていないため、設定の様子を残しておこうと思います。

DHCP サーバの作成

 

環境の説明。

設定は、以前に紹介した環境を利用しています。

自宅ラボで NSX-T 2.4 環境を構築する。まとめ

 

そして、設定対象の NSX-T の DHCP サーバは、下記のように作成しています。

自宅ラボで NSX-T 2.4 環境を構築する。Part.10

 

設定対象の(VM の)MAC アドレスは、vSphere Client からだけではなく、

NSX Manager からでも確認できます。

「ネットワークとセキュリティの詳細設定」→「インベントリ」→「仮想マシン」を開くと、

VM と、その vNIC の MAC アドレスを確認することができます。

nsxt-dhcp-bind-02.png

 

今回の ゲスト OS(DHCP クライアント)は、Oracle Linux 7 です。

また、この時点ではホスト名をあらわす「コンピュータ名」が「localhost.localdomain」になっています。

※サマリにある「名前」は、ゲスト OS のホスト名ではなく、仮想マシン名です。

 

DHCP サーバ への IP アドレスの「静的割り当て」設定追加。

今回は、NSX の Manager で設定します。

 

「ネットワークとセキュリティの詳細設定」→「ネットワーク」→「DHCP」→「サーバ」を開きます。

DHCP サーバ「dhcp-sv-001」を作成ずみです。

サブネットマスク、デフォルトゲートウェイ、DNS サーバといった DHCP オプションは、

DHCP サーバで設定してあるので、静的割り当てでは、IP アドレスとホスト名を設定してみます。

 

「静的割り当て」にある「追加」をクリックします。

nsxt-dhcp-bind-01.png

 

静的割り当ての設定を入力して、「追加」ボタンをクリックします。

今回は、下記だけ追加入力しています。

  • IP アドレス: DHCP サービスで割り当てる IP アドレス。
  • MAC アドレス: 先ほど確認した vm01 のもの。
  • ホスト名: VM のゲスト OS に、DHCP で割り当てるホスト名。

ちなみに、赤い「*」印のあるもの(IP アドレスと MAC アドレス)が必須項目です。

nsxt-dhcp-bind-03.png

 

静的割り当ての設定が追加されました。

GUI からの操作では、表示名が MAC アドレスになります。

nsxt-dhcp-bind-04.png

 

DHCP によるアドレス設定の確認。

DHCP クライアントとなる VM では、指定した MAC アドレスを持つ vNIC のポートグループとして、

DHCP サーバを接続してある NSX-T 論理スイッチ(今回は ls-nsxt-001)を割り当てます。

※これは NSX Manager ではなく vSphere Client で設定します。

nsxt-dhcp-bind-05.png

 

ゲスト OS では、DHCP クライアントによるネットワーク設定のタイミングで、

静的割り当て設定した IP アドレスとホスト名が反映されるはずです。

 

Oracle Linux 7 では、Red Hat Enterprise Linux 7 や CentOS 7 と同様に

ネットワーク設定で NetworkManager が利用されています。

たとえば VM コンソールなどからアクセスして、

下記のように journalctl コマンドなどで NetworkManager のログから

DHCP によるネットワーク設定の様子を確認することができます。

nsxt-dhcp-bind-07.png

 

NSX Manager のインベントリでも、

vm01 の IP アドレスとホスト名が変更されたことが確認できます。

nsxt-dhcp-bind-08.png

 

この機能を利用することで、VM デプロイ時などに

IP アドレスを制御しやすくなりそうかなと思います。

 

つづくつもり・・・

今回は、NSX-T の REST API でオブジェクトを削除していきます。

 

これまでの投稿で、NSX-T のネットワークを REST API で作成してみました。

NSX-T 2.4 を REST API で操作してみる。Part.1

 

このラボ環境の概要は下記をどうぞ。

自宅ラボで NSX-T 2.4 環境を構築する。まとめ

 

今回の削除対象も下記イメージ図の赤枠の部分です。

基本的に、これまで API で作成したオブジェクトを、作成時とは逆順に削除することになります。

NSX-T_Lab-2019_API-Part-06.png

 

削除対象オブジェクトの ID 確認。

API によるオブジェクトの削除では、オブジェクトの ID(UUID)を指定します。

そこで、おもな削除対象オブジェクトの ID を先に確認しておきます。

 

API の利用には、これまでの投稿と同様に curl / jq コマンドを利用しています。

変数「$CRED」では「ユーザ名:パスワード」、変数 $MGR には NSX Manager のアドレスを格納しています。

 

論理ルータ「t1-router-001」の UUID を取得します。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers | jq -r '.results[] | select(.display_name == "t1-router-001") | .id'

b8c1e482-a6d0-47eb-aca3-315abf738c8f

 

論理スイッチ「ls-nsxt-001」の UUID を取得します。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-switches | jq -r '.results[] | select(.display_name=="ls-nsxt-001") | .id'

639efb66-79aa-41f2-8c34-a32d4d74a8d5

 

DHCP サービスの削除。

 

DHCP サーバと論理スイッチを切断。

論理スイッチから、attachment_type が「DHCP_SERVICE」になっている論理ポートを確認します。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-ports?logical_switch_id=639efb66-79aa-41f2-8c34-a32d4d74a8d5 | jq -r '.results[] | select(.attachment.attachment_type=="DHCP_SERVICE") | .id'

f5cd00bd-143c-4506-950c-9b43112d233a

 

論理スイッチから、論理ポートを削除します。

DHCP サーバを接続している論理ポートなので、一般的な論理ポート削除とは異なり「detach=true」を指定します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-ports/f5cd00bd-143c-4506-950c-9b43112d233a?detach=true

 

DHCP サーバの削除。

DHCP サーバ「dhcp-sv-001」の ID を確認します。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/dhcp/servers | jq -r '.results[] | select(.display_name=="dhcp-sv-001") | .id'

63ad4619-3749-438e-83e9-90265604174c

 

DHCP サーバを削除します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/dhcp/servers/63ad4619-3749-438e-83e9-90265604174c

 

DHCP サーバ プロファイルの削除。

DHCP サーバ プロファイル「dhcp-prof-001」の ID を確認します。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/dhcp/server-profiles | jq -r '.results[] | select(.display_name=="dhcp-prof-001") | .id'

488512e2-d953-42ea-95c4-affe4b1dc063

 

DHCP サーバ プロファイルを削除します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/dhcp/server-profiles/488512e2-d953-42ea-95c4-affe4b1dc063

 

オーバーレイ論理スイッチの削除。

論理スイッチを削除します。論理スイッチ ID は、冒頭で確認したものを指定します。

「cascade=true」で、論理スイッチに作成されている論理ポートを一緒に削除します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-switches/639efb66-79aa-41f2-8c34-a32d4d74a8d5?cascade=true

 

Tier-1 論理ルータの削除。

Tier-1 論理ルータは、論理ルータ ポートが残っていると削除することができません。

そこで、対象の論理ルータにポートが残っていないか確認してみます。

logical_router_id を指定することで、特定の論理ルータに作成されているポートを取得することができます。

論理ルータの ID は、冒頭で確認したものを指定しています。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-router-ports?logical_router_id=b8c1e482-a6d0-47eb-aca3-315abf738c8f | jq -r '.results[] | {display_name:.display_name, resource_type:.resource_type, logical_router_port_id:.id}'

{

  "display_name": "LinkedPort_t1-router-001",

  "resource_type": "LogicalRouterLinkPortOnTIER1",

  "logical_router_port_id": "d580e2fb-4c10-41ff-ae1d-af2d9bc5659d"

}

{

  "display_name": "t1-port-001",

  "resource_type": "LogicalRouterDownLinkPort",

  "logical_router_port_id": "2b708512-2fab-4fd2-bc83-4ed01d0569e9"

}

 

上記のように、ルータ ポートが残っている場合は、それぞれ削除しておきます。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-router-ports/d580e2fb-4c10-41ff-ae1d-af2d9bc5659d

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-router-ports/2b708512-2fab-4fd2-bc83-4ed01d0569e9

 

下記のように、論理ルータ ポートがゼロになっていることを確認することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-router-ports?logical_router_id=b8c1e482-a6d0-47eb-aca3-315abf738c8f | jq -r '.result_count'

0

 

論理ルータを削除します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-routers/b8c1e482-a6d0-47eb-aca3-315abf738c8f

 

Tier-0 ルータ側の論理ルータ ポートの削除。

Tier-1 論理ルータと Tier-0 論理ルータのリンクの、Tier-0 論理ルータ側の論理ポート

(resource_type は LogicalRouterLinkPortOnTIER0)も削除しておきます。

複数の Tier-1 論理ルータ ポートを作成している場合は、Tier-1 論理ルータ側のポートを削除する前に

対向のポート ID を確認しておくとよいと思います。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-router-ports | jq -r '.results[] | select (.resource_type=="LogicalRouterLinkPortOnTIER0") | {display_name:.display_name, logical_router_id:.logical_router_id, logical_router_port_id:.id}'

{

  "display_name": "LinkedPort_t1-router-001",

  "logical_router_id": "64f51cf0-bdf8-49d2-8a51-309b97b6ab40",

  "logical_router_port_id": "722849ae-a48a-4684-99e1-d7e06dcc0a23"

}

 

論理ルータ ポートを削除します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-routers/722849ae-a48a-4684-99e1-d7e06dcc0a23

 

API の動作確認やツール開発では、何度も環境を初期化する需要があるはずなので、

このような DELETE メソッドによるオブジェクト削除の自動化ができるようにしておくと便利かなと思います。

 

以上、NSX-T の REST API でひたすらオブジェクト作成する話でした。

NSX-T を REST API で操作してみます。

今回は、ラボで構成したルーティング/SNAT設定について API で追加設定してみます。

新規作成した Tier-1 論理ルータでのアドバタイズメント設定変更、

そして、Tier-0 論理ルータへのデフォルトルートと SNAT ルールの追加をします。

 

前回はこちら。

NSX-T 2.4 を REST API で操作してみる。Part.4

 

一連の投稿の前提/想定環境などは下記をどうぞ。

NSX-T 2.4 を REST API で操作してみる。Part.1

 

この投稿は、以前の下記投稿の API 版です。

自宅ラボで NSX-T 2.4 環境を構築する。Part.11

 

論理ルータ ID の取得。

今回の設定追加では、Tier-0/Tier-1 論理ルータ ID が必要になります。

論理ルータ ID の取得例はこれまでの投稿でも紹介しましたが、

下記のように NSX Manater の Web UI での表示名(display_name)と ID を一覧することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers | jq -r '.results[] | {"LR_Name": .display_name, "ID": .id}'

{

  "LR_Name": "t0-router-01",

  "ID": "64f51cf0-bdf8-49d2-8a51-309b97b6ab40"

}

{

  "LR_Name": "t1-router-001",

  "ID": "b8c1e482-a6d0-47eb-aca3-315abf738c8f"

}

 

今回は、URI の一部としてルータ ID を指定したいので、変数に格納しておきます。

たとえば、下記のようなコマンドラインでもルータ ID を取得できます。

 

Tier-0 論理ルータの ID です。

$ T0_LR_ID=`curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers | jq -r '.results[] | select(.router_type=="TIER0" and .display_name=="t0-router-01") | .id'`

$ echo $T0_LR_ID

64f51cf0-bdf8-49d2-8a51-309b97b6ab40

 

Tier-1 論理ルータの ID です。

$ T1_LR_ID=`curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers | jq -r '.results[] | select(.router_type=="TIER1" and .display_name=="t1-router-001") | .id'`

$ echo $T1_LR_ID

b8c1e482-a6d0-47eb-aca3-315abf738c8f

 

Tier-1 論理ルータのアドバタイズメント設定変更。

API で新規作成した Tier-1 論理ルータの、ルート アドバタイズメントの有効化と、

 

念のため、現在のアドバタイズメント設定の _revision を確認しておきます。

「$T1_LR_ID」には、前の手順で取得した論理ルータ ID が含まれています。

数値がゼロ以外の場合は、JSON ファイルでもその値にあわせます。

 

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers/$T1_LR_ID/routing/advertisement | jq -r '._revision'

0

 

JSON ファイルを作成します。

今回は、アドバタイズの状態と、「すべての接続ルートをアドバタイズ」にあたる

advertise_nsx_connected_routes を有効にします。

 

t1-adv-rule.json

{

  "resource_type" : "AdvertisementConfig",

  "enabled" : true,

  "advertise_nsx_connected_routes" : true,

  "_revision" : 0

}

 

そして、アドバタイズを設定変更します。

$ curl -ks -u $CRED -X PUT -H "Content-type: application/json" -d @./t1-adv-rule.json https://$MGR/api/v1/logical-routers/$T1_LR_ID/routing/advertisement

 

Tier-0 論理ルータへのスタティック ルート追加。

NSX-T のラボ環境で必須というわけではありませんが、Tier-0 ルータへのスタティック ルートを追加します。

 

下記のような、ルーティング情報の JSON ファイルを作成します。

デフォルト ルートとして、「"network": "0.0.0.0/0"」宛のネクスト ホップとして、192.168.1.46 を指定しています。

※宛先の IP アドレスは、前提環境としてNSX-T ネットワークの外部に用意してあるゲートウェイです。

 

t0-default-route-01.json

{

  "display_name": "t0-default-route-01",

  "network": "0.0.0.0/0",

  "next_hops": [

    {

      "ip_address": "192.168.1.1",

      "administrative_distance": 1

    }

  ]

}

 

下記のようなコマンドラインで、スタティックルートを追加できます。

「$T0_LR_ID」には、前の手順で取得した論理ルータ ID が含まれています。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t0-default-route-01.json https://$MGR/api/v1/logical-routers/$T0_LR_ID/routing/static-routes

 

Tier-0 ルータへの SNAT ルール追加。

これも必須ではありませんが、Tier-0 論理ルータへの SNAT ルールを追加しておきます。

SNAT ルールは Tier-0/Tier-1 どちらでも設定できますが、

今回はこの環境のネットワーク構成にあわせて Tier-0 ルータで設定します。

 

今回は、172.16.1.0/24 からのソース アドレスを 192.168.1.46 に変換します。

ルール適用するポートは、論理ルータ ポート ID で指定します。

 

Tier-0 論理ルータ ポートは、下記のように情報取得することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-router-ports?logical_router_id=$T0_LR_ID

 

下記のような JSON ファイルを用意します。

applied_tos には、適用先の Tier-0 論理ルータ ポートの情報を指定しています。

 

t0-nat-rule-01.json

{

  "action": "SNAT",

  "match_source_network": "172.16.1.0/24",

  "translated_network": "192.168.1.46",

  "enabled": true,

  "applied_tos": [

    {

      "target_id": "ルール適用先の Tier-0 論理ルータ ポート ID",

      "target_display_name": "t0-uplink-port",

      "target_type": "LogicalRouterPort",

      "is_valid": true

    }

  ]

}

 

そして、下記のようなコマンドラインで SNAT ルールを追加します。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t0-nat-rule-01.json https://$MGR/api/v1/logical-routers/$T0_LR_ID/nat/rules

 

これで API を利用して、以前に構築した NSX-T のテナントネットワークと同様のラボ環境ができました。

ID の取得や JSON ファイルの生成なども含めて、一連の手順をスクリプトにしておくと、

複数環境の構成を自動化したりできるかなと思います。

 

以上、NSX-T 2.4 を API で操作してみる話でした。

NSX-T を REST API で操作してみます。

今回は NSX-T による DHCP サーバを作成して、オーバーレイ論理スイッチに接続します。

 

一連の投稿の前提/想定環境などは下記をどうぞ。

NSX-T 2.4 を REST API で操作してみる。Part.1

 

前回はこちら。

NSX-T 2.4 を REST API で操作してみる。Part.3

 

この投稿は、以前の下記投稿の API 版です。

自宅ラボで NSX-T 2.4 環境を構築する。Part.10

 

NSX-T の DHCP サーバ作成は、下記のような流れです。

  • サーバ プロファイルの作成
  • DHCP サーバの作成
  • DHCP サーバへの IP アドレス プールの作成
  • DHCP サーバを論理スイッチに接続

 

DHCP サーバ プロファイルの作成。

まず、サーバ プロファイルの定義を記載した JSON ファイルを作成します。

NSX Edge クラスタ ID が必要なので、前回まで内容をもとに ID を確認して、

JSON ファイルを完成させます。

 

下記のような JSON を作成します。

 

dhcp-prof-N.json

{

  "display_name": "DHCP プロファイル名",

  "edge_cluster_id": "Edge クラスタ ID"

}

 

DHCP サーバ プロファイルを作成します。

コマンドライン末尾の jq コマンドにより、作成された サーバ プロファイルの ID を取得しておきます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./dhcp-prof-N.json https://$MGR/api/v1/dhcp/server-profiles | jq -r '.id'

 

DHCP サーバの作成。

JSON ファイルを作成します。おもに赤字部分を、ネットワーク環境にあわせます。

dhcp_server_ip には、未使用の IP アドレスを指定します。

gateway_ip には、DHCP サービスを利用する論理スイッチを接続した

論理ルータ ポートの IP アドレスを指定します。

 

DNS や ドメイン名の設定といった、DHCP オプションも指定できます。

 

dhcp-sv-N.json

{

  "display_name": "DHCP サーバ名",

  "dhcp_profile_id": "DHCP サーバ プロファイルの ID",

  "ipv4_dhcp_server": {

    "dhcp_server_ip": "172.16.1.2/24",

    "dns_nameservers": [

      "192.168.1.101",

      "192.168.1.102"

    ],

    "domain_name": "go-lab.jp",

    "gateway_ip": "172.16.1.1"

  }

}

 

DHCP サーバを作成します。

ここでも、作成した DHCP サーバの ID を取得しておきます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./dhcp-sv-N.json https://$MGR/api/v1/dhcp/servers | jq -r '.id'

 

DHCP の IP プールの作成。

DHCP サーバには、IP アドレス プールを作成します。

 

JSON ファイルを作成します。赤字の部分を、ネットワークにあわせて修正します。

ここでの gateway_ip は、論理スイッチを接続している Tier-1 論理ルータ ポートの IP アドレスを指定します。

 

dhcp-pool-N.json

{

  "display_name": "DHCP IP アドレス プール名",

  "gateway_ip": "172.16.1.1",

  "allocation_ranges": [

    {

      "start": "172.16.1.10",

      "end": "172.16.1.99"

    }

  ]

}

 

IP アドレス プールを作成します。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./dhcp-pool-N.json https://$MGR/api/v1/dhcp/servers/$DHCP_SV_ID/ip-pools

 

論理スイッチへの DHCP サーバの接続。

作成した DHCP サーバを、論理スイッチに接続します。

対象の論理スイッチの ID が必要になるため、取得しておきます。

※論理スイッチ「ls-nsxt-001」は、前回に作成したものです。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-switches | jq -r '.results[] | select(.display_name == "ls-nsxt-001") | .id'

 

これまでの Tier-1/Tier-0 のリンクや、論理ルータ ポート作成とは異なり、

「"attachment_type" : "DHCP_SERVICE"」という DHCP 接続のための指定をします。

 

下記のような JSON ファイルを作成します。

 

dhcp-port-N.json

{

  "display_name": "DHCP サーバを接続する論理スイッチ ポートの名前",

  "logical_switch_id": "論理スイッチ ID",

  "attachment" : {

    "attachment_type" : "DHCP_SERVICE",

    "id" : "DHCP サーバの ID"

  },

  "admin_state": "UP"

}

 

では、DHCP サーバを論理スイッチに接続(ポートを作成)します。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./dhcp-port-N.json https://$MGR/api/v1/logical-ports

 

これで、論理スイッチに接続した VM で、DHCP サービスが利用可能になります。

ここまでの DHCP サービスの簡易的な設定確認には、

論理スイッチ に接続している VM などからの下記のようなものが考えられます。

  • 実際に VM で DHCP によるネットワーク設定がされるか?
  • VM から、DHCP サーバに指定した dhcp_server_ip への疎通確認などが可能か?

 

もうすこし続く。

NSX-T 2.4 を REST API で操作してみる。Part.5

NSX-T を REST API で操作してみます。

今回はオーバーレイ ネットワークの作成として、

論理スイッチと、ゲートウェイになる Tier-1 論理ルータ ポートを作成します。

 

一連の投稿の前提/想定環境などは下記をどうぞ。

NSX-T 2.4 を REST API で操作してみる。Part.1

 

前回はこちら。

NSX-T 2.4 を REST API で操作してみる。Part.2

 

前提とする設計について。

サンプルをシンプルにするため、オブジェクト名やアドレスの規則を決めておきます。

「テナント番号」のような感じで、オーバーレイ ネットワーク番号(N)をもうけて、

それをオブジェクト名やアドレスに使用します。

 

これ以降の例では、下記のようにオブジェクト名/アドレスを採番しています。

  • オブジェクト名: ~-N(例: ls-nsxt-001)
  • ネットワークアドレス: 172.16.N.0/24(例: 172.16.1.0/24)
  • デフォルトゲートウェイ: 172.16.N.1(例: 172.16.1.1)

 

オーバーレイ 論理スイッチの作成。

論理スイッチを作成するための JSON ファイルを作成します。

オーバーレイ論理スイッチの作成には、オーバーレイ トランスポート ゾーンの ID が必要です。

※ここで指定するオーバーレイ トランスポート ゾーン「tz-overlay-01」は、前提として作成ずみのものです。

$ curl -ks -u $CRED -X GET  https://$MGR/api/v1/transport-zones | jq -r '.results[] | select(.transport_type=="OVERLAY" and .display_name=="tz-overlay-01") | .id'

4a51e97d-f991-407c-ab73-66820a117f70

 

JSON を作成します。赤字の部分は環境にあわせた値にします。

オーバーレイ トランスポート ゾーン ID は、この環境であれば、

「4a51e97d-f991-407c-ab73-66820a117f70」になります。

 

ls-nsxt-N.json

{

  "display_name": "オーバーレイ 論理スイッチの名前",

  "description": "",

  "transport_zone_id": "オーバーレイ トランスポート ゾーン ID",

  "admin_state": "UP",

  "replication_mode": "MTEP",

  "hybrid": false,

  "_revision": 0

}

 

論理スイッチを作成します。

作成と同時に、レスポンス情報から論理スイッチ ID を取得しておきます。

$ curl -ks -u $CRED -H "Content-type: application/json" -X POST -d @./ls-nsxt-N.json https://$MGR/api/v1/logical-switches | jq -r '.id'

144f4777-a514-4351-b88e-5f6a1f6877e5

 

論理スイッチ ポートの作成。

NSX Manager の Web UI から実施する場合は、論理ルータ ポートを作成すると、論理スイッチのポートも自動作成されます。

一方、API の場合は、手動で論理スイッチ ポートを作成しておく必要があります。

 

JSON ファイルを作成します。

ここでは、先ほど作成した論理スイッチの ID が必要となります。

この環境であれば、論理スイッチ ID は「144f4777-a514-4351-b88e-5f6a1f6877e5」です。

 

ls-port-N.json

{

  "display_name": "論理スイッチ ポート名",

  "logical_switch_id": "オーバーレイ 論理スイッチ ID",

  "admin_state": "UP"

}

 

論理スイッチ ポートを作成します。

ここでも、作成した論理スイッチ ポートの ID を取得しておきます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./ls-port-N.json https://$MGR/api/v1/logical-ports | jq -r '.id'

02c7afd1-20cf-4528-8de2-360534960cd6

 

Tier-1 論理ルータ ポートの作成。

論理スイッチを Tier-1 論理ルータに接続し、ゲートウェイとなる IP アドレスを設定します。

 

ここでは、先ほど作成した、論理スイッチ ポートの ID が必要になります。

さらに、Tier-1 論理スイッチの ID が必要となるため、取得しておきます。

※ここでの論理スイッチ名「t1-router-001」は、前回の投稿で作成したものを指定します。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers | jq -r '.results[] | select(.router_type=="TIER1" and .display_name=="t1-router-001") | .id'

b8c1e482-a6d0-47eb-aca3-315abf738c8f

 

t1-port-N.json

{

  "display_name": "論理ルータ ポートの名前",

  "resource_type": "LogicalRouterDownLinkPort",

  "linked_logical_switch_port_id": {

    "target_id": "オーバーレイ 論理スイッチ ポート ID"

  },

  "logical_router_id": "Tier-1 論理ルータ ID",

  "subnets": [

    {

      "ip_addresses": [

        "ゲートウェイの IP アドレス"

      ],

      "prefix_length": 24

    }

  ]

}

 

ここまでの情報により、ここまでの実行例であれば下記のように値を指定します。

  • logical_router_id: "b8c1e482-a6d0-47eb-aca3-315abf738c8f"
  • linked_logical_switch_port_id の target_id: "02c7afd1-20cf-4528-8de2-360534960cd6"
  • logical_router_id 配下の ip_addresses: "172.16.1.1"

 

それでは、JSON ファイルをもとに Tier-1 論理ルータ ポートを作成します。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t1-port-N.json https://$MGR/api/v1/logical-router-ports

 

これで、オーバーレイ ネットワークとそのゲートウェイが作成されます。

今回作成した論理スイッチに VM を接続しネットワーク設定をすれば、

ping などで Tier-1 論理ルータ ポートに設定したアドレスへの疎通がとれるはずです。

 

ただ、今回作成した論理スイッチのネットワークには DHCP サーバがないため

VM には手動でのネットワーク設定が必要になります。

次回は、NSX-T による DHCP サーバを API で作成します。

 

つづく・・・

NSX-T 2.4 を REST API で操作してみる。Part.4

NSX-T を REST API で操作してみます。

今回は、Tier-1 論理ルータの作成です。

 

一連の投稿の前提/想定環境などは下記をどうぞ。

NSX-T 2.4 を REST API で操作してみる。Part.1

 

以前に投稿した下記の、API 操作版です。

自宅ラボで NSX-T 2.4 環境を構築する。Part.9

 

Tier-1 論理ルータの作成。

まず、Tier-1 論理ルータを作成するために、JSON ファイルを用意します。

その前提として、Tier-1 論理ルータを接続する NSX Edge クラスタ の ID を取得する必要があります。

オブジェクトの ID については、殆どのものが NSX Manager の Web UI からでも確認できます。

しかし、今回はあえて ID も API で取得してみます。

 

Edge クラスタ「edge-cluster-01」の ID を取得してみます。

なお、この Edge クラスタは、前提として作成ずみのものです。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/edge-clusters | jq -r '.results[] | select(.display_name == "edge-cluster-01") | .id'

7228228c-6d93-46be-bb7a-f5e367cf1390

 

ここで用意する JSON ファイルは、下記のような内容です。

赤字の部分は、環境固有の値となります。

※これ以降の JSON も含め、わかりやすいサンプルにするため、あえてオプション指定を少なくしています。

{

  "display_name": "Tier-1 論理ルータの名前",

  "router_type": "TIER1",

  "edge_cluster_id": "Edge クラスタ ID",

  "edge_cluster_member_indices": [

    0

  ],

  "high_availability_mode": "ACTIVE_STANDBY"

}

 

display_name と edge_cluster_id に、具体的な値を指定した JSON を作成しました。

 

t1-router-001.json

{

  "display_name": "t1-router-001",

  "router_type": "TIER1",

  "edge_cluster_id": "7228228c-6d93-46be-bb7a-f5e367cf1390",

  "edge_cluster_member_indices": [

    0

  ],

  "high_availability_mode": "ACTIVE_STANDBY"

}

 

それでは、論理ルータを作成します。

作成と同時に、レスポンス情報から作成された論理ルータの ID を取得しておきます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t1-router-001.json https://$MGR/api/v1/logical-routers | jq -r '.id'

b8c1e482-a6d0-47eb-aca3-315abf738c8f

 

作成ずみの論理ルータの ID は、下記のように取得することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers | jq -r '.results[] | select(.display_name == "t1-router-001") | .id'

b8c1e482-a6d0-47eb-aca3-315abf738c8f

 

Tier-0 論理ルータとの接続。

Tier-1 論理ルータを Tier-0 論理ルータを接続(リンク)させるために、

それぞれの論理ルータにポートを作成する必要があります。

 

Tier-0 論理ルータ側のルータ ポート作成。

まず、Tier-0 論理ルータ側でポートを作成します。

このとき、Tier-0 論理ルータのルータ ID が必要になります。

ここで指定する Tier-0 論理ルータ「t0-router-01」は、前提として作成ずみのものです。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers | jq -r '.results[] | select(.display_name == "t0-router-01") | .id'

64f51cf0-bdf8-49d2-8a51-309b97b6ab40

 

オーバーレイ論理スイッチの論理ルータ ポート作成とは異なり、

resource_type には「LogicalRouterLinkPortOnTIER0」を指定します。

 

t1-router-001_t0-link-port.json

{

  "display_name": "作成する Tier-0 論理ルータ側のポート名",

  "resource_type": "LogicalRouterLinkPortOnTIER0",

  "logical_router_id": "Tier-0 論理ルータの ID"

}

 

それでは、ポートを作成します。

作成と同時に、レスポンス情報から作成されたポートの ID を取得しておきます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t1-router-001_t0-link-port.json  https://$MGR/api/v1/logical-router-ports | jq -r '.id'

 

Tier-1 論理ルータ側のルータポート作成。

Tier-0 論理ルータ側のポートを作成した後に、Tier-1 論理ルータ側でポートを作成します。

こちらでは、下記のような指定をします。

  • logical_router_id には、この投稿の最初に作成した Tier-1 論理ルータのルータ ID を指定します。
  • resource_type では「LogicalRouterLinkPortOnTIER1」を指定します。
  • linked_logical_router_port_id では、ひとつ前の手順で作成した Tier-0 論理ルータのポート ID を指定します。

 

t1-router-001_t1-link-port.json

{

  "display_name": "作成する Tier-1 論理ルータ側のポート名",

  "resource_type": "LogicalRouterLinkPortOnTIER1",

  "logical_router_id": "Tier-1 論理ルータの ID",

  "edge_cluster_member_index": [

    0

  ],

  "linked_logical_router_port_id": {

    "target_id": "Tier-0 論理ルータ ポートの ID",

    "target_type": "LogicalRouterLinkPortOnTIER0",

    "is_valid": true

  }

}

 

作成した JSON ファイルで、論理ルータ ポートを作成します。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t1-router-001_t1-link-port.json https://$MGR/api/v1/logical-router-ports

 

これで、Tier-1 論理ルータが作成され、Tier-0 論理ルータと接続された状態になりました。

NSX Manager の Web UI でも、Tier-0 ルータが接続されたことが確認できます。

nsxt-api-p02-01.png

 

つづく。

NSX-T 2.4 を REST API で操作してみる。Part.3

NSX-T の特徴のひとつである、REST API での操作を試してみます。

REST API を利用する場合の主な目的は、作業の自動化だと思います。

そこで、ここではいわゆる「テナント」を複数作成するようなケースを想定して、

Tier-1 論理ルータの作成から、オーバーレイ ネットワークの作成を REST API で実行してみます。

 

今回の一連の投稿です。

NSX-T 2.4 を REST API で操作してみる。Part.1 (この投稿自身)

NSX-T 2.4 を REST API で操作してみる。Part.2

NSX-T 2.4 を REST API で操作してみる。Part.3

NSX-T 2.4 を REST API で操作してみる。Part.4

NSX-T 2.4 を REST API で操作してみる。Part.5

 

それでは、まず利用する環境/ツールについて説明します。

 

利用する環境について。

以前に投稿した、自宅 NSX-T ラボ環境を利用しています。

自宅ラボで NSX-T 2.4 環境を構築する。まとめ

 

上記 URL にある「Part.9」から先の部分(Tier-1 ルータの作成から)を、REST API で構築してみます。

イメージ図の、赤枠の部分です。

NSX-T_Lab-2019_API-Part-01.png

 

NSX-T Data Center REST API について。

NSX-T Data Center REST API は、下記のサイトにドキュメントが公開されています。

NSX-T Data Center REST API - VMware API Explorer - VMware {code}

 

NSX Manager が展開されている環境であれば、NSX Manager ログイン後の

「?」→「API ドキュメント」でも確認できます。

nsxt-api-p01-01.png

 

API Guide のドキュメントが参照できます。

nsxt-api-p01-02.png

 

利用するツールについて。

今回は、Linux OS を実行元としています。

root@photon-machine [ ~ ]# cat /etc/photon-release

VMware Photon OS 3.0

PHOTON_BUILD_NUMBER=5e45dc9

 

REST API にアクセスする場合に一般的に利用される下記のコマンドライン ツールを利用しています。

  • curl
  • jq

 

curl と jq は、yum / tdnf などでインストールしておきます。

VMware Photon OS 3.0 を利用する場合は、デフォルトでは jq がインストールされていないので、

下記のように tdnf コマンドでインストールしておきます。

# tdnf install -y jq

 

REST API へのアクセス方法について。

REST API へのアクセスには curl コマンドを使用しますが、OS root ユーザである必要はなく一般ユーザで実行可能です。

そこで、bash のプロンプトは「$」とだけ表記しています。

今回は、コマンドライン例の見ための都合により、ユーザ:パスワード を変数に格納しています。

※ちなみに例示のパスワードは VMware のデモ/ハンズオンなどで一般的に利用されるものです。

$ CRED='admin:VMware1!VMware1!'

 

また、NSX Manager のアドレスは、変数「MGR」に格納して、

コマンドラインでも「$MGR」と表記しています。

※これは、うちの自宅 NSX Manager (ローカル)のアドレスです。

$ MGR=lab-nsxt-mgr-01.go-lab.jp

 

curl コマンドによるアクセス確認として、NSX-T のバージョンを確認してみます。

NSX-T の REST API では、JSON 形式のデータを扱います。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/node/version

{

  "node_version": "2.4.1.0.0.13716579",

  "product_version": "2.4.1.0.0.13716575"

}

 

必要に応じて、jq コマンドで JSON をフィルタ/成形します。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/node/version | jq -r '.product_version'

2.4.1.0.0.13716575

 

それでは、NSX-T 環境を API で操作していきます。

つづく!

NSX-T 2.4 を REST API で操作してみる。Part.2

PowerCLI 11.3 がリリースされて、

NSX-T の論理スイッチの情報取得が簡単になりました。

New Release: VMware PowerCLI 11.3.0 - VMware PowerCLI Blog - VMware Blogs

 

PowerCLI 11.3 では、Get-VirtualNetwork コマンドレットで

NSX-T 論理スイッチの情報が取得できるようになりました。

PowerCLI> gcm Get-VirtualNetwork | select Name,Version,Source | Format-List

 

Name    : Get-VirtualNetwork

Version : 11.3.0.13964826

Source  : VMware.VimAutomation.Core

 

 

NSX-T 論理スイッチの情報取得。

NSX-T 論理スイッチは、NetworkType が「Opaque」です。

ちなみに、標準仮想スイッチ(vSS)の標準ポートグループは「Network」、

下記にはありませんが分散仮想スイッチ(vDS)の分散ポートグループは「Distributed」になります。

※Connect-VIServer で vCenter に接続ずみです。

PowerCLI> Get-VirtualNetwork

 

Name                                               NetworkType

----                                               -----------

pg-nsxt-edge-vtep                                  Network

pg-nsxt-edge-vlan                                  Network

VM Network                                         Network

ls-nsxt-002                                        Opaque

ls-nsxt-001                                        Opaque

 

 

ここでの ls-nsxt-001、ls-nsxt-002 は vSphere Client から見ると通常のポートグループとは異なるアイコンで、

NSX-T の論理スイッチだとわかります。

 

ちなみに、これらの NSX-T 論理スイッチは、事前に NSX Manager で作成しておいたものです。

自宅ラボで NSX-T 2.4 環境を構築する。Part.9

powercli-nsxt-ls-02.png

 

vNIC へのNSX-T 論理スイッチ割り当て。

VM の vNIC に論理スイッチを割り当てるには、「-NetworkName」で論理スイッチ名を指定します。

vSphere の vDS による分散ポートグループでは「-Portgroup」などで指定していましたが、

NSX-T の N-VDS による論理スイッチでは、vSS の標準ポートグループの場合と同じ

「-NetworkName」オプション指定で設定することになります。

 

標準ポートグループ「VM Network」が割り当てられている

VM「vm01」の vNIC「Network adapter 1」があります。

PowerCLI> Get-VM vm01 | Get-NetworkAdapter -Name "Network adapter 1" | select Parent,Name,NetworkName | Format-List

 

Parent      : vm01

Name        : Network adapter 1

NetworkName : VM Network

 

 

vNIC のポートグループの割り当てを、NSX-T 論理スイッチ「ls-nsxt-001」に変更してみます。

PowerCLI> Get-VM vm01 | Get-NetworkAdapter -Name "Network adapter 1" | Set-NetworkAdapter -NetworkName "ls-nsxt-001" -Confirm:$false

 

Name                 Type       NetworkName  MacAddress         WakeOnLan

                                                                  Enabled

----                 ----       -----------  ----------         ---------

Network adapter 1    Vmxnet3    ls-nsxt-001  00:50:56:9f:fa:ac       True

 

 

vSphere Client からみても、vNIC の「ネットワーク」設定が

論理スイッチに変更されたことが確認できます。

powercli-nsxt-ls-01.png

 

以上、NSX-T 論理スイッチを PowerCLI で変更してみる話でした。

自宅で手軽に NSX-T の機能を確認できるように、

ネステッド ESXi 環境を利用したラボを構築してみます。

一連の投稿のまとめです。

NSX-T_Lab-2019_setup_summary.png

 

はじめに、今回のラボ構成の方針と、全体のイメージを説明します。

自宅ラボで NSX-T 2.4 環境を構築する。Part.1

 

ネスト環境の外側の vCenter / ESXi での設定について説明します。

VM 配置と、リソースの割り当てについて、ついでに DNS などの関連サーバの準備についても説明します。

自宅ラボで NSX-T 2.4 環境を構築する。Part.2

 

ひきつづき、ネスト環境の外側の vCenter ESXi での設定のうち

物理~ネスト外側でのネットワークの準備について説明します。

ここでのポイントは、物理 ESXi での仮想スイッチとポートグループの設定です。

自宅ラボで NSX-T 2.4 環境を構築する。Part.3

 

ここから、ネスト環境の内側の vCenter / ESXi の準備です。

おもに、仮想スイッチとポートグループの設定について説明します。

自宅ラボで NSX-T 2.4 環境を構築する。Part.4

 

NSX-T の「ホスト トランスポート ノード」の設定をします。

ESXi に、NSX-T 独自の仮想スイッチである N-VDS を構成します。

ここで構成するのは 2種類ある N-VDS のうち「オーバーレイ N-VDS」の方です。

自宅ラボで NSX-T 2.4 環境を構築する。Part.5

 

NSX Edge の VM を展開します。

「Edge トランスポート ノード」とよばれるもので、

Edge にもオーバーレイ N-VDS を構成します。

自宅ラボで NSX-T 2.4 環境を構築する。Part.6

 

NSX Edge を「VLAN トランスポート ゾーン」に追加して、VLAN N-VDS を構成します。

NSX Edge は、オーバーレイ トランスポート ゾーンと、VLAN トランスポート ゾーンの

両方に追加されることになります。

自宅ラボで NSX-T 2.4 環境を構築する。Part.7

 

NSX Edge による Tier-0 論理ルータを作成して、

オーバーレイ ネットワークへの入り口になるアップリンク ポートを作成します。

自宅ラボで NSX-T 2.4 環境を構築する。Part.8

 

オーバーレイ ネットワークで分散ルーティングする、Tier-1 論理ルータを作成します。

そして、オーバーレイ ネットワーク(の論理スイッチ)を作成して、

Tier-1 論理ルータにゲートウェイになるポートを作成します。

自宅ラボで NSX-T 2.4 環境を構築する。Part.9

 

NSX-T 環境内の VM むけに、DHCP サーバを用意します。

自宅ラボで NSX-T 2.4 環境を構築する。Part.10

 

自宅での NSX-T 環境への経路のとりかたについて紹介します。

自宅ラボで NSX-T 2.4 環境を構築する。Part.11

 

以上、NSX-T 自宅ラボ構築のまとめでした。

NSX-T の、ネステッド ESXi 環境を利用したラボを構築してみました。

今回は、これまでの補足としてラボへの経路の工夫ついて説明します。

 

前回はこちら。

自宅ラボで NSX-T 2.4 環境を構築する。Part.10

 

一連の投稿のまとめはこちら。

自宅ラボで NSX-T 2.4 環境を構築する。まとめ

 

作成した自宅ラボのネットワーク構成の概要について。

作成したラボの、ネットワーク構成の概要です。

NSX-T_Lab-2019_setup_Part11-1.png

 

ルーティング設定について。

今回のラボは、NSX-T 環境に入ってからの動作確認をしたかったので、

NSX-T への入り口の Tier-0 ルータのアップリンク(一般的には BGP などが利用されるはずの部分)ではルーティング プロトコルは特に使用せず

外部のネットワークにある「ラボを利用する端末」をスタティックルートで NSX-T のオーバーレイネットワークにむけてしまいます。

 

オーバーレイ ネットワークとの経路では、下記のような設定をしています。

  • オーバーレイ ネットワークの VM は、ゲスト OS のデフォルトゲートウェイを Tier-1 ルータ ポートにする。
  • Tier-1 ルータでは、接続したオーバーレイ 論理スイッチのネットワークを Tier-0 ルータにアドバタイズ。
  • Tier-0 ルータは、デフォルトルート(0.0.0.0/0)を、VLAN ネットワークのゲートウェイへ。
  • 「ラボを利用する端末」のスタティックルートは、オーバーレイ ネットワーク(172.16.0.0/16)を Tier-0 ルータのアップリンクへ。

NSX-T_Lab-2019_setup_Part11-2.png

 

Tier-0 ルータでのスタティックルート の設定は、

Tier-0 ルータを選択して「ルーティング」→「スタティック ルート」を開いて、

「追加」から実施します。

nsx-t-11-02.png

 

Tier-1 ルータでのアドバタイズの設定は、

Tier-1 ルータの「ルーティング」→「ルートのアドバタイズ」から設定します。

ここでは、「すべての接続ルートをアドバタイズ」を有効にします。

nsx-t-11-01.png

 

オーバーレイ ネットワーク VM むけの SNAT。

オーバーレイ ネットワークの VM が、外部ネットワークにアクセスしやすいように、Tier-0 ルータの SNAT を利用しています。

NSX-T_Lab-2019_setup_Part11-3.png

 

この SNAT は、Tier-0 ルータで、オーバーレイ ネットワークのレンジの IP アドレスに対して設定しています。

適用対象は、Tier-0 ルータのアップリンクです。

nsx-t-11-03.png

 

以上、NSX-T のラボ環境を作成する話でした。

NSX-T のネステッド ESXi 環境を利用したラボを構築してみます。

今回は、論理スイッチに DHCP サーバを追加します。

 

前回はこちら。

自宅ラボで NSX-T 2.4 環境を構築する。Part.9

 

まとめはこちら。

自宅ラボで NSX-T 2.4 環境を構築する。まとめ

 

NSX-T での  DHCP サービスは、

DHCP プロファイル/DHCP サーバを作成してから、論理スイッチに接続して使用します。

NSX-T_Lab-2019_setup_Part10.png

 

論理スイッチに接続した VM のゲスト OS では、手動でネットワーク設定をすることもできますが、

ラボの利用をシンプルにするため、NSX-T の DHCP サービスを利用します。

 

DHCP サーバ プロファイルの作成。

まず、DHCP サーバ プロファイルを作成します。

NSX Manager の「ネットワークとセキュリティの詳細設定」→

「ネットワーク」→「DHCP」→「サーバプロファイル」の「追加」をクリックします。

nsxt-dhcp-01.png

 

サーバ プロファイルは、名前、Edge クラスタ、メンバー(Edge トランスポート ノード)を指定して、「追加」します。

nsxt-dhcp-02.png

 

サーバ プロファイルが作成されました。

nsxt-dhcp-03.png

 

DHCP サーバの作成。

DHCP サーバは、となりの「サーバ」タブにある「追加」から実施します。

DHCP サーバには、名前、IP アドレスとサブネットマスク、DHCP サーバ プロファイルを指定します。

それ以外の DHCP オプションは、ここ(DHCP サーバ)もしくは、後で IP アドレス プールで指定します。

 

ここでの DHCP サーバの IP アドレスは、未使用のアドレス(ルータ ポートや IP プールで使用しないもの)を指定します。

このアドレスは実際にサーバに付与されるので、DHCP サービスがうまく利用できない場合は、

同じ論理スイッチに接続した VM からサーバへの疎通確認ができるか確認してみるとよいと思います。

nsxt-dhcp-04.png

 

IP アドレス プールの追加。

作成した DHCP サーバに、IP アドレス プールを追加します。

nsxt-dhcp-06.png

 

IP アドレスプールは、名前、IP アドレス 範囲、デフォルト ゲートウェイを指定して、「追加」します。

IPアドレスの範囲は開始アドレスと終了アドレスをハイフン(-)でつなげて入力します。

IP アドレス プールでは、DHCP オプション(ドメイン名、DNS サーバのアドレスなど)も指定することができます。

nsxt-dhcp-07.png

 

DHCP サーバの論理スイッチへの接続。

DHCP サーバで、「論理スイッチに接続」を実施します。

nsxt-dhcp-08.png

 

作成ずみの論理スイッチを選択して、「接続」します。

これで、論理スイッチに接続した VM に DHCP サービスが提供されるようになります。

nsxt-dhcp-09.png

 

VM での DHCP 利用について。

VM 側では、ゲスト OS のネットワーク設定で DHCP 設定にしておくと、

DHCP サービスによって IP アドレスなどが設定されるようになります。

 

Linux ゲストであれば、ログファイルなどから DHCP によるネットワーク設定の様子がわかります。

nsxt-dhcp-11.png

 

あと1回つづくつもり。

自宅ラボで NSX-T 2.4 環境を構築する。Part.11

NSX-T のネステッド ESXi 環境を利用したラボを構築してみます。

今回は、オーバーレイ ネットワーク同士の分散ルーティングをする、Tier-1 論理ルータを追加します。

 

前回はこちら。

自宅ラボで NSX-T 2.4 環境を構築する。Part.8

 

まとめはこちら。

自宅ラボで NSX-T 2.4 環境を構築する。まとめ

 

下記の構成イメージの、赤枠の部分が、今回の対象です。

NSX-T_Lab-2019_setup_Part09.png

 

同じ論理スイッチに接続した VM は、論理スイッチの機能により L2 通信が可能となり、

Tier-1 ルータ ポートを作成することで、L3 通信が可能になります。

※ただし VM のゲスト OS でのルーティング(デフォルトゲートウェイ/スタティックルート)設定は必要です。

 

T1 ルータの作成。

Tier-1 の論理ルータは、NSX Manager の

「ネットワークとセキュリティの詳細設定」→「ファブリック」→「ルーター」→「ルーター」画面の、

「追加」→「Tier-1 ルーター」から実施します。

nsxt-t1-01.png

 

Tier-1 ルータの、名前、接続する Tier-0 ルータ、Edge クラスタ、Edge クラスタ メンバー

(Edge トランスポート ノード)を指定して、「追加」します。

nsxt-t1-02.png

 

オーバーレイ 論理スイッチの作成。

Tier-1 ルータのダウンリンク ポートに接続する、オーバーレイ 論理スイッチを作成します。

オーバーレイ 論理スイッチも、VLAN 論理スイッチと同様に NSX Manager の

「ネットワークとセキュリティの詳細設定」→「ファブリック」→「スイッチング」→「スイッチ」画面の、「追加」から実施します。

nsxt-ls-01.png

 

作成する論理スイッチの、名前と、オーバーレイ トランスポート ノードを指定して、「追加」します。

nsxt-ls-02.png

 

トラフィック タイプが「オーバーレイ」の論理スイッチが作成されました。

nsxt-ls-03.png

 

オーバーレイ 論理スイッチは、実はオーバーレイ トランスポート ゾーンを作成した時点で、L2 スイッチとして作成/利用可能でした。

ただし、オーバーレイ 論理スイッチのネットワーク同士でルーティングするには、

ゲートウェイとして Tier-1 ルータ ポートを作成することになります。

 

T1 ルータ ポートの作成。

「ネットワークとセキュリティの詳細設定」→「ファブリック」→「ルーター」→「ルーター」画面で、

作成された Tier-1 ルータの「設定」→「ルーター ポート」を開き、「追加」をクリックします。

nsxt-t1-11.png

 

ルータ ポートの、名前と、接続する論理スイッチを指定します。

タイプは「ダウンリンク」にしておきます。

論理スイッチ ポートの設定は、デフォルトのままで大丈夫です。

論理ルータでポートを作成すると、対応する論理スイッチ ポートもセットで作成されます。

nsxt-t1-12.png

 

画面をスクロールし、サブネットを「追加」します。

論理スイッチのゲートウェイとなる、IP アドレスとプリフィックス長

(サブネットマスクのビット数)を入力して、論理スイッチを「追加」します。

nsxt-t1-13.png

 

論理ルータのダウンリンク ポートが、作成されました。

nsxt-t1-14.png

 

このように、T1 ルータにポートを作成したオーバーレイ 論理スイッチ同士では、

分散ルーティングができるようになります。

※ゲスト OS でのデフォルト ゲートウェイは、T1 ルータ ポートの IP アドレスに設定します。

 

論理スイッチの VM への割り当て。

NSX-T の論理スイッチは ESXi でも利用できるようになっており、

vSphere Client から通常のポートグループと同様に選択/vNIC への割り当てができるようになっています。

nsxt-ls-05.png

 

あと少し続く。

自宅ラボで NSX-T 2.4 環境を構築する。Part.10

NSX-T のネステッド ESXi 環境を利用したラボを構築してみます。

今回は、NSX-T 外部/オーバーレイ ネットワークの境界になる、Tier-0 論理ルータを追加します。

 

前回はこちら。

自宅ラボで NSX-T 2.4 環境を構築する。Part.7

 

まとめはこちら。

自宅ラボで NSX-T 2.4 環境を構築する。まとめ

 

下記の構成イメージの、赤枠の部分が、今回の対象です。

NSX-T_Lab-2019_setup_Part08.png

 

VLAN 論理スイッチの作成。

VLAN 論理スイッチは、NSX Manager の「ネットワークとセキュリティの詳細設定」→

「ファブリック」→「スイッチング」→「スイッチ」画面の、「追加」から実施します。

nsxt-edge-uplink-01.png

 

論理スイッチの、名前、トランスポート ゾーン、VLAN ID を指定します。

ここのトランスポート ゾーンで、VLAN トランスポート ゾーンを選択する必要があります。

ここで指定する VLAN ID は、NSX Edge の管理ネットワークではなく、ルーターとして利用するアップリンクの VLAN です。

ただし、管理ネットワークと同じ VLAN ID も指定可能です。

※まちがえてオーバーレイ トランスポート ゾーンを選択した場合、論理スイッチは削除して再作成します。

nsxt-edge-uplink-02.png

 

VLAN 論理スイッチが作成されました。

「トラフィック タイプ」で VLAN ID が正しいことを確認しておきます。

nsxt-edge-uplink-03.png

 

Tier-0 ルータの作成。

Tier-0 の論理ルータは、NSX Manager の

「ネットワークとセキュリティの詳細設定」→「ファブリック」→「ルーター」→「ルーター」画面の、

「追加」→「Tier-0 ルーター」から実施します。

nsxt-edge-uplink-12.png

 

ルーターの名前と、Edge クラスタを指定します。

ラボでは Tier-0 ルーターでの SNAT も利用したいため、

高可用性モードは「アクティブ / スタンバイ」を指定しています。

 

「追加」でルーターが作成されます。

これは VM を展開するわけではなく、NSX Edge の内部にルータを作成します。

nsxt-edge-uplink-13.png

 

Tier-0 ルータのアップリンク ポートの作成。

作成された Tier-0 ルータの「設定」→「ルーター ポート」を開き、「追加」をクリックします。

nsxt-edge-uplink-15.png

 

ルーター ポートの、名前、トランスポート ノード、論理スイッチを指定します。

論理スイッチでは、さきほど作成した VLAN 論理スイッチを指定します。

タイプは「アップリンク」、オーバーレイ ネットワークの経路ではないので MTU は 1500 にしておきます。

nsxt-edge-uplink-17.png

 

IP アドレスと、プレフィックス長(サブネットマスクのビット数)を入力して、「追加」します。

nsxt-edge-uplink-18.png

 

同一ネットワーク セグメントからであれば、

作成したポートの IP アドレスへ ping などで疎通がとれるようになるはずです。

nsxt-edge-uplink-19.png

 

もうすこし続く・・・

自宅ラボで NSX-T 2.4 環境を構築する。Part.9

NSX-T のネステッド ESXi 環境を利用したラボを構築してみます。

今回は、前回の投稿で展開した NSX Edge に、VLAN のトランスポート ゾーン/N-VDS を追加します。

 

前回はこちら。

自宅ラボで NSX-T 2.4 環境を構築する。Part.6

 

まとめはこちら。

自宅ラボで NSX-T 2.4 環境を構築する。まとめ

 

VLAN トランスポート ゾーンの作成。

トランスポート ゾーンは、NSX Manager の

「システム」→「ファブリック」→「トランスポート ゾーン」画面の、「追加」から実施します。

※スクリーンショットでは、オーバーレイ トランスポート ゾーンだけ作成されています。

nsxt-vlan-tz-01.png

 

作成するトランスポート ゾーンと N-VDS の名前を入力します。

トラフィック タイプで「VLAN」を選択してから、「追加」します。

nsxt-vlan-tz-02.png

 

VLAN トランスポート ゾーンが作成されました。

nsxt-vlan-tz-03.png

 

VLAN トランスポート ゾーンへの NSX Edge 追加。

「システム」→「ファブリック」→「ノード」→「Edge トランスポート ノード」画面で Edge を選択し、

「概要」→「編集」から開始します。

nsxt-vlan-tz-13.png

 

作成した VLAN トランスポート ゾーンを、「選択済み」に移動して「保存」します。

nsxt-vlan-tz-15.png

 

「N-VDS の追加」で、N-VDS を選択します。

オーバーレイ トランスポート ゾーンと同様に、アップリンク プロファイルを新規作成します。

nsxt-vlan-tz-16.png

 

作成するプロファイルの名前を入力します。

nsxt-vlan-tz-17.png

 

アップリンクの名前は、Edge VM ではポートグループでのチーミングを設定するため、

オーバーレイ トランスポート ゾーンの時と同様に「アクティブ アップリンク」だけ入力し、

「スタンバイ アップリンク」は空欄にしています。

 

トランスポート VLAN、MTU は、VLAN トランスポート ゾーンの場合はデフォルト設定にしています。

※TEP の構成がなく、MTU は 1500 でも疎通が可能です。(ただ、実はデフォルトが 1600)

nsxt-vlan-tz-18.png

 

「Edge トランスポート ノードの編集」画面に戻ります。

もともと作成されていたオーバーレイ N-VDS「nvds-overlay-01」には、

アップリンクに「pg-nsxt-edge-vtep」というポートグループを割り当てています。

nsxt-vlan-uplink-06.png

 

追加作成する VLAN N-VDS「nvds-vlan-01」には、

アップリンクに「pg-nsxt-edge-vlan」というポートグループを割り当て、「保存」します。

nsxt-vlan-uplink-07.png

 

トランスポート ゾーンへ追加後の NSX Edge。

NSX Edge が、オーバーレイ トランスポート ゾーンだけでなく

VLAN トランスポート ゾーンにも追加されたことがわかります。

nsxt-vlan-tz-23.png

 

vSphere Client から NSX Edge VM の vNIC を確認すると、NSX Manager の設定によって、

オーバーレイ N-VDS で使用される vNIC(ネットワーク アダプタ 2)には、pg-nsxt-edge-vtep ポートグループ、

VLAN N-VDS で使用される vNIC(ネットワーク アダプタ 3)には、pg-nsxt-edge-vlan ポートグループが割り当てられました。

nsxt-edge-20.png

 

ちなみに、Edge VM で VLAN ID をうけるため、

物理 ESXi だけでなく、ネステッド ESXi 側の仮想スイッチでも対象 VLAN を通過させる必要があります。

今回は標準ポートグループを使用しており、

両方のポートグループで VLAN ID 4095 を設定しています。

nsxt-vlan-uplink-08.png

 

あわせて、ポートグループではセキュリティ設定を「承諾」にしています。

nsxt-vlan-uplink-09.png

 

まだまだ続く。

自宅ラボで NSX-T 2.4 環境を構築する。Part.8