EVE-NG实战：802.1Q VLAN标签抓包与单臂路由详解

如果你只是想把VLAN实验在EVE-NG里“敲通”，那链路其实很短：建两台交换机、划两个VLAN、端口一配，ping通就算完事。但我一直觉得，网络实验的价值不在“通”，而在“看清”。同样一条ping命令，你在PC的接入链路上抓包，和在交换机间的Trunk链路上抓包，看到的东西完全是两个世界——一个干干净净没有标签，一个被802.1Q的四字节Tag包裹得明明白白。这篇是EVE-NG流量洞察系列的第二篇，专讲802.1Q VLAN。我会用一套双交换机加单臂路由的拓扑，把同VLAN跨交换机通信和VLAN间路由的标签行为从头到尾抓给你看。不管你是备考网工认证的学生，还是被VLAN标签绕晕的运维新人，这套实测过程都能让你把“Access、Trunk、PVID、Native VLAN”这些概念从纸面落到抓包窗口里。老手也可以直接跳到第5节，那里有几个我实际踩过、也看别人反复踩的坑。

1. 先搭实验床：EVE-NG里的拓扑、镜像与Capture挂载

1.1 为什么挑IOL L2镜像跑VLAN实验

EVE-NG支持好几类节点镜像，做二层交换实验首选IOL L2（IOS on Linux），而不是Dynamips或qemu系列。原因很直接：IOL跑的是思科IOS的Linux移植版，交换特性完整，VLAN、Trunk、STP、RSTP、PortFast这些该有的都有，命令行和真机几乎一致，而且资源占用极低。我试过在一台8GB内存的EVE-NG服务器上同时跑八台IOL L2交换机加几个VPCS，CPU和内存都能压住，启动时间也就十几秒。这对反复调整拓扑、推翻重来的学习场景很重要。

Dynamips跑的是老版本IOS，纯路由器镜像为主，交换功能靠NM-16ESW这种板卡模拟，VLAN能力弱，而且每个节点单独吃CPU，拓扑稍大一点就卡成PPT。qemu类的vIOS和vEOS更贴近真机，但也更重，一台就要1GB以上内存，启动还慢，做纯二层标签观察实验属于杀鸡用牛刀。如果你手头只有qemu镜像，也不是不能用，只是没必要。

一个提醒：IOL镜像需要自己获取并打包，网上有现成的加工教程，核心是给镜像文件加上正确权限（一般是/opt/unetlab/addons/iol/bin目录下，赋755并写wrapper）。如果你在拓扑里把IOL节点拖进来后双击没反应，大概率是权限问题，去EVE-NG的终端里用/opt/unetlab/wrapper -m跑一下镜像，看报错就知道了。这个细节和实验本身无关，但卡住的人非常多，先排查掉。

1.2 双交换机加一台路由器的完整规划

这节实验的拓扑我设计成三个部分：两台二层交换机、一台路由器、四台PC。交换机之间用Trunk连接，路由器单独接在SW1上用Trunk上联，这样一套拓扑能覆盖两个核心场景——同VLAN跨交换机通信，以及VLAN间路由。

具体连线和地址规划如下：

PC的地址我统一放在两张表里，方便后面配置时对照：

为什么非得加路由器？因为只验证同VLAN跨交换机通信的话，两台交换机加PC就够了，但802.1Q最精华的部分恰恰在“标签的改写”上——帧进了路由器子接口被剥掉标签，路由后再打上另一个VLAN的标签出去。没有三层设备，这部分链路层行为就看不见。所以宁可多启动一个IOL L3镜像，也要把单臂路由这个场景加进来。

1.3 连线时就要把抓包点埋好：EVE-NG Capture的两种入口

EVE-NG里挂抓包有两种方式。第一种是在拓扑编辑界面双击链路，会弹出一个勾选项，给链路的两个端点分别开启Capture；第二种是在拓扑运行界面右键某个节点，选择某个接口再选Capture。我实际用下来，第二种更顺手，因为拓扑跑起来之后临时想抓哪条链路，不用切回编辑模式，直接在节点上操作就行。

