ACL 在配置层面看起来是"想加多少加多少"，在硬件层面却是有限资源。每条规则要落进 TCAM（三态内容寻址存储器），容量是出厂就定死的。理解这个约束，才能解释为什么一台标称支持 4K ACL 的交换机，实际加到 300 条就再也加不进去。
普通内存是"给地址取数据"，一次访问一个地址。TCAM 是"给内容找地址"，把待查的键值和表里所有 entry 同时比较，单周期返回第一个匹配项。它每个 bit 有三种状态：0、1、X（don't care）。X 是它能做通配的原因——permit 10.1.0.0 0.0.255.255 里的掩码在硬件里就是一批 X。
代价是密度。一个 TCAM bit 需要约 10–16 个晶体管，而 SRAM bit 只要 6 个。同样面积下 TCAM 容量只有 SRAM 的几分之一。这就是为什么交换机内存有几个 GB，TCAM 只有几千条。
另一个特性是"必须整块分配"。TCAM 通常按固定大小的 block 划分，常见 128 或 256 entry 一块。一条 ACL 即使只有 1 条规则，也要占掉一整个 block。这个特性造成的浪费，比规则本身的数量影响大得多。
不是一对一。以下几种情况会放大消耗：
带计数器的 ACE 在某些平台占 2 个 entry（一个匹配、一个计数）。带端口范围的规则会被展开——permit tcp any any range 1000 2000 在硬件里要拆成多条，具体条数取决于范围和芯片的编码能力，常见是拆成 8 条或 16 条。带 TCP flag 组合的规则同样要展开。
IPv6 ACL 的消耗通常是 IPv4 的 2–4 倍，因为地址宽度从 32 bit 变成 128 bit，一条 IPv6 规则在 TCAM 里要横向占多个 entry 的宽度。
端口安全是隐形消耗大户。每个被允许的 MAC 地址会生成一条 MAC ACL 规则，24 个端口每口允许 4 个 MAC，就是 96 条。如果配置成"学习后转静态"，运行一段时间后 MAC 数量会随终端增长。
QoS 分类器和策略路由也吃同一块 TCAM。很多现场只盯着"ACL 有多少条"，忘了 QoS 的 8 个优先级、CoPP 的十来条协议限速、以及策略路由的下一跳表，全都在同一个池子里。
| 规则类型 | 典型 entry 消耗 | 放大因素 |
|---|---|---|
| 单条 IPv4 ACE（精确匹配） | 1 | 基本无 |
| 单条 IPv4 ACE（带计数器） | 2 | 平台相关 |
| 带端口范围的 ACE | 8–16 | 范围跨度越大越多 |
| 带 TCP flag 组合的 ACE | 2–4 | flag 组合数 |
| 单条 IPv6 ACE | 2–4 | 地址宽度 128 bit |
| 端口安全 MAC 规则 | 1 / MAC | 每端口允许数 × 端口数 |
| QoS 分类器 | 1–2 / 类 | 优先级数 × 匹配条件数 |
| CoPP 分类 | 1 / 协议类 | 协议分类粒度 |
这条最容易被忽略。假设 TCAM 1024 entry，按 128 entry 一个 block 划成 8 块。你写了一条只有 4 条规则的 ACL，它占掉 1 个 block，浪费 124 entry。再写一条 10 条规则的 CoPP ACL，又占 1 个 block，浪费 118。
四个功能各占一块，就用掉 512 entry，而实际规则只有 126 条。利用率 24.6%。这时候管理界面上可能显示"TCAM 使用 50%"，看起来还有余量，但剩下的 4 个 block 每个只有 128 entry，任何一条超过 128 条规则的 ACL 都放不进去。
所以判断余量不能看百分比，要看"还有几个完整的 block"。这个数字多数平台不直接显示，只能通过尝试下发一条测试 ACL 来探测。
三种表现，取决于平台实现。
第一种，明确报错。CLI 返回类似 Error: ACL resource exhausted 的提示，或者 SNMP Trap 上报。这是最友好的，至少你知道没生效。
第二种，接受配置但不下发硬件。配置写进了 running-config，show running-config 里能看到，但 show acl resource 显示未安装。流量按默认动作处理——通常是放行。安全策略形同虚设，而且从配置上看不出任何异常。这是最危险的一种。
第三种，挤掉最老的规则。新规则下发成功，老的规则被静默删除。表现是"上周还能拦住的流量，这周突然通了"，而且没有任何日志。
区分方法只有一个：下发后立即查硬件安装状态和命中计数。如果规则在配置里但命中计数始终为 0，基本可以判定没进硬件。
| 表现 | 配置层可见 | 硬件层可见 | 风险 |
|---|---|---|---|
| 明确报错 | 配置失败 | 未安装 | 低，能立刻发现 |
| 接受但不下发 | 配置成功 | 未安装，命中 0 | 高，安全缺口无感知 |
| 挤掉老规则 | 配置成功 | 老规则消失 | 高，故障延迟出现 |
一台 24 口接入交换机，TCAM 1024 entry，block 大小 128，共 8 块。规划四类策略：
端口安全：24 口 × 每口 4 个允许 MAC = 96 条，占 1 block（128 entry）。 服务器放行 ACL：允许 3 个网段、拒绝其余，共 4 条，占 1 block。 QoS 分类：8 个优先级 × 2 个匹配条件 = 16 条，占 1 block。 CoPP：10 类协议限速 = 10 条，占 1 block。
已用 4 block = 512 entry，实际规则 96 + 4 + 16 + 10 = 126 条。剩余 4 block。
现在加一条业务 IP ACL，200 条规则。按 128 entry 一块算，200 条需要 2 块，占用 256 entry。剩余 2 block。
再加一条 IPv6 ACL，50 条规则，按每条展开 3 entry 计 = 150 entry，需要 2 块。剩余 0 block。
此时总规则数 = 126 + 200 + 50 = 376 条，TCAM 全满。表面利用率 376 / 1024 = 36.7%，但一条新规则都加不进去了。如果再有一条 20 条规则的 ACL 要下发，就会触发前面说的三种表现之一。
这个算例说明两件事：一是容量数字（1024）和可用规则数（376）之间没有线性关系；二是规划时要按"每个功能占几个 block"来算，不是按"总共有多少条规则"。
写法上有四个直接有效的手段。合并同网段规则，把 5 条相邻的 /24 合并成 1 条 /21 加例外；把最常用的规则放前面，命中即停，减少后续比较（这不省 entry，但省查找延迟）；避免端口范围，用服务组或应用识别替代；IPv6 策略尽量在边界设备做，接入层只做 IPv4。
上线前必须做三件事。第一，查硬件安装状态，确认每条 ACL 的 installed 标志为真。第二，查命中计数，下发后打几条测试流量，计数应该增长。第三，留出至少 2 个 block 的余量给后续变更，不要等满了再想办法。
设备侧的差异很大。锐应的 8+4 口千兆工业交换机（PoE 可选）在网管界面里把 ACL 资源占用单独列出来，能看到已用 entry 和剩余 block，配合 工业交换机 产品线的 ACL 配置模板，可以在规划阶段就把 block 算清楚；PON 侧的类似资源约束体现在业务模板数量上，锐应 PON 与 OLT 方案 里有对应说明。
不能。TCAM 是芯片内部的物理资源，出厂定死。能做的只有优化规则、把策略上移到其他设备、或者换一台 TCAM 更大的机型。
可能是平台把 ACL 截断到某个长度，也可能是 TCAM block 只够装 100 条。查硬件安装状态和每条规则的命中计数，哪条计数为 0 就是没生效的那条。
按"每端口允许 MAC 数 × 端口数"算。24 口每口 4 个 MAC 是 96 条，占掉一个 128 entry 的 block。如果允许数提到 16 个，就是 384 条，要占 3 个 block。
不影响 entry 数量，影响查找延迟和命中分布。首条匹配意味着命中后立即返回，把高频规则放前面能减少平均比较次数。但每条规则占的 entry 数不变。
三个信号：硬件安装标志为真、规则命中计数随测试流量增长、以及接口上抓包验证实际丢弃行为。只看 show running-config 里有没有那几行配置是不够的。
TCAM 是一项必须提前规划的资源，而不是配完再看。按 block 算余量、下发后查硬件安装状态，这两个习惯能避免绝大多数静默失效。锐应科技的工业交换机在网管界面里直接显示 ACL 资源占用，便于规划阶段核对。
