3. 数据链路层故障：MAC地址冲突、VLAN配置错误、STP环路与端口阻塞
数据链路层，说白了就是二层网络的核心。交换机在这里干活，MAC地址是它的命根子。这一层出问题，往往不是整网瘫痪，而是「部分不通、时断时续、广播风暴」这种让人抓狂的间歇性故障。我处理过的网络故障里，数据链路层占了将近一半。
咱们一个一个来拆解。
3.1 MAC地址冲突
MAC地址理论上全球唯一，但现实中总有人搞事情。比如虚拟机克隆、手动修改MAC、或者某些低端设备出厂就重复。冲突的结果是什么？交换机MAC表会来回跳，数据包在两个人之间反复横跳，最后谁也上不了网。
核心现象：PC-A和PC-B间歇性断网，ping网关丢包严重，交换机上查看MAC表，同一个MAC地址在两个端口之间反复漂移。
我记得有一次，某公司新上了一批瘦客户机，结果每天早上都有几台无法认证。查了半天，发现是IT批量部署时忘了改虚拟机的MAC地址。嗯，这种低级错误其实很常见。
排查步骤
- 查看MAC表抖动：在交换机上执行
show mac address-table或display mac-address，关注同一个MAC是否出现在多个端口。 - 定位冲突源：使用
show mac address-table address <MAC>确认当前学习到的端口。 - 抓包确认：在冲突端口上抓包，看ARP请求和回应是否来自不同设备。
- 隔离与修复：临时shutdown冲突端口，逐个恢复，找到真凶。
我的习惯：在核心交换机上开启MAC地址漂移检测功能（比如Cisco的 port-security mac-address sticky 配合 violation restrict），能自动把冲突端口errdisable掉，避免影响全网。
避坑指南
我曾经遇到过一种情况：两台服务器做了网卡绑定（NIC Teaming），但配置成了「主动-主动」模式，结果两个端口都向外发相同的MAC地址。交换机以为发生了冲突，疯狂刷新MAC表。解决方案是把绑定模式改成「主动-备用」，或者启用LACP。
3.2 VLAN配置错误
VLAN配置错误，是我见过最频繁的二层故障。说白了就是：该通的没通，不该通的瞎通。常见的有三种：Access口和Trunk口不匹配、Native VLAN不一致、VLAN被修剪掉了。
| 故障类型 | 现象 | 典型原因 |
|---|---|---|
| Access/Trunk不匹配 | PC能获取IP但无法跨交换机通信 | 一端是Access，另一端是Trunk |
| Native VLAN不一致 | CDP/LLDP邻居丢失，部分流量异常 | 两端Trunk口的Native VLAN不同 |
| VLAN被修剪 | 特定VLAN在链路上完全不可达 | VTP修剪或手动allowed vlan列表遗漏 |
你想想看，如果两台交换机之间的Trunk口，一边允许了VLAN 10，另一边只允许了VLAN 20，那VLAN 10的流量就过不去。这种问题用 show interfaces trunk 一眼就能看出来。
快速定位命令：
# 查看Trunk口状态和允许的VLAN列表
show interfaces trunk
# 查看某个VLAN是否在链路上可用
show vlan id 10
# 查看MAC表，确认VLAN是否正常学习
show mac address-table vlan 10我个人习惯在配置Trunk口时，明确指定 allowed vlan，而不是用默认的 all。这样能避免不小心把不该通的VLAN放过去，也方便后期排查。
实战案例
有一次，某楼层所有PC都无法访问服务器。我检查了接入交换机和汇聚交换机之间的链路，发现Trunk口配置了 switchport trunk allowed vlan 1-100，但服务器在VLAN 200。嗯，问题就在这里。加上VLAN 200后，一切恢复正常。
3.3 STP环路与端口阻塞
STP（生成树协议）是二层的防环机制。但STP本身也会出问题：要么该堵的没堵（环路），要么不该堵的堵了（端口阻塞）。环路会导致广播风暴、MAC表震荡、交换机CPU飙升；端口阻塞则会导致链路冗余失效，甚至单点故障。
注意：环路发生时，不要慌。先拔掉一根网线，网络立刻恢复，这就是环路。然后慢慢查是哪条链路导致的。
STP故障排查思路
- 确认根桥：使用
show spanning-tree root查看根桥是否在预期位置。根桥漂移会导致次优路径。 - 检查端口角色：使用
show spanning-tree interface <端口>查看端口是Root Port、Designated Port还是Alternate Port。 - 查看端口状态：重点关注Blocking和Listening状态的端口，确认是否应该阻塞。
- 检查TCN（拓扑变更通知）：频繁的TCN会导致MAC表被反复清空，影响转发性能。
我的经验：很多STP问题是因为链路抖动引起的。比如一根网线接触不良，端口不断up/down，每次up都会触发TCN，导致全网MAC表刷新。解决方案是开启 spanning-tree portfast 和 bpduguard，把接入端口快速收敛，同时防止非法BPDU攻击。
STP环路与端口阻塞的对比
| 对比项 | 环路 | 端口阻塞 |
|---|---|---|
| 现象 | 广播风暴、CPU 100%、所有灯狂闪 | 部分流量不通、冗余链路失效 |
| 原因 | STP未收敛、BPDU丢失、单向链路 | 优先级配置错误、链路故障导致阻塞 |
| 排查命令 | show spanning-tree detail |
show spanning-tree blockedports |
| 紧急处理 | 拔线、手动shutdown端口 | 调整优先级、检查物理链路 |
为什么会发生单向链路？说白了就是光纤一根断了，或者光模块只收不发。STP收不到BPDU，以为链路正常，结果就形成了环路。我建议在关键链路上开启UDLD（单向链路检测），能自动检测并关闭故障端口。
3.4 数据链路层故障知识体系
下面这张图，把数据链路层三大故障的核心逻辑串起来了。你可以把它当作排查时的思维导图。
3.5 综合排查建议
数据链路层故障，很多时候是连锁反应。比如一个VLAN配置错误，可能导致STP拓扑变更，进而引发MAC表抖动。所以排查时，我建议按这个顺序来：
- 先看物理层：端口up/down？光功率正常吗？
- 再看MAC表：有没有漂移？有没有异常学习？
- 然后看VLAN：Trunk口允许了哪些VLAN？Native VLAN一致吗？
- 最后看STP：根桥在哪？端口角色对不对？有没有频繁TCN？
一个小技巧：在交换机上开启 logging console 或 monitor，实时观察MAC地址学习和STP状态变化。很多故障在发生瞬间就能看到日志，比事后翻log高效得多。
数据链路层是网络稳定的基石。把MAC、VLAN、STP这三个点吃透，二层的故障基本都能搞定。嗯，下一层咱们再聊网络层的那些事儿。