这里有个大家容易忽略的细节：一条链路的Capture是分“端”的。比如SW1的Gi0/5连到SW2的Gi0/4，右键SW1的Gi0/5抓包，和右键SW2的Gi0/4抓包，抓到的是同一条物理链路，但因为EVE-NG底层是桥接实现，有时候会出现一端能抓到、另一端是空文件的情况。经验做法是：哪端没流量就换另一端抓，或者直接在链路属性里挂Capture，这个入口生成的抓包通常更稳。

另外提醒一点：抓包文件会存在EVE-NG服务器上，浏览器里打开的其实是通过WebSocket拉取的实时流。如果你想长期保留某个pcap，建议在Wireshark窗口里直接另存一份，或者通过EVE-NG的导出功能把pcap下载到本地。我习惯把每个阶段的抓包都单独存成文件，文件名带上场景和抓包点，比如lab2_sameVLAN_trunk.pcap，后面复盘或者写文章都不用重新跑实验。

2. 打开VLAN的开关：Access、Trunk、PVID与802.1Q标签规则

2.1 IOL交换机开局：创建VLAN和接口模式

节点启动后，第一件事是给交换机创建VLAN。进入全局配置模式，SW1和SW2都执行下面的配置：

code复制vlan 10
 name VLAN10
!
vlan 20
 name VLAN20

接着按拓扑规划配置接口。SW1的配置如下，SW2相应把Trunk口对上即可：

code复制interface range Gi0/0-1
 switchport mode access
 switchport access vlan 10
!
interface range Gi0/2-3
 switchport mode access
 switchport access vlan 20
!
interface Gi0/4
 switchport mode trunk
 switchport trunk allowed vlan 10,20
!
interface Gi0/5
 switchport mode trunk
 switchport trunk allowed vlan 10,20

注意一个IOL特有的坑：EVE-NG面板上节点显示的几个网卡口和命令行里的接口编号不是随意对应的，一般是从Gi0/0开始按顺序排。如果你拓扑里给交换机接了4条线，那这四个口就是Gi0/0到Gi0/3，后面留的空口是Gi0/4、Gi0/5。别在没接线的接口上配了半天，回头发现流量根本不走这个口。

配完之后用三个命令核对：

code复制show vlan brief
show interfaces trunk
show interfaces Gi0/5 switchport

show vlan brief看VLAN里都有哪些端口，如果VLAN 10下面的端口列表空荡荡，说明access配置没生效；show interfaces trunk看Trunk链路状态、Native VLAN和允许的VLAN列表，这是排障最常用的命令；show interfaces switchport看单个端口的详细模式，Access还是Trunk、PVID是多少，一眼就知道。

2.2 PVID不是VLAN：Access口和Trunk口对无标签帧的不同态度

PVID是Port VLAN ID，也就是端口的默认VLAN编号。它的核心作用是处理“无标签帧”的归属——当一个不带802.1Q标签的帧到达端口时，交换机就按这个端口的PVID给帧打上一个内部VLAN标记，然后再参与转发决策。这个机制理解透了，Access和Trunk的区别就迎刃而解。

Access口的PVID等于它所属的access vlan。帧从Access口进来，无标签，打上PVID对应的VLAN标记进入交换芯片；出Access口时，交换机会把VLAN标签剥掉，再以无标签形式发给终端。所以终端网卡永远不会在Access链路上看到802.1Q标签——这也解释了为什么普通PC不配置任何VLAN也能正常通信。

Trunk口的PVID默认是VLAN 1，也就是常说的Native VLAN。Trunk口对帧的处理比Access口复杂：

• 带标签的帧进来，只要VID在允许列表里，就保留标签进入对应的VLAN；
• 无标签的帧进来，被打上Native VLAN的标记，归入Native VLAN处理；
• 出方向时，Native VLAN的帧剥掉标签发送，其他允许VLAN的帧保留标签发送。

这就导致一个很多人想不明白的现象：同一台交换机，VLAN 10的帧在Trunk上带着VID 10的标签，VLAN 1的帧在Trunk上却是裸奔的。如果两台交换机的Native VLAN配置不一致，无标签帧到对端后会被归入不同的VLAN，二层转发立刻错乱，这正是后面第5节要讲的Native VLAN mismatch问题。

