这是一个创建于 1690 天前的主题，其中的信息可能已经有所发展或是发生改变。
这延迟也太爆炸了，只能切到 163 用 UU 。
 |
1
lightcreater 2020-03-30 21:03:58 +08:00
听说最近上海精品网被降权了，上海的话用联通连接日本效果应该会非常棒。
|
 |
2
mxr49 2020-03-30 21:07:14 +08:00
上海电信精品网+BGP 做中转，连接东京客户公司 VPN 服务器延迟依然 35 左右，因此网络没有任何问题，是你自己的问题。
|
|
4
mxr49 2020-03-30 21:10:32 +08:00
不知道，反正很久没用过精品网常规线路经香港裸连日本了。
|
 |
5
zli 2020-03-30 21:11:19 +08:00
垃圾精品网，赶紧取消保平安！
|
 |
6
my2492 2020-03-30 21:17:52 +08:00
我怀疑回程走联通了，你看看是不是 IIJ-联通-CN2 这么走的，联通-IIJ boom，上海联通-上海 CN2 boom
|
 |
7
wdlth 2020-03-30 23:18:09 +08:00
走了 HGC 吧，那个 QoS 厉害。
|
 |
9
PESH 2020-03-31 01:21:51 +08:00
GD 的游宽连 JP 亚马逊全 160 延迟了~平时就 6-70
|
 |
10
skyeycirno 2020-03-31 05:52:46 +08:00
因为上海 CN2 的 58.32 那个段，日本 NTT 回程要绕棒子
|
|
12
PESH 2020-04-01 09:37:32 +08:00
@celao 就是游宽到 JP 亚马逊服务器后就全变 160+延迟了,看了下是到了韩国后去 JP~~11 59.43.187.102 9 ms 9 ms 9 ms 中国 广东 广州 电信 *
12 59.43.183.106 12 ms 12 ms 13 ms 中国 香港 电信 * 13 1.254.241.32 13 ms 13 ms 14 ms 中国 香港 skbroadband.com AS9318 14 118.221.4.64 46 ms 47 ms 47 ms 韩国 skbroadband.com AS9318 15 * * * * 16 * * * * 17 211.210.54.30 49 ms 49 ms 49 ms 韩国 首尔 skbroadband.com AS9318 18 * * * * 19 * * * * 20 52.93.46.57 87 ms 87 ms 88 ms 韩国 首尔 amazon.com * 21 54.239.123.27 127 ms 131 ms * 韩国 首尔 amazon.com AS16509 22 54.239.45.187 116 ms 116 ms 121 ms AMAZON.COM 骨干网 amazon.com * 23 * * * * 24 * * * * 25 52.95.31.51 118 ms 118 ms 119 ms 日本 东京都 东京 amazon.com AS16509 26 52.95.31.185 117 ms 117 ms 117 ms 日本 东京都 东京 amazon.com AS16509 27 52.95.31.176 153 ms 159 ms 161 ms 日本 东京都 东京 amazon.com AS16509 28 52.95.31.122 161 ms 164 ms 167 ms 日本 东京都 东京 amazon.com AS16509 |
 |
13
bjclue 2020-04-01 18:29:20 +08:00
這是家用精品網的關係 到日本 目前全改爲繞韓國回城 具體何時恢復不知， 另外説一下 上海企業電信寬帶 到日本還是正常 ping 值 回城正常不饒韓國. 一分錢一分貨！
|
 |
