用计数验证策略
策略类配置是否真正生效，靠计数器判断最快。每条 ACL 条目在设备上通常都有匹配次数，为关键条目加上日志或统计后，间隔两次采样对比增量，就能区分「完全没有匹配上」和「匹配上但后续被丢弃」这两种完全不同的原因。需要注意的是列表末尾的隐含拒绝通常不计入任何条目：报文被默认丢弃时，你会看到所有条目计数都不增长，却找不到是哪里丢的。高流量接口上开启日志也要谨慎，日志量会迅速淹没真正有价值的信息。
基本信息
| 查看方式 | 显示整个 ACL 的条目与匹配计数 |
|---|---|
| 采样方法 | 间隔一段时间取两次，比较增量而非累计值 |
| 日志方式 | 在关键条目加日志关键字，注意条目数量与流量规模 |
| 隐含规则 | 列表末尾的默认拒绝通常不单独计入可见计数 |
| 平台差异 | Cisco 用 show ip access-lists，华为用 display acl |
典型使用场景
- 策略不生效排查：区分未匹配与匹配后被丢弃
- 放行确认：验证新加的白名单条目是否被命中
- 安全审计：确认异常来源确实被拦截条目命中
- 变更验证：改动前后对比各条目命中分布变化
- 冲突排查：发现某条位于前面的条目抢占了本应放行的流量
示例
示例
# 第一次采样
show ip access-lists WAN-IN
# 间隔一段时间后第二次采样，逐条对比增量
show ip access-lists WAN-IN
# 华为
display acl 3000
# 命中为零的条目：先确认匹配条件与流量方向是否正确结果与判断
| 观察结果 | 含义 | 下一步 |
|---|---|---|
| 目标条目计数增长 | 策略已命中，按预期处理 | 继续验证后续动作是否正确 |
| 目标条目为零但业务不通 | 流量未走到该 ACL 或方向配反 | 检查应用接口与方向 |
| 所有条目均为零 | 可能被隐含拒绝丢弃 | 补充显式拒绝条目以便观察 |
| 前序条目增长异常 | 条目顺序存在问题 | 调整顺序并重新验证 |
ACL 的匹配是自上而下逐条判断，调整顺序等同于改变策略语义；改动前把当前计数留档，便于对比确认影响范围。
在高流量接口上给命中频繁的条目标记日志，会产生极大量日志，可能拖慢设备并让日志系统失去价值。