2.3 802.1Q那四个字节到底装了些什么

先放一个标准802.1Q帧在以太网头部的样子。普通以太网帧是“目的MAC（6字节）+源MAC（6字节）+类型（2字节）+负载”，802.1Q在源MAC和类型字段之间插入了4字节的VLAN Tag，变成了“目的MAC+源MAC+Tag+类型+负载”。

Tag里包含两块内容：

TCI里的结构我拆开说：PCP占3位，共8个优先级，用于QoS；DEI占1位，用于指示丢包优先级，旧标准里叫CFI；VID占12位，取值范围0到4095，其中0和4095保留，实际可用的VLAN ID是1到4094。

比如VID等于10，换算成二进制就是12位的000000001010，放在TCI的低12位，前面5位是PCP和DEI。抓包里如果直接看十六进制，一个VLAN 10的普通帧大概长这样：

code复制目的MAC   源MAC      TPID   TCI     EtherType
00:50:56:... 00:0c:29:...  81 00  00 0a   08 00

81 00就是TPID（0x8100），00 0a里低12位是0x00a，即十进制10，说明这是VLAN 10的帧。Wireshark会自动把这些字段解析成友好显示，但我建议你自己对照十六进制看一次，因为命令输出可以造假，抓包窗口里的原始字节不会。

还有一个值得记住的细节：VLAN Tag插在源MAC之后，而不是帧头最前面。这样设计的好处是目的MAC仍在固定位置，交换机查MAC表做转发决策时不用跳过额外字节，硬件处理效率最高。理解了这一点，你就能明白为什么VLAN标签和IP层的VXLAN、GRE封装完全是两码事——它不是包住整个二层帧，而是在二层头里“加塞”了一个字段。

3. 同一VLAN跨交换机通信：抓包看标签的加与拆

3.1 实际操作：启动回放与Wireshark联动

所有节点开机后，先确认状态：EVE-NG界面里节点图标变绿，说明系统启动完成。IOL启动比较快，路由器稍慢一点，按下开机键后等个十来秒基本都能进命令行。

给PC1和PC3配置IP。在EVE-NG里右键PC1，选择Console，会弹出一个VPCS终端窗口。VPCS的最小配置语法是：

code复制ip 192.168.10.10 255.255.255.0 192.168.10.1

回车确认后可以用show ip检查。PC3同样配成ip 192.168.10.20 255.255.255.0 192.168.10.1。配好之后先互ping一下，确保PC1和PC3能通，再去挂抓包点。我习惯先确认连通性，再开抓包，否则抓包文件里全是乱七八糟的ARP广播，分不清主次。

抓包点我挂两个：一个是PC1到SW1的接入链路（右键SW1的Gi0/0口选Capture），一个是SW1到SW2的Trunk链路（右键SW1的Gi0/5选Capture）。两个Wireshark窗口会同时弹出，然后回到PC1上执行ping 192.168.10.20，让Wireshark多抓几秒，再回到两个窗口点停止。

3.2 抓包结果对比：Access口无标签，Trunk口带VID 10

对照两个窗口的ICMP报文，结果非常直观。

PC1接入链路这个窗口里，所有ICMP Echo Request和Echo Reply都是普通以太网帧，EtherType直接就是0x0800（IPv4），没有任何VLAN标签。这是因为PC1作为终端根本不感知VLAN，它发出的帧就是原生以太网帧；SW1收到后按Gi0/0的PVID（VLAN 10）打标签完成内部转发，出Gi0/0时又把标签剥掉，所以PC1看到的永远是“干净”的帧。

SW1到SW2的Trunk链路上情况完全不同。同一个ping会话的报文出现在这里时，EtherType变成了0x8100，Wireshark显示为802.1Q Virtual LAN，展开后能看到Priority和ID字段，ID就是10。也就是说，同样一份ICMP流量，在Access链路上是无标签的，一上Trunk就被交换机加了4字节的VLAN Tag，换成VID 10的“身份证”继续传输。

