VxLan静态隧道

汤愈韬

19人浏览 · 2026-07-05 16:53:49

汤愈韬 · 2026-07-05 16:53:49 发布

一个BD不能绑定多个VNI，BD跟VNI是一对一的

BD号尽量一样，好分析

建立隧道，希望5010能穿透中间的网络

实际上只能用一个

interface nve 1 这就是一个隧道接口

静态 VXLAN 隧道配置逻辑全解

子接口的配置是 bridge-domain 10，它直接绑定的是 BD，再通过 BD 间接关联 VNI。子接口本身从来不会直接出现 VNI 编号，它只管 “VLAN→BD” 的接入映射，不管隧道、不管 VNI。

真正直接配置 VNI 的只有两个地方：

BD 视图下：vxlan vni 5010 —— 定义「本地 BD ↔ 全局 VNI」的绑定关系
NVE 接口视图下：vni 5010 head-end peer-list 3.3.3.3 —— 定义「VNI ↔ 静态对端 VTEP」的隧道关系

加上子接口的「VLAN→BD」，刚好形成一条完整的三级映射链：

物理 VLAN → 子接口 → BD → VNI → 对端 VTEP → VXLAN 隧道

三处配置的各自作用与本质

我们从下往上（接入侧→隧道侧）逐层讲，每个配置只干一件事，完全不重叠。

1. 第一级：子接口配置 —— 「VLAN → BD」接入映射

配置示例

interface GigabitEthernet 0/0/1.10 mode l2
 encapsulation dot1q vlan 10   # 匹配物理链路上的VLAN10标签
 bridge-domain 10              # 把匹配到的流量送入BD10

核心作用

只负责接入侧流量分拣：把物理链路上带指定 VLAN 标签的流量，剥离标签后送入对应的本地 BD。

它只管 “物理链路和本地二层容器怎么对接”，完全不知道 VXLAN、不知道 VNI、不知道对端设备是谁；
VNI 和它没有直接关系，它只认 BD。

类比：小区快递柜，只负责 “按楼号（VLAN）把快递分到对应格口（BD）”，不管快递最后要发到哪个城市。

2. 第二级：BD 下的 vxlan vni —— 「本地 BD ↔ 全局 VNI」标识映射

配置示例

bridge-domain 10
 vxlan vni 5010   # 给BD10绑定全局唯一的VNI编号5010

核心作用

这是最核心的一层绑定：给本地的二层广播域（BD），分配一个全局唯一的 VXLAN 标识（VNI）。

本地意义：BD10 是交换机内部的二层容器，只在本机有效；
全局意义：VNI5010 是全网统一的子网标识，所有 Leaf 都认可；
绑定之后，设备就知道：BD10 里的流量要走隧道的话，就用 VNI 5010 做标签；从隧道收到 VNI 5010 的流量，就送进 BD10。

这层配置解决的问题：本地 BD 号可以随便改、不同设备可以不一样，但 VNI 必须全网统一，靠这层映射实现 “本地编号” 和 “全局标识” 的解耦。

类比：本地仓库给货物贴上全国统一的快递批次号（VNI），仓库内部编号（BD 号）随便叫，但发出去必须用统一的批次号，对方仓库才能识别。

3. 第三级：NVE 接口下的 vni head-end peer-list —— 「VNI ↔ 对端 VTEP」隧道映射

配置示例

interface Nve 1
 source 10.0.0.1                  # 本端VTEP源地址
 vni 5010 head-end peer-list 10.0.0.2   # 静态指定：VNI5010的对端VTEP是10.0.0.2

核心作用

这是静态 VXLAN 隧道的核心配置，手动告诉设备：这个 VNI 对应的远端 VTEP 地址是什么，相当于手动建立隧道。

静态 VXLAN 没有 BGP EVPN 自动发现邻居的能力，必须手动指定每个 VNI 的对端 VTEP IP；
设备收到 BD 送过来的、带 VNI 标识的流量，查 NVE 接口下的配置，就知道这个 VNI 的包该发给哪个对端地址；
反向收到对端发过来的 VXLAN 包，解出 VNI 后，也能对应到对应的 BD。

