（20:00 已恢复）电信把与日本 IIJ 和 bbtec 的路由切走了

更新:已恢复

电信走联通出口，再访问 iij 么？

@ 是的，现在已经切回电信自己出口

@hlz0812 为何要这样做？

@bclerdx 工作人员操作失误吧

@hlz0812 这玩意还能操作失误？

@bclerdx 不然为什么突然切走又切回来，不是操作失误就是设备调试要断掉一台核心路由上面的业务，不过看着好像是没断掉啊。不过最近肯定是要找时间换核心路由的板卡了，不知道是什么时候操作

@hlz0812 @bclerdx 看新闻看新闻

@CernetBoom 那么新闻来源呢？没来源或渠道，怎么看新闻？

@hlz0812 我真心希望电信把到 NTT 的日常炸先解决了。公司鸟博士的电信出口走 NTT 来访问业务，日常炸！也是时好时坏，现在基本上一过 10:00，电信国际出口经 NTT 转接的日常炸，访问最终目标服务器的 CDN 就各种丢包，丢包率高达 50%。不知道鸟博士能不能切换至联通出口，联通访问 NTT 没什么问题。

@bclerdx ntt 的机房压根就没考虑做大陆业务，连 aws 都接了 20G 163 了，而且 ntt 东京到 163 是 ntt 付费给电信，取决于 ntt 买了多少带宽，不是电信买 ntt 多少

@CernetBoom 请问关键词是什么？我去查一下

@hlz0812 https://blogs.oracle.com/internetintelligence/large-european-routing-leak-sends-traffic-through-china-telecom

@hlz0812 这只是连锁反应中的一环罢了

@hlz0812 难不成 NTT 有访问大陆电信或大陆的业务？您知道 NTT 买了多少 163 的带宽？您说的 AWS 买了 20GB 的 163 的带宽数据从何而得？跪谢！

@CernetBoom 为何欧洲的 7W 多数据会泄露，并经由中国电信网络广播至全球？

@bclerdx NTT 东京至 163 买了 55G 带宽，aws 东京买了 2*10G，东京两个接入点各 10G 对等

@bclerdx 路由泄漏这事情以前就发生过好几次了，是本地流量绕地球，不是数据泄漏

@CernetBoom
@hlz0812
可怕！可怕！可怕！
甲骨文（ Oracle ）互联网分析部门主管道格马多里（ Doug Madory ）认为，6 月 6 日的 BGP 路由泄漏事件持续两个小时，“这是相当长的时间，足以降低全球通信能力。”推测可能存在恶意企图。

@bclerdx 结尾不都写了，Safe Host 发错路由把自己的上游 AS13237 的路由发给了中国电信，结果电信又没做过滤和 Max Prefix，然后电信又把错路由发给其他 ISP 去了

Google 2017 年也向 Verizon 漏了自己 16 万条路由，然后 Verizon 没有做 Max Prefix 或者没有生效，结果 NTT 和 KDDI 等全变 NTT/KDDI-Verizon-Google-其他方向了

不用奇怪的，有的时候这种事情经常发生，有意无意的都有，CT 和 Verizon 等只是受害者

@bclerdx 笑死了，你还看轮子的啊？真喜欢断章取义

@hlz0812 然后网报上都直接称呼“ BGP Leak ”为“路由泄漏”。另外，本地流量绕地球，会有什么实际上和本质上的恶果？

@bclerdx 麻烦你去看英文原文，人家只是说 CT 缺乏阻止路由泄露的安全措施，以及 CT 在发生此类事件时响应不及时

"It also reveals that China Telecom, a major International carrier, has still implemented neither the basic routing safeguards necessary both to prevent the propagation of routing leaks nor the processes and procedures necessary to detect and remediate them in a timely manner when they inevitably occur. Two hours is a long time for a routing leak of this magnitude to stay in circulation, degrading global communications."

@CernetBoom 难道这个锅只由 Safe Host 背？ CT 没有做到对来访的路由信息做甄别和核查，就放行并广播至全球？那么 Safe Host 的上有服务商是 enNetworks GmbH （ AS13237 ），而中国电信的 AS 4134，这么明显的 AS 号都不对，Safe Host 就能把地址泄漏给 AS4134，而不是给 AS13237 么？

@bclerdx 脱离现实的例子，原来 NTT 到 CW 从 Telia 走，现在 NTT 从 Verizon 过 Google 去 CW，变成自己要从自己的下游走，本身就不和逻辑，然后因为流量改走 NTT-Verizon-Google，可能直接就把 NTT-Verizon 或者 Verizon-Google 塞死了

@CernetBoom 别动不动就乱口帽子嘛~

@bclerdx Safe Host 把 AS13237 发给自己的路由 发给中国电信了，Safe Host AS13237 和 AS4134 都有接，哪里 AS 不对了？

"人家只是说 CT 缺乏阻止路由泄露的安全措施，以及 CT 在发生此类事件时响应不及时"
"结果电信又没做过滤和 Max Prefix"
还需要再重复一遍吗

@bclerdx 这种断章取义的文章少看，看英文原文就知道作者什么态度了

@CernetBoom 别激！动！别激！动！别激！动！需要消！化！需要消！化！需要消！化！这里仅做交流与讨论，有不同观点很！正！常！很！正！常！很！正！常！

@CernetBoom 英文原文只是一言堂而已，需要多渠道、多维度来倾听、区别与甄别，最终做出合理的判断。

@bclerdx 路由泄露和 Hijack Prefix 一天不发生好几次都很奇怪了

@bclerdx 比如听一个造谣的讲出来的？

@bclerdx 电信没义务检查错误，主要责任是那个乱发路由的

@bclerdx 另外我是指轮子的文章断章取义，不是对你个人的

@hlz0812 不设 Max Prefix 等预防性措施是电信的责任

@bclerdx 本地流量绕地球最直观的就是慢了呗，本来在本地就能交换的流量绕地球一圈，都要堵死骨干了

@bclerdx 另外某 DCS 还天天乱漏路由

@hlz0812 难不成任其发展，殃及自身？

@bclerdx 发现了就切回去

为啥 aws 到电信很多 ip 还要绕 ntt 呀

@txydhr 去问 Amazon

电信的运维能力其实很一般的，比如国干上有个 100G 链路闪断或者错包，最先发现并反应过来的，就是腾讯跟阿里的拨测丢包。报过去个把小时，再慢悠悠告诉我们 XX 链路故障。

@helijia21 拨测丢包是什么意思？