RFC 7348 —— VXLAN：打破 VLAN 的时空枷锁

Yefimov
4 阅读7分钟

1. 核心痛点：VLAN 的“天花板”与云时代的矛盾

在 VXLAN 出现之前，数据中心网络隔离主要靠 VLAN (802.1Q) 。但随着云计算和服务器虚拟化的爆发，VLAN 的三个致命缺陷暴露无遗：

1.1 缺陷一：ID 不够用 (4094 的限制)

  • VLAN ID：只有 12 bit，最多支持  4096 个，去掉保留值，实际可用 4094 个。
  • 云场景：一个大型公有云（如 AWS, Azure）可能有数百万个租户。每个租户可能需要多个隔离网段。4094 个 ID 连一个大型数据中心的租户都分不过来，更别说多租户隔离了。
  • 后果：租户之间不得不共享 VLAN，导致安全隔离性下降，或者需要极其复杂的网络规划。

1.2 缺陷二：生成树协议 (STP) 的阻塞

  • 机制：为了防止二层环路，传统以太网依赖 STP (Spanning Tree Protocol) 。
  • 代价：STP 会阻塞冗余链路，只保留一条活动路径。这意味着你买了 10 条链路，可能只有 1 条在干活，其他 9 条都在“ standby”。
  • 后果：带宽利用率极低，无法利用 ECMP (等价多路径路由) 进行负载均衡。

1.3 缺陷三：虚拟机迁移的范围限制

  • 需求：为了高可用和负载均衡，虚拟机 (VM) 需要在物理服务器之间实时迁移 (vMotion/Live Migration)。
  • 限制：VM 迁移要求源和目的必须在同一个二层广播域 (同一个 VLAN/IP 子网)，否则 IP 地址会变，业务会中断。
  • 矛盾：物理数据中心通常很大，受限于 VLAN 和 STP，二层域很难跨越多台核心交换机扩展。这导致 VM 只能在一个很小的物理范围内迁移，无法充分利用整个数据中心的资源。

VXLAN 的愿景：
“我们要在现有的三层 IP 网络 (Underlay) 之上，构建一个逻辑上的、无限的二层网络 (Overlay)。让二层域可以跨越任何三层边界，让隔离数量扩展到千万级，让所有链路都能负载分担！”

2. 原理深潜：MAC in UDP 的魔法

RFC 7348 定义的核心技术非常简单而优雅：MAC in UDP。
它把原始的二层以太网帧，整个打包塞进一个 UDP 数据包里，然后通过现有的 IP 网络 发送出去。

2.1 报文封装结构 (Encapsulation)

想象一下俄罗斯套娃：

+------------------+------------------+------------------+------------------+------------------+
|  Outer Ethernet  |   Outer IP Header|  Outer UDP Header|   VXLAN Header   | Inner Ethernet Frame |
|  (Underlay L2)   |  (Underlay L3)   |  (Tunnel Port)   |  (VNI + Flags)   | (Original Tenant Traffic)|
+------------------+------------------+------------------+------------------+------------------+
|  DA: VTEP_B_MAC  |  SA: VTEP_A_IP   |  Sport: Random   |  Flags: 0x08     |  DA: VM_B_MAC    |
|  SA: VTEP_A_MAC  |  DA: VTEP_B_IP   |  Dport: 4789     |  VNI: 10001      |  SA: VM_A_MAC    |
|  Type: 0x0800    |  Proto: UDP (17) |  Len: ...        |  Reserved: 0     |  Type: 0x0800    |
+------------------+------------------+------------------+------------------+  ... (IP/TCP/Data) |
关键字段解析：

  1. Outer Header (外层头) ：

    • MAC/IP：属于物理网络 (Underlay)。源和目的是 VTEP (VXLAN Tunnel End Point)  的物理接口地址。
    • 作用：指导数据包如何在物理网络中路由。路由器只看这个头，完全不知道里面包了什么。

  2. UDP Header：

    • 目的端口：4789 (IANA 分配的标准端口，早期实现曾用 8472)。
    • 源端口：通常由 VTEP 随机生成（基于内层流的哈希），这对于利用 ECMP (等价多路径)  至关重要！因为路由器会根据 UDP 源端口做哈希，将不同流量分摊到不同物理链路上。

  3. VXLAN Header (8 字节) ：

    • Flags (8 bit) ：第 3 位 (I 位) 必须为 1 (00001000 = 0x08)，表示这是一个有效的 VNI。

    • VNI (24 bit) ：VXLAN Network Identifier。这是 VXLAN 的灵魂！

      • {224≈16002^{24}≈1600} 万。
      • 足以给每个租户、甚至每个应用分配独立的 ID。

    • Reserved：剩余位必须为 0。

  4. Inner Frame (内层帧) ：

    • 原始的租户数据包（包含租户的 MAC、IP、TCP/UDP 等）。
    • 对物理网络完全透明。

2. 核心组件：VTEP