补充：如果是动态 VXLAN（BGP EVPN），这行配置就不需要了。NVE 接口下不用手动写 peer-list，对端 VTEP 地址靠 BGP EVPN 自动学习，更适合大规模网络。

类比：物流中转站的路由表，写死 “批次号 5010 的货物，全部发往广州中转站（10.0.0.2）”，不用动态查询。

数据包的封装

MAC表

传统的MAC表是mac地址跟出接口的对应关系，现在的MAC表有mac跟下一跳的对应关系，特别像路由表。

VxLAN MAC地址表项

MAC地址动态学习

跨子网单播报文转发

BUM流量转发

BUM 是三类需要 在同一个二层广播域内泛洪（群发）的以太网帧的统称：

类型	全称	含义	典型场景
B	Broadcast 广播帧	目的 MAC 为全`FFFF-FFFF-FFFF`的帧，要发给广播域内所有设备	ARP 请求、DHCP 请求
U	Unknown Unicast 未知单播帧	MAC 地址表中找不到目的 MAC 对应的出接口，只能泛洪查找	设备刚上线、MAC 表项老化后首次通信
M	Multicast 组播帧	目的 MAC 为组播地址，要发给所有组成员	视频直播、动态路由协议报文

传统 VLAN 网络里，交换机收到 BUM 帧后，直接在同 VLAN 的所有 Trunk/Access 口泛洪就行，天然实现群发。

VXLAN 场景下的核心痛点

VXLAN 大二层是跑在三层 Underlay 网络之上的，而三层网络天生隔离广播域，不支持二层帧的全网泛洪：

物理链路上只能传 IP 包，不能直接透传二层广播帧；
同 VNI 的虚拟机分散在多台 Leaf 上，要实现和传统 VLAN 一样的广播效果，必须有一种机制，把 BUM 帧送到所有同 VNI 的远端 VTEP。

头端复制，就是解决这个问题的最简单、最基础的方案。

头端复制是什么？核心本质

1. 官方定义

头端复制（Head-End Replication，也叫入站复制 Ingress Replication）：BUM 帧进入 VXLAN 隧道的源端 VTEP（头端 / 入站端），自己将报文复制多份，每份封装成独立的单播 VXLAN 报文，分别发送给同一个 VNI 下所有的远端 VTEP。

大白话：源端 VTEP 自己当 “群发器”，一份报文复印 N 份，单独寄给每个远端站点；中间 Underlay 网络只负责普通单播转发，不用做任何群发处理。

2. 核心特点

复制动作只在源 VTEP 做：中间 Spine、传输链路不参与复制，全程就是普通 IP 单播转发；
按 VNI 维度复制：每个 VNI 有自己独立的远端 VTEP 列表，不同 VNI 的 BUM 流量各自复制，互不干扰；
不依赖底层组播：Underlay 网络不需要配置任何组播协议（PIM、IGMP 等），只要 IP 单播可达就能用。

BUM帧大量泛洪的问题

不是 BUM 帧本身可怕，是「大二层的超广广播域 + VXLAN 头端复制的带宽放大效应」，把传统小二层里的局部小问题，放大成了全网级的灾难。传统 VLAN 里一个广播包只影响几十台设备，VXLAN 大二层里一个广播包能冲击几千上万台设备，还会成倍占用骨干带宽，这就是老师说 “怕太多 BUM 帧” 的底层原因。

一、为什么大二层特别怕 BUM 帧？4 个核心原因

1. 广播域指数级扩大，故障域直接覆盖全网

这是最本质的区别。

传统小二层（普通 VLAN）：广播域通常限制在一个机柜、一个机房楼层，最多几十上百台设备。就算出现广播风暴，影响范围也很小，排查快、损失小。
VXLAN 大二层：一个 VNI 对应的广播域可以跨机柜、跨机房、甚至跨地域，同一个大二层下可能有几千上万台虚拟机。
一个普通的 ARP 广播包，会送到所有同 VNI 的主机上，每台主机都要中断业务、CPU 处理这个无关报文，大量 BUM 帧会直接耗尽服务器的 CPU 资源，导致正常业务卡顿。

举个直观的例子：传统 VLAN 里一个 ARP 风暴，可能只瘫痪一个业务部门；大二层里一个 ARP 风暴，能瘫痪整个租户的所有业务集群，影响范围扩大了上百倍。

