📚 课程目录第4章数据链路层排查（一）

4. 数据链路层排查（一）：MAC地址冲突、ARP欺骗与攻击、交换机端口故障

数据链路层，说白了就是让数据在同一个物理网络里「点对点」传过去。这一层出问题，最直接的表现就是——明明网线插着，灯也亮着，但就是ping不通。我这些年排查下来，发现MAC地址冲突、ARP欺骗、还有交换机端口那点破事，占了数据链路层故障的八成以上。咱们一个一个说。

4.1 MAC地址冲突

MAC地址理论上全球唯一，但现实中总有人手动改，或者虚拟机克隆忘了重置。一旦冲突，交换机就懵了——同一个MAC从两个端口冒出来，它该把数据往哪送？

4.1.1 现象与判断

间歇性断网：能通一会儿，然后突然掉线，过一会儿又恢复。
交换机日志报警：出现 MAC address flapping between port 之类的信息。
抓包看到重复MAC：同一个源MAC地址，来自不同的源IP。

我的习惯： 遇到间歇性断网，第一件事不是重启设备，而是先看交换机的MAC地址表。用 show mac-address-table 扫一眼，如果同一个MAC出现在两个端口上，基本就实锤了。

4.1.2 排查步骤

定位冲突MAC：从交换机日志或MAC表里找到那个「到处乱跑」的MAC地址。
反向查找IP：在核心交换机上查ARP表，找到这个MAC对应的IP。
顺藤摸瓜：根据IP找到具体设备。如果是服务器，检查网卡配置；如果是虚拟机，检查克隆设置。
修复：把重复的MAC改掉，或者重新生成。

注意： 有些网卡支持「MAC地址透传」或「本地管理地址」，这在虚拟化环境里特别容易引发冲突。我曾经遇到一个案例，VMware ESXi 的虚拟交换机没配好，导致所有虚拟机都用了同一个MAC——那场面，简直灾难。

4.2 ARP欺骗与攻击

ARP协议本身没安全机制，谁问都能答，谁答都信。这就给了攻击者可乘之机。ARP欺骗，说白了就是冒充别人——攻击者告诉网关「我是受害者」，又告诉受害者「我是网关」。这样一来，所有流量都经过攻击者，它想干嘛就干嘛。

4.2.1 两种常见场景

场景	攻击目标	典型现象
中间人攻击	截获通信数据	网页被插入广告、密码被盗、会话被劫持
拒绝服务攻击	让目标断网	受害者无法上网，网关ping不通

4.2.2 排查方法

看ARP表：在网关或核心交换机上执行 arp -a，检查有没有同一个IP对应两个不同的MAC。如果有，基本就是被攻击了。
抓包分析：用Wireshark抓ARP包。正常的ARP请求和应答是成对出现的。如果看到大量 ARP Reply 没有对应的 ARP Request，那就是有人在「主动投喂」假信息。
检查网关MAC：在受害者的机器上 arp -a | findstr 网关IP，看看网关的MAC是不是真的。如果不确定，去交换机上查一下网关设备真正的MAC。

避坑指南： 我曾经处理过一个「间歇性卡顿」的故障。查了三天，从光模块换到服务器网卡，最后发现是一台测试服务器上跑了个ARP欺骗工具，忘了关。那台机器就静静地躺在角落里，每天发几万个假ARP包。所以，我建议在交换机上开启 DAI（Dynamic ARP Inspection） 和 DHCP Snooping，从源头掐死ARP欺骗。

4.2.3 防御配置示例（Cisco交换机）

! 启用DHCP Snooping
ip dhcp snooping
ip dhcp snooping vlan 10,20,30
interface GigabitEthernet0/1
 ip dhcp snooping trust

! 启用DAI
ip arp inspection vlan 10,20,30
interface GigabitEthernet0/1
 ip arp inspection trust

4.3 交换机端口故障

端口故障分两种：一种是物理层面的，比如网线坏了、光模块脏了；另一种是协议层面的，比如STP环路、端口协商失败。咱们重点说后者，因为前者靠换线就能解决，后者才考验真功夫。

4.3.1 STP/RSTP环路

环路是二层网络最可怕的故障。一旦出现广播风暴，整个网络瞬间瘫痪。STP（生成树协议）就是为了防环路设计的，但它自己也会出问题。

环路典型症状：

所有交换机端口指示灯狂闪，像迪厅灯球。
CPU利用率飙升到100%，交换机几乎无法管理。
网络延迟极高，丢包率接近100%。
抓包看到大量重复的广播帧，TTL（实际上二层没有TTL，但帧会无限转发）。

我的经验： 环路发生时，别慌。最快的应急手段是——拔线。找到环路中最近的一台交换机，把疑似环路的端口拔掉。网络通常会在几秒内恢复。然后，再慢慢查是哪根线接错了。

排查环路步骤：

看STP状态：show spanning-tree，检查端口角色。正常情况下，应该有一个Root Port和几个Designated Port，剩下的应该是Alternate Port（Blocking）。如果所有端口都是Forwarding，那肯定有环路。
看端口流量：show interface counters，找那些广播包和组播包数量异常高的端口。
启用BPDU Guard：在接入层端口上开启 spanning-tree bpduguard enable。一旦有人私接交换机，端口会自动关闭，防止环路扩散。

4.3.2 端口协商失败

端口协商，就是两个设备商量好用多快的速度、全双工还是半双工。如果商量崩了，就会出现能link up但无法通信的诡异现象。

常见原因：

一端强制设了速度和双工，另一端是自动协商。
网线质量差，导致协商失败，回退到半双工。
光模块不兼容，或者光衰太大。

排查方法：

检查项	命令/方法	正常值
端口状态	`show interface status`	connected
速度和双工	`show interface`	两端一致，建议全双工
错误计数	`show interface counters errors`	CRC、FCS错误应为0
光模块信息	`show interface transceiver`	温度、电压、光功率在正常范围

注意： 端口协商失败最坑的地方在于——端口灯是亮的，你以为没问题。但实际上，大量数据包因为双工不匹配而损坏。我建议，所有服务器和网络设备之间的链路，都手动设为 全双工，并固定速度。自动协商在复杂环境下太容易出幺蛾子了。

4.4 本章知识体系

下面这张图，把数据链路层常见的三类故障、它们的症状、排查手段和防御措施串在了一起。你可以把它当作一张「故障地图」，遇到问题先定位到区域，再按图索骥。