MAC 地址表是交换机转发数据的"通讯录"——它记着每个终端的 MAC 地址该从哪个口出去。表一旦写满，新出现的 MAC 就学不进去，目的地查不到的帧只能被丢向所有端口。结果不是"断网"，而是广播式泛洪、带宽被吃、排查时一头雾水。
▲ 图1：表满之后，查不到目的 MAC 的单播帧只能泛洪出去，原本点对点的流量变成全网广播。
二层工业交换机在数据链路层干活，转发依据就是这张表。标准里叫 FDB（转发数据库），硬件上落在 CAM/TCAM 这类能并行查找的存储器里。学习过程很直接：收到一帧，把"源 MAC + 入端口"写进表；转发时查"目的 MAC"对应哪个口，命中就单播出去，没命中就泛洪。
表里每条记录都带一个老化计时器，默认 300 秒（IEEE 802.1D 的规定值）——这段时间没再见过这个 MAC，记录就被清掉，腾出位置给新终端。
表被打满后，交换机还能正常转发表里已有的那些 MAC，这部分流量不受影响。麻烦出在"新面孔"：一台没在表里的终端发出帧，交换机查不到目的 MAC，按规则只能泛洪到除入端口外的所有口。表满的时间越长，被泛洪的"未知单播"越多，原本该点对点走的流量变成了全网广播。
广播风暴本来就跟表满无关（广播帧任何时候都泛洪），但表满会让"单播被迫泛洪"叠加上来，雪上加霜。很多现场把卡顿怪到带宽不够，问题可能就是在mac表。
接入层工业交换机常见 8K–16K 表项，看着不少，可一旦环路或攻击，几分钟就能写满。
各档次的量级
档次 | MAC 表容量 | 典型位置 | 默认老化 | 表满后行为 |
非网管 / SOHO | 1K–4K | 桌面、小办公室 | 300s | 泛洪 |
接入层工业交换机 | 8K–16K | 车间接入、PoE 接终端 | 300s | 泛洪 + 停止学习新 MAC |
三层 / 汇聚 | 32K–64K | 核心、VLAN 间路由 | 300s | 泛洪 |
核心 / 数据中心 | 128K–1M | 骨干、大二层 | 300s | 泛洪 |
一台接入层工业以太网交换机，表项标称 8K 看着够用，可一旦环路或攻击，300 秒老化期内表项可能几分钟就打满，之后所有新终端的流量都走泛洪。
▲ 图2：从 SOHO 到核心，MAC 表容量跨度可达两个数量级以上，选型时得按终端规模留余量。
老化时间设的是"多久没通信就忘掉这个 MAC"。300 秒是出厂默认，多数管理型交换机能改成 10 秒到上百万秒。把老化调短（比如 60 秒），好处是终端搬家后表更新快；坏处是活跃终端也会被频繁清掉再学，表项一直抖，未知单播变多。把老化调长（比如 1 小时），表更容易被"僵尸地址"占满，真满的时候更难腾位置。
所以老化时间不是越小越好，得按终端流动频率定：工位固定的工厂，可以长一点；手机、AP 频繁漫游的场所，反而适合短一点。
Cisco 系看 show mac address-table count 和 show mac address-table aging-time；
华为系看 display mac-address 和 display mac-address aging-time；
Linux 网桥用 bridge fdb show。三个现象叠在一起基本能确诊：
a.日志里出现 "MAC table full" 之类告警；
b.端口"未知单播 / 泛洪"计数持续上涨；
c.交换机 CPU 莫名其妙偏高（部分机型会把泛洪帧送 CPU 软处理）。
锐应科技的工业以太网交换机 也按这套思路提供了表项计数和告警，排障时先看计数再下结论，比盲测快得多。
有个常见误解：表满了交换芯片转发就变慢。硬件转发对"表里已有的流量"几乎零影响，查表是线速的。真正掉速的是泛洪带来的连锁反应——未知单播占满上联带宽、广播域里每台设备都得处理这些无关节帧、部分机型泛洪帧还要进 CPU。
所以表满的症状通常是"某些业务卡顿、ping 抖动、录像丢帧"，而不是"全端口速率腰斩"。这也解释了为什么工业现场宁可上锐应科技 的大表项机型，也不愿在接入层将就小表——省下的那点成本，远不够一次全网卡顿的排障工时。
1、环路 / 自环：两台交换机之间多出一根线、又没开 STP/RSTP/ERPS，广播帧绕圈，MAC 被反复学成不同端口，300 秒老化期内表项快速打满。一个 64 路摄像头的车间，若某台接入交换机和上行之间自环，监控 VLAN 里很快就能看到卡顿。
2、终端 MAC 漂移：虚拟化、手机频繁漫游、双网卡绑定配错，同一 MAC 在多个口来回跳，表项频繁刷新也吃资源。
3、故意攻击：MAC 泛洪攻击就是拿一堆假源 MAC 狂发帧，把表填满让后续流量全泛洪，方便嗅探。
4、静态 MAC 绑太多：给关键设备做静态绑定固然稳，但静态项也占表，绑过头反而挤占动态空间。
1、先治环路：接入层老老实实开 RSTP/ERPS，多余的线别乱接。
2、缩广播域：按业务切 VLAN、划子网，单台交换机要记的 MAC 立刻少一截。
3、上 IGMP Snooping：组播流量别让它也跟着泛洪。
4、关键设备静态绑定 + 端口安全：限制单端口能学的 MAC 数，既防攻击又控表项。
5、实在不够就换大表机型：接入层从 8K 升到 16K、核心上 64K 以上，余量就出来了。接入层多用工业POE交换机给摄像头供电时，更要把表容量和终端数对齐。
MAC 地址表和 ARP 表是一回事吗？
不是。MAC 表是二层转发用的，记 MAC 和端口；ARP 表是三层用的，记 IP 和 MAC 的对应关系。三层交换机两块表都有，各管各的层。
表满了会丢包吗？
已知 MAC 的流量正常转，不丢。被泛洪的未知单播一般也不直接丢，而是占用带宽；只有当上联或背板被泛洪吃满、出现拥塞时，才会在队列里丢。
老化时间调到 0 会怎样？
很多设备里"0"表示不老化（永久保留），表项只增不减，最容易导致慢慢写满。别随便设 0。
家用小交换机需要关心这个吗？
基本不用。家里十来个终端，表才几千项，根本填不满。这个话题主要是企业网、工业现场、数据中心那种终端多、VLAN 多、还可能被攻击的场景才要紧。
MAC 地址表满了不会直接断网，代价是未知单播泛洪把带宽和 CPU 拖下水，排查时先看表项计数和告警最省时间。选设备时把表容量和终端规模对齐，比事后救火划算得多。
本文由专注工业通信设备的锐应科技整理。了解更多产品方案可访问锐应科技官网 www.szrayin.com。
