自宅ラボとしてワークステーションに物理 ESXi を導入し、その上に複数台の Nested ESXi と vCenter Server で vSphere クラスタを構築しています。
NSX-T 3.2 も利用していて、これまでは物理 ESXi 上に直接 Manager/Edge をデプロイし、vCenter Server と連携させていたのですが、この度環境の見直しがあり、NSX-T を Nested ESXi 側に移行した....
... のですが、移行後からなぜか一向に Geneve Tunnel が動作しないトラブルに遭遇。

症状

症状として、構築時点では特に何も問題は見られず、ホストトランスポートノードも Edge ノードも正常稼働しているが、いざセグメントを作成し、VM を Overlay ネットワークに接続すると、VM を動かしているホストトランスポートノードのトンネル状態が「停止」となってしまう。

いろいろ切り分けてみると、

Overlay セグメントのゲートウェイに ping は疎通する
Overlay セグメントのゲートウェイより向こう側に ping は疎通しない
同じ Overlay セグメントに接続されている East-West VM 間で ping は疎通する

という状態で、ホストトランスポートノード内で動作はしているようですが、ホストトランスポートノードと Edge トランスポートノード間で正常に TEP トンネルを確立できていない様子。

とはいえ、ホストトランスポートノードから Edge トランスポートノードへの TEP インタフェースあての ping も通るし、MTU も 1600 以上を設定しているし、なんでなんだーと悩み続けること数日間。。。

[root@esxi01-ifrit:~] vmkping ++netstack=vxlan 192.168.103.9 -s 1592 -d
PING 192.168.103.9 (192.168.103.9): 1592 data bytes
1600 bytes from 192.168.103.9: icmp_seq=0 ttl=64 time=0.631 ms
1600 bytes from 192.168.103.9: icmp_seq=1 ttl=64 time=0.649 ms
1600 bytes from 192.168.103.9: icmp_seq=2 ttl=64 time=1.212 ms
 :

結果

この記事を見つけ、まさに当てはまっていました。
要は VDS 環境でホストトランスポートノードの TEP インタフェース（vmk10）が作成されているところに Edge VM をデプロイし、TEP 用のインタフェースを PortGroup にくっつけてしまうと、そのインタフェース間でトンネル確立ができなくなってしまう、ということのようです。

今回で言うと、NSX-Manager からホストトランスポートノードの設定を行う際にこちらの NSX-Geneve-DSwitch を VDS として指定し、スタティック IP を割り付けています。
また、Edge トランスポートノードの設定を行う際も、Edge スイッチ（Overlay）の作成時に同 VDS を指定しており、この構成がよろしくなかったようです。

面倒ですが、Edge 用に別の VDS を作成し、Edge VM のネットワークをそちらの VDS に切り替えることで、無事にトンネル確立ができるようになりました。
物理環境でも同じことが起きるかは不明ですが、Edge の配置には気を付けたほうがよさそうです。

追記（補足）

いまさらながら追記：

要は VDS 環境でホストトランスポートノードの TEP インタフェース（vmk10）が作成されているところに Edge VM をデプロイし、TEP 用のインタフェースを PortGroup にくっつけてしまうと、そのインタフェース間でトンネル確立ができなくなってしまう、ということのようです。

これは若干間違っていて、NSX-T における「Geneve によるトンネリングが開始されるポイント」が「パケットが VDS を抜けていくタイミング（レイヤ）」であるため、同じポートグループ間だとトンネリングされない、というオチ（製品仕様）だったようですね。

これだと構成上、上の例のようにわざわざポートグループを分けなければならいことになるため、これを回避する Inter TEP と呼ばれる構成方法があります。