在VMware NSX-T
网络构建中,有两个地方需要配置VLAN
, 分别是:
逻辑交换机/分段
中的VLAN
, 如图:Uplink Profile
中的传输VLAN(Transport VLAN
), 如图:
逻辑交换机
的VLAN
决定了逻辑交换机上的端口类型,表示access
或者trunk
类型的端口。逻辑交换机
又分为基于VLAN
类型和Overlay
类型两种。
对于VLAN
类型的逻辑交换机
, 如果配置的VLAN
为单一VLAN
时,表示端口为access
类型。这时逻辑交换机
与所连接的虚拟接口间的数据是不携带VLAN tag
的,但发送到ESXi主机外部的物理网络的报文会携带有所配置的VLAN tag
。VLAN 0
则比较特殊,在NSX-T
以及vSphere
体系里都表示不携带VLAN tag
。而如果配置多个VLAN
后,表示端口为trunk
类型。这种情况下,发送到逻辑交换机
的报文则必须携带有配置范围内的VLAN tag
。而该tag
也会透传到外部物理网络。因而使用VLAN
类型的逻辑交换机需要底层物理网络做相应的配置允许相应的VLAN
通行。
而对于Overlay
类型的逻辑交换机
, 可以不配置VLAN
, 这种情况下,逻辑交换机
的端口为access
类型。当设置VLAN
时,即使设置的是单一VLAN
,也会自动修改为trunk
类型。这种情况下,逻辑交换机
与虚拟接口间的报文则必须携带配置范围内的VLAN tag
。
整体逻辑可以梳理为:
上边说到,在Overlay
类型的逻辑交换机
的报文发送到ESXi
外部的物理网络的报文与逻辑交换机VLAN
选项无关。而影响这underlay
报文VLAN tag
的是上文提到的另一个VLAN
调置: 传输VLAN(Transport VLAN)
。该选项只能设置单一VLAN
。当Uplink Profile
的Transport VLAN
未设置时,默认值为0
, 这种情况下,underlay
报文不携带VLAN tag
。如果设置为其他的VLAN tag
, 则underlay
报文则会携带该VLAN tag
。
如果NSX
虚拟交换机的承载为vCenter
的VDS
, 则在vCenter
的Network
标签中看到逻辑交换机/分段
的VLAN
信息,如图:
需要注意的,这里显示的access
类型的逻辑交换机/分段
的VLAN
信息是正确的,而trunk
类型的逻辑交换机/分段
的信息则没有正确显示。
下面对上述情况进行实验。
我的实验环境为嵌套部署的ESXi
主机,ESXi
主机的网络接到底层ESXi
上用来模拟物理网络的VSS
上,并将混杂模式
,MAC地址更改
, 伪传输
三个选项都设置为接受
, VLAN
设置为4095
, 表示允许所有VLAN
。在底层ESXi
环境上再启动一台CentOS
虚拟机接入该VSS
。由于VSS
的混杂模式
开启,因而CentOS
虚拟机上可以抓到所有流出嵌套ESXi
主机而到达VSS
的流量,拓扑如图:
在NSX-T
环境中创建VLAN
类型逻辑交换机
, 并将VLAN
设置为200
.在两台ESXi
主机上各创建一台虚拟机, IP
分别配置为6.6.6.11/24
和6.6.6.12/24
, 并将虚拟机网卡接入创建的逻辑交换机
.从6.6.6.11
通过ping
访问6.6.6.12
.
从观察机CentOS
上抓包可以看到物理网络报文的VLAN tag
为200
:
1 | 10:49:04.187978 00:50:56:82:70:f0 > 00:50:56:82:a6:ae, ethertype 802.1Q (0x8100), length 102: vlan 200, p 0, ethertype IPv4, 6.6.6.11 > 6.6.6.12: ICMP echo request, id 4244, seq 7, length 64 |
将逻辑交换机VLAN
修改为0
之后再次测试, 从抓包数据可以看到物理网络报文不再携带VLAN tag
:
1 | 10:52:09.802257 00:50:56:82:70:f0 > 00:50:56:82:a6:ae, ethertype IPv4 (0x0800), length 98: 6.6.6.11 > 6.6.6.12: ICMP echo request, id 4245, seq 10, length 64 |
再将逻辑交换机VLAN
修改为1600-1700
, 此时无法ping
通了.
接着,在两台虚拟机上分别配置VLAN
子接口,VLAN tag
设置为1601
, IP
分别设置为1.1.1.1/24
和1.1.1.2/24
:
1 | ip link add link ens192 ens192.1601 type vlan id 1601 |
此时, 从1.1.1.1
访问1.1.1.2
, 抓包结果为:
1 | 10:58:42.206065 00:50:56:82:70:f0 > 00:50:56:82:a6:ae, ethertype 802.1Q (0x8100), length 102: vlan 1601, p 0, ethertype IPv4, 1.1.1.1 > 1.1.1.2: ICMP echo request, id 4246, seq 9, length 64 |
可以看到物理网络报文的VLAN tag
为1601
.
再创建overlay
类型的逻辑交换机
, 不设置VLAN
, 此时VLAN
显示为N/A
:
将两台测试机迁移到overlay
类型逻辑交换机
,再次从6.6.6.11
访问6.6.6.12
, 访问能够成功.
此时, Uplink Profile
的Transport VLAN
为0
:
从抓包可以看到内层报文和外层报文都没有VLAN tag
:
1 | 11:10:30.479318 00:50:56:69:15:41 > 00:50:56:65:8c:86, ethertype IPv4 (0x0800), length 156: 10.10.10.101.63181 > 10.10.10.100.6081: Geneve, Flags [C], vni 0x10000, proto TEB (0x6558), options [8 bytes]: 00:50:56:82:70:f0 > 00:50:56:82:a6:ae, ethertype IPv4 (0x0800), length 98: 6.6.6.11 > 6.6.6.12: ICMP echo request, id 4266, seq 9, length 64 |
修改overlay逻辑交换机
配置VLAN
为1600-1700
, 从6.6.6.11
访问6.6.6.12
失败. 这时使用VLAN
子接口ens192.1601
从1.1.1.1
访问1.1.1.2
, 访问成功.
从抓包结果看, 内部报文已携带VLAN tag
: 1601
:
1 | 11:17:55.136613 00:50:56:69:15:41 > 00:50:56:65:8c:86, ethertype IPv4 (0x0800), length 160: 10.10.10.101.54392 > 10.10.10.100.6081: Geneve, Flags [C], vni 0x10000, proto TEB (0x6558), options [8 bytes]: 00:50:56:82:70:f0 > 00:50:56:82:a6:ae, ethertype 802.1Q (0x8100), length 102: vlan 1601, p 0, ethertype IPv4, 1.1.1.1 > 1.1.1.2: ICMP echo request, id 4269, seq 8, length 64 |
现在修改所使用的Uplink Profile
, 将Transport VLAN
修改为300
:
此时,再次抓包:
1 | 11:22:19.472658 00:50:56:69:15:41 > 00:50:56:65:8c:86, ethertype 802.1Q (0x8100), length 164: vlan 300, p 0, ethertype IPv4, 10.10.10.101.54392 > 10.10.10.100.6081: Geneve, Flags [C], vni 0x10000, proto TEB (0x6558), options [8 bytes]: 00:50:56:82:70:f0 > 00:50:56:82:a6:ae, ethertype 802.1Q (0x8100), length 102: vlan 1601, p 0, ethertype IPv4, 1.1.1.1 > 1.1.1.2: ICMP echo request, id 4269, seq 272, length 64 |
可以看到,外层报文的VLAN tag
为300
, 内层VLAN tag
为1601
.
因为实验环境是采用的嵌套虚拟化环境, 可以在旁路抓包分析. 如果是在物理环境中, 可能只能在ESXi
主机上进行抓包.
可以使用pktcap-uw
和tcpdump-uw
来抓取uplink
数据包:
1 | pktcap-uw --uplink vmnic1 --dir 2 -o - |tcpdump-uw -ner - |
但是pktcap-uw
产生的pcap
数据包中不包括报文VLAN tag
. 直接使用pktcap-uw
可以从元信息
中看到VLAN tag
, 也支持--vlan
选项只抓取指定的VLAN
.
1 | 05:52:33.944512[9] Captured at UplinkSndKernel point, TSO not enabled, Checksum not offloaded and not verified, SourcePort 67108877, VLAN tag 300, length 60. |
在通过-o
选项生成pcap
文件时,可以使用--ng
选项写入注释信息, 其中会包含VLAN tag
:
1 | -P, --ng (only working with '-o') |
这样生成的pcap
文件使用wireshark
打开时,可以看到Packet comments
部分:
参考:
- https://zhuanlan.zhihu.com/p/35616289
- https://support.huawei.com/enterprise/zh/doc/EDOC1100086528
- https://support.huawei.com/enterprise/zh/doc/EDOC1000178049/834147df
- https://www.h3c.com/cn/d_201909/1231231_30005_0.htm
- http://www.p2vlab.com/lets-make-a-vlan-backed-nsx-t-logical-segment/
- https://nuwan.vip/nsx-t-logical-switching/
- https://www.lab2prod.com.au/2022/05/nsx-t-deterministic-traffic-on-vlan-backed-segments.html
- https://www.lab2prod.com.au/2020/11/nsx-t-inter-tep.html
- https://www.reddit.com/r/vmware/comments/t29mqx/capturing_vlan_tags_with_wireshark_in_esxi/
- https://www.virten.net/2015/10/esxi-network-troubleshooting-with-tcpdump-uw-and-pktcap-uw/
- https://blogs.vmware.com/vsphere/2018/12/esxi-network-troubleshooting-tools.html
- https://rutgerblom.com/2019/07/06/nsx-t-data-path-visibility-part-1/
- https://rutgerblom.com/2019/07/14/nsx-t-data-path-visibility-part-2/
- https://rutgerblom.com/2019/07/19/nsx-t-data-path-visibility-part-3/
- https://virtualork.wordpress.com/2021/05/03/nsx-t-east-west-data-path-part-i/
- https://itdeepdive.com/2020/11/nsx-t-packet-capture-east-west-traffic-on-overlay-segment/