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

[hlz0812]

原来 IIJ 的流量走联通
原来 bbtec 的流量走 ntt

并不是因为海缆故障，电信到 IIJ202.97.6.46/45 正常在线，bbtec 221.111.179.214/213 221.111.202.50/49 221.111.202.18 221.111.202.62 全部正常在线

[hlz0812]

更新:已恢复

[bclerdx]

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

[hlz0812]

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

[bclerdx]

@hlz0812 为何要这样做？

[hlz0812]

@bclerdx 工作人员操作失误吧

[bclerdx]

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

[hlz0812]

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

[CernetBoom]

@hlz0812 @bclerdx 看新闻看新闻

[bclerdx]

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

[bclerdx]

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

[hlz0812]

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

[hlz0812]

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

[CernetBoom]

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

[CernetBoom]

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

[bclerdx]

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

[bclerdx]

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

[hlz0812]

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

[hlz0812]

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

[bclerdx]

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

[CernetBoom]

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

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

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