4. 二层转发故障诊断
二层转发故障是园区网中最常见、也最容易被误判为“链路不通”的一类问题。它的根源往往不在物理层，而在 VLAN 归属、Trunk 允许列表、生成树状态或 EtherChannel 成员协商这几个环节。与三层故障不同，二层故障的典型表现是：接口 up/up、链路灯正常，但主机拿不到地址、跨交换机同 VLAN 不通、或出现间歇性丢包与环路告警。诊断的核心思路是沿着“接入端口 → Trunk 链路 → STP 拓扑 → 链路聚合”这条转发路径逐段确认，用 show vlan、show spanning-tree、show etherchannel 三条命令把抽象的二层状态变成可判断的证据。
一、VLAN 层故障：端口归属与活动状态
VLAN 故障的第一类场景是端口没有加入正确的 VLAN，或 VLAN 本身不存在。接入端口默认属于 VLAN 1，如果管理员忘记执行 switchport access vlan 20，主机会被放进 VLAN 1，表现为“能通但通错网段”。第二类场景是 VLAN 未在 VLAN 数据库中创建，端口配置了 switchport access vlan 30 却显示 inactive，因为该 VLAN 不存在。第三类场景是 VLAN 被 shutdown 或从数据库中删除，导致所有成员端口失效。
排查时先看端口状态与归属：
Switch# show vlan brief
VLAN Name Status Ports
---- ----------- --------- -------------------------------
1 default active Gi0/1, Gi0/2
10 Sales active Gi0/5, Gi0/6
20 Finance active
30 Guest active Gi0/9
如果 Gi0/7 配置为 VLAN 20 却未出现在任何 VLAN 的 Ports 列中，说明该端口未处于 access 模式或 VLAN 不存在。此时用 show interfaces Gi0/7 switchport 确认 Administrative Mode 与 Access Mode VLAN，再用 show vlan id 20 确认 VLAN 是否 active。修复动作通常是补建 VLAN 或修正端口模式。需要特别注意的是，VLAN 1 无法删除也无法 shutdown，因此“VLAN 1 不通”往往不是 VLAN 层问题，而应转向 Trunk 或 STP 排查。
二、Trunk 层故障：允许列表与封装协商
Trunk 故障最隐蔽的形式是“链路 up、VLAN 1 能通、业务 VLAN 不通”。原因通常是 Trunk 两端允许的 VLAN 列表不一致，或一端配置了 switchport trunk allowed vlan 而另一端为默认全部。默认情况下 Trunk 允许 VLAN 1–4094，一旦某端被收窄为只允许 VLAN 10，那么 VLAN 20 的流量会在该链路上被静默丢弃，且不会产生明显的接口错误计数。
诊断命令是：
Switch# show interfaces trunk
Port Mode Encapsulation Status Native vlan
Gi0/1 on 802.1q trunking 1
Port Vlans allowed on trunk
Gi0/1 10,20,30
Port Vlans allowed and active in management domain
Gi0/1 10,20
这里要重点看两行：Vlans allowed on trunk 是配置允许列表，Vlans allowed and active 是“允许且已激活”的交集。如果 VLAN 30 出现在第一行却不在第二行，说明 VLAN 30 未创建或未激活，问题回到 VLAN 层；如果 VLAN 30 根本不在第一行，则是 Trunk 允许列表缺失。修复用 switchport trunk allowed vlan add 30，而不是直接覆盖整条列表，避免误删其它 VLAN。此外，封装不匹配（一端 dot1q、一端 ISL）或 native VLAN 不一致也会造成流量错位，前者导致 Trunk 无法建立，后者会把未打标签流量注入错误 VLAN，可用 show interfaces trunk 的 Native vlan 列比对两端。
三、STP 层故障：阻塞、根桥与拓扑震荡
STP 故障的典型表现是“链路正常但某个 VLAN 完全不通”，因为该 VLAN 的转发端口被阻塞，或根桥位置异常导致次优路径。排查入口是：
Switch# show spanning-tree vlan 20
VLAN0020
Spanning tree enabled protocol rstp
Root ID Priority 32788
Address 0011.2233.4455
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
---------- ---- --- --------- -------- ----
Gi0/1 Root FWD 4 128.1 P2p
Gi0/2 Desg FWD 4 128.2 P2p
Gi0/3 Altn BLK 4 128.3 P2p
判断要点有三：第一，看 This bridge is the root 是否出现在预期之外的交换机上，若接入层交换机意外成为根桥，说明优先级未规划，流量路径被拉长；第二，看关键上行口是否处于 BLK，若业务 VLAN 的唯一下行口被阻塞，需检查是否存在环路或 BPDU 异常；第三，看拓扑是否频繁变化，用 show spanning-tree detail 观察 topology change 计数是否持续增长，这通常意味着端口 flapping 或单向链路。修复手段包括：为根桥和备份根桥显式设置 spanning-tree vlan 20 priority 4096、在接入端口启用 spanning-tree portfast 与 bpduguard、以及排查物理层的间歇性抖动。
四、EtherChannel 层故障：成员协商与负载分布
EtherChannel 故障常表现为“聚合口 up 但带宽没有叠加”或“部分成员口被挂起”。核心原因是成员口的速率、双工、VLAN 模式、Trunk 允许列表或 STP 状态不一致，导致协商失败。诊断命令是：
Switch# show etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
Group Port-channel Protocol Ports
------+-------------+---------+--------------------------------
1 Po1(SU) LACP Gi0/1(P) Gi0/2(P) Gi0/3(s)
看到 (s) 即 suspended，说明该成员口未通过协商。常见原因包括：一端是 LACP 主动模式而另一端是静态 on、成员口速率不一致、或成员口上存在不同的 Trunk 允许列表。修复顺序是先统一两端协议模式（推荐 LACP active/active），再逐口比对 show interfaces Gi0/3 switchport 与 show etherchannel 1 port-channel，确认 VLAN 与 Trunk 配置完全一致。若聚合口本身处于 STP 阻塞，则需回到 STP 层排查，因为 EtherChannel 在 STP 中视为单一逻辑端口。
五、诊断顺序与结果判读
面对“二层不通”的报障，建议按 VLAN → Trunk → STP → EtherChannel 的顺序推进，因为后一层的问题常常被前一层掩盖。例如 EtherChannel 成员口 suspended，可能只是因为该口所在 VLAN 未在 Trunk 允许列表中激活。每一步都要形成“命令输出 → 判断依据 → 修复动作 → 复验结果”的闭环：用 show vlan brief 确认端口归属后，用 show interfaces trunk 核对允许列表，再用 show spanning-tree vlan X 确认转发端口，最后用 show etherchannel summary 确认所有成员口为 (P)。修复后不要只看接口状态，应实际从同 VLAN 主机发起 ping 或查看 MAC 地址表 show mac address-table vlan 20，确认流量确实沿预期路径转发。只有命令输出与业务验证同时通过，才能判定故障真正闭环。