📚 课程目录第4章数据链路层

第4章数据链路层：MAC地址、ARP协议与交换机转发

很多人遇到“Link Up但ping不通”时，第一反应是查IP、查路由。但实际上一大半故障，卡在数据链路层。说白了就是MAC地址、ARP表和交换机这三件事没对得上。我在一线排查网络时，至少有一半的“ping不通”案件，最后定位到链路层——不是MAC地址冲突，就是ARP缓存作祟，或者交换机的MAC表出了问题。这章我们就把这三样东西彻底讲透。

4.1 MAC地址：设备的物理身份证

MAC地址是48位的十六进制数，出厂就烧死在网卡上。理论上全球唯一。你拿ipconfig /all（Windows）或ifconfig（Linux）就能看到它。

典型案例： 去年有个客户，新装了几十台服务器，其中两台ping不通网关。我查了半小时，发现两台服务器的MAC地址一模一样——奸商刷了克隆网卡。这种坑，你光看IP根本看不出来。所以排查时一定拿arp -a对一下MAC，看有没有重复。

MAC地址根据第一个字节最低两位，分成三种：

单播（Unicast）：0x00/0x04… 指向唯一设备。
广播（Broadcast）：FF-FF-FF-FF-FF-FF，所有设备都会收。
组播（Multicast）：01-00-5E-xx-xx-xx，只有加入组的设备处理。

排查Ping不通时，记得先确认目标MAC是否有效。如果ARP表里没有目标IP的MAC，那说明问题出在ARP解析阶段。

快速查看MAC地址的命令：

Windows:  ipconfig /all | findstr "物理地址"
Linux:    ip link show | grep link/ether
macOS:    ifconfig en0 | grep ether

4.2 ARP协议：IP与MAC的翻译官

ARP（Address Resolution Protocol）把IP地址翻译成MAC地址。原理很简单：A想知道B的MAC，就在广播域里喊一声“谁是192.168.1.2？”——所有设备都收到，只有B回答“我是，我的MAC是xx:xx:xx:xx:xx:xx”。A收到后，把映射关系写进ARP缓存。

但正是这个“简单”，埋了很多雷。我曾经遇到一个故障：PC能Ping通同网段网关，但Ping不通另一台PC，持续了3天。最后抓包发现——PC发的ARP请求，目标PC确实收到了，但应答包因为交换机端口安全策略被丢弃了。交换机上配了端口安全，只允许特定MAC通过，而应答包的源MAC不在允许列表里。所以ARP表永远填充不上。

避坑经验： ARP缓存有老化时间（通常2-5分钟）。我建议排查时先用arp -d清除缓存再重新Ping，看能否触发新的ARP请求。如果清了还是不通，重点抓ARP请求和应答。

ARP协议也容易遭到欺骗（ARP Spoofing）。一个攻击者冒充网关的MAC，所有流量都经过他。所以在大二层环境里，建议配置DAI（Dynamic ARP Inspection）。

ARP请求：广播，目标MAC全F。
ARP应答：单播，直接回复请求者。
免费ARP（Gratuitous ARP）：主机主动广播自己的IP+MAC，用于通知地址变化或检测冲突。

你可以在交换机上用debug arp（谨慎使用）或者抓包观察ARP交互。

4.3 交换机转发原理

交换机工作在数据链路层，核心武器是MAC地址表。它根据帧的目标MAC决定转发还是泛洪（Flood）。初始时MAC表是空的，收到一个帧就学习源MAC和入端口，以后给该MAC发帧时只从那个端口出去。

学习：记录源MAC和端口。
转发：目标MAC在表中，定向发送。
泛洪：目标MAC不在表中，或目标MAC是广播地址，向除接收端口外的所有端口发送。
过滤：源MAC和目标MAC在同一端口，不转发。

怎么看MAC表？

# 华为/思科交换机
display mac-address
show mac address-table

重点关注：是否学到了正确的目标MAC，以及端口是否正确。

交换机还有一个重要概念：广播域。广播帧会扩散，如果广播域太大，会引发广播风暴。这也是导致Ping超时的原因之一。我记得有一次园区网故障，终端Ping核心交换机丢包严重，一查发现MAC地址表瞬间增长到上万条——原来有人在局域网里发了大量免费ARP伪造不同IP，交换机疯狂学习，CPU撑爆了。

切记： 交换机MAC地址表是有容量的（一般几千到几万条）。如果超过容量，交换机可能无法学习新MAC，甚至降级为Hub模式——所有帧都泛洪，网络性能崩溃。检查一下show mac address-table count。

4.4 链路层排查实战思路

当你面对“Link Up但Ping不通”，链路层应该怎样快速排查？我总结了一个三步法：

查ARP表：arp -a看有没有目标IP的MAC记录。没有？说明ARP没成功；有？继续往下看。
查交换机MAC表：show mac address-table | include 目标MAC，确认目标设备的MAC是否在交换机上，以及对应的端口是否对。
抓包确认：在源和交换机上抓包，看ARP请求是否发出？应答是否回来？帧是否正常被转发？

症状	可能链路层原因	排查命令
ARP表里没有目标MAC	ARP请求没到达；目标没应答；中间交换机过滤了ARP	`tcpdump arp` / `show mac-address-table`
ARP表有MAC，但Ping不通	MAC关联的端口不对；交换机端口VLAN不一致；端口阻塞	`show mac-address-table dynamic` + `show interfaces status`
MAC地址在交换机上体现为多个端口	MAC漂移（环路或欺骗）	`show mac-address-table flapping`
ARP表频繁变化	ARP老化过快/攻击	抓包看免费ARP频率

举个例子： 有一次A和B直连交换机，A能Ping通自己网关，但Ping不通同网段的B。我看了A的ARP表，没有B的MAC。在交换机上抓包，发现A的ARP请求被广播到B口，B也回了，但交换机没有把应答转发回A——因为交换机配置了端口安全，B口只允许特定的唯一MAC通过，而B的MAC不在允许列表。关掉端口安全就通了。这种场景，你不看二层根本想不到。

另外提醒一句：不要忽视免费ARP。有些设备开机后会发免费ARP，如果交换机上有人工配置了静态MAC表，或者另一台设备在同一个IP上发过免费ARP，就会导致MAC表混乱。我曾经被坑过一次：一台打印机和一个服务器IP冲突，但两人MAC不同，交换机不停学习、解学习，搞得时通时断。

上面这张图把Ping不通时链路层核心路径画清楚了。不论你从“检查ARP缓存”开始，还是从“交换机MAC表”入手，关键就几点：ARP请求能不能到？ARP应答能不能回？交换机能否正确转发单播帧？把这三点搞明白了，九成的链路层故障都能拿下。

链路层排查不复杂，但极容易被忽略。很多“Ping不通”的根因，翻来覆去就是ARP表空了、MAC表错了、交换机端口奇怪了。希望这章能帮你少走弯路。我是老工程师了，每次都先看二层，再看三层，这个顺序救过我很多次。