3. Overlay网络基础与封装技术

Underlay负责把数据包从一台物理设备送到另一台物理设备,而Overlay要解决的是另一个问题:让分布在不同物理位置、甚至跨越三层路由域的虚拟机或容器,看起来像接在同一台二层交换机上。实现这一目标的核心手段是隧道(Tunnel)——把原始报文整体当作载荷,再套上一层新的外层头部,由Underlay网络负责转发外层,到达隧道终点后再剥离外层、还原原始报文。

理解Overlay,关键是理解“封装”这一动作改变了什么。原始报文在隧道入口被加上外层IP头、外层UDP/TCP头以及隧道协议头,形成一个新的、更大的数据包。这个新包在Underlay中只按外层目的IP转发,Underlay设备完全不需要理解内层是什么协议、属于哪个租户。到达隧道终点后,外层被去掉,内层原始帧或包被交给对应的虚拟网络。因此,Overlay的三大要素是:隧道端点(NVE/VTEP)、封装协议、控制平面(用于学习或下发对端地址与VNI映射)。

VXLAN:当前最主流的Overlay封装

VXLAN(Virtual eXtensible LAN)由RFC 7348定义,是目前数据中心Overlay的事实标准。它把原始二层帧封装进UDP中,使用目的端口4789(早期部分实现使用8472,需注意兼容性)。VXLAN引入24位的VNI(VXLAN Network Identifier),可支持约1600万个隔离的二层网段,远超传统VLAN的4094个。承担封装与解封装功能的设备称为NVE(Network Virtualization Edge),其上的隧道接口称为VTEP(VXLAN Tunnel Endpoint),每个VTEP拥有一个Underlay可达的IP地址。

VXLAN的报文结构为:外层以太头 → 外层IP头 → 外层UDP头 → VXLAN头(8字节,含24位VNI)→ 原始以太帧。外层IP的源和目的分别是本端和对端VTEP地址,UDP源端口通常由内层帧的哈希计算得出,用于Underlay的ECMP负载分担。

NVGRE与GENEVE:另外两种封装选择

NVGRE(Network Virtualization using Generic Routing Encapsulation)由微软等提出,使用GRE作为外层封装,用GRE头中的24位VSID(Virtual Subnet ID)标识虚拟网络。它的优点是复用已有GRE实现,但GRE头部字段的哈希熵不足,容易导致Underlay ECMP负载分担不均,且部分网络设备对GRE的解析支持不如UDP广泛,因此在实际数据中心中部署少于VXLAN。

GENEVE(Generic Network Virtualization Encapsulation)是较新的通用封装格式,设计目标是兼容并扩展VXLAN、NVGRE等既有方案。它同样基于UDP(默认端口6081),头部长度可变,通过TLV(Type-Length-Value)字段携带元数据,例如VNI、策略标识、安全上下文等。GENEVE的灵活性使其更适合与SDN控制器、可编程数据面配合,但生态成熟度仍在发展中。

Overlay隧道封装与MTU开销示意 原始二层帧(内层) 内层以太头 + 载荷 封装 封装后报文(外层 + 内层) 外层 以太头 外层 IP头 外层 UDP头 VXLAN头 (VNI) 内层以太头 + 载荷 封装开销 ≈ 50~70 字节 MTU 关系:Underlay MTU ≥ 内层帧长 + 封装开销 内层帧最大 1500 B (传统以太网MTU) + 封装开销 50~70 B (VXLAN约50B) = Underlay需 ≥ 1550~1570 B 否则需分片或调小内层MTU 三种Overlay封装对比 VXLAN UDP 4789 / 24位VNI 生态最成熟,主流选择 NVGRE GRE / 24位VSID 哈希熵不足,部署较少 GENEVE UDP 6081 / TLV可变头 灵活可扩展,生态发展中

封装开销与MTU:最容易被忽视的工程约束

封装不是免费的。以VXLAN为例,外层以太头14字节、外层IP头20字节、外层UDP头8字节、VXLAN头8字节,合计50字节。如果内层原始帧是标准的1500字节,封装后总长达到1550字节。若Underlay链路的MTU仍为1500字节,这个包就必须分片,或者被丢弃。分片会显著增加转发开销、降低吞吐,并可能因分片重组失败导致丢包;丢弃则直接造成业务不通。

因此,部署Overlay时必须统一规划MTU。常见做法有两种:一是把Underlay物理接口和所有中间链路的MTU提升到1550~1600字节(推荐1600留出余量),使封装后的包无需分片;二是保持Underlay MTU为1500,把隧道接口或虚拟机网卡的MTU调小到1450字节左右,让内层主动适配。前者性能更好,但要求全网设备支持并统一配置;后者兼容性更好,但会略微降低有效载荷效率。

实际配置中,以Linux VTEP为例,通常需要显式设置物理接口MTU和VXLAN接口MTU:

# 将物理接口MTU提升到1600,承载封装后报文
ip link set dev eth0 mtu 1600

# 创建VXLAN接口,指定VNI、本地与远端VTEP地址
ip link add vxlan100 type vxlan id 100 \
    local 10.0.0.1 remote 10.0.0.2 \
    dev eth0 dstport 4789

# VXLAN接口MTU设为1450,保证内层帧封装后不超过1600
ip link set dev vxlan100 mtu 1450
ip link set dev vxlan100 up

配置完成后,可用ping -M do -s 1422 10.0.0.2验证:1422字节ICMP载荷加上8字节ICMP头、20字节内层IP头,正好1450字节内层包,封装后约1500字节,若Underlay MTU为1500则刚好通过;若失败,说明路径中某段MTU不足或封装开销计算有误。也可用ip -d link show vxlan100确认VNI、本地/远端地址和dstport是否正确。

规划建议:在Overlay部署前,先用ping -M do -s <size>逐跳探测Underlay路径的实际MTU,确认所有链路都能承载“内层MTU + 封装开销”。若无法统一提升MTU,应把内层MTU下调到安全值,并在虚拟机模板或容器网络配置中同步设置,避免应用层出现“小包正常、大包不通”的隐蔽故障。

三种封装的选型判断

如果追求生态成熟、设备支持广泛、运维资料丰富,优先选VXLAN;如果已有GRE体系且对VNI数量需求不大,NVGRE可作为过渡;如果面向可编程网络、需要携带额外元数据或与SDN控制器深度联动,GENEVE更具扩展性。无论选哪种,都必须把封装开销和MTU作为设计输入,而不是部署后再补救。Overlay的连通性故障中,相当一部分并非路由或VNI配置错误,而是MTU不匹配导致的大包丢弃——这类问题往往表现为“能ping通但传文件失败”,排查时应优先检查隧道接口MTU与Underlay路径MTU。