VLAN修剪实战：让Trunk链路只放行必要VLAN

跟组网打交道久了，你会发现一个很有意思的现象：很多项目里，Trunk 端口上跑着的流量并不都是我们“真正需要的流量”。我第一次听到“VLAN修剪”这个词，是在某次网络改造的评审会上，当时几个工程师盯着交换机端口占用率曲线发愁，明明办公网用户没几个，专线链路却总是被广播包塞满。后来排查下来，根子就在 Trunk 端口默认放行了所有 VLAN，很多不该在这个网段出现的广播帧，全都顺着中继链路“借道”溜达了一遍。

VLAN修剪，简单说就是让交换机之间的 Trunk 链路只放行实际需要的 VLAN，不让无关 VLAN 的广播、组播、未知单播继续占着链路资源。它解决的是二层网络里“广播乱窜”和“带宽白费”的问题。这篇文章适合刚接触 VLAN、正在系统学交换技术的同学，也适合那些被 Trunk 流量搞到头大的运维工程师。我会把原理、配置、验证手段，以及我踩过的坑一起写出来，读完你就能照着手里的设备做一遍。

1. VLAN修剪要解决什么问题：不裁剪的 Trunk 会怎样

1.1 广播帧在二层网络里如何“借道窜门”

要理解修剪，得先理解交换机在没有修剪时是怎么干活的。二层交换机处理帧时有个基本规则：目的 MAC 在 MAC 地址表里能找到，就只往对应端口转发；找不到，就向同一个 VLAN 内的所有端口泛洪。

这里的关键是“同一个 VLAN”。Access 端口划分很清楚：划到 VLAN 10 的口，只在 VLAN 10 内收发数据。但 Trunk 端口不一样，它天生是“超车道”，默认情况下允许所有 VLAN 的帧通过。你可以把 Trunk 理解成一栋楼的货运电梯：电梯里装的是哪个楼层的货它不管，只要有货就往上送。

于是问题来了。假设 A 楼有一台打印机发出一个广播帧，这个广播属于 VLAN 10，正常应该在 VLAN 10 所在的所有 Access 口转一圈。但如果 B 楼的交换机通过 Trunk 和 A 楼相连，而这个 Trunk 默认放行所有 VLAN，那么这台交换机不管 B 楼有没有任何设备属于 VLAN 10，都会老老实实地把这个广播帧复制一份送到 B 楼去。B 楼交换机收到以后，发现这个 VLAN 的广播在本地根本找不到接收者，再往其他口一转发，链路带宽和交换机 CPU 就白白消耗掉了。

这种“借道窜门”在 VLAN 数量少、链路带宽大的时候，感觉不明显。一旦 VLAN 数量到几十个，Trunk 链路又只有千兆甚至百兆，广播流量占比就会肉眼可见地飙升。我就见过一个场景：某办公楼的接入交换机上行口长期占用率达到 70%，抓包一看，超过一半是 ARP 广播和未知单播，而这些流量绝大多数不属于下行端口所在的 VLAN。

1.2 没修剪时流量到底浪费在哪

很多人以为广播帧就几十字节一个，不碍事。但真实环境里广播的杀伤力不是单帧大小，而是数量。网络里只要有一台设备不断发起 ARP 请求，或者某个端口下挂了一个小 Hub 形成环路，广播帧就会在 Trunk 链路上成倍放大。

放大怎么来的？假设你有 4 个 VLAN：VLAN 10、20、30、40，交换机 A 和交换机 B 之间一条 Trunk。实际情况是 VLAN 20 只存在于 A 楼的接入层，B 楼那边根本没有 VLAN 20 的任何设备。但 Trunk 默认放行 VLAN 20，所以 A 楼 VLAN 20 里的所有广播帧、组播帧，都会往这条链路上发。B 楼交换机接过来后，它发现本地没有 VLAN 20 的接口，这个帧就变成“无意义流量”：占用带宽、消耗 CPU、被丢弃，然后反复循环。

除了广播，还有未知单播和组播。像视频点播、在线课堂这类组播应用，如果 Trunk 不修剪，组播流会传到所有互联交换机，哪怕对端根本没有组播接收者。结果就是链路被没必要的流量塞满，真正要紧的数据排队延迟。

咱们用一个简单换算来感受：假设一个广播帧是 128 字节，每秒出现 1000 个，也就 1 Mbps 左右，听着不多。可如果 Trunk 上同时有十几个 VLAN 在泛洪，每秒几万个广播帧，就是几十 Mbps 的空耗。在百兆接入和千兆汇聚的典型办公环境里，这足以让正常业务流量开始卡顿。

