摘要

  • 两条公开测试路径前往丹麦TDC的一处环回地址，分别耗时175.604毫秒和181.747毫秒，并显示途经北美；作为对照，Colt路径只需22毫秒。
  • 后续测试显示，GTT从伦敦到同一地址约需20毫秒，从阿姆斯特丹约需12毫秒，从哥本哈根只需2至4毫秒。由此可见，最初“GTT缺少欧洲路径”的解释并不成立。
  • 报告者随后称，TDC为英国一侧未具名的AS安排了直连路由，连接地点看来是LINX。问题据称已经解决，但这条路由没有冗余，故障时流量仍可能重回北美。

路由故障最容易让人误判的时刻，往往是第一张图刚刚变得清晰的时候。

2026年7月29日，Peter Keller在RIPE路由工作组邮件列表提出一个问题：英国剑桥的一处终端站点访问丹麦TDC网络中的目的地时，出现了持续高延迟。楼宇统一管理的接入商刚刚更换了国际上游，时间上与异常相吻合，但Keller并不能确认新上游究竟是谁。

他贴出的第一条测试路径极具戏剧性。它从伦敦出发，经过利物浦，跨到蒙特利尔，再进入纽约的GTT节点，最后回到丹麦TDC，抵达93.178.170.33时为175.604毫秒。另一条由NTT查询工具生成、被描述为从伦敦路由器出发的路径，显示了阿什本和华盛顿的节点，最终为181.747毫秒。

Colt给出了对照。它在伦敦直接交给TDC，只显示三个跳点，22毫秒即到达同一地址。两条慢路径与这条欧洲内路径之间，大约相差150毫秒。

如果调查停在这里，结论几乎会自动写成：GTT和TDC在欧洲没有合适的互联，因此流量只能去北美交接。后续证据恰恰否定了这个说法。

20毫秒的反例

一名参与者使用GTT自己的查询工具测试93.178.170.33。从伦敦出发，路径很快进入TDC，终点大约20毫秒；从阿姆斯特丹出发约12毫秒；从哥本哈根出发则约2至4毫秒。

这三个结果证明的范围很窄，却足以改变调查方向：至少对被测试的地址，GTT能够在欧洲把路径交给TDC。最初看到的跨洋绕行，不能再归因于“GTT没有欧洲入口”。

新的问题变成：Cogent实际学到了哪条前缀路由，它从谁那里学到，又为何把这条路由选为最佳？

这是路径可视化与路由诊断的分界。traceroute能显示某个观测点收到哪些跳点回复、耗时如何变化。它无法直接显示没有被宣告的路线，也看不到运营商之间的商业关系、本地优先级或过滤规则。地图可以告诉调查者去哪里查，却不能替控制面作证。

被测试的地址不是应用目的地

公开路径都指向93.178.170.33。它的反向DNS名称表明，这是TDC的一处环回地址。RIPEstat当前将该地址归入93.178.128.0/18，并显示起源AS为AS3292；AS3292的持有者名称是TDC Holding。

邮件线程没有公开实际业务目的地址。因此，93.178.170.33只能被称为用于比较通往TDC路径的测试目标，不能写成发生业务问题的服务器。这个边界还提醒我们，公开材料没有说明应用协议，也没有证明去程与回程一致。

路由器名称同样不是精确地理证明。反向DNS由运营商维护，可能过时，也可能只表达网络规划含义。RIPE Atlas有关区域网格的文档明确提醒，依赖反向DNS和IP地理定位判断路径是否出境可能出现错误。

不过，在本案中，城市标签、往返时延的突增，以及Colt的独立对照彼此一致。合理的结论不是“每个节点的物理位置都已证实”，而是“两条样本路径表现出跨大西洋绕行，而一条欧洲内替代路径显著更短”。这已经足够启动下一步调查。

前缀信息把问题从地理移向策略

另一名参与者随后贴出Cogent在德国查询93.178.128.0/18的结果。被选中的AS路径为3257 3292 3292 3292 3292。也就是说，Cogent通过GTT的AS3257学到该前缀，TDC的AS3292在路径中多次预置。结果还显示加拿大下一跳以及社区值174:22003。

