3. 交换机转发原理：MAC地址表学习、泛洪机制、广播帧在交换机中的处理流程
聊到广播丢包，咱们得先搞清楚交换机是怎么干活的。很多兄弟一上来就抓包、看计数器，其实根子上的问题往往出在转发原理没吃透。我见过不少案例，查了半天，最后发现是MAC表没学好，或者广播帧处理逻辑搞混了。
说白了，交换机就是个“智能转发器”。它不像HUB那样无脑复制，而是靠一张MAC地址表来做决策。这张表怎么来的？怎么维护的？遇到不认识的目的MAC怎么办？广播帧又是什么待遇？咱们一个一个说。
3.1 MAC地址表的学习过程
交换机刚上电的时候，MAC地址表是空的。它怎么知道哪个MAC在哪个端口？靠“偷学”。
核心逻辑：交换机从某个端口收到一个数据帧，它会提取帧头里的源MAC地址，然后把这个MAC和接收端口绑定起来，写进MAC地址表。
举个例子。假设PC-A连在交换机的G0/1口，PC-B连在G0/2口。PC-A发了个帧给PC-B。交换机从G0/1收到这个帧，一看源MAC是AA:AA:AA:AA:AA:01，立马记下来：
| MAC地址 | 关联端口 | 老化时间（默认） |
|---|---|---|
| AA:AA:AA:AA:AA:01 | G0/1 | 300秒 |
嗯，这里要注意。MAC表不是永久有效的。每条记录都有一个老化计时器，默认300秒（Cisco设备）。如果这个MAC在300秒内没有再发帧，交换机就会把它删掉。为什么？因为网络拓扑会变，设备会换端口，老条目留着反而会出错。
我个人习惯，排查丢包问题时，第一件事就是看MAC表。命令很简单：
show mac address-table
# 或者
show mac address-table dynamic如果发现某个MAC出现在错误的端口上，或者干脆没有，那丢包的原因基本就找到了。
3.2 泛洪机制：当交换机“不认识”目的MAC时
现在问题来了。交换机收到一个帧，目的MAC是BB:BB:BB:BB:BB:02。它查了一下MAC表，没找到。怎么办？
答案很简单：泛洪（Flooding）。
交换机把这个帧从除了接收端口以外的所有端口都发出去。你想想看，这不就跟HUB一样了吗？没错，在“不认识”的情况下，交换机退化成HUB。
避坑指南：我曾经遇到过一个客户，内网经常卡顿，丢包率很高。查了半天，发现是MAC表被撑爆了。原因是有台设备在疯狂发送源MAC随机的垃圾帧，导致交换机不断学习新MAC，同时不断老化旧MAC，CPU负载飙升，正常帧的转发被严重拖慢。
泛洪本身不是问题，它是交换机保证“不漏帧”的一种机制。但泛洪太多，就会变成广播风暴的导火索。尤其是当网络里有环路的时候，泛洪帧会无限循环，瞬间打垮整个网络。
所以，我建议你在排查丢包时，关注一下端口的泛洪计数：
show interface <端口号> | include Flood如果泛洪帧数量异常高，说明MAC表学习出了问题，或者网络里有环路/攻击。
3.3 广播帧在交换机中的特殊待遇
广播帧，目的MAC是FF:FF:FF:FF:FF:FF。交换机怎么处理它？
答案是：无条件泛洪。
不管MAC表里有没有记录，只要收到广播帧，交换机就把它从所有其他端口转发出去。这是广播帧的“特权”，也是它的“原罪”。
为什么会这样？因为广播帧的设计初衷就是“让所有人都收到”。ARP请求、DHCP发现报文，都是广播帧。没有广播，网络就没法正常工作。
但问题也出在这里。广播帧多了，网络就遭殃了。每个广播帧都要被复制到所有端口，占用带宽、消耗CPU。如果广播帧的速率超过一定阈值，交换机的CPU就会忙于处理广播，导致正常数据帧被丢弃——这就是典型的广播丢包。
我的经验：在接入层交换机上，我一般会配置风暴控制（Storm Control），限制广播帧的速率。比如设置一个阈值，当广播流量超过端口带宽的20%时，交换机自动丢弃多余的广播帧。这能有效防止广播风暴波及整个网络。
配置示例（Cisco）：
interface GigabitEthernet0/1
storm-control broadcast level 20
storm-control action shutdown注意，风暴控制是一把双刃剑。阈值设得太低，正常的ARP请求都可能被误杀，导致通信异常。我建议你先做一段时间的基线监控，看看正常情况下的广播帧速率是多少，再据此设定阈值。
3.4 交换机转发流程全景图
为了让你更直观地理解整个过程，我画了一张流程图。它把MAC学习、泛洪、广播处理串在了一起。
3.5 广播帧与丢包的关系
好了，现在我们把广播帧和丢包串起来。广播帧在交换机里走的是“泛洪通道”，这个通道有几个特点：
- 带宽消耗：每个广播帧都要被复制N份（N=端口数-1），占用大量带宽。
- CPU消耗：交换机CPU需要处理每个广播帧，尤其是ARP请求，CPU负载一高，转发性能就下降。
- 队列溢出：当广播帧速率超过端口出队列的深度时，正常的数据帧就会被挤掉——这就是丢包。
实战建议：如果你怀疑广播导致丢包，可以登录交换机，查看端口上的广播计数和丢包计数：
show interface <端口号> | include broadcast|dropped如果广播包数量巨大，同时有丢包计数增长，那基本可以锁定是广播风暴或广播过载导致的丢包。
我记得有一次，一个客户的监控网络频繁丢包。我上去一看，发现所有摄像头都在发广播包，速率高达每秒几千个。原因是有个摄像头的IP地址冲突，导致它不断发送ARP请求。我帮他们划分了VLAN，把摄像头和办公网络隔离开，广播域缩小了，丢包问题立刻解决。
嗯，这就是广播帧在交换机里的完整故事。从MAC学习，到泛洪，再到广播帧的特殊处理，每一步都可能成为丢包的根源。你排查的时候，顺着这个流程走一遍，基本不会漏掉关键点。