这背后的转发逻辑值得细说。PC1的帧到达SW1后，交换芯片按入端口PVID标记为VLAN 10，查MAC表发现目的MAC（PC3）不在本地端口上，需要从Trunk口转发。出Gi0/5时，SW1发现VLAN 10不是Native VLAN（默认Native是VLAN 1），于是保留标签原样发出。SW2在Gi0/4收到这个带VID 10的帧，查自己的MAC表，发现PC3在Gi0/1，于是把帧转到Gi0/1，出端口是Access口，标签被剥掉，PC3收到一个干净的普通帧。整个过程，VLAN标签只在两台交换机之间的Trunk链路上“存在”。

3.3 抓包里必然出现的“意外访客”：STP、CDP与Native VLAN

如果你用默认配置直接抓Trunk，会发现一个“污染源”：STP BPDU。IOL上默认运行PVST（Per-VLAN Spanning Tree），也就是每个VLAN一个生成树实例，每个实例都单独发BPDU。结果就是Trunk链路上一会儿一个目标MAC为01:80:c2:00:00:00的BPDU帧，而且有的BPDU带标签、有的不带——不带标签的是VLAN 1（Native VLAN）的BPDU，带标签的是VLAN 10、VLAN 20的BPDU。

第一次看这个现象时我愣了一下，后来想明白了：PVST把BPDU本身也当作普通数据帧，按VLAN规则在Trunk上传输，所以VLAN 10的BPDU自然带着VID 10的标签，而VLAN 1是Native VLAN，它的BPDU就成了无人认领的无标签帧。这解释了为什么Native VLAN mismatch会造成STP异常——两边对无标签BPDU的归属理解不一致，生成树拓扑就乱了。

如果你觉得BPDU吵眼睛，实验时可以在交换机上关掉CDP和LLDP，并给连接PC的端口开PortFast：

code复制interface range Gi0/0-3
 spanning-tree portfast
 no cdp enable

这样抓包窗口里就只剩ARP和ICMP这些和实验目标直接相关的流量，分析起来清爽得多。不过我要多说一句：STP在Trunk上的表现本身就是802.1Q行为的一部分，看过一次、理解一次，比直接关掉有价值。我自己的顺序是——先开着看一遍，再关掉做后续验证。

4. VLAN间通信实测：单臂路由如何改写标签

4.1 广播域的边界：为什么VLAN 10的ARP不会出现在VLAN 20

VLAN的定义就是二层广播域。PC1要和其他主机通信，第一步是解析对方的MAC地址——如果目标和自己同网段，直接发ARP广播；如果目标不在本网段，就发ARP广播解析网关MAC，然后把数据交给网关转发。

关键在于ARP广播的传播范围。PC1的ARP请求进入SW1后，被打上VLAN 10的标签，交换机把它泛洪到VLAN 10内部的所有端口：本地Access口（PC3），以及Trunk口（SW2和R1所在链路）。PC2接在VLAN 20的Access口上，SW1根本不会把VLAN 10的帧从VLAN 20的端口转发出去。所以在VLAN 20里抓包，永远看不到VLAN 10的ARP广播——这就是广播域隔离的直观体现。

由此引出一个必然结论：不同VLAN之间要通信，必须经过三层路由。二层交换机只认MAC和VLAN，它可以把帧从Trunk送到另一台交换机的VLAN 10端口，但永远无法把一个VID 10的帧“变成”VID 20的帧再送去VLAN 20。这个“翻译”工作只能由三层设备完成。说得更生活化一点：二层交换机是楼层内的走廊，只能把你送到同楼层的房间；三层设备才是电梯，能把你的数据包从10楼送到20楼，而且到了20楼还会重新给你贴一张20楼的通行证。

4.2 路由器子接口配置：encapsulation dot1Q是唯一入口

单臂路由的经典做法是在路由器物理接口上创建多个子接口，每个子接口对应一个VLAN。R1的配置如下：

code复制interface Gi0/0
 no shutdown
!
interface Gi0/0.10
 encapsulation dot1Q 10
 ip address 192.168.10.1 255.255.255.0
!
interface Gi0/0.20
 encapsulation dot1Q 20
 ip address 192.168.20.1 255.255.255.0

