概述

本文记录针对NSX-T传输节点配置文件中的主机上行链路进行测试比对，一种是基于常规双上行链路，一种是基于交换机做了Lacp或M-lag，使用Lag组成员，另外一种则是直接复用Lag组作为上行链路。

环境概述

嵌套虚拟化安装vSphere ESXi 7.0U3版本，并安装VCSA和NSX-T。

计划测试三两种场景

1. 基于物理链路的上行
2. 将上行链路组成lag，指定lag组成员做未上行
3. 将上行链路组成lag，复用聚合组作为上行

主备上行链路

按照计划，将上行链路uplink-1、uplink-2分别对应vmnic1、vmnic2，逻辑图如下所示

配置传输节点

集群配置NSX，等待完成。

耐心等待一会儿后NSX配置就好了。

创建了一个Segment01，用于后续使用。

VCSA上也同步了该Segment，类型为N-vDS。

通过命令行查看

esxcli network nic list
nsxdp-cli vswitch instance list

可以看到vdrPort的传输节点是使用的vmnic1网卡，vmnic2网卡就处于被动状态。

需要注意的是vdr-vdrPort的MAC地址在所有传输节点上都是相同的，默认为 02:50:56:56:44:52，即使环境中未使用T0、T1网关。

现模拟故障：将vmnic1 shutdown 掉，看会是什么情况。

esxcli network nic down -n vmnic1

根据实际操作可见，vdr-vdrPort的传输节点切换到了vmnic2网卡上了。

业务冗余验证①

创建2个虚拟机，并将网络指定到该segment01上。

使用长ping虚拟机IP地址，并up/down物理网卡，和预期一样，在整个过程中虚拟机并无中断网络。

NSX Manager 触发上行链中断告警，但并未对业务造成影响。

聚合上行链路

同样，按照计划，将上行链路1、上行链路2分别对应lag1-0、lag1-1在此之前需要先把VCSA上面的Lag配置好。

将Lag1配置好后，管理主机网络，并调整上行链路分别指向lag1-0、lag1-1 。

Lag1为一个聚合组，它包含了lag1-0、lag1-1成员，该聚合组对应了2个物理链路vmnic1和vmnic2。所以该聚合组内的任意一个物理链路发生up/down的时候也是不会影响到业务的，逻辑图如下图所示。

所以此时创建配置文件活动上行链路和备用上行链路输入lag1-0 和 lag1-1。

新建传输节点配置文件，选择刚才创建好的上行链路配置文件Lag1，并指定上行链路1、上行链路2

同样也将集群配置NSX，等待完成。

耐心等待一会儿后NSX配置就好了。

同样创建了一个Segment，用于后续使用。

先看下当前的网卡状态

通过命令行查看

esxcli network nic list
nsxdp-cli vswitch instance list

看到vdr-vdrPort的传输节点Uplink默认是void，无效的，因为我是嵌套的环境，没有使用交换机做LACP，正常情况下这里应该是显示lag1-0或者lag1-1。

同样，现模拟故障：将vmnic1 物理网卡shutdown 掉，看会是什么情况。

esxcli network nic down -n vmnic1

可见状态并没有变化

虽然NSX Manager 提示LAG 成员关闭，但并未对业务造成影响。

业务冗余验证②

由于是嵌套环境，不能对虚拟交换机做LACP所以这里无法记录该过程，今后有机会了再补充。

验证方式如上。

复用聚合链路

将NSX传输节点直接复用lag1组，逻辑图如下所示：

传输节点配置文件中绑定上行选择lag1组。

同样创建了一个Segment03，用于后续使用

VCSA上也同步了该Segment，类型为N-vDS。

通过命令行查看

nsxdp-cli vswitch instance list

可以看到vdrPort的传输节点是使用的lag1聚合组。

现模拟故障：将vmnic1 shutdown 掉，看会是什么情况。

esxcli network nic down -n vmnic1

根据实际操作可见，vdr-vdrPort的传输节点并无变化。

业务冗余验证③

创建2个虚拟机，并将网络指定到该Segment上。

使用长ping虚拟机IP地址，并up/down物理网卡，和预期一样，在整个过程中虚拟机并无中断网络。

NSX Manager 触发上行链中断告警，但并未对业务造成影响。

总结

此次验证了三种上行链路方式均可满足业务冗余链路需求，在部署NSX-T的时候，需结合实际情况选择最佳方案。