修剪解决的就是这个浪费：把 Trunk 上原本“什么都放行”的默认策略，改成“只有需要跨交换机互访的 VLAN 才放行”。这样广播、组播和未知单播自然就被挡在链路外面，该通的地方通，不该通的地方一把关死。

2. 静态修剪与动态VTP修剪：两条主流实现路径

2.1 静态手工修剪：最笨但最好理解的方案

实现 VLAN 修剪，最直接的办法是手工在 Trunk 端口上配置允许通过的 VLAN 列表。这个操作在网络设备里的标准术语叫“Trunk 允许列表”，很多人把它和修剪混用，但本质上这就是最简单的静态修剪。

配置思路很简单：在交换机上找到通往另一台交换机的 Trunk 口，把允许列表从“ALL”改成你指定的几个 VLAN。比如只有 VLAN 10 和 VLAN 30 需要跨交换机通信，那就写trunk allowed vlan 10,30。其他诸如 VLAN 20、40 的流量，无论广播还是单播，统统不许上这条链路。

静态修剪的优点是可控性极高。每一步操作都是明确的、可预测的，哪条链路通哪些 VLAN，写清楚就完事。运维排查起来也简单：接口配置查看列表一目了然，不依赖任何协议状态。

缺点也很明显：维护量大。网络拓扑一变，比如新加了一台交换机、某个 VLAN 的成员从 A 楼迁到 B 楼，就要同步修改所有相关 Trunk 的允许列表。如果漏改一条，轻则业务不通，重则广播又顺着漏网的链路“串门”。VLAN 数量少、几十台设备以内的小网络，静态修剪完全够用；你要是管着几百台交换机的园区网，逐条手改 Trunk 的允许列表，不现实，而且早晚出错。

2.2 VTP动态修剪的工作原理

设备数量多的时候，VLAN 修剪通常由 VTP（VLAN Trunking Protocol）动态完成，所以很多老工程师口中的“VLAN修剪”，默认就是指 VTP Pruning。

先说 VTP 的用途。VTP 是一个二层协议，用来在一个管理域内同步 VLAN 数据库。你在其中一台交换机上创建了 VLAN 10，VTP 会把这条信息通告给整个域里的其他交换机，大家都自动“认识” VLAN 10，不需要每台设备手动创建一遍。这个功能听着很方便，但跟修剪有什么关系？

关系在于：VTP 不仅同步 VLAN 数据库，它还能同步“修剪信息”。VTP 域会维护一份“裁剪列表”，告诉每台交换机：某个 VLAN 会在哪些 Trunk 链路下游出现。如果一台交换机发现自己和下游所有交换机都没有属于某个 VLAN 的端口，它就会在这条 Trunk 上主动剪掉该 VLAN 的流量。

举一个实际运转的例子。园区里三台核心交换机互联，其中一台下面接了只有 VLAN 10 设备的接入交换机，另一台下面全是 VLAN 20 的设备。VTP 裁剪开启后，连接 VLAN 20 那台核心的 Trunk 链路，会自动判断“我对端不需要 VLAN 10”，于是 VLAN 10 的广播、组播、未知单播都不会再从这条链路发送。整个过程不需要你手工去改每条 Trunk 的允许列表，VLAN 数据库的增删会驱动裁剪列表自动变化。

这里要特别说明，VTP 裁剪只影响动态学到的 VLAN 转发决策，不影响本机已配置的 VLAN 和 Access 口通信。VLAN 10 在 A 楼的设备之间正常互访，完全不受影响，只是不会跨着 Trunk 漫游到不需要它的地方去。

2.3 两种方案怎么选

静态修剪和动态 VTP 修剪不是互斥的关系，实际项目中我更愿意把两者结合着用。核心的 Trunk 链路用手工允许列表写得明明白白，汇聚层以上的互联链路建立 VTP 域并开启裁剪，让边缘变化自动适应。

如果硬要做个对比，我列了一个表，方便你对照自己的场景选：

需要提醒一句：VTP 动态修剪依赖 VTP 域内所有交换机正确运作。如果你有两台交换机不在同一个 VTP 域，或者某台设备的 VTP 版本不一致，那修剪通告根本传不过去，相当于白配。所以选动态方案之前，先把 VTP 的全局状态检查一遍，这是基本功。

3. 实操配置：从规划到验证的完整步骤

3.1 动手之前先把 VLAN 与拓扑理清楚

配置 VLAN 修剪最大的坑，不是命令敲错，而是没理清拓扑就盲目开剪。

我见过有人为了优化性能，把所有 Trunk 的允许列表都改了，结果漏掉了跨交换机跑管理业务的 VLAN，导致无线控制器和 AP 之间失去了管理通路，整片区域的无线网络全部掉线。事后排查才发现，他忘了画一张 VLAN 与业务对应表。

所以，第一步永远是理清楚三张表：