这个配置里最关键的一行就是encapsulation dot1Q 10。它的意思是：这个子接口只处理Trunk链路上VID等于10的帧。带VID 10的帧到达路由器物理口后，交换芯片根据标签把帧分发到对应的子接口，同时剥掉标签；子接口把帧交给IP协议栈做三层路由。出方向则反过来：子接口决定从哪个VLAN出去，就把对应VID的标签加回去。

新手最容易犯的错误有三个。第一，物理口shutdown了。子接口的状态继承自物理口，物理口down，所有子接口无论配置多正确都起不来。第二，忘了配encapsulation。子接口如果不显式声明dot1Q封装，默认不会处理任何VLAN标签帧。第三，VLAN号写错或两个子接口写成了同一个VID，帧会被错误地送进同一个三层接口，路由表直接乱套。

另外别忘了一个前置条件：SW1连R1的那个口必须是Trunk，而且allowed vlan里要有10和20。我见过有人R1子接口配得一丝不苟，结果SW1的Gi0/4还是Access模式，标签帧根本到不了路由器。排查顺序应该是：先把交换机侧的口模式查清楚，再查路由器子接口。

4.3 抓包对比：同一条Trunk链路上两个VID的双向流量

配置完成后，在PC1上执行ping 192.168.20.10，同时挂上SW1到R1这条Trunk链路的抓包。这次看到的画面和同VLAN通信时完全不一样。

先看从PC1到PC2的方向：PC1发ARP请求解析网关192.168.10.1的MAC，这个请求在Trunk上带VID 10的标签到达R1的Gi0/0，被Gi0/0.10接收。R1回ARP应答，目的MAC是PC1，这个应答在Trunk上同样带着VID 10的标签回到SW1，SW1从VLAN 10的Access口剥掉标签交给PC1。这一来一回，PC1和网关的ARP交互全部发生在VID 10里。

PC1拿到网关MAC后，开始发ICMP Echo Request。这个帧的目的MAC是R1的MAC，VID是10，到达R1后被Gi0/0.10剥掉标签。R1查路由表，发现192.168.20.0/24直连在Gi0/0.20，于是把包交给Gi0/0.20重新封装二层头——源MAC改成R1在VLAN 20方向的MAC，目的MAC改成PC2的MAC。出Gi0/0时，这个帧被打上VID 20的标签进入Trunk链路，SW1识别VID 20，从VLAN 20的Access口剥掉标签发给PC2。

所以你在Wireshark里看到的画面是：同一段Trunk链路上，从SW1发向R1的包带着VID 10的标签，从R1发回SW1的包带着VID 20的标签。ICMP的Request和Reply分别出现在两个VLAN下。这不是什么异常，恰恰是路由器的正常工作方式——入方向剥一个标签，出方向打另一个标签。如果你在两个窗口分别抓PC1的接入链路和Trunk链路，还能发现：PC1侧看到的ICMP请求和回显全部无标签，而Trunk侧每个方向都有对应的标签版本，对应关系一目了然。

这个实验做完，我对“路由器改写MAC地址”这句话的理解从抽象变成了具体。以前总是背“路由器改变源目MAC，不改变源目IP”，抓包之后才发现，在VLAN环境里它还要额外干一件事——改VLAN标签。三层设备其实就是标签的“翻译官”。

5. 翻车现场实录：几个让实验室里最像真机的VLAN问题

5.1 Trunk allowed vlan漏配：VLAN 10的报文到底去哪儿了

现象很典型：PC1能ping通SW1上同VLAN的PC3，但死活ping不通SW2上的另一台VLAN 10主机PC3（这里指的是第二台跨交换机的同VLAN主机）。抓PC1的接入链路，ICMP Request发得欢快得很，但抓SW1到SW2的Trunk链路，半个ICMP包都看不到。

排查路径不复杂，但很多人会先怀疑STP、怀疑ARP，绕一大圈。正确顺序应该是：

code复制show interfaces trunk

看Allowed VLAN列表里有没有10和20。如果只显示VLAN 1，那问题就是Trunk放行列表漏了。执行：

code复制interface Gi0/5
 switchport trunk allowed vlan 10,20