VTEP (VXLAN Tunnel End Point)  是 VXLAN 世界的“边境海关”。

  • 角色：负责封装 (Encap) 和解封装 (Decap)。

  • 位置：可以是物理交换机 (ToR, Spine)，也可以是虚拟化交换机 (vSwitch, OVS)，甚至是服务器内核 (Linux Bridge, VRF)。

  • 工作流程：

    1. 接收：VM A 发送一个普通以太网帧给 VM B。
    2. 查找：本地 VTEP 查表，发现 VM B 在远端 VTEP (IP: 10.0.0.2)，属于 VNI 10001。
    3. 封装：加上 UDP 头 (Dport 4789)、VXLAN 头 (VNI 10001)、外层 IP/MAC 头。
    4. 发送：扔进物理网络。
    5. 解封装：远端 VTEP 收到包，检查 UDP 端口 4789，剥离外层头，检查 VNI 10001 是否合法。
    6. 交付：将原始以太网帧发给 VM B。

3. 深度案例实录：跨越三层的二层通信

假设我们有两个数据中心机架，中间隔着三层路由网络。

场景：

  • 租户 A 的 VM1 (MAC: AA, IP: 192.168.1.10, VNI: 5000) 在 Rack 1。
  • 租户 A 的 VM2 (MAC: BB, IP: 192.168.1.20, VNI: 5000) 在 Rack 2。
  • 物理网络：Rack 1 VTEP IP = 10.1.1.1, Rack 2 VTEP IP = 10.2.2.2。

3.1 通信流程

  1. VM1 发送 ARP 请求 (如果不知道 VM2 MAC) 或 直接发送 ICMP：

    • 帧：Src: AA, Dst: BB, Type: IPv4
    • 到达 Rack 1 VTEP。

  2. Rack 1 VTEP 查表 (MAP Table) ：

    • 查找 VNI 5000 + Dest MAC BB。
    • 发现映射：MAC BB -> Remote VTEP 10.2.2.2。
    • (注：这个映射表怎么来的？见下文 9.4 控制平面)

  3. 封装 (Encapsulation) ：

    • Inner: 原始帧 (AA -> BB)。
    • VXLAN: VNI = 5000, Flags = 0x08。
    • UDP: SrcPort = 54321 (随机), DstPort = 4789。
    • Outer IP: Src = 10.1.1.1, Dst = 10.2.2.2。
    • Outer MAC: Src = VTEP1_MAC, Dst = Next_Hop_MAC。

  4. 物理网络传输：

    • 中间的路由器只看到 10.1.1.1 -> 10.2.2.2 的 UDP 包。
    • 它们根据 IP 和 UDP 端口进行 ECMP 哈希，走不同的链路，充分利用带宽。
    • 路由器完全不管 VNI 5000，也不管里面的 MAC 地址。

  5. Rack 2 VTEP 接收：

    • 收到 UDP 包，目的端口 4789 -> 识别为 VXLAN。
    • 检查 VNI 5000 -> 确认本地有这个租户。
    • 解封装：剥掉 Outer IP/UDP/VXLAN 头。
    • 还原出原始帧：Src: AA, Dst: BB。

  6. 交付：

    • 将帧发送给 VM2。
    • VM2 的感觉：“哇，VM1 就在我的隔壁交换机上！我们好像在同一个二层局域网里！”
    • 事实：它们可能相隔几千公里，中间经过了无数个三层路由器。

4. 关键挑战：控制平面 (Control Plane)

RFC 7348 只定义了数据平面 (怎么封装包)，但留下了一个巨大的悬念：VTEP 怎么知道 MAC 地址对应哪个远程 IP？  (即 MAC-to-VTEP 的映射表怎么建立？)

这就引出了 VXLAN 的两种主要模式：

4.1 模式一：泛洪与学习 (Flood and Learn) - 类似传统以太网

  • 原理：模仿传统交换机的 ARP 泛洪。

  • 过程：

    1. VTEP 不知道 VM2 在哪。
    2. 它将 ARP 请求包封装成 VXLAN 组播包 (Multicast)，发送到特定的组播组 (对应 VNI)。
    3. 所有加入该组播组的 VTEP 都会收到包。
    4. VM2 所在的 VTEP 回复单播 ARP 响应。
    5. 源 VTEP 学习到 MAC BB -> VTEP 10.2.2.2 的映射，存入本地表。

  • 缺点：

    • 依赖物理网络支持 IP 组播 (配置复杂，很多网络不支持)。
    • 泛洪流量大，浪费带宽。
    • 扩展性差。

4.2 模式二：集中式控制平面 (Centralized Control Plane) - 现代主流

  • 原理：引入一个“大脑”控制器，统一管理所有映射关系。

  • 代表技术：

    • EVPN (Ethernet VPN, RFC 7432) ：目前最主流、最标准的方案。使用 BGP 协议在 VTEP 之间分发 MAC/IP 路由信息。
    • SDN Controller (如 VMware NSX, OpenDaylight)：控制器通过 OpenFlow 或 Netconf 下发流表。

  • 过程：

    1. VM1 上线，VTEP1 告诉控制器：“我有 MAC AA, VNI 5000”。
    2. VM2 上线，VTEP2 告诉控制器：“我有 MAC BB, VNI 5000”。
    3. 控制器通过 BGP EVPN 告诉 VTEP1：“想找 MAC BB？去 10.2.2.2 找”。
    4. VTEP1 直接建立单播隧道，无需泛洪。

  • 优点：

    • 无需组播。
    • 收敛快，扩展性极强。
    • 支持多活网关、快速故障切换。
    • 现状：现代数据中心 (Spine-Leaf 架构) 几乎全部采用 VXLAN + EVPN。
avatar
文章
阅读
粉丝