2. 头端复制带来的带宽放大效应（VXLAN 特有，最致命）

这是 VXLAN 架构独有的痛点

头端复制的原理：同 VNI 下有 N 台 Leaf，源端 VTEP 收到 1 份 BUM 帧，就要复制成 N-1 份单播报文，分别发给所有远端 VTEP。

带宽放大公式：1 份 BUM 流量 → 产生 (N-1) 份骨干网流量，N 是 VTEP 数量。
实际场景举例：一个数据中心有 20 台 Leaf，都属于同一个 VNI；1 个 100Mbps 的广播流，经过头端复制后，上行骨干网会产生 19×100Mbps = 1900Mbps 的流量。如果出现广播风暴，几秒内就能打满所有 Leaf 的万兆上行链路，直接挤占正常业务流量，导致业务丢包、断流。

传统二层 Trunk 链路里，广播包只是在一条共享链路上传输，不会被复制多份，没有这种放大效应；而 VXLAN 头端复制相当于 “一份流量变 N 份”，BUM 越多，带宽浪费越严重。

3. 未知单播泛洪加剧，无效流量暴增

大二层场景下，虚拟机跨 Leaf 迁移非常频繁，会带来大量未知单播帧：

虚拟机迁移后，Leaf 的 MAC 表项还没及时更新，目的 MAC 找不到出接口，就会触发未知单播泛洪；
大二层范围越大，主机数量越多，MAC 表项老化、漂移的概率越高，未知单播流量就越多。

这些未知单播帧同样会走头端复制、全网泛洪，所有主机都要接收处理不属于自己的报文，既浪费服务器 CPU，又浪费骨干带宽，属于完全无效的垃圾流量。

4. 广播风暴的危害被无限放大

传统二层有 STP 防环，就算出现环路，影响范围也局限在单个 VLAN，收敛快、损失可控。但在大二层场景下：

如果出现配置环路、服务器双网卡环路、虚拟交换机环路，BUM 帧会被反复泛洪、反复复制；
再叠加头端复制的带宽放大效应，瞬间就能打满全网所有链路，整个大二层业务直接瘫痪；
因为范围太大，排查环路位置的难度也远高于传统 VLAN，故障持续时间会更长。

VXLAN配置介绍

对比项	`encapsulation dot1q vlan 10`	`encapsulation untag`
匹配对象	带 VLAN10 标签的帧	不带任何标签的帧
入站处理	剥离 VLAN10 标签，送入 BD	直接送入 BD，无需剥标签
出站处理	打上 VLAN10 标签再发出	不打标签，直接发出
同物理口数量	可以创建多个，每个对应不同 VLAN	同一个物理口下只能有 1 个
链路类型	对应传统 Trunk 链路，单链路多 VLAN	对应传统 Access 链路，单链路单业务
典型场景	服务器 vSwitch、交换机级联 Trunk	普通 PC、物理终端、Access 对接

vlan在leaf 交换机就终结掉了，leaf交换机不创建vlan，用的BD

静态 VXLAN 隧道的核心不足总结

静态 VXLAN 的本质是纯手动配置、无独立控制平面、仅靠数据平面转发的二层隧道方案，所有隧道关系、泛洪列表全靠人工逐条配置，优势是原理简单、小规模部署快，不足全部集中在运维成本、规模扩展性、功能能力、

1. 运维配置成本极高，规模上来后指数级增长

这是静态 VXLAN 最直观的缺陷，核心源于头端复制的 peer-list 全手动逐条配置：

每新增一个 VNI，需要在所有同业务 Leaf 的 NVE 接口下，手动添加该 VNI 对应的所有远端 VTEP 地址；每新增一台 Leaf，需要在所有存量相关 Leaf 上，给每个已有 VNI 都补加新 Leaf 的 VTEP 地址。
配置量随「Leaf 数量 × VNI 数量」指数级上升：比如 10 台 Leaf、20 个业务 VNI，单台设备就要配置 20×9=180 条 peer-list 规则，全网配置量超千条，人工配置极易出现漏配、错配。
变更风险高：调整 VNI、扩容设备时，需要多台设备同步修改配置，任何一台配置不一致，就会出现单通、泛洪异常，业务故障概率高。