第一张是 VLAN 清单：VLAN 编号、用途、网关网段、DHCP 服务器在哪。第二张是接入分布表：每个 VLAN 的成员设备主要分布在哪些楼层或楼栋，哪些 VLAN 只在本地、不需要出楼。第三张是互联链路表：核心交换机之间、核心到接入、接入到接入，每条 Trunk 链路连的是哪两台设备，经过这些链路的 VLAN 应该有哪些。

表格不用做得多精美，关键是信息准确。哪怕只是用纸笔画一条竖线代表 Trunk，旁边写下“放行 VLAN 10、20”，也比直接敲命令强得多。

3.2 动态修剪的标准配置流程

下面以一个典型三层网络为例，演示动态 VTP 修剪的配置流程。命令以主流厂商的接口风格做示意，不同品牌的具体命令词有差异，但操作思路完全一致。

全局启用 VTP，在核心交换机上（也就是 VTP Server）执行：

vtp domain LAB-NETWORK vtp version 2 vtp pruning

vtp domain设置的是管理域名称，域内所有交换机的域名必须完全一致。vtp version 2是为了让较老的交换机也能正确理解修剪通告，现代设备如果全部支持 v3，也可以直接用 v3。vtp pruning就是在全局层面开启动态修剪的开关。

然后在互联接口上，把它配置成 Trunk：

interface GigabitEthernet0/0/24 switchport trunk encapsulation dot1q switchport mode trunk

这里有个容易忽略的点：VTP 修剪一定要配合 Trunk 端口才有意义。Access 口本来就不承载多 VLAN 流量，根本没有“修剪”的对象。同时，如果交换机之间有多个 Trunk 口，VTP 修剪会在每个 Trunk 口上独立生效，只要某一个口下游存在对应 VLAN 的端口，这个 VLAN 就可以从该口通过。

配置完成后，用几个验证命令检查状态：

show vtp status show vlan pruning show interfaces trunk

show vtp status要看三样东西：VTP 模式是否是 Server 或 Client、域名称是否一致、修剪是否显示 Enabled。show vlan pruning会列出每个 VLAN 在当前设备上的修剪状态，能看到哪些 VLAN 是活跃的、哪些被裁剪了。show interfaces trunk则是最直观的检查，它会显示每个 Trunk 口当前允许通过的 VLAN 列表，如果修剪生效，你会在列表里看到部分 VLAN 已经消失。

我通常的操作习惯是：先把 VTP 模式、域名、版本三项确认无误，再动接口配置，最后对照show vlan pruning的输出和之前画的 VLAN 表，逐项核对有没有被误剪的 VLAN。

3.3 静态修剪的配置与验证思路

如果你的网络规模小，或者核心链路不想依赖 VTP，那就用静态修剪。同样以 Trunk 端口为例：

interface GigabitEthernet0/0/24 switchport trunk allowed vlan 10,20,30,100

这句的意思是，这条 Trunk 链路只放行 VLAN 10、20、30、100。如果之前默认是放行所有 VLAN，通常还需要补一句移除操作：

interface GigabitEthernet0/0/24 switchport trunk allowed vlan remove 40-50

静态修剪的验证比动态简单，直接看同一句配置和show interfaces trunk的输出是否一致即可。这里我建议你特别注意show interfaces trunk里的“Vlans allowed on trunk”和“Vlans active on trunk”两行。“allowed”是配置层面，“active”是运行层面，如果某个 VLAN 被配置为允许，但本地没有任何该 VLAN 的端口，那么 active 列表里也看不到它，这属于正常现象。

另外提醒一句，静态修剪并不会阻止两端的交换机之间维护同一 VLAN 的 VTP 或 STP 协议报文，这些协议帧仍然需要穿越 Trunk。这是好事，因为 STP 要保证无环，必须依赖所有链路上的 BPDU 正常收发。

4. 我踩过的坑与实战排障速查

4.1 几个容易翻车的场景

先说 VLAN 1。VLAN 1 是所有交换机的默认 VLAN，承载着 CDP、VTP、STP 等大量控制协议流量。VLAN 1 默认是不能被修剪的。哪怕你改了全局修剪、手工把允许列表里的 VLAN 1 删掉，很多厂商的设备依然会保证 VLAN 1 的协议报文可以穿越 Trunk。这一点不是 bug，是保护机制，不然 VTP 通告都传不过去，动态修剪自己就“罢工”了。

第二个容易翻车的场景是管理 VLAN。很多网络里管理 VLAN 和业务 VLAN 是分开的，运维走 SSH 或 Telnet 管理交换机。如果你做静态修剪时把管理 VLAN 的网段忘在列表外面，相当于自断了远程管理的通路。我吃过一次亏，半夜改核心配置，把管理 VLAN 11 从 Trunk 允许列表里误删了，结果远端设备全部失联，最后只能跑机房。所以，所有涉及管理 VLAN 的 Trunk 口，建议单独打标签，配置后第一时间验证管理通道。