问题立即消失。这个坑我在EVE-NG里踩过不只一次，因为IOL镜像默认的端口模式是dynamic auto，两台交换机对接时如果不强行指定trunk模式，协商结果可能不是Trunk。我现在的习惯是：所有交换机间链路和交换机到路由器的上行链路，一律显式写switchport mode trunk，不依赖任何自动协商，宁可命令多敲两行。

5.2 Native VLAN mismatch：BPDU正常，业务却不通

还有一个更隐蔽的坑：SW1的Trunk口把Native VLAN改成了10，SW2保持默认VLAN 1。配置命令如下：

code复制interface Gi0/4
 switchport trunk native vlan 10

这时候你会看到一个诡异的现象：两端Trunk状态都UP，CDP没报错，STP也在正常工作（因为BPDU走Native VLAN），但VLAN 10的跨交换机通信就是不通。原因在于：SW1认为VLAN 10是Native VLAN，所以VLAN 10的帧在Trunk上不带标签；SW2却认为无标签帧是VLAN 1，于是把这些帧归入VLAN 1处理。VLAN 10的帧到了SW2被当成VLAN 1，SW2上没有任何端口属于VLAN 1的业务，帧直接被丢弃。

反过来也一样：SW2发出的VLAN 10帧带着标签，SW1收到后看到VID 10认为没问题，但SW2发的VLAN 1帧不带标签，SW1却认为那是VLAN 10，两边对无标签帧的“翻译”完全错位。

排障命令是：

code复制show interfaces trunk

如果两端Native VLAN不一致，Cisco设备会明确提示Native VLAN mismatch。处理方式是把两端的Native VLAN统一改成同一个值（无特殊需求就保持默认VLAN 1）。这里我额外强调一句：不要把Native VLAN改成业务VLAN，除非你有明确的二层安全需求（比如Native VLAN黑洞），否则默认VLAN 1是最省心、最不容易出错的配置。这个问题的根子还是PVID的理解——Native VLAN其实就是Trunk口的PVID，收发方向都受它约束。

5.3 路由器子接口“失联”：问题往往在交换机那一侧

VLAN间路由不通时，新手的第一反应是检查路由器。但根据我的经验，问题出在交换机上行口的概率反而更高。

我在一次实验中碰到过：R1的子接口配置看起来完全正确，show ip interface brief显示Gi0/0.10和Gi0/0.20都是up/up，路由表里也有两个直连网段，但PC1 ping网关就是不回。抓路由器物理口的包，发现PC1发来的ARP请求带VID 10标签，到了路由器却被丢弃。

问题出在SW1连R1的Gi0/4口还是Access模式，而且access vlan配的是10。这样一来，从SW1到R1的链路上，VLAN 10的帧不带标签，R1的子接口Gi0/0.10只认带VID 10标签的帧，无标签帧直接丢弃；VLAN 20的帧就更惨了，从VLAN 20的Access口根本不会被转发到Gi0/4上。

处理方式很简单：把Gi0/4改成Trunk口，并放行VLAN 10和20。这引出一个通用排查方法论：从源端ping到网关，逐段抓包定位断点。第一段抓PC接入链路，确认帧已经发出；第二段抓交换机到路由器的Trunk链路，确认帧是否带正确标签到达路由器；第三段在路由器上确认接收情况。哪一段开始消失，问题就锁定在哪一段。这个“逐段抓包找断点”的习惯，在真实网络排障里同样适用。

5.4 EVE-NG抓包本身的坑：抓不到、空文件、接口名对不上

最后聊几个EVE-NG平台自身的抓包问题，这些和VLAN配置无关，但遇到一次就折腾半天。

第一，节点没开机就挂Capture，开机后有时抓不到流量。我的习惯是等节点完全启动、能ping通业务之后，再右键接口挂Capture。第二，链路双端抓包出现一端空文件。前面说过，EVE-NG底层是桥接实现，一端可能抓不到或者只抓到广播帧，此时换另一端抓即可，不用怀疑配置。第三，一个链路多个抓包窗口同时开着，IOL节点的CPU会明显飙高，影响实验稳定性。我在跑三四个抓包点时就遇到过IOL假死，后来控制在两三个抓包点以内，明显稳定很多。