这份输出仍然不能解释合同，更不能证明动机。但它把异常压缩成一个可以核查的控制面问题：Cogent收到的是哪条宣告，在哪个位置收到，哪些备选根本没有进入它的选择集合。

一个网络可以购买四家上游，却只向其中一家宣告某个前缀。在账单上，这叫多上游；在该前缀的实际可达性上，却可能仍然只有一条有效通道。类似地，两家运营商可以同时在欧洲铺设大量基础设施，却没有针对相关路由建立所需的欧洲对等关系。

BGP不会选择地图上最短的线。它只能在收到并接受的路径中，按照策略作出选择。

最终诊断来自报告者转述

9月4日，Keller更新了与TDC对等互联负责人及工程师沟通的结果。按照他的说法，英国一侧未公开名称的AS拥有另外三家传输商，却只向Cogent宣告了相关前缀；与此同时，Cogent不愿在欧洲与TDC对等互联。

这两个条件拼在一起，可以解释为什么短路径存在，却没有为相关流量所用。它也纠正了最初对GTT的归因：GTT既不是唯一缺口，也不是简单的地理瓶颈；它只是出现在Cogent已经选中的那条路由里。

公开材料中没有Cogent或TDC联合发布的事故报告，也没有英国AS的配置。因此，文章必须保留“据Keller与TDC沟通后转述”这一层归属，不能把它写成各方独立确认的事实。

参与者还讨论了英国AS是否出于成本原因限制宣告。这个推测听起来符合某些商业激励，却没有证据支持。价格、误配置、合同约束或风险偏好，都可能产生相同的外部结果。分析控制权不需要虚构动机。

直连修复了正常状态

Keller称，TDC随后为自己与英国AS安排了一条直连路由。9月7日，他补充说两家网络都在伦敦互联网交换中心出现，因此这条连接看来是在LINX完成。线程没有公布BGP会话、端口或配置，LINX地点只能算有依据的推断，不能算独立验证。

日常结果是成功的：Keller说问题已经解决。

但他在同一次更新中说明，这条直连路由并不冗余。一旦发生故障，流量可能暂时再次经过北美。

这句话改变了“修复完成”的含义。旧路径并没有消失，只是退到故障状态。正常时期的监控会显示低延迟；只有直连会话、端口、承载线路或宣告撤回时，备用路径的真实质量才会出现。

直接双边互联完全可以是优秀的应急措施。它让真正相关的两家网络掌握修改权，不必等待大型传输商改变一项普遍政策，实施速度也可能很快。它的代价是把原有的长路径问题，变成对单一短路径的依赖。

修复眼前性能与建立韧性，不是同一件事。

关闭故障前，还缺一次撤路测试

一份足以支持关闭事件的记录，应当先写清英国前缀究竟向哪些上游宣告。其次，记录直连会话的位置、责任方和接收的路由集合。第三，指定一条不共享同一端口、承载和策略故障域的欧洲备用路径。最后，从受影响的两端分别测试正常状态和主路径撤回状态，保留AS路径与往返时延。

如果撤回直连后，延迟重新接近176至182毫秒，那么旧绕行依然是事实上的备用方案。运营团队至少知道自己购买的是“性能优先、故障时显著降级”，并能据此设定服务承诺。如果第二条欧洲路径能够接管，直连修复才真正成长为冗余设计。

这场RIPE线程最有价值之处，不是社区迅速找到了一个运营商来责备，而是公开证据逐步推翻了最早的直觉。最初的路径发现症状；GTT的欧洲测试否定过度简化的成因；Cogent的前缀视图定位被选中的宣告；与TDC的沟通找到可执行杠杆。

现在只剩一个问题没有经过实测：当这条直连不存在时，网络会作出什么选择？

证据边界

所有时延和路径均来自线程参与者公布的测试。最终诊断与修复效果是Keller在同TDC沟通后的转述，并非运营商联合发布的复盘。RIPEstat只确认当前的地址、前缀与AS身份，不重放7月的全部路由状态。对地理位置的判断必须受到反向DNS局限约束。

来源