2. 扩展性极差，仅适用于极小网络

静态 VXLAN 的架构天然不支持横向扩容，规模稍大就会出现性能和运维双重瓶颈：

隧道层面：头端复制列表手动维护，Leaf 数量超过 5 台后，配置和维护成本已经不可控；
带宽层面：静态 VXLAN 只能使用头端复制处理 BUM 流量，无法使用 Underlay 组播优化，Leaf 数量越多，带宽放大效应越严重，少量 BUM 流量就会打满骨干链路；
表项层面：MAC 地址完全靠数据平面泛洪学习，主机数量越多，泛洪流量越大，设备 MAC 表压力越高，容易出现表项溢出、学习失败。

行业通用结论：静态 VXLAN 仅适合 3 台以内 VTEP 的小型场景、测试环境或点对点专线互联，无法支撑生产级数据中心。

3. 无控制平面，MAC 学习低效，BUM 流量不可控

静态 VXLAN 没有 BGP EVPN 这类控制平面协议，所有转发信息全靠数据平面泛洪获取，是其所有功能缺陷的根源：

MAC 学习完全依赖泛洪：未知单播、ARP 广播必须全网泛洪才能学习到远端 MAC，无效流量占比高，且无法做 ARP 代答、未知单播抑制等优化，BUM 流量占比远高于动态 VXLAN。
无三层路由控制面：静态 VXLAN 基本只支持二层转发，无法通过控制平面同步主机路由、网段路由，几乎不支持分布式三层网关，跨子网流量必须绕行集中式网关，转发路径长、时延高，无法发挥 Spine-Leaf 架构的分布式优势。

4. 三层功能严重受限，无法适配分布式网关架构

这是静态 VXLAN 的核心能力短板，也是生产环境很少用它的核心原因：

静态 VXLAN 仅能实现二层大二层互通，没有三层 VNI、IRB 主机路由、EVPN Type5 路由等能力，跨子网转发只能依赖集中式网关，哪怕是同 Leaf 下的跨子网流量也要绕行核心，转发效率低、核心设备压力大。
租户三层隔离能力弱，无法和 VPN 实例（VRF）做精细化联动，多租户三层隔离的灵活性远低于动态 EVPN VXLAN。

5. 故障收敛慢，可靠性差

静态隧道没有控制平面的状态感知和快速收敛机制：

对端 VTEP 故障、链路中断时，本端无法快速感知隧道失效，只能依赖物理链路状态检测、或者 MAC 表项老化来失效，收敛时间是秒级甚至分钟级，业务中断时间长。
没有隧道级别的冗余备份机制，只能依赖 Underlay 的 ECMP 做路径冗余，Overlay 层面无法实现隧道主备、快速倒换，可靠性维度能力缺失。

6. 自动化与云适配能力为零，不符合云化趋势

静态 VXLAN 纯人工配置的模式，完全无法适配云数据中心的自动化需求：

无法对接 SDN 控制器、云平台实现自动化编排，虚拟机创建、迁移、扩容时，无法自动同步隧道、表项，必须人工干预配置。
不支持虚拟机迁移的动态感知，虚拟机跨 Leaf 迁移后，MAC 地址需要重新泛洪学习，业务中断时间长，无法满足云业务弹性扩缩容、无感迁移的要求。

7. 排障难度大，运维效率低

没有统一的控制平面，导致故障定位困难：

没有统一的路由、隧道状态视图，隧道不通、业务不通时，只能逐台设备核对配置、查 MAC 表，排查效率极低。
没有协议状态、路由统计等监控指标，BUM 流量异常、表项异常等问题很难快速定位根因。

最终总结

静态 VXLAN 的所有不足，根源都是「无控制平面，全靠手动配置 + 数据平面泛洪」，它本质是 VXLAN 的入门级、简化版实现，仅适合小型测试、点对点互联场景；生产环境中大型网络，统一采用BGP EVPN 作为控制平面的动态 VXLAN，就是为了解决上述所有问题：自动发现邻居、自动同步 MAC / 路由、支持分布式网关、收敛快、可弹性扩容。