15
CernetBoom 2020-04-02 06:03:21 +08:00 via Android
@PESH @lightcreater 根本就只有 NTT 这样，是 NTT 现在把 RPKI Invalid 的路由过滤掉了，因为原来上海电信把 58.32.0.0/16 的 IRR 记录写错到了 AS4809(应该写 AS4812)，导致 RPKI Invalid
|
|
16
mxr49 2020-04-02 12:27:43 +08:00
@CernetBoom 很遗憾你的结论可能是错的。你可以打开这个： https://www.ctclouds.com/cloud/front/support/lookingGlass
源地址选 CN2 精品上海，然后目标地址输入你日本的地址，真正商用的延迟还是在 60 左右，和家用的有区别。因为我自己也是商用的刚才特意测试了一下延迟还是老样子 60 左右没变。 |
|
17
CernetBoom 2020-04-02 12:45:07 +08:00 via Android
@mxr49 先搞搞清我在说什么，中国大陆 CN2 去 NTT(所谓去程)这一方向不做处理 从来就都是要从 NTT 香港走的，你随便找个日本 IP 来还能走出双向 CN2 直达 NTT 东京？
你说的 CTClouds 的 Looking Glass 我就能测出 33/39ms 的双向直达 NTT 东京 我说的问题是现在 NTT 到 58.32.0.0/16 这个段(所谓回程)没路由 /走香港，就是因为 RPKI Invalid 的问题 |
|
18
mxr49 2020-04-02 12:57:11 +08:00
@CernetBoom 这还是一般家宽的问题，我自己商用的现在延迟就是 60 左右没变。
|
|
19
CernetBoom 2020-04-02 13:02:22 +08:00 via Android
@mxr49 只要你处理过，就是家宽照样都能 33-39，根本和商宽没区别
现在是只有 58.32.0.0/16 因为 IRR 里信息不对所以 NTT 把路由过滤了导致出向走不到 NTT 或者绕香港 N 年前的 IRR 信息就被电信填错，是 NTT 最近开始过滤 RPKI Invalid 的条目才导致路由变动 |
|
23
mxr49 2020-04-02 13:27:50 +08:00
@kandm 说是这么说，大部分市场上的日本 BGP 都是回程 CN2 去程 163，很少有双向 CN2，我的也是回程 CN2，但本地 CN2 的话去程也变 CN2 。我早就说过，日本线路是所有地区里最糟糕的，完全就是一分价钱一分货，没有任何贪便宜的可能性。我用过大部分市场上销售 BGP 的 VPS，凡是 IP 27.124 开头的都超售不知道几百倍了，还不如裸连日本。像我现在用的 BGP 是独服，价格 1000 多每个月，不过这是客户要求我用这个服务器的，当然费用也都是客户报销。
|
 |
24
justs0o 2020-04-02 14:14:03 +08:00
|
|
25
mxr49 2020-04-02 14:25:33 +08:00
@justs0o 那你想怎么办？在我看来很简单，要么 IPLC，或者经过香港连日本也是一种临时办法，指望电信短时间内解决基本不可能。在电信眼里咱们都是小喽喽。你又不是大客户。
|
 |
26
kandm 2020-04-02 14:35:19 +08:00  1
@mxr49 你用商宽了，你用 BGP 了，你厉害了，可以了吗？商宽是公司付的钱，BGP 是客户的钱，这还能用出优越感了？你要是自己拉个 1000M 的 IPLC，哪再来炫耀，好不好？
|
 |
28
mnihyc 2020-04-02 17:02:54 +08:00
@CernetBoom 这个路由走成这样也是同样的原因？ 还是说 aws jp 只能这么走回国内精品网？
https://ftp.bmp.ovh/imgs/2020/03/eb606116a756a810.png |
|
30
CernetBoom 2020-04-02 22:26:45 +08:00 via Android
|
|
31
mxr49 2020-04-03 21:19:02 +08:00
@CernetBoom 我用的真正的电信商用 CN2，IP 116.247 开头，你可以测测 116.247.128.1 这个地址，看看和 58.32 开头的有什么不同。
|
|
32
CernetBoom 2020-04-03 23:00:19 +08:00 via Android
@mxr49
  有什么不同？区别还不够明显？ |
|
33
CernetBoom 2020-04-03 23:19:00 +08:00 via Android
@mxr49 其他段都和所谓什么商用 CN2 一样的，就是家宽也一样，只有 58.32.0.0/16 整段因为 RPKI Invalid 有问题，你商用要是写错 IRR 照样没路由
根本就不是和去向绕香港一个问题，而且去向绕香港是你的问题，不是我的 |
 |
