未命中时怎么处理
ACL 里所有规则都没命中时设备怎么办，这是三厂最容易出差异的地方。思科的末条是隐式拒绝所有，配了 permit 就等于拒绝其余全部；华为与 H3C 的缺省行为随版本与引用场景变化，工程上统一在末尾显式写一条兜底规则，行为才完全可控。判断标准只有一句：ACL 写完以后，未列出的流量到底按理会被放通还是被拦掉，必须能明确说清。
基本信息
| 适用平台 | 华为 VRP、思科 IOS、H3C Comware |
|---|---|
| 思科行为 | 末尾隐式 deny any，规则表末尾自动拒绝全部 |
| 华为与 H3C 行为 | 按版本与引用场景有差异，建议显式写兜底规则 |
| 工程做法 | 无论哪家设备，ACL 末尾都显式写出兜底动作 |
| 核对方式 | 用规则计数配合测试来源验证未列出的流量是否按预期处理 |
典型使用场景
- 收紧访问控制时，明确哪些来源被排除在外
- 配置 NAT 源选择时，确认不需要转换的流量确实未被纳入
- 路由策略里筛选路由条目，未匹配的路由按缺省行为处理
- 安全审计时逐条说明每个 ACL 的缺省动作
- 跨厂商迁移配置时，把上游设备的隐式行为在新设备上显式写出来
华为 VRP
华为 VRP
acl number 2000
rule 5 permit source 192.168.1.0 0.0.0.255
rule 100 deny # 显式兜底，不依赖缺省行为
display acl 2000 # 查看规则与命中计数
# 若策略本意是只拦少数来源，兜底应写成 rule 100 permit思科 IOS
思科 IOS
ip access-list standard 10
permit 192.168.1.0 0.0.0.255
! 末尾隐式 deny any：其余来源全部被丢弃
show ip access-lists 10 # 每条规则的匹配计数可判断命中情况
! 若只想拦少数来源，必须在末尾显式 permit anyH3C Comware
H3C Comware
acl basic 2000
rule 5 permit source 192.168.1.0 0.0.0.255
rule 100 deny # 显式兜底
<H3C> display acl 2000缺省行为对照
| 对比项 | 思科 IOS | 华为 VRP | H3C Comware |
|---|---|---|---|
| 未命中时的默认动作 | 隐式拒绝全部 | 随版本与引用场景不同，需显式写 | 随版本与引用场景不同，需显式写 |
| 写兜底的必要性 | 可写可不写，写了更直观 | 强烈建议显式写 | 强烈建议显式写 |
| 兜底放行写法 | permit ip any any | rule 编号 permit ip | rule 编号 permit ip |
| 兜底拒绝写法 | deny ip any any | rule 编号 deny ip | rule 编号 deny ip |
| 核对方式 | 规则匹配计数 | 规则匹配计数 | 规则匹配计数 |
工程做法
- 写规则前先明确本意：是要只放通少数还是只拦截少数，两种意图的兜底方向相反
- 无论厂商如何，末尾都显式写出兜底动作，配置换设备或换版本时行为一致
- 多条 ACL 用于不同场景时分别确认：接口过滤、源地址转换与路由策略的缺省动作互不通用
- 上线前用未列出网段做验证：确认其被拦或被放通符合设计，这是唯一可靠的确认方式
- 把每个 ACL 的缺省动作写进变更文档，交接与审计时不用重新推演
依赖缺省行为是配置事故的常见来源：同一份 ACL 在接口过滤里表现为只放通少数来源，被 NAT 引用时可能表现为只转换少数来源，语义随引用场景漂移。显式兜底能把行为钉死。
规则匹配计数可以用来验证兜底规则是否真的在工作：如果兜底规则的计数持续增长，说明前面几条规则覆盖的范围与业务实际需求存在偏差，值得回头核对。