源站带宽被打满时的上游黑洞路由应对，重点不是“把流量挡掉”这么简单，而是确认丢弃范围、按上游规则触发路由，并安排好恢复。黑洞路由通常会让发往某个目标地址的流量在运营商或网络服务商侧被丢弃，因此恶意流量和正常用户流量都可能无法到达源站。
如果攻击流量已经占满源站接入链路，只在源站设备上加过滤规则通常无法腾出上游带宽；此时才需要评估上游处置。以下五步可作为应急流程，具体命令、前缀和权限以服务商的书面策略为准。
第一步：确认带宽瓶颈和受影响范围
先区分链路打满、设备处理能力不足和单项服务异常。查看网络设备的接口流量、丢包与错误计数，并对照监控中的入方向带宽曲线；同时确认受影响的是单个源站地址、同一网段，还是多个服务。不要仅凭访问变慢就下黑洞决定。
还要确认目标地址是否专用于该源站。若它与其他客户或服务共用，黑洞可能把无关业务一起切断。记录事件开始时间、流量方向、目标范围和已观察到的现象，供上游核对。
第二步：查明上游触发方式并建立授权
联系提供接入或传输服务的上游，确认是否支持远程触发黑洞（RTBH）、通过 BGP community 标记触发，或必须由其值班人员代为操作。BGP community 的取值和生效范围由各服务商定义，不能照搬其他网络的配置。
提前核对账号权限、紧急联系人、可公告的地址前缀、最大前缀长度及撤销方法。部分网络仅接受已登记的目标前缀；常见的单地址前缀格式是 IPv4 /32、IPv6 /128，但上游不一定接受客户自行公告这些更具体的路由，需以对方策略为准。
第三步：按最小范围触发黑洞
确定受攻击且获准处置的最小目标后，按上游指定方式提交请求或发出路由。提交时明确目标、业务影响、开始时间、操作人和计划复核时间；若由上游代操作，应让对方复述生效对象，避免误将整个网段列入黑洞。
如果正常访问必须保留，应先询问上游是否提供流量清洗或其他定向缓解方案。黑洞路由的特点是简单、见效路径短，但不会识别流量好坏；流量清洗通常尝试过滤攻击、保留合法请求，不过是否可用、切换方式和恢复时长都取决于具体服务。
第四步：验证路由已生效，并观察副作用
触发后不要只看源站流量下降。请上游确认路由已在其网络中生效，同时检查链路利用率、丢包和其他业务可达性。若有独立于受影响链路的管理通道，可从外部监测点确认目标不可达是否符合预期，并观察同网段其他服务是否仍正常。
若带宽仍高，攻击可能指向其他目标，或流量经过不同上游；若正常业务也中断，先核对黑洞范围与共享地址情况，不要未经确认反复扩大公告范围。需要更细粒度匹配时，可咨询是否支持 BGP FlowSpec 等能力，但须确认双方实现、规则限制和风险控制。
第五步：确认风险解除后撤销并复核
黑洞不应长期保留。与上游确认攻击流量已降到可接受范围，再按原通道撤销路由或请求解除标记；随后核对路由状态、链路流量和业务探测结果。恢复后分阶段观察一段时间，若流量再次飙升，重新评估清洗或限流方案，而不是默认再次黑洞同一范围。
事件结束后记录触发与撤销时间、上游响应、影响范围和改进项，并确保值班人员能找到操作权限与撤销流程。这样，源站带宽被打满时的上游黑洞路由应对才不仅能快速止损，也能避免误伤持续扩大。
常见问题
黑洞路由会只丢弃攻击流量吗？
通常不会。它按目标路由丢弃流量，发往同一目标的正常请求也可能受影响。
源站本地加规则能替代上游黑洞吗？
若接入链路已经饱和，本地规则通常不能释放上游链路容量。应联系上游评估黑洞或清洗。
什么时候可以撤销？
应结合流量监测、上游确认和业务探测判断；不要仅因源站暂时恢复就立即撤销。
能否直接公告 /32 或 /128？
这取决于上游的路由接收策略和授权配置。先确认允许的前缀与触发方式，不要自行假定公告一定生效。
