两种过滤思路
白名单是默认拒绝、显式放行：边界清晰、能防住意外发布，但漏维护就会误伤；黑名单是默认放行、显式拒绝：变更简单、影响面小，但新情况需要追补规则。运营网络通常按场景组合使用——入向偏白名单更保守，出向偏黑名单更灵活。
基本信息
| 白名单 | 默认拒绝、显式放行，边界清晰 |
|---|---|
| 白名单风险 | 漏维护即误伤，新业务上线前必须先更新清单 |
| 黑名单 | 默认放行、显式拒绝，变更简单 |
| 黑名单风险 | 新情况需要追补规则，存在窗口期 |
| 组合使用 | 入向偏白名单，出向偏黑名单 |
| 文档要求 | 两套策略并存时必须记录每条规则的用途 |
典型使用场景
- 入向净化：只接受已知来源的前缀，防止异常通告
- 出向控制：用黑名单快速阻断已知问题前缀
- 新业务上线：白名单场景要先更新清单再发布
- 排障「某前缀为何被拦」：需要能追溯到具体规则
- 过渡期管理：从黑名单切换到白名单时按客户逐批迁移
两种写法
两种写法
# 白名单风格：默认拒绝，显式放行
ip prefix-list PL-ALLOW permit 192.0.2.0/24
!
# 黑名单风格：默认放行，显式拒绝
ip prefix-list PL-DENY deny 203.0.113.0/24 le 32
ip prefix-list PL-DENY permit 0.0.0.0/0 le 32
!
show ip prefix-list PL-ALLOW
show ip prefix-list PL-DENY两种思路对比
| 思路 | 默认动作 | 优点 | 风险 |
|---|---|---|---|
| 白名单 | 拒绝 | 边界清晰、防意外发布 | 漏维护即误伤 |
| 黑名单 | 放行 | 变更简单、影响面小 | 新情况需追补规则 |
| 两者并存 | 视对象而定 | 兼顾安全与灵活 | 规则来源不清时难以排障 |
| 未命中任何规则 | 取决于平台默认 | 不适用 | 等价于全放行或全拒绝，必须实测确认 |
两种策略并存时必须留文档：排障时说不清某前缀为什么被拦，策略就变成了不可维护的黑盒，变更风险随之上升。
白名单的更新节奏要跟着业务走：新业务先更新白名单再发布，顺序反了就是一次可以预见的故障。