Tag: hinet

Ubuntu 撥 HiNet PPPoE 時會因為 MTU 而導致有些網站連不上

之前用 HiNet 固定制 (不需要 PPPoE，直接設 IP 就會通的那種)，跑起來順順的也沒麼問題，最近剛好合約滿了就打算換成非固定制 (需要撥 PPPoE 才會通)，結果換完後發現有些網站常常連不上 (不是一直都連不上)，但只要設了 proxy.hinet.net (今年年底要停止服務了) 或是改從 cable 線路出去就正常。

測了不少設定都沒用 (像是改 tcp timestamp 設定，或是 sack 之類的設定)，後來發現 MTU 的值不太對，用 ifconfig 看發現我的 ppp0 是 1500 而不是 1492，直接先 ifconfig ppp0 mtu 1492 改下去測，發現本來不能連的網站就通了...

(補充一下，我看了 Windows 的設定是 1480，所以也沒問題，但不知道怎麼算的...)

查了一下 MTU 相關的問題，發現在「wrong mtu value on dsl connection」這邊有討論到。裡面提到的 workaround 是到 /etc/NetworkManager/system-connections/ 裡找出你的 PPPoE 設定檔，然後在 ppp 區域的裡面寫死 mtu 參數：「mtu=1492」(這邊的 1492 是從 1500 bytes 扣掉 PPPoE 的 8 bytes 得出來的)，不過我測試發現在修改設定檔時會被改回來，加上測試發現沒用，只好自己寫一個 /etc/network/if-up.d/pppoe-mtu 惡搞了：

#!/bin/sh -e

if [ "$IFACE" != "ppp0" ]; then
        exit 0
fi

/sbin/ifconfig ppp0 mtu 1492

放進去後要記得 chmod 755。

從 ticket 上面看起來還是沒有解 (2009 年就發現了)，看起來 PPPoE 不是絕對多數而且又有 workaround，短期應該不會修正...

HiNet 宣佈年底關閉 Proxy 服務

HiNet 宣佈今年年底將要關閉 Proxy 服務了，也就是 proxy.hinet.net:80 這組：「HiNet Proxy 終止服務公告」。

現在愈來愈多網站都走 HTTPS 的情況下，Proxy 服務能帶來的好處愈來愈少了... 大概只剩下出國的優先權比較高 (因為變成機房 IP 連出國)。

Facebook 觀察 IPv6 的使用情況

Facebook 是在六年前啟用了 IPv6 服務，然後分析了現在各地區 IPv6 使用的情況：「How IPv6 deployment is growing in U.S. and other countries」，另外提供了統計系統的資料給大家查 (不過看起來只有二月以後的？)：「Facebook IPv6」。

然後被提到台灣區的成長在這幾個月很快速，主要原因是中華電信的導入：

We are also seeing countries and regions with less mature internet infrastructure start to transition to IPv6. Although overall deployment is still low, recent growth in some places has been exponential. Taiwan, for example, has gone from less than 1 percent in February 2018 to more than 10 percent as of May 28, 2018. Taiwan's rapid growth directly corresponds to recent IPv6 initiatives by Chunghwa, Taiwan's largest ISP.

先前在 Twitter 上有提到中華在 www.ipv6.hinet.net 網站上的跑馬燈有公告關於 IPv6 的導入，所以到這個月月底，使用比率應該都還會有明顯的提昇：

因為 Windows 7 以上的系統直接 PPPoE 的應該都會拿到 IPv6 address，但如果是 IP 分享器的就不一定支援了，不然應該會更高...

另外行動網路的部份也陸陸續續在轉移了，像我的 blog 上可以看到有 emome-ip6.hinet.net 的訪客，而且 Google 搜尋也可以看到一些資訊了：「"emome-ip6.hinet.net" - Google 搜尋」。

Cloudflare 推出 1.1.1.1 的 DNS Resolver 服務

Cloudflare 推出了 1.1.1.1 上的 DNS Resolver 服務：「Announcing 1.1.1.1: the fastest, privacy-first consumer DNS service」，主打項目是隱私以及效能。

然後因為這個 IP 的特殊性，上面有不少奇怪的流量... 而 Cloudflare 跟 APNIC 交換條件後取得這個 IP address 的使用權 (然後 anycast 發出去)：

