4. 交换机的工作原理：MAC地址表、泛洪与广播帧的转发逻辑

要搞懂广播丢包，你得先明白交换机到底是怎么干活的。很多人觉得交换机就是个“智能集线器”，插上就能用。其实它的核心就三件事：学习、转发、泛洪。今天我就把这套逻辑掰开揉碎了讲给你听。

4.1 MAC地址表：交换机的“记忆”

交换机不像集线器那样无脑复制信号。它有一张自己的“通讯录”——MAC地址表。这张表记录了每个端口下连接了哪些MAC地址。

我刚开始做网络运维时，遇到一个故障：某台电脑明明连着交换机，但就是ping不通网关。排查了半天，最后发现是MAC地址表老化导致的。从那以后，我养成了一个习惯——先查MAC表。

4.1.1 表的结构

一张典型的MAC地址表长这样：

说白了，这张表就是交换机的“导航地图”。它告诉交换机：发往某个MAC地址的帧，该从哪个端口扔出去。

4.1.2 学习机制

交换机怎么知道哪个MAC在哪个端口？靠的是源MAC地址学习。

当一个帧从某个端口进入交换机时，交换机会查看帧的源MAC地址。如果这个MAC不在表中，就把它和入端口绑定，记录到表里。这个过程是自动的，不需要人工干预。

4.2 泛洪（Flooding）：不知道就往所有口发

交换机不是万能的。它也有“不认识”的MAC地址。这时候怎么办？

答案是：泛洪。

泛洪，就是把帧复制一份，从除了接收端口以外的所有端口发出去。你想想看，这其实是一种“笨办法”，但也是最可靠的办法。

4.2.1 什么时候会泛洪？

• 未知单播帧：目标MAC不在MAC地址表中。
• 广播帧：目标MAC是FF-FF-FF-FF-FF-FF。
• 组播帧：如果没启用IGMP Snooping，组播帧也会被当作广播处理。

我记得有一次，客户反映内网突然变慢。我抓包一看，发现交换机在疯狂泛洪未知单播帧。原因是某台服务器的网卡坏了，MAC地址一直在变，导致MAC表频繁刷新，大量帧被泛洪到整个网络。

4.2.2 泛洪的代价

泛洪虽然能保证帧到达目的地，但代价很大。它会消耗交换机CPU资源，占用带宽，甚至引发广播风暴。尤其是在大二层网络中，一个广播帧可能被复制成成千上万份。

4.3 广播帧的转发逻辑

广播帧是泛洪的“重灾区”。它的目标MAC是全F，交换机一看就知道：这玩意儿必须发给所有人。

4.3.1 广播帧的处理流程

1. 交换机收到一个广播帧。
2. 检查源MAC，更新MAC地址表（如果有变化）。
3. 目标MAC是广播地址，直接进入泛洪流程。
4. 将帧复制，从所有其他端口（包括Trunk口）发送出去。
5. 如果启用了VLAN，广播帧只在同一个VLAN内泛洪。

这里有个关键点：广播帧不会跨VLAN传播。VLAN就是广播域的分界线。这也是为什么我建议用VLAN来隔离广播域。

4.3.2 广播帧与CPU的关系

交换机收到广播帧后，除了泛洪，还会把帧上送到CPU处理。因为广播帧通常携带了控制协议（如ARP、DHCP）。CPU需要解析这些帧并做出响应。

如果广播帧太多，CPU就会过载。我见过一台接入层交换机，CPU利用率飙到90%以上，就是因为某个端口收到了大量广播帧。最后查出来是一台中毒的PC在疯狂发送ARP请求。

4.4 知识体系图：交换机转发决策流程

下面这张图总结了交换机收到一个帧后的完整决策路径。你可以把它当作排查广播丢包问题的“思维导图”。

4.5 实战中的避坑指南

讲完了理论，我分享几个实际排查中容易踩的坑。

4.5.1 MAC地址表震荡

当一个MAC地址在短时间内频繁出现在不同端口时，交换机会不断更新MAC表。这会导致大量帧被错误泛洪。我曾经在数据中心遇到过，原因是某台服务器的双网卡绑定了同一个MAC，但两个端口都连到了同一台交换机上。

4.5.2 广播帧与CPU保护

很多交换机有CPU保护功能，比如限制每秒处理的广播帧数量。如果配置不当，正常的ARP请求也可能被丢弃。我建议你在部署时检查一下 storm-control broadcast 的阈值。

4.5.3 不要忽视老化时间

MAC地址表默认老化时间是300秒。如果网络中有设备频繁上下线，老化时间太短会导致MAC表频繁刷新，增加泛洪概率。反之，老化时间太长又可能导致表项过时。我个人习惯在接入层设置300秒，在汇聚层设置600秒。

# 查看MAC地址表
show mac address-table

# 查看广播帧统计
show interface <接口名> | include broadcast

# 查看CPU利用率
show process cpu

# 配置广播风暴控制
interface GigabitEthernet0/1
 storm-control broadcast level 10