第三个坑是 RSPAN 或远程镜像的专用 VLAN。这种 VLAN 专门用来承载镜像流量，大多数交换机要求它不能被 VTP 修剪。如果修剪把它干掉了，你的抓包和监控系统会突然“失明”，还特别难排查，因为业务流量都正常，只是监控少了一段。配置远程镜像专用 VLAN 时，记得确认动态修剪列表里把它排除掉。

第四个坑是 VTP 透明模式。透明模式的交换机不会参与 VTP 通告的转发，也不会学习 VLAN 数据库，但它会无条件转发 VTP 报文。如果一台透明模式交换机挡在 VTP Server 和 Client 之间，它自己转发 VLAN 通告没问题，但修剪信息是否有效就要打问号了。所以，我建议混合部署时做好明确规划，最好把透明模式设备放在 VTP 域的末端，别放在中间路径上。

4.2 排障命令与错误示范

排障的第一步，永远是先确认修剪到底有没有生效。很多人配置完以后只看了show vtp status，看到 Pruning 显示 Enabled 就以为大功告成了。但show vtp status只能说明全局开关开了，不能说明每条 Trunk 上的修剪状态都是对的。

我建议按这个顺序排查链路一端的修剪状态：

先看 VTP 域和版本。域名不一致，修剪通告无法互通，可能只有一台设备在“自以为”。版本不一致也会导致同样的问题。再看 Pruning 的全局状态，某些设备可能需要先确保 VTP 模式是 Server 或 Client，透明模式设备虽然也能配置修剪，但不会主动传播修剪信息。最后看具体 Trunk 口的允许列表，如果列表是默认的 ALL，说明修剪指令还没有覆盖到这条链路，此时即使全局开了，这个口上还是全 VLAN 泛洪。

排查中常见的错误示范是：在错误端口上配置修剪。有人认为“VLAN 10 只在接入层，所以我在接入层交换机的所有 Access 口上禁止 VLAN 10”。这完全跑偏了，Access 口本来就只有一个 VLAN，禁不禁止都无感。修剪要作用的是连接两台交换机的 Trunk 口，不是终端接入的 Access 口。

还有一个常见误解是“VLAN 在本地没有端口，修剪就会自动去掉它”。这句话不准确。对于动态修剪，确实会自动裁剪；但对于静态修剪，如果你没有在允许列表里移除这个 VLAN，它就是不会通过。动态修剪依赖的是 VTP 通告信息，和本机 VLAN 有没有端口是两码事。

4.3 更进一步的优化建议

配置修剪不是一锤子买卖，网络是活的，该重新梳理的节点要定期梳理。我个人的习惯是每半年把show vlan pruning的结果导出来，和当前的 VLAN 规划表对比一次，把废弃 VLAN 清理掉，把新增 VLAN 的分布补上。这样动态修剪才能在真正需要的时候发挥作用，而不是靠运气蒙混过关。

如果你在冗余链路环境里工作，还可以把 VLAN 修剪和 VLAN 负载均衡结合起来考虑。比如两条 Trunk 做链路聚合或者 STP 冗余，静态修剪可以让不同的 VLAN 走不同的链路，既减少了广播泛洪，又让流量分担更均匀。这个思路在大型园区网里尤其好用，但要注意结合 STP 的端口角色一起看，别剪完之后某些 VLAN 从一条链路整体消失，等于把鸡蛋全放一个篮子里。

另外，VLAN 修剪只能优化二层的广播和无意义流量，它管不了三层路由层面的事情。真遇到全网广播风暴，别急着甩锅给 Trunk，先查环路、查 ARP 攻击、查非法 DHCP，把二层拓扑的完整性修好，修剪才能安安静静地当“锦上添花”。我用过一次动手排障的顺序：先确认所有交换机 STP 正常、没有环，再看 Trunk 修剪状态，最后才怀疑广播源。按这个顺序查，绝大多数广播问题都能在三步内定位到源头。

我个人实际调试中的体会是：VLAN 修剪最大的价值，是让网络里每一条链路的流量变得“有目的性”。配置它不需要太高深的算法知识，更像做减法，把 Trunk 这条大路修窄一点，只放行真正需要过路的 VLAN。踩过几次坑之后，我现在每动一次 Trunk 都会有三个习惯动作：先画表规划，再敲配置，最后用show interfaces trunk核对 active 列表。网络无小事，尤其是二层链路这种一错就全网飘红的地方，一次只改一条链路、改完立刻验证，才是最稳妥的路径。