3. 数据链路层故障排查：MAC地址表、ARP协议、VLAN配置、STP问题定位与解决
数据链路层，说白了就是让数据在同一个广播域里找到正确的设备。很多人觉得这层简单，不就是查查MAC地址嘛。但我在项目里栽过好几次跟头，发现这层的问题往往最隐蔽——它不像IP层那样有明确的报错，而是直接“不通”，让你摸不着头脑。
这一章，我把数据链路层最常见的四个故障点拆开来讲：MAC地址表、ARP协议、VLAN配置、STP。每个点我都会结合自己的实战经历，告诉你问题长什么样、怎么定位、怎么解决。
核心思路：数据链路层故障排查，本质上就是回答三个问题——设备认不认识对方？数据该走哪条路？这条路通不通？
3.1 MAC地址表：交换机的“通讯录”
交换机的MAC地址表，就像一本通讯录。它记录着哪个MAC地址在哪个端口上。通讯录乱了，数据就送错地方。
3.1.1 表项老化导致丢包
我遇到过最典型的场景：一台服务器突然断连几秒，然后又恢复了。查了一圈，最后发现是MAC地址表老化时间设置太短。
默认老化时间一般是300秒。但如果网络中有频繁的端口切换或链路震荡，表项会被反复刷新。老化时间太短，表项被清掉，交换机就得重新泛洪，丢包就来了。
排查命令：
# 查看MAC地址表
show mac address-table
# 查看老化时间
show mac address-table aging-time
# 查看某个MAC的漂移记录
show mac address-table notification3.1.2 MAC地址漂移
MAC地址漂移，说白了就是一个MAC地址在两个端口之间反复跳变。这通常意味着网络中有环路，或者有人接了交换机级联线。
我记得有一次，客户说整个办公网间歇性卡顿。我登录核心交换机一看，日志里全是MAC地址漂移告警。顺着告警查下去，发现一个工位下面私接了一台小交换机，还形成了环路。
避坑指南：我曾经因为没开MAC地址漂移检测，排查了整整两天才发现问题。建议在生产交换机上开启漂移检测，并配置告警阈值。
# 开启MAC地址漂移检测
mac address-table notification mac-move
mac address-table notification interval 603.1.3 MAC地址黑洞
还有一种情况：MAC地址表里明明有记录，但数据就是不通。这可能是硬件转发表项损坏，或者软件层面的黑洞路由导致的。
我处理过一个案例：某台接入交换机上，所有流量到某个MAC地址就丢了。查表发现表项正常，但清空表项后重新学习就恢复了。嗯，这就是典型的表项损坏。
3.2 ARP协议：IP到MAC的“翻译官”
ARP协议负责把IP地址翻译成MAC地址。翻译错了，数据就送错门。翻译不出来，数据就送不出去。
3.2.1 ARP欺骗攻击
ARP欺骗是数据链路层最常见的攻击手段。攻击者伪造ARP应答，告诉交换机“这个IP对应的MAC是我”。然后所有发往那个IP的流量都到了攻击者手里。
我在做安全审计时遇到过：某公司财务系统频繁掉线，但网络本身没问题。抓包一看，ARP表里网关的MAC地址被篡改了。最后发现是内网有人中了木马，在发伪造ARP包。
排查方法：
- 用
arp -a查看本机ARP表，对比网关的真实MAC - 在交换机上查看ARP表：
show ip arp - 抓包分析ARP应答的源MAC是否一致
3.2.2 ARP超时与重传
ARP请求发出去，对方没回应，就会超时。超时后重传，重传几次还不行，就宣告失败。这通常是因为对方设备离线、防火墙拦截了ARP包，或者二层链路有问题。
我个人的习惯是：先ping一下目标IP，如果ping不通，马上抓包看有没有ARP请求和应答。有请求没应答，问题在对方；连请求都没有，问题在本机或网关。
3.2.3 代理ARP的坑
代理ARP是路由器替其他设备回应ARP请求。听起来很方便，但容易造成路由混乱。我见过一个案例：两个网段通过路由器互联，但路由器开启了代理ARP，导致终端设备以为所有IP都在同一个广播域里，路由表完全乱了。
建议：除非有明确需求，否则关闭代理ARP。用静态路由或动态路由协议来管理跨网段通信。
# 关闭代理ARP（接口下配置）
no ip proxy-arp3.3 VLAN配置：隔离与连通的艺术
VLAN配置问题，说白了就是“该通的没通，不该通的通了”。我排查过的VLAN故障，90%都是配置不一致导致的。
3.3.1 Trunk链路配置不匹配
两台交换机之间用Trunk链路连接，但一端允许的VLAN列表和另一端不一致。结果就是某些VLAN的流量过不去。
我记得有一次，新上线一个VLAN 100，配置好了接入端口，但终端就是获取不到IP。查了半天，发现Trunk链路上没放行VLAN 100。加上switchport trunk allowed vlan add 100，问题秒解。
| 问题类型 | 现象 | 排查命令 |
|---|---|---|
| Trunk VLAN列表不匹配 | 部分VLAN不通 | show interfaces trunk |
| Native VLAN不一致 | CDP/LLDP邻居丢失 | show interfaces trunk |
| Access VLAN配置错误 | 终端无法通信 | show vlan brief |
3.3.2 Native VLAN不匹配
Native VLAN是Trunk链路上不打标签的VLAN。如果两端Native VLAN配置不一致，控制协议（如CDP、LLDP、STP BPDU）就无法正常通信。
我曾经遇到一个诡异问题：两台交换机之间链路状态是up，但STP邻居就是学不到。查了半小时，发现一端Native VLAN是1，另一端是99。改成一致后，STP立刻收敛。
避坑指南：建议把Native VLAN改成非默认值（比如999），并确保两端一致。这样可以防止VLAN跳跃攻击。
# 配置Native VLAN
interface GigabitEthernet0/1
switchport trunk native vlan 9993.3.3 VLAN间路由问题
不同VLAN之间通信需要三层设备（路由器或三层交换机）。如果VLAN间路由没配好，跨VLAN的流量就会丢。
我排查过一个案例：VLAN 10和VLAN 20之间ping不通，但各自内部通信正常。检查发现三层交换机上没配VLAN间路由。加上ip routing和对应的SVI接口后，问题解决。
3.4 STP生成树：环路的“终结者”
STP的存在就是为了防止环路。但STP本身也会出问题——端口阻塞、收敛慢、甚至导致环路。
3.4.1 端口阻塞导致链路不可用
STP会阻塞冗余端口来防止环路。但如果根桥选举出了问题，或者端口优先级配置不当，该通的端口被阻塞了，不该通的反而通了。
我记得有一次，客户说核心到接入的链路带宽不够，但明明有两条链路。查STP状态发现，其中一条链路的端口处于Blocking状态。调整端口优先级后，两条链路都开始转发流量。
STP端口状态检查命令：
# 查看STP状态
show spanning-tree
# 查看某个端口的STP状态
show spanning-tree interface GigabitEthernet0/1
# 查看根桥信息
show spanning-tree root3.4.2 收敛速度慢
传统STP收敛需要30-50秒。链路断了，STP要重新计算，这段时间网络就是断的。对于生产环境来说，这完全不可接受。
我建议使用RSTP（快速生成树协议）或MSTP（多生成树协议）。RSTP收敛时间可以缩短到1-2秒。如果设备支持，直接上RSTP。
配置示例：
# 启用RSTP
spanning-tree mode rapid-pvst
# 启用MSTP
spanning-tree mode mst3.4.3 STP环路故障
最严重的情况：STP失效，网络形成环路。广播风暴、MAC地址漂移、CPU飙升，所有症状一起出现。
我处理过一个紧急故障：整个办公网瘫痪，所有交换机CPU 100%。登录核心交换机，发现STP状态异常，多个端口处于Forwarding状态。最后拔掉一根级联线，网络立刻恢复。事后分析，是某台交换机的STP协议被误关闭了。
紧急处理步骤：
- 拔掉疑似环路的链路（先恢复网络）
- 检查所有交换机的STP状态
- 确认根桥选举是否正确
- 检查端口优先级和路径开销
- 开启BPDU Guard和Root Guard
3.5 实战排查思路总结
说了这么多，最后给一个我自己的排查思路。遇到数据链路层问题，我一般按这个顺序来：
- 第一步：确认物理链路状态（up/down）
- 第二步：检查MAC地址表（有没有表项、有没有漂移）
- 第三步：检查ARP表（能不能解析到MAC）
- 第四步：检查VLAN配置（Trunk、Native VLAN、Access VLAN）
- 第五步：检查STP状态（端口角色、状态、根桥）
这个顺序不是固定的，但大多数情况下能帮你快速定位问题。你想想看，链路都不通，查STP有什么用？先解决底层，再往上走。
一句话总结：数据链路层故障，80%是配置不一致导致的，15%是环路，5%是硬件问题。配置一致性检查，永远是第一优先级。