首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
测试工具
SmokePing
IPv6 访问测试
Coding
V2EX  ›  宽带症候群

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

  •  
  •   hlz0812 · 191 天前 · 2616 次点击
    这是一个创建于 191 天前的主题,其中的信息可能已经有所发展或是发生改变。
    原来 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 全部正常在线
    42 回复  |  直到 2019-06-14 19:29:56 +08:00
        1
    hlz0812   191 天前
    更新:已恢复
        2
    bclerdx   191 天前 via Android
    电信走联通出口,再访问 iij 么?
        3
    hlz0812   191 天前 via iPhone
    @bclerdx 是的,现在已经切回电信自己出口
        4
    bclerdx   190 天前 via Android
    @hlz0812 为何要这样做?
        5
    hlz0812   190 天前 via iPhone
    @bclerdx 工作人员操作失误吧
        6
    bclerdx   188 天前
    @hlz0812 这玩意还能操作失误?
        7
    hlz0812   188 天前 via iPhone
    @bclerdx 不然为什么突然切走又切回来,不是操作失误就是设备调试要断掉一台核心路由上面的业务,不过看着好像是没断掉啊。不过最近肯定是要找时间换核心路由的板卡了,不知道是什么时候操作
        8
    CernetBoom   188 天前 via Android
    @hlz0812 @bclerdx 看新闻看新闻
        9
    bclerdx   188 天前
    @CernetBoom 那么新闻来源呢?没来源或渠道,怎么看新闻?
        10
    bclerdx   188 天前
    @hlz0812 我真心希望电信把到 NTT 的日常炸先解决了。公司鸟博士的电信出口走 NTT 来访问业务,日常炸!也是时好时坏,现在基本上一过 10:00,电信国际出口经 NTT 转接的日常炸,访问最终目标服务器的 CDN 就各种丢包,丢包率高达 50%。不知道鸟博士能不能切换至联通出口,联通访问 NTT 没什么问题。
        11
    hlz0812   188 天前 via iPhone
    @bclerdx ntt 的机房压根就没考虑做大陆业务,连 aws 都接了 20G 163 了,而且 ntt 东京到 163 是 ntt 付费给电信,取决于 ntt 买了多少带宽,不是电信买 ntt 多少
        12
    hlz0812   188 天前 via iPhone
    @CernetBoom 请问关键词是什么?我去查一下
        14
    CernetBoom   188 天前 via Android
    @hlz0812 这只是连锁反应中的一环罢了
        15
    bclerdx   188 天前
    @hlz0812 难不成 NTT 有访问大陆电信或大陆的业务?您知道 NTT 买了多少 163 的带宽?您说的 AWS 买了 20GB 的 163 的带宽数据从何而得?跪谢!
        16
    bclerdx   188 天前
    @CernetBoom 为何欧洲的 7W 多数据会泄露,并经由中国电信网络广播至全球?
        17
    hlz0812   188 天前 via iPhone
    @bclerdx NTT 东京至 163 买了 55G 带宽,aws 东京买了 2*10G,东京两个接入点各 10G 对等
        18
    hlz0812   188 天前 via iPhone
    @bclerdx 路由泄漏这事情以前就发生过好几次了,是本地流量绕地球,不是数据泄漏
        19
    bclerdx   188 天前
    @CernetBoom
    @hlz0812
    可怕!可怕!可怕!
    甲骨文( Oracle )互联网分析部门主管道格‧马多里( Doug Madory )认为,6 月 6 日的 BGP 路由泄漏事件持续两个小时,“这是相当长的时间,足以降低全球通信能力。”推测可能存在恶意企图。
        20
    CernetBoom   188 天前
    @bclerdx 结尾不都写了,Safe Host 发错路由把自己的上游 AS13237 的路由发给了中国电信,结果电信又没做过滤和 Max Prefix,然后电信又把错路由发给其他 ISP 去了

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

    不用奇怪的,有的时候这种事情经常发生,有意无意的都有,CT 和 Verizon 等只是受害者
        21
    CernetBoom   188 天前
    @bclerdx 笑死了,你还看轮子的啊?真喜欢断章取义
        22
    bclerdx   188 天前
    @hlz0812 然后网报上都直接称呼“ BGP Leak ”为“路由泄漏”。另外,本地流量绕地球,会有什么实际上和本质上的恶果?
        23
    CernetBoom   188 天前
    @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."
        24
    bclerdx   188 天前
    @CernetBoom 难道这个锅只由 Safe Host 背? CT 没有做到对来访的路由信息做甄别和核查,就放行并广播至全球?那么 Safe Host 的上有服务商是 enNetworks GmbH ( AS13237 ),而中国电信的 AS 4134,这么明显的 AS 号都不对,Safe Host 就能把地址泄漏给 AS4134,而不是给 AS13237 么?
        25
    CernetBoom   188 天前
    @bclerdx 脱离现实的例子,原来 NTT 到 CW 从 Telia 走,现在 NTT 从 Verizon 过 Google 去 CW,变成自己要从自己的下游走,本身就不和逻辑,然后因为流量改走 NTT-Verizon-Google,可能直接就把 NTT-Verizon 或者 Verizon-Google 塞死了
        26
    bclerdx   188 天前
    @CernetBoom 别动不动就乱口帽子嘛~
        27
    CernetBoom   188 天前
    @bclerdx Safe Host 把 AS13237 发给自己的路由 发给中国电信了,Safe Host AS13237 和 AS4134 都有接,哪里 AS 不对了?

    "人家只是说 CT 缺乏阻止路由泄露的安全措施,以及 CT 在发生此类事件时响应不及时"
    "结果电信又没做过滤和 Max Prefix"
    还需要再重复一遍吗
        28
    CernetBoom   188 天前
    @bclerdx 这种断章取义的文章少看,看英文原文就知道作者什么态度了
        29
    bclerdx   188 天前
    @CernetBoom 别激!动!别激!动!别激!动!需要消!化!需要消!化!需要消!化!这里仅做交流与讨论,有不同观点很!正!常!很!正!常!很!正!常!
        30
    bclerdx   188 天前
    @CernetBoom 英文原文只是一言堂而已,需要多渠道、多维度来倾听、区别与甄别,最终做出合理的判断。
        31
    CernetBoom   188 天前
    @bclerdx 路由泄露和 Hijack Prefix 一天不发生好几次都很奇怪了
        32
    CernetBoom   188 天前
    @bclerdx 比如听一个造谣的讲出来的?
        33
    hlz0812   188 天前 via iPhone
    @bclerdx 电信没义务检查错误,主要责任是那个乱发路由的
        34
    CernetBoom   188 天前
    @bclerdx 另外我是指轮子的文章断章取义,不是对你个人的
        35
    CernetBoom   188 天前
    @hlz0812 不设 Max Prefix 等预防性措施是电信的责任
        36
    hlz0812   188 天前 via iPhone
    @bclerdx 本地流量绕地球最直观的就是慢了呗,本来在本地就能交换的流量绕地球一圈,都要堵死骨干了
        37
    CernetBoom   188 天前
    @bclerdx 另外某 DCS 还天天乱漏路由
        38
    bclerdx   187 天前 via Android
    @hlz0812 难不成任其发展,殃及自身?
        39
    hlz0812   187 天前 via iPhone
    @bclerdx 发现了就切回去
        40
    txydhr   187 天前 via iPhone
    为啥 aws 到电信很多 ip 还要绕 ntt 呀
        41
    CernetBoom   187 天前 via Android
    @txydhr 去问 Amazon
        42
    helijia21   183 天前 via Android
    电信的运维能力其实很一般的,比如国干上有个 100G 链路闪断或者错包,最先发现并反应过来的,就是腾讯跟阿里的拨测丢包。报过去个把小时,再慢悠悠告诉我们 XX 链路故障。
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   897 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 26ms · UTC 22:41 · PVG 06:41 · LAX 14:41 · JFK 17:41
    ♥ Do have faith in what you're doing.