3. 数据链路层故障：MAC地址冲突、VLAN配置错误、STP环路问题、链路聚合故障
数据链路层，说白了就是二层网络的核心。它负责把数据包从一个设备传到另一个设备，靠的是MAC地址。这一层要是出问题，整个局域网可能直接瘫痪。我处理过的网络故障里，至少有一半都跟这层有关。今天咱们就聊聊最常见的四种：MAC地址冲突、VLAN配置错误、STP环路、链路聚合故障。
3.1 MAC地址冲突
MAC地址冲突，就是两台设备用了同一个MAC地址。交换机一看，这地址怎么从两个端口冒出来？它就会混乱，数据包要么丢，要么发错地方。
为什么会发生？
- 虚拟机克隆后没改MAC
- 有人手动改了网卡MAC地址
- 某些低端设备出厂MAC重复
怎么排查？
我个人习惯先看交换机的MAC地址表。用命令 show mac address-table 或者 display mac-address。如果发现同一个MAC出现在多个端口，基本就是冲突了。
# 华为交换机查看MAC表
<Huawei> display mac-address
MAC address VLAN Learned-From Type
0001-2e3d-4f5a 10 GE0/0/1 dynamic
0001-2e3d-4f5a 10 GE0/0/2 dynamic ← 冲突！关键点：同一个MAC地址，只能从一个端口学到。出现两个端口，就是冲突。
我的经验：有一次客户说网络时断时续，我查了半天，最后发现是某台服务器的虚拟机克隆后没改MAC。两台虚拟机抢同一个地址，网络能不乱吗？
怎么解决？
- 找到冲突的设备，修改MAC地址
- 虚拟机记得在克隆后重新生成MAC
- 实在不行，可以配置静态MAC绑定，但治标不治本
注意：别随便改生产设备的MAC，改了可能影响授权或业务。先确认再动手。
3.2 VLAN配置错误
VLAN是用来隔离广播域的。配置错了，要么不通，要么不该通的反而通了。我见过最典型的错误就是Access口和Trunk口搞混。
常见错误类型：
- Access口VLAN不对：PC接在VLAN 10的口上，但实际配成了VLAN 20
- Trunk口没放行VLAN：交换机之间Trunk口只放行了VLAN 10，但VLAN 20的流量过不去
- Native VLAN不一致：两端Trunk口的Native VLAN不同，导致二层帧被错误处理
排查命令：
# 查看端口VLAN配置
show interfaces gigabitEthernet 0/0/1 switchport
# 查看Trunk口放行列表
show interfaces trunk核心思路：从PC出发，沿着路径逐级检查每个端口的VLAN配置。Access口看PVID，Trunk口看Allowed VLAN列表。
举个例子：
你想想看，PC A在VLAN 10，PC B在VLAN 20。中间交换机Trunk口只放行了VLAN 10。那PC B肯定ping不通PC A。这不是故障，是配置没做全。
避坑指南：我曾经遇到一个故障，所有VLAN都配了，就是不通。最后发现是Trunk口两端的Native VLAN不一致。一端是VLAN 1，另一端是VLAN 99。结果不打标签的帧全被丢弃了。嗯，这种问题用抓包都看不出来，得仔细对配置。
3.3 STP（生成树）环路问题
环路，是二层网络最可怕的故障。一旦出现广播风暴，整个网络瞬间瘫痪。STP就是为了防止环路而生的，但它本身也可能出问题。
环路的表现：
- 交换机CPU飙升，端口指示灯狂闪
- 网络延迟极大，甚至完全不通
- 抓包看到大量重复的广播帧
STP故障常见原因：
- STP没启用：某些低端交换机默认关闭STP
- 端口角色错误：应该阻塞的端口变成了转发状态
- BPDU保护没开：有人乱插交换机，导致根桥被抢
- 链路震荡：端口频繁up/down，STP不断重新计算
怎么快速定位环路？
我个人的方法很简单：先看端口流量。用 show interface counters 看哪个端口收发包异常多。然后拔线测试——拔掉疑似环路的链路，看网络是否恢复。
# 查看端口流量统计
show interface gigabitEthernet 0/0/1
# 重点关注：Input rate, Output rate, Broadcast packets警告：拔线测试要小心！先确认业务影响范围，最好在维护窗口操作。我曾经在白天直接拔线，结果把核心业务给断了，被领导骂了一顿。
预防措施：
- 开启BPDU保护：
spanning-tree bpduguard enable - 开启根桥保护：
spanning-tree rootguard - 配置环路保护：
spanning-tree loopguard - 所有接入端口启用PortFast
我的建议：STP的收敛时间默认是30-50秒，太慢了。如果网络规模不大，可以启用RSTP（快速生成树），收敛时间能降到1-2秒。我现在的项目基本都用RSTP或者MSTP。
3.4 链路聚合故障
链路聚合，就是把多条物理链路绑成一条逻辑链路。既能增加带宽，又能做冗余。但配置起来坑也不少。
常见故障：
- 两端聚合模式不匹配：一端是LACP，另一端是静态聚合
- 成员端口配置不一致：速率、双工、VLAN配置不同
- 物理链路问题：其中一条线坏了，但聚合组没感知
- 哈希算法导致负载不均：某些流量全走一条链路
排查步骤：
# 查看聚合组状态
show etherchannel summary
# 查看成员端口详情
show etherchannel port-channel举个例子：
我记得有一次，客户说链路聚合后带宽没提升。我一看配置，两端聚合模式都是LACP，但协商状态显示「down」。再查，发现其中一条链路的速率是100M，其他是1000M。速率不一致，LACP直接把这个端口踢出了聚合组。
关键点：链路聚合要求成员端口的所有配置完全一致。速率、双工、VLAN、Trunk配置，一个都不能差。
怎么解决？
- 确保两端模式一致（LACP对LACP，静态对静态）
- 检查所有成员端口的物理参数
- 用
show lacp neighbor查看LACP协商状态 - 如果负载不均，可以调整哈希算法（基于源MAC、目的MAC、IP等）
避坑指南：我曾经在配置链路聚合时，忘了把成员端口从普通端口模式改成聚合模式。结果物理线都接好了，但聚合组里一个成员都没有。嗯，这种低级错误，排查起来最浪费时间。所以我现在配置完都会用 show etherchannel summary 确认一下。
知识体系总览
下面这张图，把数据链路层四种故障的核心逻辑串起来了。你可以把它当作排查时的参考地图。
数据链路层的故障，说白了就是MAC、VLAN、STP、链路聚合这四个方面。排查时别慌，按顺序来：先看MAC表有没有冲突，再看VLAN配置对不对，然后检查STP状态，最后确认链路聚合是否正常。我这些年处理过的故障，90%都能用这个思路搞定。