Google Groups 脫離 Usenet 系統

先前在「Google Groups 將在 2024/02/22 斷開與 Usenet 的連接」這邊提到的,Google Groups 在 2024/02/22 會斷開與 Usenet 的 NNTP peering,日子到了...

在 Google Groups 上官方更新 banner 訊息了:

從我自己架的 News Server 上也可以從 innreport 中 incoming feed 的各個指標看到差異了:

可以再觀察幾個月看看後續的量,原先使用 Google Groups 的人會跑來 Usenet 上面嗎?或是 Usenet 就繼續萎縮下去...?

AWS 的 VPC 在 Routing 上的改善

在這次 re:Invent 發表會上,AWS 也宣佈了一些跟 VPC routing 有關的改善。

第一個是 AWS Transit Gateway 彼此可以互串了:「New for AWS Transit Gateway – Build Global Networks and Centralize Monitoring Using Network Manager」。

第二個是可以拿 EC2 的機器 (實際上應該是 ENI) 當作 routing 的目標:「New – VPC Ingress Routing – Simplifying Integration of Third-Party Appliances」。

不過我記得第二個好像早就可以了啊,這次不知道是簡化了什麼東西...

Inter-Region VPC Peering 的範圍大幅增加

AWS 的 Inter-Region VPC Peering 又多了不少區域了:「Inter-Region VPC Peering is Now Available in Nine Additional AWS Regions」。

本來是支援 us-{east,west}-{1,2} 這四個,現在又多了 9 個,來到了 13 個:

Starting today, Inter-Region Virtual Private Cloud (VPC) Peering is available in AWS EU (London), EU (Ireland), EU (Paris), Asia Pacific (Mumbai), Asia Pacific (Sydney), Asia Pacific (Singapore), Asia Pacific (Tokyo), Canada (Central) and South America (São Paulo) Regions in addition to AWS US East (Northern Virgina), US East (Ohio), US West (Northern California), US West (Oregon) Regions.

與現在的 region 表格比較,剩下的是 ap-northeast-2 (南韓首爾) 與 eu-central-1 (德國法蘭克福),其他公開使用的區域都在這波的公告全上了。(也就是美國政府專屬區域與中國區不算在內)

Jeff Barr 正在努力回顧去年 re:Invent 發表的東西:Inter-Region VPC Peering

居然是在補進度 XDDD 這是去年 AWS re:Invent 發表的功能:「New – Inter-Region VPC Peering」,在去年的時候也有提到了:「AWS 總算推出跨區 VPC Peering 了...」。

不過當時不確定跨區域時怎麼處理傳輸加密 (或者沒有處理?),這邊 Jeff Barr 補充提到了一些細節:

Data that passes between VPCs in distinct regions flows across the AWS global network in encrypted form. The data is encrypted in AEAD fashion using a modern algorithm and AWS-supplied keys that are managed and rotated automatically. The same key is used to encrypt traffic for all peering connections; this makes all traffic, regardless of customer, look the same. This anonymity provides additional protection in situations where your inter-VPC traffic is intermittent.

這樣架構會簡單不少,不需要自己再疊一層確保加密這件事情 (因為當時沒翻到資料說有加密...)。

AWS 總算推出跨區 VPC Peering 了...

AWS 總算是開始支援跨區 VPC Peering 了... 這功能喊好久了啊:「Announcing Support for Inter-Region VPC Peering」。

不過目前支援的地區只有這些:

Inter-Region VPC Peering is available in AWS US East (N. Virginia), US East (Ohio), US West (Oregon) and EU (Ireland) with support for other regions coming soon.

算是個開頭... 不然以前都要自己搞 High Availability 的 site-to-site IPsec tunnel。

另外沒看到跨區時有沒有加密... (理論上應該要?)

既有的 VPC 可以增加更多 subnet 了

既有的 Amazon VPC 可以增加更多的 subnet 了:「Amazon Virtual Private Cloud (VPC) now allows customers to expand their existing VPCs」。

Amazon Virtual Private Cloud (VPC) now allows customers to expand their VPCs by adding secondary IPv4 address ranges (CIDRs) to their VPCs.

除了中國與 GovCloud 以外都支援了:

There is no additional charge to use this feature. This feature is available in all AWS regions except GovCloud and AWS China (Beijing) regions.

這樣就不用另外開一個 VPC 再用 peering 的方式打通...

Amazon Lightsail:AWS 的 VPS 服務

所以 AWS 決定也跳進來搞 VPS 服務了?推出了 Amazon Lightsail:「Amazon Lightsail – The Power of AWS, the Simplicity of a VPS」。

定價策略就跟 VPS 一樣:

如果你熟悉數字的話,這其實跟 DigitalOcean 的規格與價錢一模一樣 (參考「Pricing on DigitalOcean」這頁),連備份的 USD$0.05/GB/month 也相同。目前雖然只有 us-east-1 有,但看起來複製並不難...

FAQ 裡有提到可以透過 VPC peering 連進 AWS:

You can connect your Lightsail instances to VPC resources in your AWS account privately, by using VPC peering. Just choose Enable VPC peering on your Lightsail account page, and Lightsail does the work for you. Once VPC peering is enabled, you can address other AWS resources in your default AWS VPC by using their private IPs.

