3. 数据链路层诊断：MAC地址表学习异常、STP/RSTP环路问题、VLAN配置错误排查
数据链路层，说白了就是交换机工作的核心层。很多刚入行的朋友觉得这层简单，不就是转发个帧嘛。但我在项目里踩过的坑，十有八九都跟这层有关。MAC表学错了、环路没防住、VLAN配串了——任何一个都能让你排查到怀疑人生。
今天咱们就把这三个老大难问题掰开揉碎，一个一个说清楚。
3.1 MAC地址表学习异常
交换机靠什么转发？靠MAC地址表。这张表要是乱了，数据帧要么乱飞，要么直接丢了。
3.1.1 正常学习过程
先简单回顾一下正常流程：
- 交换机从某个端口收到一个帧，取出源MAC地址。
- 查MAC表，如果没有这个MAC，就把它和入端口绑定，写入表里。
- 查目的MAC，如果表里有，就从对应端口转发；如果没有，就泛洪到所有端口（除了入端口）。
听起来很简单对吧？但实际部署中，问题往往出在细节上。
3.1.2 常见异常场景
| 异常现象 | 可能原因 | 排查方向 |
|---|---|---|
| MAC表不更新 | 端口安全配置、MAC地址老化时间过长 | 检查 port-security、mac-address-table aging-time |
| MAC表频繁抖动 | 环路、网线质量差、网卡故障 | 检查日志中的MAC flapping告警 |
| MAC表条目错误 | 静态配置错误、VLAN间MAC冲突 | 核对静态MAC、检查VLAN划分 |
| MAC表容量满 | 设备规格不足、广播攻击 | 查看 show mac address-table count |
核心排查命令（以Cisco为例）：
show mac address-table
show mac address-table aging-time
show mac address-table count
show logging | include MACFLAP我个人习惯：遇到MAC表抖动，第一件事不是看配置，而是先看日志。MAC flapping告警能直接告诉你哪两个端口在来回跳，顺着这个线索查，效率最高。
3.1.3 避坑指南
我曾经在一个数据中心项目里，所有服务器都做了双网卡绑定。结果发现MAC表一直在两个端口之间来回跳，交换机日志刷屏。查了半天，原来是绑定模式配成了主动-主动，两个端口同时发相同源MAC的帧。交换机以为有人在搞环路攻击，直接开始丢包。
解决方案很简单：把绑定模式改成主动-被动，或者启用交换机端的 port-channel 配置，让交换机把两个端口当成一个逻辑端口来处理。
3.2 STP/RSTP环路问题
环路，是二层网络最怕的东西。广播风暴一来，整个网络直接瘫痪。STP（生成树协议）就是用来防这个的。
3.2.1 STP与RSTP的核心差异
| 特性 | STP (802.1D) | RSTP (802.1w) |
|---|---|---|
| 收敛时间 | 30-50秒 | 1-3秒 |
| 端口角色 | Root、Designated、Blocking | Root、Designated、Alternate、Backup |
| 端口状态 | Blocking、Listening、Learning、Forwarding | Discarding、Learning、Forwarding |
| 拓扑变更机制 | TCN BPDU，需要Root Bridge确认 | Proposal/Agreement握手，快速同步 |
说白了，RSTP就是STP的加速版。现在新设备基本都默认跑RSTP，但很多老项目还在用STP。你想想看，一个网络拓扑变了，要等30秒才能恢复通信，这在今天根本没法接受。
3.2.2 环路故障的典型症状
- 广播风暴：所有端口流量暴增，CPU利用率100%，设备失去响应。
- MAC表抖动：同一个MAC地址在多个端口之间反复出现。
- 网络时断时续：STP在反复计算拓扑，端口在Blocking和Forwarding之间来回切换。
注意：环路不一定马上导致全网瘫痪。如果环路中只有少量广播流量，你可能只会观察到间歇性丢包。这种"软环路"最难排查，因为它不会触发明显的风暴告警。
3.2.3 排查步骤
- 确认STP状态：
show spanning-tree，看所有端口的角色和状态。 - 定位Root Bridge：确认Root Bridge是不是你期望的那台设备。如果不是，检查Bridge Priority配置。
- 检查端口角色：所有非Root端口应该是Alternate（阻塞）状态。如果某个端口应该是阻塞的，但实际是Forwarding，那就是问题了。
- 查看拓扑变更记录：
show spanning-tree detail，看TCN计数是否在持续增长。 - 抓包分析BPDU：用Wireshark抓STP/RSTP的BPDU报文，确认谁在发、谁在收、优先级对不对。
快速定位环路的口诀：
1. 看CPU —— 高负载大概率是环路
2. 看日志 —— MACFLAP告警指向问题端口
3. 看STP —— 确认端口角色和状态
4. 拔网线 —— 拔掉疑似环路的链路，看网络是否恢复我记得有一次在园区网割接，新加了一台交换机，结果整个办公区网络瘫痪了。我按上面的步骤查，发现新交换机的STP优先级设成了0（最高优先级），它直接抢了Root Bridge的位置。而它跟核心交换机之间又有一条冗余链路没配STP，形成了环路。拔掉那条线，网络立刻恢复。后来我养成了一个习惯：新设备上线前，先检查STP配置，优先级绝对不能乱设。
3.3 VLAN配置错误排查
VLAN配置错误，是数据链路层最常见的"人为故障"。说白了就是：该通的没通，不该通的反而通了。
3.3.1 典型错误场景
| 错误类型 | 现象 | 原因 |
|---|---|---|
| Access端口VLAN不匹配 | 终端无法获取IP地址 | 交换机端口VLAN与终端所在VLAN不一致 |
| Trunk链路允许VLAN遗漏 | 跨交换机同VLAN不通 | Trunk端口没有 allowed vlan 放行该VLAN |
| Native VLAN不一致 | 部分流量不通，或出现VLAN跳跃攻击 | Trunk两端Native VLAN配置不同 |
| VLAN未创建 | 端口配置了不存在的VLAN | 交换机上没有 vlan <id> 创建该VLAN |
3.3.2 排查命令
# 查看端口VLAN配置
show interfaces status
show interfaces trunk
show vlan brief
# 查看VLAN是否创建
show vlan id <vlan-id>
# 查看Trunk允许的VLAN列表
show interfaces <interface> trunk
# 查看Native VLAN
show interfaces <interface> switchport3.3.3 实战案例
我曾经处理过一个故障：某公司新部署了一批IP电话，电话能注册，但通话时断时续。查了一圈，发现交换机Trunk端口上配了 switchport trunk allowed vlan 1-100,200-300，但IP电话的语音VLAN是150，数据VLAN是250。这两个VLAN都在允许列表里，按理说没问题。
但仔细一看，Trunk两端的Native VLAN不一致——一端是VLAN 1，另一端是VLAN 99。Native VLAN不匹配会导致BPDU和CDP等控制协议无法正常通信，间接影响了语音流的QoS标记传递。修正Native VLAN后，问题解决。
重要提醒：Trunk两端的Native VLAN必须一致。如果不一致，交换机会把收到的未标记帧错误地归入不同的VLAN，造成二层转发混乱。而且，这也是一个安全漏洞——VLAN跳跃攻击就是利用Native VLAN不一致来实现的。
3.4 本章知识体系
下面这张图总结了数据链路层三大诊断方向的核心逻辑，方便你快速回顾：
数据链路层的诊断，说白了就是三件事：看MAC表学没学对、看STP有没有防住环路、看VLAN配没配通。这三块搞定了，二层网络的问题基本都能拿下。
嗯，这里要再强调一句：别光靠脑子记，把上面那些命令练熟，遇到问题先看日志再看表，最后才动配置。这个顺序能帮你省下大量排查时间。