★ FEATURED ARTICLE 做网络这一行谁还没跟 trunk 打过几回交道呢我第一次真正弄懂 trunk 通信过程是在一个跨楼的二层组网项目里。当时两台交换机之间已经拉好了好几条网线可楼下每个部门都是独立 VLAN楼层交换机一多线缆越拉越乱端口却总不够用。后来有人提醒我别一条 VLAN 拉一根线了把两边的上联口配置成 trunk一条线就能带着十几个 VLAN 一起跑。从那以后我查故障第一反应就会先去看 trunk 状态。这篇博文就以 VLAN Trunk 为例把 trunk 的通信过程完整拆开标签怎么打、协商怎么发生、帧在链路上到底长什么样、跨交换机通信时数据怎么走再附上我在实际配置和排障里踩过的坑。不管是刚入门网络的新人还是要独立组网或处理二层故障的运维都值得花十分钟把这套逻辑捋顺。1. 从多个VLAN到一条中继链路1.1 为什么要用VLAN切割广播域网络里没有VLAN时所有设备共享一个二层广播域。ARP广播、DHCP发现、某些协议组播会在整个网段内扩散局域网主机一旦多广播报文损耗不可忽视。而且一旦出现二层环路广播风暴会让交换机CPU占用迅速飙升整个网络近乎瘫痪。引入VLAN后广播域被切开故障影响范围能缩小到一个VLAN内这是VLAN存在的首要理由。但这带来一个新问题VLAN之间在二层是隔离的如果两个交换机都划分了VLAN10、20、30那交换机之间该怎么把不同VLAN的流量送过去答案不是各自拉线而是用 trunk 中继链路让一条物理链路同时承载多个 VLAN 的帧。1.2 最笨的办法与trunk做法的对比如果按最朴素的想法每台交换机上给VLAN10拉一条物理线、VLAN20再拉一条物理线这样当然也能跑通但工程上完全不可接受楼层之间可能只有一两根预埋光缆一根物理线只能承载一个VLANVLAN数量一多就没有扩展余地。trunk的做法是一条物理链路把多个VLAN的帧全部封装好再发出去接收方依靠帧里的VLAN标识还原出它属于哪个VLAN。这就像从一个个的专用小屋改成了一条共享主干道每辆车挂了不同颜色的牌子到了十字路口交警只看牌子就能分流向。1.3 除了交换机互连还有哪里依赖trunk单臂路由是典型场景交换机与路由器之间用一条trunk路由器的物理接口上划分子接口每个子接口对应一个VLAN的网关。如果三层交换机要实现VLAN间路由其VLANIF接口本身也是基于二层的trunk承载。无线网络中AP上联到AC的流量也常走trunk。所以trunk通信过程可以说是所有多VLAN场景的底座不是某一台设备上的孤岛功能。2. 决定通信成败的三个机制2.1 802.1Q标签给帧写上小区门牌号802.1Q是IEEE标准它定义了如何在以太网帧里插入VLAN标签。标准以太网帧结构中在目的MAC6字节、源MAC6字节之后紧跟着类型/长度字段。802.1Q会在源MAC和类型字段之间插入4字节Tag前2字节是TPID固定为0x8100表示这是一个带VLAN标签的帧后2字节中包含3比特PCP优先级、1比特DEI丢弃指示和12比特VIDVID的取值范围是1到4094。这4字节就是核心VLAN身份就在这里。插入标签后以太网帧最大长度从1518字节变成1522字节。如果业务数据已经是1500字节加上4字节标签后会超过普通MTU长度所以二层接口往往需要把MTU调大或者在三层上做分片协商。很多VXLAN场景下MTU问题都会在trunk这层爆发这个细节我放到后面的排障章节里讲。补充一点802.1Q标签是不对帧内容加密的它只是信令所以标签可以被误改或伪造这也是后面安全风险的一个根源。2.2 协商协议trunk是“自动”出现的吗很多同学对着设备互联端口什么都不做结果发现两台交换机自动形成了trunk这是因为端口模式里开启了动态协商。常见模式有本端模式对端模式协商结果AccessAccessAccess无tagTrunkTrunkTrunk强制走trunkDynamic autoDynamic desirable能协商成TrunkDynamic autoDynamic auto协商失败保持AccessTrunkDynamic auto/desirable能协商成Trunk表格里最关键的一点是如果两边都设成了Auto链路反而不会成为trunk而如果一边是Desirable另一边是Auto才会协商成功。这个反直觉的特性曾经让不少人在施工现场挠头。生产环境我的建议是禁用自动协商两边全部手动指定trunk。自动协商看着方便但对安全不友好——它意味着你不想让某个口变成trunk对端一台配置不当的交换机插上来时端口可能自动被协商成中继整个VLAN就暴露了。收敛和可控性永远比自动化更重要尤其是对接入侧端口。2.3 Native VLAN唯一不贴标签的“默认车道”Native VLAN这个概念经常让人栽跟头。在一个trunk口上除了Native VLAN之外的所有VLAN都会打上802.1Q标签发往Native VLAN的帧不打标签直接用普通以太网帧在链路上传。接收方收到无标签帧时会默认把这些帧归入其Native VLAN。两端Native VLAN不一致是经典故障源。假如A端Native VLAN是10B端Native VLAN是20。A端想发的VLAN10流量不会打标签B端接收后发现没有标签就把它归到自己的VLAN20于是VLAN10的帧流入了VLAN20的广播域二层隔离瞬间失效。更危险的是双标签攻击攻击者在Access口发出带两层VLAN标签的帧交换机剥掉外层后内层标签仍保留可能被trunk转发到不该去的VLAN。所以安全基线通常要求把Native VLAN改成某个不收业务、没人用的黑洞VLAN并且两端固定一致。3. 一次完整通信过程的流水账3.1 先搭一个拓扑画面假设有SW-A和SW-B两台交换机中间用一个物理口连接并配置为trunk放行VLAN10和VLAN20。PC-A接在SW-A上属于VLAN10PC-B接在SW-B上属于VLAN10还有一个PC-C接在SW-B上属于VLAN20。三个PC的IP如果都在同一网段那是二层通信不碰网关如果PC-A要访问VLAN20的服务器就需要经过网关走单臂路由或三层交换机trunk上同时会有多种VLAN的标签帧交错出现。先看PC-A ping PC-B都是VLAN10二层通信这是最基础的场景。3.2 PC-A到SW-A的Access口入口先确定身份PC-A发出的普通帧没有标签。SW-A的Access接口固定属于VLAN10帧进入交换机后交换芯片在内部给这块数据打上VLAN10的标识。注意这时线上并没有插入802.1Q标签Access口只是以一个VLAN的身份接收。交换芯片查MAC地址表发现目标MAC应该从某个trunk口出去于是把内部VLAN10信息放到帧里在发出trunk口前把802.1Q Tag实际插入帧头。这才是“打标签”发生的真正位置。3.3 中间的那根trunk帧带着标签在跑现在连接SW-A和SW-B的物理线路上以太网帧变成了目的MACPC-B、源MACPC-A、TPID 0x8100、优先级/VID10、协议类型、IP头……。交换机之间不关心IP地址只看这个Tag就能知道该把帧交给哪个VLAN的上层。这里有个常见误解很多人以为Access口收到的帧也带Tag或者Trunk口收到帧后交换机一定会把Tag剥掉。实际上Tag是在“进入trunk口之前”由交换芯片加上在“出trunk口”时保留而Access口收到的是无Tag帧交换机内部用虚拟接口的metadata保存VLAN归属不一定改成线上Tag。抓包验证时只有Trunk链路上的包才看得到0x8100终端网卡抓包永远看不到Tag——除非网卡配置了VLAN。3.4 SW-B收到Tag后的处理读标识、查表、去标识SW-B的trunk口收到带Tag的帧后首先检查这个帧的VID是否在“trunk允许通过的VLAN列表”里。如果在就拿到这个VLAN的上下文继续查MAC表如果不在直接丢帧。本例VID10在列表里SW-B查到目标MAC对应的是某个Access口该口属于VLAN10因为出口是Access口交换芯片会在送出前把802.1Q Tag剥掉把原始帧还给PC-B。PC-B看到的帧和普通局域网帧一模一样这也说明Tag是只在交换机之间使用的信封不是直接给终端看的内容。3.5 跨VLAN时trunk上的报文走向换成PC-A要访问某个VLAN20的服务器单臂路由场景。PC-A发出目标MAC为网关MAC的帧网关在路由器上。SW-A把帧从trunk口送到路由器路由器在物理接口下划分子接口其中一个子接口封装了VLAN10的Tag另一个子接口封装VLAN20的Tag。路由器收到Tag为10的报文剥掉Tag后做路由然后从封装VLAN20的子接口发出重新打上Tag为20SW-B收到后查MAC表在Access口剥离Tag发给服务器。这个过程中trunk上一个方向可能同时跑着两种Tag的流量交错出现但交换芯片只认VID天然在二层就做了分流。所以trunk的设计看起来简单却是多VLAN环境能够成立的基石。4. 配置trunk的标准动作与避坑点4.1 手工配置trunk的最基本步骤配置命令以某主流企业交换机的命令行风格为例不同品牌关键字略有差异但思路通用# 进入互联端口 interface GigabitEthernet0/0/1 # 强制指定trunk模式 switchport mode trunk # 只放行需要的VLAN而不是默认全放行 switchport trunk allowed vlan 10,20 # 设置一致的native VLAN建议使用业务不用的值 switchport trunk native vlan 999 # 关闭动态协商避免对端接入后自动成为trunk switchport nonegotiate exit逐条讲一下意图第一行是进入接口第二行是让端口进入trunk模式第三行如果只写“switchport trunk allowed vlan 10,20”部分设备会理解为覆盖原有列表把之前默认允许的所有VLAN替换成10和20这样能缩小风险面第四行是native VLAN的调整两端必须一致第五行是关闭端口自动协商。很多人只记得第二行后面三行全漏结果就是上线后隔壁端口一插把这个口协商成了trunk安全基线直接破了。4.2 链路聚合下的trunk从一根线到一组口当单条物理链路带宽不够比如跑监控回传1Gbps已经接近打满就需要把多根物理线捆成一个逻辑trunk。企业里一般用链路聚合协议如LACP来协商成员口两端把物理口加入同一个聚合组组内接口配置保持一致。链路聚合后的逻辑端口依然可以作为trunk口来使用VLAN标签规则不变只是负载分担变成了基于源目MAC、IP等哈希算法。这里有个容易被忽略的坑聚合组里所有成员口的VLAN配置必须一致。某次我排查一个链路聚合故障发现有一个成员口之前被单独执行过“allowed vlan remove”其他成员口放行的VLAN比它多结果部分VLAN的流量在这个成员口上被丢而LACP协议层面还显示正常业务却时断时续。后来排查到这个问题时我人都愣住了。所以链路聚合配置完一定要用统一命令批量应用不要手工单个口去改。4.3 接口模式选型与Access的搭配接入终端、PC、IP电话这类设备接口一定是Access模式并且PVID要设成该业务VLAN交换机互联、路由器和三层设备对接才用Trunk模式。在实际项目中有不少人把上行口设成Access结果VLAN跨不了交换机或者更糟把终端的口设成Trunk终端发出的无Tag帧只能落在Native VLAN上业务全乱。还有一种情况是直接在Trunk口下又加了一句“switchport access vlan 10”这种混写会让端口同时拥有Access和Trunk属性部分设备会有优先级差异极易引发注意不到的丢包。所以配置前先想清楚这个端口要接的是什么角色Access还是Trunk不要写两套参数。5. 常见问题与排查方法实录5.1 跨交换机不通但本地联通一切正常典型现象PC-A能ping通本交换机同网段设备但ping不通对端设备。我习惯按这个顺序查看物理链路和协议状态是否都Up确认互联端口确实是trunk模式查看trunk放行的VLAN列表是否包含业务VLAN检查两端Native VLAN是否一致抓包确认线上帧是否带Tag且VID正确再查MAC表看目标MAC是否学到以及从哪个接口学到的。很多人一上来就ping目标IP发现不通就去调IP这是在错误的方向上浪费力气。二层跨交换机通信本质上是找MAC表项IP只是包装壳。如果MAC表项缺失多半是VLAN或Tag的问题调IP没用。这里还要补一句如果使用远程SSH、Telnet管理交换机排查时尽量不要在这些互联口上同时做变更以免管理通道被破坏最好带Console或独立带外管理否则一旦配置错误你连设备都进不去了。5.2 trunk的Allowed列表“看起来没问题”但业务就是不通我遇过一个很典型的隐蔽故障有人在交换机上用命令把某些VLAN从Trunk口移除操作时误把目标VLAN也一起移除了后来加VLAN又没有指定正确接口业务VLAN在Trunk口没有放行。表面看Trunk口状态Up协议也UpMAC表里却始终学不到远端MAC。这类问题用一句话总结Trunk的放行列表是白名单不是显式放行的VLAN一律不会转发到对端。排查时最好的方法是直接执行查看命令查看类似“Allowed VLAN on trunk”的字段一条一条和业务VLAN清单对。如果有自动化的网络管理平台还可以定时比对基线避免人工漏配。另外要小心命令的覆盖语义。某些设备上switchport trunk allowed vlan add 10,20是在原有列表里追加而直接写switchport trunk allowed vlan 10,20可能直接覆盖整表。这种细微差别会导致你原本放行了VLAN1-100结果补一条10,20反而把100以后的VLAN全删了。操作前先查清设备的命令行为不要把“以为”当成“事实”。5.3 Native VLAN不一致一切看起来正常广播却四处乱跑故障表现比较怪大体能通但偶尔有设备掉线抓包发现很多本不该出现的广播报文跨了VLAN。这种经常就是两端Native VLAN对不上。因为Trunk口本来对Native VLAN不打标签A端发出来的是无标签帧B端把它理解为自己的Native VLAN一旦两个VLAN不同隔离就被打穿。安全视角更要重视如果Native VLAN设为默认的VLAN1且Trunk放行列表包含VLAN1那么当一个Trunk口连接了不受信任的设备时登录VLAN1的设备可能被利用。双标签攻击的原理前面说过攻击者在Access口发一个带有两层标签的帧交换机剥掉外层Tag后剩下内层Tag在Trunk上继续传播可能直达攻击者指定的VLAN。防御措施有三条把Native VLAN改成未使用的黑洞VLANTrunk放行列表别包含Native VLAN和其他敏感VLANTrunk口上禁用动态协商。这三条说起来简单但很多运维体系里一直没有落地。5.4 抓包验证在Trunk上按帧里的Tag还原真相如果怀疑Tag有问题最可靠的办法是抓包。准备一台笔记本接在支持端口镜像的交换机上把镜像源设成出问题的trunk口然后在笔记本上抓包。抓到以后会看到帧头里有一个“802.1Q Virtual LAN”的字段里面能看到priority、DEI、ID等信息。如果业务VLAN10那么该字段的ID应该是10如果看到ID0或其他值说明VLAN标记异常。要注意抓包器看到的帧长度会变成1522字节而不是普通以太网的1518字节如果抓包软件默认显示1518以下才算以太网帧需要调整过滤条件。另外交换机的镜像口本身如果在Access模式下可能又会把Tag剥掉再转发给笔记本最终看不到Tag。所以镜像口要配置成类似Trunk或专用镜像模式别在镜像口上再套一层Access转换。这是我当年踩过的一个坑看到抓包里全是Plain帧还以为Trunk根本没加Tag差点带偏排障方向。5.5 MTU与Jumbo帧大包丢了小包却健步如飞二层Trunk的Tag会让最大帧长度增加4字节很多二层交换机内部都忍得了这个MTU但一旦跨三层口、VXLAN这类封装场景额外头部会带来连锁反应。典型故障是小包、普通TCP网页能打开但数据库备份或大文件传输频繁卡死ping大包测试却能稳定复现。这时要检查接口MTU是否不小于1518/1522字节三层路由口上还要考虑路径MTU发现与TCP MSS问题。一个简单有效的排查测试是从终端连续ping大尺寸的包比如带1472字节载荷加上IP头20字节ICMP头8字节正好1500再依次递增看哪里开始分段或丢包。如果加上Tag后的帧被物理传输层卡住MTU调整往往立竿见影。不过别一上来就全局开Jumbo大帧会带来碎片化和兼容性问题建议只在必要链路或业务VLAN里开。6. 安全加固与个人经验备忘6.1 让Trunk口“少而窄”安全上有个原则叫最小化暴露面。Trunk口只应该出现在需要多VLAN互通的设备之间如交换机互联、路由器和核心交换机之间。对终端的口一律Access不给它动态协商的机会。Trunk的Allowed VLAN只放行业务必需的那些VLAN别图省事让它跑所有VLANNative VLAN改成不承载业务的黑洞VLAN如果设备支持还可以启用MAC地址表安全、风暴抑制、端口安全等策略这些都值得写成基线模板。6.2 我实际配置中踩过的几个坑第一次配Trunk时我按照教科书把两头都设成Trunk结果发现链路是Up了但跨交换机VLAN10就是不通。慢工细活一查原来两台设备默认的Native VLAN分别是1和999靠动态协商把链路变成了Trunk但Native VLAN不一致无标签的VLAN1流量被对端归到999管理用的地址不在一个网段设备直接失联。后来我把两端Native VLAN统一成业务无关的VLAN999再手动固定模式重启后一切正常。从此我养成了习惯任何涉及Trunk的变更都会在配置前同时截屏两端的当前状态变更后立刻验证绝不留“等会儿再看”的尾巴。还有一次某项目为了防环把核心交换机互联口上加了禁用生成树的功能结果某个设备上又启用了一个协议和Trunk联动临时出现环路。所以配置Trunk时STP、边缘端口、协商模式这些参数要一起想不能只顾着VLAN和Tag。链路层的事情永远是一套组合拳单点配置再漂亮也不行。6.3 后续还能怎么扩如果你已经掌握了单条Trunk的通信过程接下来可以试试链路聚合下的Trunk、VXLAN对Trunk标签的封装、以及带无线管理VLAN的混合场景。现代网络里“一条Trunk带多个VLAN”依然是基础但VXLAN、SDN这些新协议会在这个基础上做更多抽象。掌握扎实的二层Tag基础再往上走就不慌。做了这么多年网络我越来越觉得trunk这个功能像一门基础手艺听起来简单但能顺溜地把它讲清楚、排查明白的人并不像看上去那么多。它的价值不在于那条链路本身而在于它把VLAN从单台设备的孤岛中解放出来让整个局域网的二层拓扑真正变得可设计、可扩展。每次网络出问题我第一反应都是先看trunk状态、看allowed列表、看native VLAN这套习惯救了我不止一次。
阅读完成 · 觉得有帮助？