有趣的是,這個頻寬費用超級便宜... 目前比較不確定的是 bandwidth 是不是 pool-based (沒用完的流量可以挪到其他機器上用),另外這邊的頻寬計算方式是不是算 us-east-1 內?

這個方案好有趣...

AWS 北京也支援 Direct Connect 了...

看到 AWS 官方的公告:「Announcing AWS Direct Connect for the China (Beijing) Region」。

這代表可以拉線路進 AWS 在北京的機房直連,另外可以參考「APN Partners Supporting AWS Direct Connect」的表格,可以知道要找哪些人,目前北京區看起來只有 Sinnet

CloudFlare 與 Google Cloud Platform 的合作

在「CloudFlare is now a Google Cloud Platform Technology Partner」這邊提到了 CloudFlareGoogle Cloud Platform 的合作,應該只有這段比較重要 (有實質意義):

Also, CloudFlare peers with Google in strategic locations globally, improving response times for Google Cloud Platform services.

也就是會多拉一些 peering 讓 CloudFlare 與 Google Cloud Platform 之間變順?不過更重要的部份,也就是 CloudFlare 對 client (到使用者這端) 之間的品質一直都不太好,大多數人都只是當作免費頻寬在用...

幾個新發現:IPv6 與 Facebook 台灣機房...

無意間測試時發現的...

Ubuntu 14.04 的 PPPoE 撥上 HiNet 後,會拿到 IPv6 address (我記得申請完後之前一直拿不到),然後一次拿好幾個 (不知道什麼原因,應該要去翻翻看 IPv6 是不是有什麼特性):

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:1.163.x.x  P-t-P:168.95.x.x  Mask:255.255.255.255
          inet6 addr: 2001:b011:3008:282:xxxx:xxxx:xxxx:xxxx/64 Scope:Global
          inet6 addr: 2001:b011:3008:282:xxxx:xxxx:xxxx:xxxx/64 Scope:Global
          inet6 addr: 2001:b011:3008:282:xxxx:xxxx:xxxx:xxxx/64 Scope:Global
          inet6 addr: 2001:b011:3008:282:xxxx:xxxx:xxxx:xxxx/64 Scope:Global
          inet6 addr: fe80::xxxx:xxxx:xxxx:xxxx/10 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:24632377 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16553423 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:30408127665 (30.4 GB)  TX bytes:2344774062 (2.3 GB)

然後到處亂測發現 Facebook 在台灣有機房:

gslin@GSLIN-HOME1404 [~] [00:32/W3] mtr --report www.facebook.com
Start: Thu Mar 19 00:32:25 2015
HOST: GSLIN-HOME1404              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- ipv6.dynamic.hinet.net     0.0%    10    6.2   6.5   6.2   7.3   0.0
  2.|-- 2001:b000:82:5:22:2201:1:  0.0%    10    6.1   9.0   6.1  26.4   6.3
  3.|-- 2001:b000:82:4:3201:3302:  0.0%    10    6.7   6.6   6.3   6.8   0.0
  4.|-- 2001:b000:80:3:80:82:3:2   0.0%    10   11.6  10.7   6.9  16.6   2.8
  5.|-- 2001:b000:80:4:3011:3311:  0.0%    10    6.9   7.3   6.4  10.0   1.1
  6.|-- 2001:b000:80:7:0:3:2934:1  0.0%    10   16.8   8.3   6.9  16.8   3.0
  7.|-- po126.msw01.01.tpe1.tfbnw  0.0%    10    7.9   8.0   7.5   8.9   0.0
  8.|-- edge-star6-shv-01-tpe1.fa  0.0%    10    7.3   7.2   6.8   7.6   0.0

再回頭測了 IPv4:

gslin@GSLIN-HOME1404 [~] [00:32/W3] mtr --report -4 www.facebook.com
Start: Thu Mar 19 00:33:18 2015
HOST: GSLIN-HOME1404              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- h254.s98.ts.hinet.net      0.0%    10    6.9   6.4   5.8   6.9   0.0
  2.|-- SNUH-3301.hinet.net        0.0%    10    6.3  12.2   6.2  60.9  17.1
  3.|-- SNUH-3201.hinet.net        0.0%    10    6.2   6.6   6.2   6.8   0.0
  4.|-- TPDT-3011.hinet.net        0.0%    10    7.8   8.8   7.6  10.5   0.7
  5.|-- tpdb-3311.hinet.net        0.0%    10    6.4   6.7   6.3   7.8   0.3
  6.|-- 203-75-228-33.HINET-IP.hi  0.0%    10    7.4   7.3   7.0   7.6   0.0
  7.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  8.|-- edge-star-shv-02-tpe1.fac  0.0%    10    7.3   7.3   6.8   7.7   0.0

而且 Facebook 上的圖片會導到 scontent-tpe.xx.fbcdn.net,這樣產生的量應該不小?而用 Googlescontent-tpe.xx.fbcdn.net,可以看到大約是在 2015/02/14 上線的。

透過幾個不同的 ISP 看了一下 routing,應該是跟國內幾個 ISP 有 peering,沒有的就走 TPIX 交換。

不過學術網路 (TANet) 得繞到香港 HKIX 再回來,這就有點虧了,不曉得 Facebook 對學網是不是吐其他的 endpoint 出去。(有租用國際線路 transit 的學校應該會走租用的國際線路,通常是 TWGate 就交換到 TPIX,不會這樣繞...)