Sukka 写前端、网络和基础设施时，习惯先把边界和代价摊开。把「[翻译] 深入了解 Verizon 和 BGP 优化工具是如何导致大部分互联网离线的 | Sukka's Blog」整理成可落地的中文笔记：问题在哪、默认做法会踩什么坑、该怎么选。原站导航和广告已去掉。

让我们回顾一下周一发生了什么

星期一，我们写了一篇关于大规模 BGP 路由泄漏的 文章 。我们在文章中写道，这次事故本来不会发生，因为 Verizon 不应该将这部分路由转发到互联网。文章在 UTC 时间晚上 19 时 58 分，也就是 BGP 路由泄漏之后七个小时（大家将会看到，路由泄漏事件结束的具体时间是 UTC 时间 12:39）发布的。今天，我们将通过对存档的路有数据进行深入研究和分析。我们在文中将会使用大部分读者都能够理解的简单的 Shell 命令，读者们也可以自己对路由表进行调查。

这是一起广为人所知的 BGP 路由泄漏事件，大部分在线新闻媒体都进行了报道。 Andree Toonk 在推特上发布了 2400 个受到影响的 ASN 的列表。

RIPE NCC 的归档数据

RIPE NCC 运营着一个非常有用的 BGP 路由存档，收集全球的 BGP 路由并提供一个公开的 API 用来查询数据。你可以在 https://stat.ripe.net 上找到更多相关信息。在 BGP 的世界中，所有路由都是公开的（任何人都能在其能力范围内收集足够的数据）。存档数据对于研究（比如我们在文章中做的事情）非常有价值。这个网站可以将一些非常有用的数据做成可视化的图表。

目前，RIPEstat 的数据不能实时获取，一般需要等待 8 到 12 小时。RIPEstat 的数据可以通过 Web 界面或者 API 获取。我们通过请求 API 获取到了 JSON 格式的数据。

从 RIPEstat 获取这次事件的相关数据

虽然有很多其它的 ASN 受到本次 BGP 路由泄漏事件的影响，但是我们将只关注关于 Cloudflare 的泄漏路由。我们只处理有限的数据，并聚焦在 Cloudflare 的路由发生了什么。以下所有指令可以在很多系统上运行，我们使用了运行在 MacBook Pro 上的 macOS Mojave。相关脚本和原始数据已经上传到 GitHub。

首先，我们收集了过去 24 小时 来自 AS13335（Cloudflare）的路由宣告和 AS-PATH。

路由泄漏事件发生的时间

$ # 获取 24 小时范围内的数据——大大超过我们需要的 $ ASN = "AS13335" $ START = "2019-06-24T00:00:00" $ END = "2019-06-25T00:00:00" $ ARGS = "resource= ${ASN} &starttime= ${START} &endtime= ${END} " $ URL = "https://stat.ripe.net/data/bgp-updates/data.json? ${ARGS} " $ # 从 RIPEstat 获取数据 $ curl -sS " ${URL} " | jq . > 13335 -routes.json $ ls -l 13335 -routes.json -rw-r–r– 1 martin staff 339363899 Jun 25 08:47 13335 -routes.json 这将下载 340MB 的数据——看起来很多，但是它包含大量空白和大量我们不需要的数据。接下来我们的

$ # 提取时间戳、时间路由和 AS-PATH $ jq -rc '.data.updates[]|.timestamp,.attrs.target_prefix,.attrs.path' < 13335 -routes.json | paste – – – > 13335 -listing-a.txt $ wc -l 13335 -listing-a.txt 691318 13335 -listing-a.txt 现在我们减少到了不到 70 万次路由事件，但是这些并不是 BGP 路由泄漏，而是包括 Cloudflare 的 AS13335 的所有数据。为此，我们回到周一的文章（译者注：即文章开头提到的文章）并且知道 AS396531（Allegheny Technologies）和 AS701（Verizon）出现在了 BGP 路由泄漏中。现在我们可以进一步减少数据：

深入分析 AS-PATH

$ # 提取路径为 701,396531 的数据 $ # AS701 – Verizon，AS396531 – Allegheny Technologies $ egrep '701,396531' < 13335 -listing-a.txt > 13335 -listing-b.txt $ wc -l 13335 -listing-b.txt 204568 13335 -listing-b.txt 现在数据看起来少多了，我们只需要面对 20.4 万个数据点。然而这依然是一个规模很大的数据，因为路由拓扑在发生变化时 BGP 可能会变得非常冗长。这正是 BGP 路由泄漏事件将会导致的情况。现在让我们看看有多少路由收到了影响。

$ # 提取被泄漏事件影响的路由 $ cut -f2 < 13335 -listing-b.txt | sort -V -u > 13335 -listing-c.txt $ wc -l 13335 -listing-c.txt 101 13335 -listing-c.txt 现在数字小多了，我们列出了至少 101 条通过 Verizon 泄漏的路由。这份列表可能并不完整，因为 RIPEstat 这样的路由收集器并不能从 Verizon 直接获得数据，因此这些数据包含的是 Verizon 的路径和其它路径，查看上述文件中列出的 AS-PATH 时能够注意到这一点。

Verizon 应该从他们的客户 AS396531 接收哪些路由？

译者注：在这篇文章首次发布时，译者发现这篇文章中的脚本使用的参数存在错误， -n 这个参数将只能够获取有限的数据，获取全部数据应该使用 -V 参数。 相关资料 可以在 StackOverflow 上查看。文章的作者后来意识到了这个错误并进行了修改。

$ cat 13335 -listing-c.txt 8.39 .214.0/24 8.42 .245.0/24 8.44 .58.0/24 .. . 104.16 .80.0/21 104.17 .168.0/21 104.18 .32.0/21 104.19 .168.0/21 104.20 .64.0/21 104.22 .8.0/21 104.23 .128.0/21 104.24 .112.0/21 104.25 .144.0/21 104.26 .0.0/21 104.27 .160.0/21 104.28 .16.0/21 104.31 .0.0/21 141.101 .120.0/23 162.159 .224.0/21 172.68 .60.0/22 172.69 .116.0/22 .. . 这份列表非常有趣，因为其中一些路由的发起者被标注为 AS13335，但是这些路由并非属于 Cloudflare 的网络。比如我们从未宣告过 104.26.0.0/21 ，但是我们宣告了 104.26

值得单独记下的点

• AS-PATH – 目前为止已经遍历的 ASN 列表
• IETF – 互联网工程任务组，一个开放的标准组织
• RFC – 征求意见稿，由 IETF 发布，被视为规范
• RIPE NCC – 欧洲网路资讯中心，一个区域互联网注册机构
• Tier 1 – 没有默认路由、并且和其它所有 Tier 1 对等互联的网络
• Verizon 应该从他们的客户 AS396531 接收哪些路由？

落地时建议先做的 5 件事

1. 用自己的流量和设备测，不要只抄厂商推荐最小配置。
2. DNS、CDN、代理分流先画清 Fake IP 和 Real IP 的边界。
3. 前端性能看 CLS、白屏和重复渲染，而不是只看打包体积。
4. 基础设施变更走 Git，能复现、能回滚。
5. 结论写成可检查的清单：接口、超时、失败样本、回滚版本。

和智能体产品怎么接

龙虾PRO做 OpenClaw 落地时，网络、DNS 和前端性能笔记最有用的是「边界」：哪一层该加速、哪一层不该假装智能。数字员工调用外部能力前，先把超时和失败路径写死。

本文侧重全链路风控方法论。落地时请用自身业务单据做回放验证，不要把示例阈值直接当生产策略。 相关：风控体检 · 方案资源