APNIC's research group held the IP addresses 1.1.1.1 and 1.0.0.1. While the addresses were valid, so many people had entered them into various random systems that they were continuously overwhelmed by a flood of garbage traffic. APNIC wanted to study this garbage traffic but any time they'd tried to announce the IPs, the flood would overwhelm any conventional network.

We talked to the APNIC team about how we wanted to create a privacy-first, extremely fast DNS system. They thought it was a laudable goal. We offered Cloudflare's network to receive and study the garbage traffic in exchange for being able to offer a DNS resolver on the memorable IPs. And, with that, 1.1.1.1 was born.

Cloudflare 做了效能比較表 (與 Google Public DNS 及 OpenDNS 比較)，可以看到平均速度快不少：

在台灣的話，HiNet 非固定制 (也就是 PPPoE 連線的使用者) 連到 8.8.8.8 有奇怪的 latency：

可以比較同一台機器對 168.95.1.1 的反應速度：

不過如果你是 HiNet 固定制 (固 2 或是固 6 IP 那種，不透過 PPPoE，直接設定 IP address 使用 bridge mode 連線的使用者)，兩者的 latency 就差不多，不知道是 Google 還是 HiNet 的架構造成的。

另外比較奇怪的一點是在文章最後面提到的 https://1.1.1.1/，理論上不會發 IP-based 的 SSL certificate 才對？不知道 CEO 老大是有什麼誤解... XD

Visit https://1.1.1.1/ from any device to get started with the Internet's fastest, privacy-first DNS service.

Update：查了資料發現是可以發的，只是大多數的 CA 沒有提供而已...

所以 HiNet DNS Resolver 至少有三段...？

剛剛看到「HiNet DNS系統設備維護作業」：

範圍：苗栗(含)以南至雲林(含)以北HiNet上網用戶

加上之前在「中華的 DNS 架構」提到的公告，這樣看起來 HiNet DNS Resolver 至少是切成三段？

靠著公告在猜架構...

PChome 24h 連線會慢的原因... (續篇)

上一篇「PChome 24h 連線會慢的原因...」寫到 DNS resolver 會倒在路邊，但沒寫會怎麼倒... 因為規格書上沒有寫當問不到要問的東西時要怎麼處理，所以每一家處理的方式都不太一樣。

我把對各 DNS resolver 查詢 100 次的結果放在 GitHub Gist 上：「Query 24h.pchome.com.tw」，大家都是回 SERVFAIL，只是時間不一樣 (最後一個 x.xxxx total 的部份表示實際秒數，wall clock)。

先看這次的主角好了，HiNet 的 168.95.1.1 與 168.95.192.1，同時也應該是 PChome 24h 服務使用人數最多的 DNS resolver。

這兩個 DNS resolver 在遇到問題時不會馬上回 SERVFAIL，加上業界有小道消息說中華自己改了不少 code，所以跟一般的 open source software 行為不太一樣。由於看不到 PChome 端的 DNS packet，所以只能就行為來猜... 應該是在第一輪都查不到後，會先 random sleep 一段時間，然後再去問一次，如果第二次還是失敗的話才回應 SERVFAIL。

這個 random sleep 看起來可能是 10 秒，因為數據上看起來最長的時間就是這個了。

SEEDNet 的 139.175.1.1 以及 Google 的 8.8.8.8 都沒這個問題，都會馬上回應 SERVFAIL。

前陣子新出的 9.9.9.9 (參考「新的 DNS Resolver：9.9.9.9」) 則是有些特別的狀況，可以看到前面有三個 query 很慢 (第 2、3、5 三行)，但後面的速度就正常了。可能是新加坡那邊有三台伺服器在服務 (目前我這邊測試的機器到 9.9.9.9 會到新加坡)，在第一次遇到都沒有答案時會有特殊的演算法先確認，之後就會 cache 住？

所以各家 DNS resolver 反應都不太一樣，然後最大那家有問題 XD

24h.pchome.com.tw 慢一次，ecvip.pchome.com.tw 再慢一次，圖片的 a.ecimg.tw 再慢一次，一個頁面上多來幾個 domain 就會讓人受不了了 XD

其實我只要改成 8.8.8.8 或是改走 proxy.hinet.net 就可以解決啦，但還是寫下來吧 (抓頭)。

