黑洞路由触发后，业务快速恢复的关键动作只有三步：先定位并删除指向Null0的黑洞路由，再通过备用链路或临时静态路由把流量切回正常路径，最后逐条验证路由表和业务端口，确认没有残留黑洞再收工。
黑洞路由触发后的典型表现：先判断是不是黑洞
黑洞路由一旦生效,去往特定网段的流量会被设备直接丢进“黑洞”，表现就是业务端口不通、TCP连接超时，很多运维第一反应是重启设备或整体回退配置，其实没必要，最快的方式是先确认故障特征，再决定是否朝着黑洞路由方向排查。
- 业务突然中断,但设备CPU、内存没有明显升高
- ping目标地址显示超时,而不是“目标不可达”
- traceroute在某一跳之后全部丢包,且最后一跳路由正常
- 只有特定网段或特定服务受影响,其他业务正常
- 近期有人动过静态路由、路由策略或做过防环配置
行业共识认为,黑洞路由大多数用于防环和DDoS防护，真正用于业务隔离的场景较少，一旦出现上述表现，优先怀疑黑洞路由是合理的。
第1步：定位黑洞路由怎么解除最直接
黑洞路由通常下一跳是Null0、NULL0或blackhole，不同设备查黑洞路由的命令不一样，但思路一致：先找出路由表里带Null0的条目，再把它摘掉。
华为设备快速操作路径
先登录设备,进入系统视图。
- 查看路由表中的黑洞路由：
display ip routing-table | include NULL0 - 查看已配置的静态黑洞路由：
display current-configuration | include NULL0 - 删除指定黑洞路由（假设目标网段是192.168.10.0/24）：
undo ip route-static 192.168.10.0 255.255.255.0 NULL0
Cisco设备快速操作路径
- 查看路由表中的Null0条目：
show ip route | include Null0
- 查看运行配置中的Null0静态路由：
show run | include Null0 - 删除对应条目：
no ip route 192.168.10.0 255.255.255.0 Null0
Linux服务器上的黑洞路由
部分业务跑在Linux主机上,也可能配置了黑洞路由。
- 查看blackhole路由：
ip route show | grep blackhole - 删除黑洞路由：
ip route del blackhole 192.168.10.0/24
删除前先备份当前配置,华为设备可执行display current-configuration导出，Cisco用show run保存文本，别小看这一步，不少人删完才发现删错了，恢复起来更麻烦。
第2步：切流前必须分清黑洞路由和策略路由区别
实际故障中,黑洞路由和策略路由经常被混在一起排查，如果没弄清黑洞路由和策略路由区别，很可能在恢复时误删了正常的策略路由，导致业务流量被引到错误出口，中断反而扩大。
黑洞路由的动作是“丢弃”，策略路由的动作是“按规则转发”，两者在路由表里的表现、对业务的影响、恢复方式都不同，下面这张表能快速区分。
| 对比项 | 黑洞路由 | 策略路由 |
|---|---|---|
| 转发动作 | 直接丢弃，不转发 | 按匹配规则转发到指定下一跳或出接口 |
| 路由表显示 | 下一跳为Null0/blackhole | 通常不直接出现在普通路由表，需查策略 |
| 业务表现 | 目标网段完全不通 | 部分流量走错路径，可能通可能不通 |
| 恢复操作 | 删除黑洞路由条目 | 修改或删除策略路由规则 |
| 误删后果 | 恢复正确流量 | 可能把流量引向错误线路，扩大故障 |
在删除任何路由条目之前,先确认它是黑洞路由还是策略路由，华为设备可执行
display ip routing-table查看下一跳是否为NULL0，Cisco看下一跳是否为Null0，策略路由要查display traffic-policy applied-record或show route-map，不要看到类似网段就删。
第3步：运营商黑洞路由怎么处理更稳妥
有些黑洞路由不是企业自己配的,而是运营商下发的，比如遇到DDoS攻击，运营商会临时把被攻击IP指向黑洞，保护上游网络，这种情况下，企业内部怎么删都没用，因为黑洞在运营商侧。
运营商黑洞路由怎么处理更稳妥？按下面顺序来，能少走很多弯路。
- 先自查本端设备：确认是否有
ip route 目标网段 Null0这类静态配置，如果有，先删除并测试。 - 再看链路流量：监控接口流量是否突然降到接近零，如果是，大概率是上游黑洞。
- 联系运营商NOC：明确告知业务中断时间段、被影响网段、本端设备型号和已做的操作，申请解除黑洞。
- 提供恢复证明：部分运营商要求企业确认攻击已停止或流量已清洗，才解除黑洞，提前准备好流量监控截图。
- 解除后观察BGP：若走BGP，执行
display bgp routing-table或show ip bgp，确认路由重新学习、下一跳正常。
北京、上海多个IDC机房在业务高峰期都遇到过运营商黑洞误触发的情况，处理时最怕两边同时改配置，导致路由震荡，企业内部先完成自查，再联系运营商，恢复速度通常更快。
验证清单：恢复后别急着收工
黑洞路由删除后,业务不一定立刻全通，还要做几项验证，防止“看起来恢复了，实际还有残留”。
- 再查一遍路由表：华为
display ip routing-table | include NULL0，Ciscoshow ip route | include Null0，确认没有新的黑洞路由。 - 从业务侧连续ping目标地址：至少持续30秒，观察丢包情况，不要只ping一个包就下结论。
- 走一遍业务关键端口：比如TCP 443、数据库端口3306、Redis端口6379，用
telnet 目标IP 端口测试连通性。 - 查会话和连接数：如果业务依赖长连接，看连接是否重建，部分应用需要重启客户端或清理连接池。
- 记录恢复时间点：方便后续回溯，避免同一问题反复出现。
这一步不用太长,但每项都要实际执行，相当一部分业务恢复不彻底，就是因为漏了最后一公里的端口验证。
小结：先摘路由，再切流量，后查根因
黑洞路由触发后的恢复,本质上不是高深技术活，而是顺序问题，先删除或申请解除黑洞路由，再通过备用链路把业务流量引回正常路径，最后验证路由表和业务端口，顺序错了，恢复时间就会成倍拉长。
黑洞路由恢复常见问题Q&A
黑洞路由怎么解除后业务还是不通？
多数情况下是删错了路由条目,或者存在多条黑洞路由，重新用display ip routing-table | include NULL0或show ip route | include Null0检查，确认没有残留，再查下一跳是否真实可达，部分场景需要手动添加临时静态路由把流量引回出口。
运营商黑洞路由怎么处理能减少业务中断时间？
提前和运营商约定黑洞触发阈值,并部署流量清洗服务，恢复时，企业内部先完成路由切换，再联系运营商解除黑洞，避免两边同时操作导致路由震荡，已有不少企业把这一流程写进应急预案，实际中断时长明显缩短。
黑洞路由和策略路由区别会影响恢复排错吗？
会,黑洞路由删除后流量直接恢复，策略路由删错后可能把流量引向错误线路，排错时一定要先确认下一跳是Null0还是具体地址，再决定删不删，这个区别没搞清楚，恢复动作本身就可能是二次故障的来源。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/656292.html
