★ FEATURED ARTICLE 干网络这一行trunk这个词绝对绕不开。我第一次真正理解trunk是在一次深夜割接里。两台核心交换机互联VLAN 10和VLAN 20在两台设备上各自跑得好好的结果中间就拉了一根线怎么都不通。老工程师过来看了一眼丢下一句链路没放行VLAN吧敲了几条命令全网瞬间就通了。从那一刻起我才意识到trunk不只是中继链路四个字那么简单它是多VLAN网络里最基础、也最容易被忽视的关键环节。这篇文章不需要你有多高的网络理论功底只要接触过交换机、知道VLAN大概是什么就能跟着把trunk从原理到配置再到排障完整过一遍。如果你是刚入行的网工可以把它当成一份系统性的trunk学习笔记如果你已经配过trunk但没细想过内部机制这里面不少踩坑细节也值得花几分钟看看。1. trunk到底是什么先解决VLAN隔离带来的新问题1.1 VLAN隔离与跨设备通信的矛盾VLAN设计的初衷是隔离。把一个物理网络切成多个逻辑网络广播域被隔开二层流量互不干扰。比如一栋办公楼里财务部在VLAN 10技术部在VLAN 20两边各自的广播报文不会互相串门这既安全又减少了无效流量。但问题很快就来了VLAN是隔离了可业务需要互通怎么办更常见的是同一个VLAN的设备不可能全插在同一台交换机上。财务部一层楼几十个工位一台交换机端口不够得再加一台。这时候VLAN 10的设备一部分接在交换机A上一部分接在交换机B上。从逻辑上讲它们属于同一个广播域应该能二层互通。可A和B之间就拉了一根普通的物理线这根线默认只属于某一个VLAN不可能同时承载两个甚至十几个VLAN的数据。这就是trunk出现的根本原因既要让多个VLAN共用一条物理链路完成跨设备通信又不能让它们在共用链路的过程中互相混淆。我拿一个生活化的类比来讲。VLAN就像一栋楼里的不同公司每家公司的员工都戴着不同颜色的工牌。普通链路Access口就像一条只允许戴红色工牌的人通过的通道戴蓝色工牌的人根本进不去。而trunk像一条所有人都能走的公共走廊但每个人进走廊时必须把工牌亮出来走到目的地门口时再把工牌收好。工牌就是VLAN Tag也就是我们常说的VLAN标签。1.2 trunk让一条链路一物多用有了trunk两台交换机之间一根线就能搞定所有VLAN的互通。这根线上跑的每一个以太网帧都被交换机打上了当前所属VLAN的标签。对端交换机收到帧后看一眼标签就知道它属于哪个VLAN该从哪些口转发出去。这样带来的直接好处有三个。第一是端口利用率大幅提升。如果没有trunk两个VLAN互通就要两条独立链路十个VLAN就是十条线交换机的端口再多也经不起这么折腾。第二是配置维护简单VLAN增加时只需要在trunk链路上把新的VLAN加进允许列表不需要重新布线。第三是可以配合链路聚合做带宽扩展把多条物理链路捆绑成一个逻辑trunk既增加带宽又提供冗余。但trunk也绝不是把两个口配成trunk就能通这么简单。实际运维中绝大多数VLAN不通的故障根因都出在trunk的某一个小细节上允许列表没放行、Native VLAN不一致、对端VLAN没创建、动态协商出了岔子。要弄明白这些坑得先把trunk的工作原理吃透。2. trunk背后的协议机制802.1Q标签与帧的旅行2.1 802.1Q给以太网帧贴标签想让一条链路上的交换机识别帧属于哪个VLAN必须得有一个公认的标准。802.1Q就是IEEE制定的VLAN标记标准它在标准的以太网帧头里插入了一个4字节的Tag字段。具体插入位置在源MAC地址之后、Type字段之前。这4个字节分两部分前2字节是TPIDTag Protocol Identifier固定为0x8100用来告诉交换机这帧带着VLAN标签后2字节是TCITag Control Information里面包含了3 bit的优先级802.1p优先级就是从这里来的、1 bit的DEI丢弃合格指示早期是CFI以及最重要的12 bit的VIDVLAN ID。12 bit意味着理论上最多可以标识4096个VLANVLAN ID取值范围是0到4095其中0和4095保留所以实际可用的是1到4094。对于刚接触trunk的人来说最需要记住的其实是这个结论带上标签的帧在trunk链路里传输不带标签的帧在普通链路里传输。交换机在trunk口收到一个帧如果发现它带标签且标签里的VLAN在允许列表里就正常接收并转发如果发现它没带标签就会给它打上这个端口PVID对应的标签再处理。这个机制是后面理解所有故障的基础。2.2 Access口与Trunk口的分工差异交换机端口有两种基本模式理解它们的区别比背命令重要得多。Access口接入口一般连终端设备比如电脑、打印机、IP电话。这个口只属于一个VLAN。电脑发出来的帧通常不带标签Access口收到后给帧打上自己PVID的标签送进交换芯片处理从Access口发出去时交换机把标签剥掉还原成普通帧给电脑。对于终端设备来说它根本不知道VLAN的存在它只知道自己发了一包数据出去。Access口在这里起着翻译作用。Trunk口中继口一般连交换机、路由器或AP这类设备。这个口可以同时承载多个VLAN的流量。从Trunk口出去的帧除了特殊情况后面讲Native VLAN都带着标签从Trunk口进来的帧交换机根据标签决定转发策略。我用一张表来对照两者的行为差异这样更直观对比项Access口Trunk口归属VLAN只能属于一个VLAN可以属于多个VLAN接收带标签帧通常直接丢弃按允许列表决定接收与否接收不带标签帧打上PVID对应标签打上Native VLAN对应标签发送帧剥掉标签除Native VLAN外都带标签典型连接对象终端设备交换机、路由器、AP在实际配置中我见过不少新手为了让两根交换机连起来的线能通VLAN会把两边端口都设成Access且放进同一个VLAN。这在单VLAN场景下确实能通但一旦VLAN数量多了这种方案就完全行不通了链路会被VLAN数量撑爆。trunk的价值在这里体现得淋漓尽致。2.3 PVID与Native VLAN最容易踩的坑前面提到的PVID和Native VLAN是trunk配置里最容易出问题的两个概念。PVIDPort VLAN ID是端口的默认VLAN ID。Access口上它决定这个口属于哪个VLANTrunk口上它决定不带标签的帧进来后该算哪个VLAN。Native VLAN本地VLAN是Trunk口上一个特殊的VLAN。802.1Q标准规定Native VLAN的帧在trunk链路上传输时不打标签。默认情况下所有端口的Native VLAN都是VLAN 1也就是说trunk口上VLAN 1的流量在链路上是裸奔的没有标签。这样设计的初衷是为了兼容那些不理解802.1Q的旧设备让它们发出的无标签帧还能在trunk链路上传输。但在实际运维中Native VLAN已经成了trunk故障的头号来源。举个我调试过的真实例子。某次同事报障说交换机A和交换机B之间的VLAN 100不通。我上去看两台设备trunk配置看起来都正常允许列表里有VLAN 100接口状态也是UP。抓包一看链路上一堆无标签帧而且是VLAN 100的流量。问题出在A设备trunk口的Native VLAN被之前的人改成了VLAN 100而B设备上Native VLAN还是默认的VLAN 1。结果A发出去的VLAN 100流量在链路上不带标签B收到后按照自己端口的PVID理解成VLAN 1的流量两边各说各话VLAN 100当然通不了。所以这里必须强调一个铁律trunk链路两端的Native VLAN必须一致而且要尽量设置为一个不承载业务的固定VLAN比如VLAN 4094避免默认VLAN 1上有乱七八糟的报文。这个习惯能在很大程度上避免幽灵帧和跨VLAN错乱问题。3. 实战配置从零开始让trunk跑起来3.1 动手之前的规划清单配trunk虽然命令不多但规划不到位后面改起来就是灾难。我每次动手前都会过一遍下面这五件事确定VLAN清单哪些VLAN需要穿过这条trunk链路哪些不需要。原则上只放行必要VLAN不要图省事写all否则广播域跨设备扩大安全性和稳定性都受影响。确定Native VLAN两端统一用一个预留的VLAN我常用4094。不放在默认的VLAN 1上是为了避免一些设备在VLAN 1上的特殊报文比如CDP、LLDP、STP BPDU跟业务流量混在一起增加干扰面。确认物理链路光口还是电口光模块的速率和波长是否匹配多模光纤配多模模块单模光纤配单模模块这个检查在光接口场景下是必做的。确认对端设备能力对端是否支持802.1Q如果不支持或不支持dot1qtrunk根本跑不起来。现在主流设备基本都支持但旧设备或者某些家用交换机需要确认。确认是否涉及聚合如果需要跑大流量trunk通常会配合链路聚合PortChannel / Bond使用那规划时就要把聚合口的方式静态捆绑还是LACP动态协商一并定好。这套检查不只是为了配置本身更是为了后面排查问题时有一个预期基线。我习惯把上面的信息写进变更单里哪怕只是两个人协作的小项目留一份清晰的预期记录也能帮大忙。3.2 交换机间trunk的标准配置流程我以一套通用逻辑来写配置过程具体命令细节以你手头设备的官方手册为准不同厂商的语法有差异但思路完全一样。第一步在两台交换机上分别创建需要跨设备互通的VLAN。假设我们要打通VLAN 10和VLAN 20# 交换机A和B上都执行 vlan batch 10 20第二步进入连接对端交换机的物理接口把这个口模式改成trunk。注意有些设备支持批量配置或接口范围配置能省不少事# 交换机A假设上联口是GE0/0/1 interface GigabitEthernet 0/0/1 switchport mode trunk第三步设置Native VLAN两端必须一致。这里我设置为4094# 交换机A和B上都要做 interface GigabitEthernet 0/0/1 switchport trunk native vlan 4094第四步配置允许通过的VLAN列表。放行VLAN 10和20# 交换机A和B上都要做 interface GigabitEthernet 0/0/1 switchport trunk allowed vlan 10,20这里有个细节不同厂商对允许列表的语义不完全一样。有的厂商的trunk口默认只放行VLAN 1有的默认放行所有VLANall。如果默认放行所有VLAN你需要显式地把允许列表改成只包含业务VLAN否则设备上后来新建的VLAN也会自动穿过这条trunk这可能在不知不觉中扩大了广播域。建议无论厂商默认行为如何都显式写出允许列表。最后一步在VLAN 10和20里放入终端接口。假设交换机A的GE0/0/2属于VLAN 10GE0/0/3属于VLAN 20interface GigabitEthernet 0/0/2 switchport access vlan 10 interface GigabitEthernet 0/0/3 switchport access vlan 20交换机B上做同样的事情把对应终端接入对应的VLAN。这样从交换机A的VLAN 10端口进来的设备就能通过trunk链路跟交换机B上VLAN 10的设备二层互通了。3.3 路由器子接口与trunk的组合VLAN间路由trunk不只用于交换机之间一个非常经典的使用场景是单臂路由或网关终结。假设两个VLAN之间需要三层互通但你的三层设备只有一根物理线连接到交换机。这时候物理线上跑trunk再在路由器或防火墙上创建子接口每个子接口对应一个VLAN并配置IP做网关。交换机侧把连接路由器的口设成trunk放行VLAN 10和20路由器侧在这个物理口下创建两个子接口分别封装VLAN 10和20每个子接口配上对应网段的网关IP。VLAN 10里的终端要访问VLAN 20里的终端时源终端把报文发给网关——也就是VLAN 10子接口的IP路由器查路由表后把报文从VLAN 20子接口发出去交换机从trunk口收到这个带VLAN 20标签的帧转发给VLAN 20里的目标终端。整个过程里trunk链路承载了两个VLAN的流量而子接口完成了VLAN标记的剥离和封装。这个场景在小型网络里特别实用一台带几个千兆口的设备就能完成多VLAN间路由不需要额外采购三层交换机。但它的瓶颈也很明显所有跨VLAN流量都挤在一条物理链路上流量一上来就会拥塞。所以我建议这个方案只用在流量不大、预算有限的场景如果业务有大量东西向流量还是上三层交换机做VLAN间路由来得实在。3.4 配置验证不只看通了没配置完成后验证不能只停留在ping通了。我的验证习惯是三步走。第一步看端口状态和trunk状态确认成链路的接口是UP模式是trunkNative VLAN是预期值允许VLAN列表包含所有业务VLAN。如果设备支持还可以查看协议状态判断两端是否完成了VLAN信息交互。第二步做转发验证。分别从两台交换机上接在VLAN 10和VLAN 20的终端互ping能通只能说明基础转发没问题还要进一步验证trunk上是否真的带出了对应VLAN的标签帧。在交换机上做抓包或在镜像口上挂抓包工具看链路上有没有带VID 10、VID 20的帧。第三步做压力验证或边界验证。一个是验证广播抑制在交换机A的VLAN 10里发广播看交换机B的VLAN 10里能否收到而VLAN 20里收不到。另一个是验证VLAN隔离分别测试允许列表之外VLAN的流量是否被正确丢弃。这两步能确认trunk的隔离能力没有被错误配置破坏。4. 排障实录trunk链路典型故障与排查思路4.1 故障一所有VLAN都不通这个故障的特征是trunk两端之间有流量需求但整条链路一个VLAN都过不去。排查顺序从物理层往上层推。先看物理层。用端口状态命令确认链路是否UP。如果DOWN检查光模块、光纤跳线、两端用电口还是光口。曾经遇到过一次故障现场两边的单模光模块都亮着灯链路却始终DOWN。最后排查出来是一根LC-LC跳线的收发极性接反了这种低级失误在紧张割接时特别容易发生。物理层问题排除后看二层协商。如果两端设备的trunk模式是靠DTP动态中继协议协商出来的有一端被配置成dynamic auto而另一端又没主动发起协商就可能协商不出trunk链路变成access模式。这个问题的解决办法很简单两端都显式配置成trunk不要依赖动态协商。再往后看Tag封装不匹配。如果一端配置了802.1Q而另一端配置的是其他厂商私有封装或者一端在trunk上放行了VLAN而另一端没有链路状态UP但帧传不过去。这类问题光看端口状态看不出毛病必须查两端trunk的配置细节。最后一个容易被忽略的点是STP生成树阻塞。新接的链路如果网络中已有环路STP会把其中一条链路阻塞掉。检查一下对应端口是不是处于阻塞状态就能确认。4.2 故障二部分VLAN通、部分不通这种故障最典型的特征是VLAN 10通了VLAN 20不通。通常在trunk允许列表上找原因。最常见的原因是允许列表漏配。比如在一端允许列表里写了VLAN 1020另一端只写了VLAN 1020但少了一个VLAN ID或者VLAN 20在某一端压根没创建。对端设备没有VLAN 20即使trunk放行VLAN 20也没有对应转发信息。回显里会有VLAN not exist这类提示这类提示非常关键我每次排障都会先确认两端VLAN数据库一致。还有一种隐蔽情况是配置里允许列表写了VLAN ID但ID超出了对端设备的VLAN范围。比如某款设备可配置的VLAN范围只到4094你配置时写成了一个不存在的VLAN号配置不报错但流量就是出不去。所以创建VLAN和放行VLAN这两个动作要分开检查很多问题都出在放行了但没创建这种半吊子配置上。4.3 故障三时通时断与灵异现象这个故障占我排障经验里相当大的比例。表现为业务时断时续或者某些机器通、某些机器不通抓包帧时有时无。第一个嫌疑人是Native VLAN不一致。前面说过Native VLAN的帧在trunk链路不带标签而Native VLAN老化带来的影响非常隐蔽。两端Native VLAN不一致时一边发的VLAN 20的帧可能在链路另一端被理解为VLAN 100的流量路由器/三层交换机回包时发现路径不对业务就会断断续续。这个故障不开抓包基本查不出来。第二个嫌疑人是环路导致的广播风暴。业务VLAN的广播帧在环里不断转发交换机CPU占用飙升trunk链路流量被打满正常数据帧被丢弃。这种场景经常被误报为trunk坏了实际是上面有环路STP配置不当。排查方法是看端口流量统计确认某个接口收到的广播/组播报文数量异常高。第三个可能的原因是光口误码率高。物理链路虽然UP但光模块收发光功率接近临界值或者光纤弯曲半径过小导致误码帧在链路传输中被丢弃。这种情况的表现也是时通时断。看端口的光功率告警和误码统计如果CRC错误、Symbol Error在持续增加基本可以锁定光链路质量问题。4.4 排障思路速查表我把常见的trunk故障现象、可能原因和验证手段整理成一张表方便你直接照着查故障现象可能原因验证手段所有VLAN全不通物理链路问题、DTP协商失败、Tag封装不匹配检查端口状态、两端trunk模式、抓包看标签部分VLAN不通允许列表未放行、对端VLAN未创建、VLAN范围超限核对允许列表、对端VLAN数据库、设备规格时通时断Native VLAN不一致、环路广播风暴、光模块误码抓包看无标签帧、看广播统计、看光功率误码通但延迟极高链路拥塞、STP收效慢、端口协商半双工看端口流量利用率、看STP状态、检查端口双工速率两端配置正常但ping不稳定对端设备CPU高、控制平面丢包查看对端CPU利用率、查看接口丢包统计这张表的核心逻辑是从现象定位层面再从层面定位配置项。不要一上来就翻配置先确认故障现象是否稳定、影响范围多大再动手查。5. 影响范围与进阶扩展trunk不只是通这么简单5.1 链路聚合与trunk的组合玩法大型网络中单条物理trunk链路往往撑不住业务流量。这时候要把trunk和链路聚合配合起来用。链路聚合的作用是把两条或更多物理链路捆绑成一个逻辑接口带宽叠加并且成员链路之间有冗余。在这个逻辑接口上再配置trunk模式、放行多个VLAN就同时获得了多VLAN承载和高带宽高可靠两个能力。配置聚合trunk时有一个特别需要注意的点所有成员端口上的trunk配置必须完全一致包括模式、允许VLAN列表、Native VLAN。如果两个成员口配置不一致流量会打散到不一致的端口上导致转发异常。有些设备支持在聚合口上一次性下发配置到所有成员口这比自己逐个成员口配置要安全得多。我见过一个事故案例某台设备上聚合口配好了trunk但后来维护人员图省事只在一个成员口上改了一条命令没同步到聚合口结果大量流量被定向到配置不一致的成员口上整条链路丢包严重。所以聚合口上做任何变更务必确认配置是否已同步到全部成员端口。5.2 trunk的安全风险与防护建议trunk是一把双刃剑。它放行了多个VLAN如果不加防护也可能成为攻击者跨VLAN访问的跳板。最常见的一个风险是VLAN跳跃攻击。利用动态trunk协商机制攻击者把终端设备的网卡配置成DTP协商模式主动跟交换机的access口协商成一个trunk口。一旦协商成功攻击者就能在这个口上打上任意VLAN标签访问其他VLAN的流量。防护手段很简单在所有面向终端的接入端口上关闭DTP协商trunk口也手动指定不用动态模式。这条写在几乎所有安全基线里但实际网络里仍然能扫到不少开着协商的口。另一个风险是Native VLAN欺骗。如果trunk的Native VLAN是VLAN 1而攻击者处于VLAN 1就可以伪装成trunk链路上无标签的帧把帧带进其他VLAN。防护做法就是前面提到过的把Native VLAN改成一个不承载业务的专用VLAN并在接入端口上把VLAN 1从允许列表里剔除。还有一点很多人忽略trunk口放行的VLAN越少广播域就越小安全风险也越可控。不要为了省事把允许列表设置成all只放行业务必须的VLAN这是trunk安全的基本功。5.3 与STP、组播、QoS的联动trunk跑起来之后它会影响的不只是普通的单播转发。STP方面trunk链路同样参与生成树计算。如果网络里存在冗余链路STP会阻塞其中一条导致某些VLAN的流量在trunk上被阻断。做冗余设计时要理解STP的收敛机制必要时用MSTP多生成树协议把不同VLAN分配到不同的生成树实例上实现链路的负载分担。这个配置比单生成树要复杂但对大中型园区网络来说值得。组播方面交换机通常启用IGMP Snooping监听组播成员关系。在trunk链路上组播帧会通过哪些VLAN传递取决于Snooping表和Mrouter端口的状态。如果trunk链路连接着组播源或路由器需要确认IGMP查询报文能通过这些VLAN传递到接入交换机否则订阅组播的终端会收不到流。QoS方面802.1Q标签里的PRI字段3 bit优先级可以在trunk链路上端到端传递。比如IP电话和监控流量在接入侧被标记了高优先级这些帧带着PRI值穿过trunk到达核心核心设备可以依据这个优先级做队列调度。配置trunk时如果发现某些延迟敏感业务表现不佳检查一下PRI标记是否在trunk链路上被正确保留而不是被设备剥离或改写。6. 写在最后几点配置外的习惯建议trunk本身不难难的是在一堆看似正常的配置里找到那一个隐藏变量。我自己这几年踩过的坑总结下来其实就几条简单的习惯。第一条所有trunk口都做模板化配置。把Native VLAN、允许列表、DTP模式这些参数固定成一套配置模板新项目直接套用不在现场临时拍脑袋决定。就算换到不同厂商的设备逻辑也完全一致只是语法不同这样出错的概率会小很多。第二条变更之前一定先备份配置并记录变更前的基线状态。trunk变更往往影响的是多个VLAN的转发面一旦出问题回退是最高效的手段。没有基线现场就只能边摸黑边排查。我在大型变更里还会先在测试环境或维护窗口内做一次最小范围的验证确认无异常再做全网操作。第三条别迷信默认配置。很多设备默认允许所有VLAN穿过trunk默认Native VLAN是VLAN 1默认端口协商模式可能开着。这些默认值在小型测试环境无害一放到生产环境就是隐患。把trunk口的每一个参数都显式定义出来主动权才能握在自己手里。trunk还有一种很实用的扩展思路在云化和虚拟化环境里宿主机上的虚拟交换机同样使用trunk理念来承载不同业务的VLAN流量物理网卡上配置trunk虚拟机流量按VLAN标签分离。你在这里掌握的排查思路换一套环境依然能复用。技术会变但多VLAN共享一条物理链路却不互相干扰这个需求会一直存在。下次再遇到VLAN不通不妨先从trunk的这几个细节查起大概率能少走不少弯路。
阅读完成 · 觉得有帮助？
