攻击流量已经压满链路时，先要判断是清洗、限流还是隔离目标。防护平台与运营商黑洞路由的攻击应急协作，重点不是单方面提交一条路由，而是把攻击证据、目标前缀、执行权限和撤销条件说清楚。以下五步适用于不同规模的网络；具体路由策略以运营商实际支持的方式为准。
第一步：确认攻击对象与影响范围
先从防护平台告警、边界路由器流量统计和业务监控中确认受影响的公网地址、协议特征及持续状态。区分单个主机、一个网段还是多个业务地址受影响，避免把正常服务地址一并隔离。记录攻击开始时间、流量方向、主要源地址分布和业务表现；源地址可能被伪造，不应仅凭来源封禁。
同时确认目标地址归属及路由发布权限。若地址由云服务商或上游网络代为公告，需联系实际控制该前缀的一方。未确认授权前，不要自行向外发布路由。
第二步：建立双方一致的应急信息
通过事先约定的值班电话或工单渠道联系运营商，提供可执行的信息：受影响前缀、攻击现象、期望处置方式、业务影响和回拨联系人。防护平台与运营商黑洞路由的攻击应急协作应使用统一的事件编号，避免电话、邮件和工单中的目标地址不一致。
明确由谁提交申请、谁批准、谁执行，以及何种信号可以开始撤销。若运营商要求提供路由社区值或专用工单字段，应以其正式操作说明为准；不同网络的策略可能不同。
第三步：选择黑洞范围与发布方式
先比较止损范围
黑洞路由会把匹配目标地址的流量丢弃，因此能快速保护共享链路或其他服务，却也会让被指定的合法流量无法到达。目标越精确，附带影响通常越小；但运营商可能只接受符合其策略的前缀长度。IPv4 单地址常见表示为 /32，IPv6 单地址为 /128，是否接受仍取决于上游过滤规则。
远程触发黑洞（RTBH）通常通过 BGP 路由及运营商约定的社区标记触发。RFC 7999 定义了 well-known 黑洞社区 65535:666，但不能据此假设每家运营商都会接受该标记；应先确认双方的社区值、前缀限制和授权流程。若攻击流量可以被清洗且链路尚有余量，优先评估引流清洗，黑洞更适合必须迅速隔离的情形。
第四步：发布路由并核验实际效果
- 复核目标：两方逐字确认地址、前缀长度和影响业务，尤其核对是否误包含共享入口或其他客户地址。
- 执行变更：由有权限的一方按运营商流程发布黑洞路由或启用约定策略，并记录操作人、时间和变更编号。
- 观察结果：查看边界路由状态、上游确认信息、防护平台流量变化及业务探测结果。路由被接受不等于所有路径都已生效，传播范围和收敛时间会受网络策略影响。
- 检查副作用：确认攻击目标流量下降的同时，未受影响的前缀仍可访问；如正常业务也被丢弃，立即按约定升级处置。
第五步：达到条件后撤销并复盘
撤销不能只看告警暂时变绿。结合攻击流量、链路余量、清洗状态和业务探测，按双方约定的观察条件决定恢复；若攻击反复出现，可先评估清洗或更细粒度策略，再决定是否重新隔离。撤路由后继续核查可达性，防止路由残留或业务恢复不完整。
将申请记录、路由变更、验证结果和撤销时间归档，补齐下一次应急所需的联系人、授权人、支持前缀范围及社区配置。防护平台与运营商黑洞路由的攻击应急协作，最终要沉淀为可复用的联络表和变更清单，而不是临场猜测操作参数。
常见问题
黑洞路由会清洗攻击流量吗？
通常不会。它的主要作用是丢弃发往指定目标的流量，不等同于识别并过滤恶意请求的流量清洗。
可以直接对整个网段黑洞吗？
只有在确认影响范围、地址归属和授权后才考虑。网段越大，误伤合法业务的可能性越高，也可能不符合运营商的路由策略。
攻击停止后是否应立即撤销？
不宜仅凭单次告警判断。应结合持续流量观察、链路状态和业务探测，并与运营商确认撤销操作及验证结果。
运营商不支持约定社区值怎么办？
改用其认可的工单或应急接口，并确认可接受的前缀格式、审批要求和执行回执；不要自行尝试未获确认的路由标记。