我没租 IP，怎么突然多了三个 /24？
前两天突然收到 bgp.tools 的通知，说有几个 IPv4 段子的记录指向了我的 ASN。打开一看，好家伙，一来就是三个 /24：
我最近也没租这些 IP 啊，哪里冒出来的？？？
仔细看，通知里面有新建的 IRR route 对象，也有签发 ROA 的记录，目标都写着我的 AS204535。看起来像“突然有人给我下发了三个段子”，实际收到的是注册和授权记录的变更通知，当然不会有人看我顺眼就送我三个 /24，哈哈哈。
顺手查了一下 WHOIS 和相关记录，又看到了 IPXO 的名字。这几个段子都有 IPXO 相关的登记信息，看起来和 IP 租赁有关。
一开始我还真没太在意。之前接触过租 AS 的猎头，我以为是他们又拿去用了，心想怎么这次连招呼都没打。
结果后来发现，并不是我以为的那回事。
越看越不对劲
继续翻下去，发现这些记录也不只指向我的 ASN，还出现了孟加拉的 AS136809，FAST ZONE IT。
当时查到的三个段子都有分别指向 AS204535 和 AS136809 的 IRR route 对象。45.155.242.0/24 和 172.83.188.0/24 还查到了给这两个 ASN 的 ROA。至于 77.216.0.0/24，虽然通知历史里出现过签发 ROA 的消息，但我实际检查时的 RPKI 状态是 NotFound，不能直接说三个段子一直都有有效 ROA。
同一个段子给多个 ASN 做登记、授权，本来就可以有正常用途。但现在的问题是：连我自己都不知道这些东西是怎么挂到我名下的。
光看这些记录，还不能认定两个 ASN 是同一个人在操作，也不能认定它们当时一定在同时广播。IPXO 出现在记录里，同样不代表事情就是 IPXO 主动安排的。只是这一圈看下来，我已经很难把它当成一个普通的配置小失误。
具体拿这些 IP 去做什么，我没有证据。只是没跟我讲，就让路由带着我的 ASN 在外面跑，这种操作怎么看都不太像什么好事。之后真出了什么问题，别人查到的 origin 可是我的名字啊……
再看公网路径，还有更有意思的东西。当时能看到这样的 AS_PATH 尾部：
… → AS174（Cogent）→ AS401322（NetO Corp）→ AS204535（我）我自己又没有接这条上游，结果在外面看起来，像是我通过它在发布这些路由。
这也是这次让我觉得离谱的地方：路径最后写着我的 ASN，并不能证明这条路由真的从我的机器发出来。RPKI 的起源验证主要核对前缀、origin ASN 和长度；即使检查通过，也没有把整条 AS_PATH 的真实性一起担保下来。RFC 6811 讲的就是这个起源验证范围。
于是，我开始跟“自己”抢路由
后来我在自己的 Advin Johor 节点把这三个 /24 播了出去。中间也撤过一次，之后又恢复了公告，继续观察两边的变化。
我这边的公网路径主要是：
AS204535（我）→ AS206216（Advin）→ AS137409（GSL）→ 外部网络上面是从起源往外画的传播方向，跟 Looking Glass 里从观察点读回 origin 的 AS_PATH 顺序相反。
刚开始我抽查到的情况，大致就是欧美不少节点走 Cogent 那一边，亚洲不少节点走我的 Advin / GSL 这一边。同一个前缀、同一个 origin，流量却可以跑去不同的地方。
一开始两边都还在场：对面走 NetO / Cogent，我这边走 Advin / GSL。看着这张拓扑，颇有点“火力均摊，一人一半”的意思，哈哈哈。
对方那边的 .1 当时还能回应 ping。我这边虽然已经在播段子，机器上却还没绑这些 .1 地址。
然后朋友跟我提了一嘴：可以研究一下 Community 透传。
我平时也会拿 Community 做选路，但这次才算亲眼看着它参与了一场“跟自己抢路由”的折腾。
Community：先试了 990，后来换成 140
简单讲，BGP Community 就是附在路由上的标签。上游收到以后，可以按照自己的规则，决定怎么选这条路、往哪里继续传播。标准 Community 可以随路由跨 AS 传递，中间的运营商也能按策略修改或删除它。RFC 1997 对这个机制有说明。
所以，即使我没有直接跟 Cogent 建 BGP，也有可能通过中间的上游，把 Cogent 认识的标签带过去。前提当然是中间愿意传，到了那边也愿意按相应策略处理。
朋友最早给我看的，是这两个：
查了一下 Cogent 官方的 Customer User Guide，第 21 页，这里几个标签的意思分别是：
| Community | Cogent 文档中的用途 |
|---|---|
174:10 | 将对应客户路由的 Local Preference 设为 10，降低优先级。 |
174:990 | 限制对应路由向 Cogent 的 BGP 客户和 peers 传播。 |
174:140 | 将对应客户路由的 Local Preference 设为 140，高于文档中的默认客户值 130。 |
我先在 Advin 的这三个 IPv4 出口上试了 174:990。公网观察点确实能看到这个标签跟着我的路由传出去，但 AS401322 那一边的可见样本没有明显减少。
这里有个很容易想歪的地方：标签跟着携带它的那条路由走。我给自己这边加 174:990，它也不会自动跑到对方独立发布的路径上，帮我把对方禁掉。结果很可能先限制的是我自己的传播范围。
于是后来把 174:990 换成了 174:140，看看能不能让自己的路径更有竞争力。这一轮只调整三个 IPv4，IPv6 保持原样。
Local Preference 是各 AS 内部的选路属性，同一 AS 内通常偏好更高的值；174:140 是请求 Cogent 按其策略处理携带标签的路由，效果仍取决于它是否接收、识别和执行。RFC 4271 的 LOCAL_PREF 定义 也说明了这个作用范围。
然后，外面的路径样本真的开始变了。
这回，Advin 那边的可见度上来了
为了避免只看一张拓扑图就开始庆祝，我还对比了修改前后的 RIPE RIS 数据。取同一批观察点、同一个前缀，而且前后都保持新鲜的记录来比较，结果是这样的：
| 前缀 | 经 Advin 的路径样本 | 经 AS401322 的路径样本 |
|---|---|---|
45.155.242.0/24 | 268 → 332 | 73 → 9 |
77.216.0.0/24 | 269 → 331 | 71 → 9 |
172.83.188.0/24 | 280 → 338 | 65 → 7 |
这是 2026 年 10 月 22 日，新加坡时间大约 15:46 到 15:50 的对比。三个前缀分别有 64、62、58 条匹配的报送记录，从 AS401322 分支换成了 Advin 分支，这批记录里没有看到反方向的切换。
这个变化就很明显了。
不过这些数字统计的是 RIS 观察到的路径样本，不能直接当成全球流量百分比。而且这次同时做了“移除 174:990”和“添加 174:140”两件事，单靠这组结果，也没法把它们各自的贡献拆开，更看不到 Cogent 内部究竟有没有按标签设置 Local Preference。
后来再看 77.216.0.0/24 的拓扑，截图里显示的是从我这里经过 Advin、GSL，再往外扩散：
Cogent 也还在图里，只是到达这个前缀的路径可以经由 GSL、Advin 回到我这里。要看的其实是后面接着哪条分支。
这次排查留存的截图里，还有一条 bgp.tools 通知：
看到这条的时候，确实有点爽，哈哈哈。至少在 bgp.tools 当时看到的拓扑里，那条上游关系已经消失了。至于其他观察点有没有残留，要另外看，不能靠这一条通知就宣布全网撤干净。
ping.pe 红成一片，我反而有点高兴
这次还有一幕特别有意思：ping.pe 上之前还能回应的 .1，变成了这一片红：
平时看见这种画面，第一反应肯定是“完了，机器又挂了”。这次我的第一反应却是：流量是不是已经被拉过来了？
因为我自己这边当时根本还没绑 .1。
如果这些探针原本去的是对方会回应的 .1，后来改走我的 Johor 节点，就会碰到一个还没有配置该地址的目的地。结合前面的路径变化，这可以解释为什么突然红成一片。
但单看全红，能确定的只有这些探针没收到 ICMP 回复。目标停机、过滤 ICMP 等情况也会这样，所以当时嘴上说“全吃过来了”，写记录还是得把这个区别讲清楚。
后来我把三个地址都挂到了 Johor 的 dummy0：
45.155.242.1/32
77.216.0.1/32
172.83.188.1/32再从 PF 和新加坡两处机器测试，三个地址都是发 3 个包、收到 3 个，0% 丢包。Johor 上的抓包也看到了对应的请求和回复，确认这些测试确实由我这台机器回答。
这才把“外面开始看到我的路由”和“包真的到了我的机器”接上了。
折腾到这里，回头想想还是挺离谱的。只是收到一条 bgp.tools 通知，最后变成查 WHOIS、翻 IRR 和 ROA、看 AS_PATH，再到调整 Community、盯着 ping.pe 发呆。
这次最让我在意的，还是自己的 ASN 怎么会在不知情的情况下出现在这些记录和路径里。把路径拉到自己这边，只处理了眼前的选路问题，背后的授权和操作来源还没查清楚。
以后再收到“你的 ASN 又多了个段子”这种通知，我应该不会这么淡定了。免费 IPv4 没等到，倒是免费加了一场 BGP 实验，真受不了。