还有一个经常搞混的点：如果你在拓扑编辑界面给链路开Capture，弹出来的Wireshark窗口标题里会带接口名，比如sw1_gi0_5和sw2_gi0_4，别把两个窗口的流量看反了。双击链路挂Capture时，EVE-NG会让你分别选择两端是否开启，这里的“e1”“e2”对应的就是链路两端，和你在画布上点击的方向相关。拿不准的时候，用一个简单方法验证：PC1发一个ping，看哪个窗口先出现带VID标签的帧，那个窗口就是Trunk链路上贴近PC1方向的端点。

6. 从EVE-NG走向真机和更深的坑：华为命令对照与下一步扩展

6.1 Cisco IOL到华为交换机的命令翻译表

EVE-NG里用思科IOL做实验，但国内机房和项目里华为设备非常常见。802.1Q是IEEE 802.1标准委员会的协议，不是思科私有协议，所以两个厂商之间原理完全一致，只是命令行长相不同。我整理了一张对照表，做实验时可以直接参照：

这里有个默认值差异值得单独强调：思科Trunk口默认放行所有VLAN，华为Trunk口默认只放行VLAN 1。这意味着同一份配置在两边跑，结果可能完全不同——思科上配完Trunk不用额外放行VLAN就能通，华为上必须显式port trunk allow-pass vlan 10 20。许多人从EVE-NG切到真机或者切到华为模拟器时栽跟头，都是栽在这种“默认值”差异上。热词里那句port trunk pvid vlan 10，本质就是设置Trunk口的Native VLAN，和思科的switchport trunk native vlan 10一一对应。

6.2 用同一套拓扑继续玩：VLAN Pool、基于IP子网的VLAN与IPSG

这套双交换机加路由器的拓扑，扩展余地很大。我建议接下来按这三条线继续深挖，每一个都能沿用现有节点，只需要增加少量配置。

第一，VLAN Pool。这是无线网络和DHCP场景下常见的设计：多个VLAN组成一个地址池，终端上线时从池里动态分配VLAN，实现负载均衡。在EVE-NG里可以加一台DHCP服务器或核心交换机，配置多个地址池对应VLAN 10和20，观察终端获取IP时如何被分配到不同VLAN，抓包时能看到DHCP Discover报文从无标签变成带标签的过程，很有意思。

第二，基于IP子网的VLAN划分。华为交换机的VLAN划分方式里，有一种是根据报文源IP地址来决定端口归属哪个VLAN，这在终端混接、又不能动终端配置的场景下很实用。原理上，交换机收到无标签帧后，不按PVID归类，而是先看源IP，命中某个子网规则就归入对应VLAN。在EVE-NG里用IOL不一定有完全对应的命令，但可以用VLAN策略或ACL配合模拟类似效果，重点还是理解“VLAN划分的依据不止端口，还能是MAC、子网、协议”这个思想。

第三，IP Source Guard（IPSG）。这个功能常和DHCP Snooping配合，用来防止IP/MAC欺骗。在交换机接入端口开启后，端口只允许通过绑定表中记录的IP和MAC发出的流量。在EVE-NG里可以在PC1的接入端口配置ip verify source port-security，然后把PC1的IP改成另一个地址再去ping，抓包观察交换机如何丢弃源IP非法的帧。这个实验能帮你把“二层安全”和“ACL/绑定表”的概念串起来，比单纯看文档直观得多。

这几条扩展路径做下来，你的这套EVE-NG环境基本就具备了从二层标签到三层转发、再到接入安全的完整实验能力，不需要重新搭建拓扑，只需要在原基础上加节点、加配置、加抓包点。

最后分享一个我自己积累的小习惯：做这类流量洞察实验时，我永远同时开两个抓包窗口，一个盯Access链路、一个盯Trunk链路，对照着看。排障时先判断问题在“广播域边界”还是“三层转发点”，能省掉大量无效时间。另一个建议是，每完成一个阶段实验，就在EVE-NG里导出pcap并写几行备注，说明这个抓包文件验证了什么结论。等你要写报告、做认证实验答题或者给别人讲清楚VLAN原理时，这些一手抓包文件就是最好的素材，比任何教科书截图都有说服力。