34
444abc 2020-04-04 01:52:02 +08:00
只能切到 163 用 UU ?
|
|
35
mxr49 2020-04-04 13:13:02 +08:00
@CernetBoom 我估计这个是电信故意写错的，或者临时改写的，目的就是区分家用和商用，否则你能想到的问题难道电信会不知道吗？发现错了过了那么多天还不改回来吗？
|
|
37
mxr49 2020-04-04 15:34:21 +08:00
@justs0o 这也许是你一厢情愿罢了，如果真是商用的话很多都有 SLA 保证的，有些大客户服务，万一线路发生意外的话半小时内就要给出解决方案的。你一个局外人真的觉得自己就比电信内部人员懂？咱们不信看这个月月底会修好吗。我估计悬。
|
|
38
mxr49 2020-04-04 15:44:12 +08:00
很多这里的人明明就是个局外人还自以为自己很懂。别的不说就三月份我就发现过两次上海电信 CN2 连韩国临时走香港然后转接韩国 SK，而不是直连韩国 KT，延迟都增加到 100 多。但这两次都只是临时换的，时间都很短每次不超过两小时。这次 NTT 时间这么长你真的以为电信内部是不知道吗？毫无疑问是故意的，估计以后很长时间都会这个样子。
|
|
40
mxr49 2020-04-04 15:58:08 +08:00
@justs0o 没办法我用这个线路是为了做生意为了赚钱，不是用来消遣看视频打游戏什么的，如果只是一般应用的话我也不会花大价钱去连什么日本，连香港不是更好吗？
|
 |
41
hlz0812 2020-04-04 18:25:00 +08:00 via iPhone
@mxr49 公网没有 SLA 保障，专线才有，但是高级客户可能可以申请更换 ip 段什么的，电信故障响应速度很慢的，路由泄漏什么的都是别人先发现，爆了半天才发现问题
|
 |
42
akw2312 2020-04-04 18:38:53 +08:00 via Android
NTT 前幾天開始丟棄 RPKI Invalid 的路由，不是完全拒收，有些 peering(例如 KT)還是不檢測 RPKI 。
上面也有人說過了 這個段的 RPKI 是這樣的： 58.32.0.0/16 le 16 AS4809 而很明顯實際上的宣告是 58.32.0.0/17 58.32.128.0/17 AS4812 多測測幾個有過濾 RPKI Invalid 的 ISP 就會發現他們是完全拒收這兩個 /17 的。 這個問題錯很多年了，只是以前沒人過濾，現在變多了。 BTW 去年我發現這個段 HGC 沒收路由，以為是 radb 沒正確的記錄導致的，我就 proxy-registered 加了一個對的記錄，但並沒有作用，後來我也忘了去掉。 結果前兩天 CTG 透過他們一個客戶找過來，讓我把那個記錄給去了，然後他們自己加了一個一模一樣的。 所以：有人找上海電信報障了 也轉去 GNOC 了 但他們的處理方式「方向錯了」 |
|
43
CernetBoom 2020-04-05 00:29:42 +08:00 via Android
@mxr49 临时写？记录的更新日期是 2008 年还临时写？
那时候有几家会用 RPKI ？是现在开始 RPKI 过滤了才出现这种问题谢谢，以前电信会知道现在大家都开始过滤 RPKI Invalid 的路由？ 我可以明确的告诉你有人报障了，电信改了，但是改错了，改成 RADB 的了 SLA ？你搞笑呢，公网国际线路还 SLA 局外人？你才是那个局外人吧，Session 断了和路由有三条被过滤有可比性？ Session 断了直接去重启的谢谢，电信又不知道 NTT 把这三条路由过滤掉了，不报障他们根本不知道 你能不能看看#42 说了些什么 |
 |
45
smallthing 2020-04-08 12:27:15 +08:00
帖子里有个弱智
|
Select Language