接手过公司网络维护的朋友应该都有过这种体验:明明交换机配置看着没问题,终端就是不通;明明都划在同一个VLAN里,打印机一换楼层就失联。这类问题十有八九出在VLAN划分和Trunk链路这两个基础但极其关键的环节上。VLAN用来隔离广播域、划分业务逻辑,Trunk用来让跨交换机、跨设备的多个VLAN共享一条物理链路传输,两者配合,才构成园区网、办公楼网络甚至数据中心二层网络的骨干骨架。
这篇文章用实际项目的方式,从VLAN的设计初衷、802.1Q标签结构、Access口和Trunk口的本质区别讲起,再完整走一遍从拓扑规划、VLAN创建、物理端口划分、Trunk链路搭建到跨VLAN通信的配置过程,最后集中整理我这些年排障过程中反复踩过的一些坑。不管你是刚接触交换网络的入门工程师、准备系统梳理二层技术的考证党,还是被现场网络故障折磨的运维人员,这篇内容都值得花十几分钟从头读到尾。
1. VLAN到底在解决什么问题:从广播域拆分的角度理解设计初衷
1.1 没有VLAN的时代:一台交换机和一个不断膨胀的广播域
先回到最朴素的场景。假设一栋办公楼里只有一台交换机,财务、人事、研发、行政所有部门的电脑全部插在这台设备上。这台交换机工作在二层,它不懂IP地址,更不认识“哪个终端属于哪个部门”,它只知道MAC地址,并在MAC地址表的基础上完成帧的转发。
问题来了:当某个终端发出广播帧(比如ARP请求,询问某个IP地址对应的MAC地址)时,交换机会把这个帧从这个端口复制到除源端口之外的所有端口,因为交换机天生不知道目标设备在哪里,只能向全网广播。理论上,这个广播域包含了这台交换机上的所有终端。终端数量少的时候没感觉,一旦增加到几百台,广播帧的洪泛量会呈指数级上升,终端的CPU被大量无效广播包占用,网络时延明显增大,严重时直接“广播风暴”。这就像一个小会议室同时挤了几百号人,每个人都在大喊“谁叫某某某”,现场没人能听到有效信息。
所以VLAN最核心的价值,就是把一个物理上连接在一起的交换机端口,按逻辑划分成多个互相隔离的广播域。VLAN 2里的广播帧,不会被转发到VLAN 3去。每个VLAN是一个独立的二层广播域,不同VLAN之间默认不能直接二层互通。这相当于把拥挤的小会议室分成十几个小隔间,每个隔间的人只在本隔间喊话,噪声问题瞬间解决。
1.2 部门逻辑与网络逻辑的对齐:VLAN划分不仅是技术问题
实际项目里,VLAN划分从来不是随便拍脑袋的事。最常见的原则是“按业务功能或部门边界划分”。财务部门需要严格控制访问权限,单独划一个VLAN 10;人事部门的敏感数据较多,划VLAN 20;研发部门需要互相之间大量通信,划VLAN 30;行政与访客网络划VLAN 40。这套逻辑的价值体现在两个层面:
一个是安全层面。不同VLAN二层隔离之后,终端无法直接发起ARP欺骗、二层广播探测等攻击。就算某个部门的一台电脑中了病毒,它的二层影响范围也被限制在自己的VLAN内部,不至于瞬间传染全网。另一个是管理层面。网络策略、DHCP地址池、ACL访问控制、QoS优先级都可以按VLAN维度去下发。比如VLAN 40是访客网络,可以直接在网关上做精细化限速和访问互联网白名单,而VLAN 10内部则不允许访问VLAN 30的任何网段。没有VLAN之前,这些策略只能一台一台终端去配置,运维量完全不可接受。
一个容易忽视的细节是VLAN编号规划。虽然802.1Q标准支持4094个VLAN(VID范围1到4094),但我们需要在项目初期就形成一套固定的编号习惯。比如我经手的项目里常用:VLAN 1保持默认不动但尽量不承载业务,管理网段用VLAN 100,服务器区用VLAN 200,终端办公区从VLAN 10开始按部门递增。养成习惯之后,一看到标签就知道这个区域是什么角色,排障速度能快不少。
1.3 802.1Q标签结构:读懂4字节,相当于看懂Trunk的一半
VLAN要在一根物理线缆上传输,就必须在以太网帧里写入一个“身份标识”,否则对端交换机无法分辨这个帧属于哪个VLAN。这个标识机制就是IEEE 802.1Q标准。大多数人只记得“QinQ”“单标签”“双标签”这些名词,却忽略了标签本身的细粒度结构。
标准的802.1Q标签插在源MAC地址和Type/Length字段之间,长度4字节,共32比特。其中前16比特是Tag Protocol Identifier(TPID),固定为0x8100,用来告诉交换机“这个帧带VLAN标签”。后16比特里,前3比特是Priority Code Point(PCP),提供0到7的优先级,用于QoS;中间1比特是Drop Eligible Indicator(DEI),早期叫Canonical Format Indicator(CFI);最后12比特才是真正的VLAN ID,即VID。12比特的取值范围是0到4095,其中0和4095被保留,所以实际可用的VID范围是1到4094。
有个细节很多人容易弄混:TPID 0x8100并不一定是唯一值。在一些大型园区网或者运营商网络中,会看到0x88A8或者0x9100,那是QinQ和某些厂商私有的标签标识。所以在配置Trunk或者抓包排查时,别一看到不是8100就以为出故障了,得先确认整个网络的标准是否统一。
抓包看VLAN标签的时候,Wireshark会在Ethernet II层的Type字段处直接展开显示802.1Q Virtual LAN信息,能看到priority、DEI和ID三项。实际排障中,我最常做的事情就是在链路两端同时抓包做对比:如果交换机A发出的是Tagged帧,到了交换机B变成了Untagged,那一定是链路中间有端口把标签剥掉或PVID配置不一致导致的,这种问题只看配置不一定能发现,但抓包一看就原形毕露。
2. Trunk链路的工作原理:一台交换机如何在一根线上传输多个VLAN
2.1 Access口和Trunk口的本质区别:从“归属”到“通道”
不少刚入门的朋友容易把端口类型理解成“VLAN大小”,其实不是。Access端口和Trunk端口不是识别VLAN能力强弱的区别,而是接口工作模式的本质差别。
Access口一般用于连接终端(PC、打印机、IP电话等),它只属于一个VLAN,这个VLAN被称为Access VLAN或PVID。Access口在收到不带标签的普通帧时,会打上这个默认VLAN的标签后进入交换机内部处理;在往外发帧时,如果帧的VID等于Access口的PVID,会把标签剥掉再以Untagged形式发送给终端。对终端来说,它完全感知不到VLAN标签的存在,这就是“Access口视频净输出干净帧”的原因。
Trunk口则不同,它用于交换机与交换机之间(或交换机与路由器、防火墙等上层设备之间)的链路,目的是让多个VLAN共享同一条物理链路传输。Trunk口默认情况下的行为是:收到带标签的帧后,检查帧里的VID是否在Allowed-VLAN列表里,如果允许就接收处理;如果不允许就丢弃。在发送方向,Trunk口会根据配置决定哪些VLAN的帧以Tagged形式通过,哪些以Untagged形式通过。
这里的核心概念是Tagged和Untagged的组合。比如一条Trunk链路上,VLAN 10的帧全部带802.1Q标签通过,VLAN 20的帧也带标签通过,互不干扰;但Native VLAN(通常默认是VLAN 1)的帧则以Untagged身份在线缆上传输。如果两端Native VLAN配置不一致,就会发生经典故障,我到了第4部分会展开讲。
2.2 Tagged与Untagged的语义判断:每一帧到了对面怎么识别
理解Trunk,最关键是搞清楚帧在进入交换机之前和离开交换机之后,带不带标签这件事。为了把问题说透,我画个文字逻辑链路:
假设终端A连接交换机的Access口,Access口的PVID是10。终端A发出一个普通无标签帧,交换机接收后立即打上VID=10的标签,查MAC地址表后往某个Trunk口转发。Trunk口检查自己的Allowed列表,确认VLAN 10是允许通过的,于是保留帧上的VID=10标签,从物理链路发出去。对端交换机的Trunk口收到这个带标签帧,检查VID=10在自己的Allowed列表里,允许接收,再查MAC地址表往目标Access口转发。在目标Access口发出前,发现该口的PVID=10,与帧的VID一致,于是剥掉标签,终端得到一个干净普通的以太网帧。
整个过程的关键点在于,Trunk链路上帧的身份是靠VID标签维持的,Access口则负责完成“打标签”和“剥标签”的动作。所以一个VLAN在跨交换机传输时,在中间Trunk链路上一定是以Tagged形式存在。如果这个帧在Trunk链路上被剥掉了标签,接收端交换机只会上送PVID对应的VLAN或直接丢弃,导致二层转发失效。
PVID(Port VLAN ID,端口默认VLAN标识)与VLAN ID不是同一概念,但很多人把它们混淆。PVID是端口的一个属性,即“端口上收到的不带标签的帧被划分到哪个VLAN”。Access口、Trunk口、Hybrid口都有PVID,只是行为不同。Trunk口的PVID通常对应Native VLAN,默认交换机厂商普遍设置为VLAN 1。虽然Native VLAN可以不承载业务流量,但建议始终保持两端一致,且不要把它当作业务VLAN去用。
2.3 单臂路由与三层交换演进:Trunk如何衔接跨VLAN通信
VLAN是二层隔离的,如果两个VLAN之间需要通信,必须有三层网关参与。早期最常见的是单臂路由方案:路由器只用一个物理接口接到交换机上,交换机的这个接口配置为Trunk,允许多个VLAN通过;路由器上为每个VLAN创建一个子接口,比如GigabitEthernet0/0.10对应VLAN 10,.20对应VLAN 20,并分别配置IP地址。PC的网关指向对应子接口的IP。这样,VLAN 10的终端要访问VLAN 20的终端,会先把帧发给自己的网关(VLAN 10子接口),路由器剥掉VLAN 10标签后查路由表,再从VLAN 20子接口发出,重新打上VLAN 20标签交给交换机。所有跨VLAN流量都在路由器上走一圈,实现方式简单直观,适合小型网络。
但单臂路由有两个明显痛点:一是所有跨VLAN流量都挤在同一条物理链路和同一个路由器接口上,容易成为瓶颈;二是路由器转发依赖CPU,性能上限低。在园区网络里,更常用的是三层交换机方案。三层交换机在硬件层面集成了路由转发能力,交换机内部创建VLANIF接口(比如interface Vlanif 10,IP地址192.168.10.1/24),VLANIF接口就是这个VLAN的三层网关。同一台三层交换机上的VLAN 10和VLAN 20之间做路由转发时,不需要把流量发到外部设备,直接在交换机内部芯片完成,线速转发,性能和可靠性比单臂路由高一个量级。
不过要注意的是,三层交换机默认只对VLANIF接口所在VLAN的流量做本地路由,并不会自动把路由信息宣告到整个网络。如果网络里有多台三层设备,需要在设备上配置动态路由协议(如OSPF)或静态路由,让不同位置的三层网关知道非本地网段的路由信息。很多项目里的“配置了VLAN但跨交换机ping不通”往往不是二层问题,而是三层路由缺失或路由回程有问题。
3. 配置实操全过程:从零搭建一个小型园区网实例
3.1 拓扑规划与VLAN编址设计
模拟一个小型办公网络的组网:一台核心三层交换机(命名为Core-SW)下挂两台接入交换机(命名为Access-SW1和Access-SW2),三台设备之间通过光电混合链路或普通千兆电口连接,链路跑Trunk。终端侧:Access-SW1下接财务部门电脑,Access-SW2下接研发部门电脑,另外有一台服务器直接接在核心交换机上。
划分如下:
| VLAN ID | 用途 | 网段 | 网关 |
|---|---|---|---|
| VLAN 10 | 财务部终端 | 192.168.10.0/24 | 192.168.10.1 |
| VLAN 20 | 研发部终端 | 192.168.20.0/24 | 192.168.20.1 |
| VLAN 30 | 服务器区 | 192.168.30.0/24 | 192.168.30.1 |
| VLAN 99 | 管理VLAN | 192.168.99.0/24 | 192.168.99.1 |
所有接入交换机的管理地址放在VLAN 99里,方便后续远程维护。Trunk链路只放行与业务相关的VLAN,不放行VLAN 1(这个细节后面讲)。
3.2 接入交换机完整配置:VLAN创建、Access划分与Trunk对接
以主流企业级设备风格为例,用命令展示过程。在Access-SW1上:
system-view vlan batch 10 99 interface GigabitEthernet0/0/1 port link-type access port default vlan 10 interface GigabitEthernet0/0/2 port link-type access port default vlan 10 interface GigabitEthernet0/0/24 port link-type trunk port trunk allow-pass vlan 10 99这段配置的含义:创建VLAN 10和VLAN 99;Ge0/0/1和Ge0/0/2划为Access口,默认VLAN是10,连接财务终端;上联核心的Ge0/0/24设为Trunk口,只允许VLAN 10和99的帧通过。
关键设计点有两个。第一,Trunk口的Allowed列表要收得紧,不要写port trunk allow-pass vlan all。默认的VLAN 1在标准实现里总是被允许的,但业务流量各走各的,管理流量走VLAN 99,完全没有把VLAN 1放进中继列表的必要。第二,Trunk口的Native VLAN建议保持默认VLAN 1,并且在两端保持一致。如果你的网络确实需要改Native VLAN,一定要确保链路两端的Native VLAN号码一致,否则会导致VLAN标记不一致的帧被静默丢弃。
Access-SW2的配置逻辑类似,只是把default vlan改成了20。如果Access-SW2下面还接了支持VLAN的IP电话,通常电话和PC共享一个物理口,还会用到Voice VLAN概念,这里不展开。
3.3 核心交换机配置:Trunk汇聚与VLANIF三层网关
在Core-SW上,先从二层角度完成VLAN创建和Trunk对接:
system-view vlan batch 10 20 30 99 interface GigabitEthernet0/0/1 port link-type trunk port trunk allow-pass vlan 10 99 interface GigabitEthernet0/0/2 port link-type trunk port trunk allow-pass vlan 20 99 interface GigabitEthernet0/0/3 port link-type access port default vlan 30这里唯一要强调的是,Trunk两端的Allowed列表不需要完全一致,只需要保证链路两端对同一个VLAN都有“放行”配置。比如Access-SW1的Trunk放行了VLAN 10和99,Core-SW对接这个端口时也应放行VLAN 10和99;如果两端放行列表不一致,会导致部分VLAN的帧被静默丢弃。
接着配置VLANIF三层接口:
interface Vlanif 10 ip address 192.168.10.1 255.255.255.0 interface Vlanif 20 ip address 192.168.20.1 255.255.255.0 interface Vlanif 30 ip address 192.168.30.1 255.255.255.0 interface Vlanif 99 ip address 192.168.99.1 255.255.255.0VLANIF接口IP就是各VLAN终端PC的网关。终端侧设置IP地址和网关后,VLAN 10的PC与VLAN 20的PC之间通信时,会把数据包发到对应网关,核心交换机直接查路由表做三层转发。
很多人配置完发现“跨VLAN能通,但只有单向能通”,一般是终端网关配置错误。比如VLAN 10的PC把网关误写成了192.168.30.1,数据包出得去,回程包到了核心交换机后查路由发现目标地址在VLAN 10,转发到VLAN 10没问题,但PC自己的ARP表一直找不到正确网关MAC,导致看起来“只能出去不能回来”。这类问题排查时先看终端ARP表,再看看默认网关地址,比盯着交换机配置找半天高效得多。
3.4 配置验证五板斧:display、ping、抓包与MAC表联查
配置完成后,不要急着说“搞定”,把验证命令走一遍才是负责任的交付方式。我最常用的验证顺序如下:
第一板斧:检查Trunk端口状态。在Core-SW上执行display interface GigabitEthernet0/0/1或display port vlan,确认端口类型是trunk、允许VLAN列表正确、链路物理状态up。这一步能发现端口shutdown、光模块速率协商异常等物理层问题。
第二板斧:检查VLANIF接口是否生效。执行display ip interface brief,看VLAN 10、20、30、99的IP地址是否正常up。如果显示down,说明该VLAN内没有任何物理端口处于up状态,或者VLANIF接口没有被正确创建。
第三板斧:从核心交换机ping各VLAN网段的网关地址。比如ping 192.168.10.1。能通说明核心自身的三层接口没问题。
第四板斧:用终端PC做实测。把PC配置好静态IP或者通过DHCP获取地址后,在PC上ping 网关、ping 跨VLAN的服务器IP。这一步是整个配置真正“落地”的证明。
第五板斧:在交换机上查MAC地址表。执行display mac-address或按VLAN过滤,确认终端MAC出现在对应的VLAN条目下。如果MAC地址表里终端MAC以错误VLAN出现,大概率是Access口PVID配错了。
关于抓包,在便携笔记本上接一个镜像口或者串联一个傻瓜交换机做端口镜像,把Trunk链路上的包抓下来,确认Tagged帧的VID符合预期。这个操作最直观,也最能定位那些“配置看起来都对但就是不通信”的诡异问题。
3.5 不同厂商设备命令差异对照
前文用的是通用风格命令,实际上各家设备命令行有不少差异,这里整理一份对照表,方便参考:
| 操作内容 | 华为风格示例 | 思科风格示例 |
|---|---|---|
| 创建VLAN | vlan batch 10 20 | vlan 10 / vlan 20 |
| 设置Access口 | port link-type access / port default vlan 10 | switchport mode access / switchport access vlan 10 |
| 设置Trunk口 | port link-type trunk / port trunk allow-pass vlan 10 | switchport mode trunk / switchport trunk allowed vlan 10 |
| 修改Native VLAN | port trunk pvid vlan 99 | switchport trunk native vlan 99 |
| 创建VLANIF | interface Vlanif 10 | interface vlan 10 |
| 查看端口VLAN | display port vlan | show vlan brief / show interfaces trunk |
千万别在华为设备上敲switchport,也别在思科上敲port link-type,这属于最基础的“门牌号认错”问题。很多远程交付项目中,工程师把截图发过来,我第一眼就能看出是哪家设备的命令行风格,一旦混用,命令直接被拒绝或者产生完全相反的配置效果。
4. 真实排障案例:VLAN与Trunk问题定位全过程
4.1 经典故障:Trunk两端Native VLAN不一致导致部分VLAN“通一半”
现场情况:某公司一台新接入交换机加入机房,上联Trunk配置好之后,VLAN 10的终端互通正常,VLAN 20的终端却一直没有响应。配置对比显示,接入交换机Trunk口的Native VLAN被改成了99(为了“管理方便”),而核心交换机Trunk口的Native VLAN还是默认的VLAN 1。
这里发生的底层逻辑是:对于Trunk口上PVID对应的Native VLAN,端口在发送时会把该VLAN的帧剥离标签,以Untagged形式发给对端。接入交换机以Untagged发送VLAN 99的管理帧,核心交换机收到时以为这是VLAN 1的Untagged帧,于是把VLAN 99的管理流量当成VLAN 1流量处理。而对端如果一直在等Untagged的ARP响应,发现帧里根本找不到原生VLAN 1的预期内容,管理通道静默失效。
解决方案很简单:把两端Trunk口的Native VLAN改成一致,或者接入交换机的Trunk口Native VLAN改回VLAN 1。我之前处理过一个持续两小时故障的根本原因就是这个,排查过程中一直盯着Allowed列表和PVID看,忽略了Native VLAN这个“隐藏属性”。
4.2 终端能获取IP却无法跨VLAN访问服务器
另一个高频现象:PC通过DHCP获取到了192.168.10.0/24网段的IP,也能ping通网关,但无法访问192.168.30.0/24网段的服务器。
按照三层转发的思路排查,问题通常不在二层Trunk上,而是核心交换机缺少到服务器区的路由。如果核心交换机上VLANIF 30的网关是192.168.30.1,PC的网关是192.168.10.1,那么PC访问服务器时数据包先到192.168.10.1,核心交换机查路由表发现192.168.30.0/24是直连网段,直接转发,这种情况大多能通。如果服务器不在核心交换机直连网段里,而是在更后面的防火墙上,就需要看核心交换机是否有默认路由或静态路由指向防火墙,防火墙又是否有回程路由指回核心交换机。
排查思路:先在核心交换机上display ip routing-table看目标网段是否存在,再看下一跳是否正确。曾经遇到过一次问题,核心交换机有指向防火墙的默认路由,但防火墙上没有回程路由,结果是PC到服务器方向通,服务器回包方向丢。当时花了很长时间排查二层Trunk,实际上问题根本不在二层。
4.3 打印机换位置后就失联:Access口PVID与MAC表混乱
某项目里一台打印机从Access-SW1的Ge0/0/5挪到Access-SW2的Ge0/0/8,但Access-SW2的Ge0/0/8被误配成了VLAN 20,打印机原始配置在VLAN 10。打印机本身不支持VLAN配置,发出的帧不带标签,Access-SW2收到后给它强打了VLAN 20的标签,于是打印服务器(在VLAN 10)完全收不到打印机的心跳包,检查交换机MAC地址表发现打印机的MAC列在VLAN 20条目下。
这种问题在维护不规范的网络里很常见。处理方法是把新接入打印机的端口重新划入VLAN 10,同时清理交换机上对应的MAC地址表老化条目。另外,建议给打印机、IP电话这类设备单独规划固定接入端口表,端口变更走变更流程,不要图省事乱插。设备一插错VLAN,就可能在同一个广播域里产生大量ARP混乱,影响范围甚至超过那台打印机本身。
4.4 广播帧泛洪异常与环路风险
Trunk配置正确不代表万事大吉。曾经排查过一个网络时延极高的问题,在整个二层拓扑里抓包发现大量重复广播帧在Trunk链路上来回传递。原因是某台接入交换机下面的两个端口中误接了一根网线形成二层环路,STP又被人为关闭了。广播帧在环路里不断泛洪放大,最终把Trunk链路带宽耗尽。
配置Trunk时一定要确认整张二层拓扑里STP是正常运行的。很多设备默认全局开启STP,但个别端口如果配置了边缘端口且关闭了STP,又恰好有人插了网线形成环路,就会立刻出问题。我的习惯是:所有接终端的Access口配成STP边缘端口,所有接交换机的Trunk口保持STP计算状态。这样既能让终端快速上线,又能防止交换机间链路环路。
4.5 问题速查表:二层网络排障关键点汇总
| 现象 | 优先排查点 | 检查命令/方法 |
|---|---|---|
| 单个VLAN内终端不通 | Access口PVID配置是否正确、终端是否接入正确端口 | display port vlan / display mac-address |
| 跨交换机同VLAN不通 | Trunk口Allowed列表、Native VLAN一致性 | display interface trunk / display port vlan |
| 跨VLAN无法通信 | 三层VLANIF接口是否存在、路由表是否齐全 | display ip interface brief / display ip routing-table |
| 终端获取不到IP地址 | DHCP服务器所在VLAN与Trunk放行列表、PC网关配置 | 抓包 / display dhcp snooping(如开启) |
| 全网广播风暴 | STP状态、是否存在环路、Trunk泛洪端口 | display stp brief / 端口流量统计 |
| 打印机/IP电话失联 | 接入端口默认VLAN是否正确、MAC地址表学习到哪个VLAN | display mac-address / 按MAC查端口 |
排查时一个容易忽略的步骤是检查MAC地址表。有一次我在接入交换机上怎么都找不到终端MAC,后来发现终端接的是一台傻瓜交换机,傻瓜交换机再上联到接入交换机。终端MAC会从傻瓜交换机上联口学习到,但在接入交换机里它出现在上联口的MAC表项中,这需要结合“下联一个傻瓜交换机”的拓扑常识去理解,否则容易误判为终端不在线。
5. 一些值得长期保留的习惯与调试心得
写这段是因为VLAN与Trunk虽然基础,但很多网络问题的根因恰恰是基础配置的某个不起眼细节。根据我个人的排查经验,有几个习惯建议尽早建立起来。
第一,把“配置前的快照”当成必须步骤。每次改交换机配置前,先执行display current-configuration保存一份到本地,或者用设备的配置归档功能。哪怕只改一个端口,出了意外都能快速回退。我就曾经在一次批量配置中把几十个端口的PVID全部改错,如果没有配置快照,现场恢复可能要一整天。
第二,Trunk链路的Allowed列表尽量保持最小化。只放行业务VLAN,不要图省事放行所有VLAN。这个习惯有几个好处:广播域可控、安全边界可控、故障影响范围可控。一次VLAN配置错误引发的广播流不会跑到不该去的链路上。
第三,管理VLAN单独规划,不要和业务VLAN共用一段地址。管理VLAN专门承载网络设备的管理流量(SSH、SNMP、网管平台),有利于安全策略下发和流量隔离。管理VLAN的网关建议只在核心设备或专门的网管设备上配置,不要在接入交换机上配置,避免不同网关对管理路由的争抢。
第四,排查二层故障时,抓包优先级高于看配置。很多配置“看起来一致”但实际行为不一致,抓包能直接看到帧进出一个端口时带不带标签、VID是什么,是不是Native VLAN被错误剥离了标签。在Trunk链路中间串联一个纯二层交换设备,打开端口镜像抓包,是排障的终极手段。
这类基础知识的价值,往往要到重大故障时才能真正体现出来。VLAN的划分逻辑决定了网络的安全边界,Trunk的配置正确性决定了跨设备二层通信的稳定性,两者叠加在一起,就是整个园区网络稳定运行的基石。希望这篇内容能帮你把这部分基础挖得更深一些。