中華的 DNS 架構

在 Twitter 上看到「HiNet DNS系統設備維護作業」這則維護公告，裡面提到了會對 HiNet DNS 系統維護，但範圍是雲林以南：

起訖日期：2017-10-19
時間： 14:00 ~ 16:00
範圍：雲林(含)以南
說明：親愛的HiNet客戶您好﹕ 為提昇網路服務品質，HiNet DNS系統將於106/10/19(星期四)下午2:00到4:00進行設備維護，期間DNS查詢服務將可能發生瞬斷情形，若影響上網服務造成您的不便，敬請見諒，並感謝您對HiNet的支持與愛護。 祝您 身體健康 萬事如意 中華電信數據通信分公司 敬上 客服專線：0800-080-412

這樣聽起來中華有在自己內部網路跑 anycast service 了？而且這樣應該表示有機會在 DNS 層拆出不同區域的用戶？

遠傳的 DNS 改成 139.175.1.1

找資料的時候發現原來在六月底的時候換掉了：「2016/06/30 起 遠傳大寬頻(Seednet) DNS主機異動公告說明」：

感謝您對本遠傳大寬頻(Seednet)長期的支持與愛護，因DNS主機將進行異動，
DNS IP將調整為139.175.1.1，原有的DNS IP(139.175.55.244、139.175.252.16)，
將於2016年06月30日不再提供對外連線服務。

這樣的話三大 ISP 都放到最好記的網段下了 (另外兩個分別是台灣固網的 61.31.1.1 與中華的 168.95.1.1)。

CloudFlare 對 HiNet 成本的抱怨 (還有其他 ISP...)

CloudFlare 特地寫了一篇討拍文在分析對六個 ISP 的超高成本：「Bandwidth Costs Around the World」。

其他的就不講了，先看對價錢的定義：

As a benchmark, let's assume the cost of transit in Europe and North America is 10 units (per Mbps).

然後來看亞洲區以及 HiNet 的部份寫了什麼：

Two Asian locations stand out as being especially expensive: Seoul and Taipei. In these markets, with powerful incumbents (Korea Telecom and HiNet), transit costs 15x as much as in Europe or North America, or 150 units.

成本大約是 15 倍。另外說明這六個 ISP 佔了他們 50% 的頻寬成本 (以及 6% 的流量)：

Today, however, there are six expensive networks (HiNet, Korea Telecom, Optus, Telecom Argentina, Telefonica, Telstra) that are more than an order of magnitude more expensive than other bandwidth providers around the globe and refuse to discuss local peering relationships. To give you a sense, these six networks represent less than 6% of the traffic but nearly 50% of our bandwidth costs.

為什麼有種濃濃的既視感 XDDD

Slack 把服務丟上 CloudFront...

剛剛發現公司的 Slack 網域 kkbox.slack.com 已經上了 CloudFront，測了一些其他的 domain，應該是全部都上了：

gslin@home [~] [15:55/W4] mtr --report kkbox.slack.com
Start: Tue May 17 15:56:06 2016
HOST: home.gslin.org              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- h254.s98.ts.hinet.net      0.0%    10   16.3  11.7   9.3  18.8   3.1
  2.|-- SNUH-3302.hinet.net        0.0%    10   44.5  13.4   9.0  44.5  10.9
  3.|-- SNUH-3202.hinet.net        0.0%    10    8.8  12.7   8.8  26.8   5.9
  4.|-- TPDT-3012.hinet.net        0.0%    10   12.0  14.3  10.4  19.2   3.1
  5.|-- r4210-s2.hinet.net         0.0%    10    9.8  10.4   9.0  11.4   0.5
  6.|-- 203-75-228-29.HINET-IP.hi  0.0%    10   10.3  10.6   9.2  13.7   1.2
  7.|-- R1011-ASR.tpix.net.tw      0.0%    10   12.1  11.6  10.5  13.2   0.5
  8.|-- 202-133-255-122-static.un  0.0%    10   11.3  10.6   9.8  11.8   0.5
  9.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 10.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 11.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 12.|-- server-54-230-215-138.tpe  0.0%    10   11.9  11.2  10.1  12.2   0.3

這樣先前遇到從 HiNet 到 Level3 常常爛掉的問題應該是可以解決不少？