naoki86star

このインターネットの片隅で、バルスと唱えてみる

BGPUPDATEの観察

これとかこれのやつでBGPsession機能に関して、現時点2SITEでPrivateASNつなぎで、fullrouteをとってみはじめました。結局のところは、いわゆるlooking-glassで参照できるものが、一括でupdateがリアルタイムでとれる、くらいのことです。率直なところ有用性が高いわけではなさそう、と今時点では思っています*1

何をするか。とりあえず、着目するASを絞って観察してみていくことにします。

google(15169)

googleの全経路のas-pathの全パターンを観測できた地点ごとに

接続地点 as-path
20473@Atlanta 20473 1299 15169
20473@Frankfurt 20473 3356 15169
20473@Tokyo 20473 15169
136620@London 136620 15169

googleはpeer地点では全部経路をくれてるってことだと思います。VultrのAtlantaリージョンではpeerしてないんですね。peerポイントがないんですねきっと。*2

Amazon(16509)
  • 特定のprefixでupdateが頻繁にかかっている、ということを知りました。*3
  • as-pathは結構多様でprefixごとに相手先毎にいろいろ使い分けている感じみたいです。
  • (33895との使い分けが分からない)
Akamai(20940)
  • 全般pretend率高し
  • peer率が136620@Londonで1%,20473@Tokyoが0.3%,20473@Atlantaが0%*4*5
AS-path長比較(pretend込み)
接続地点 パス長平均/分散(20940) パス長平均/分散(16509) パス長平均/分散(15169)
20473@Atlanta 4.7/1.9 3.1/0.5 3.0/0.0
20473@Tokyo 4.9/1.8 3.1/0.9 2.0/0.0
20473@Frankfurt 4.4/1.8 3.1/0.2 3.0/0.0
136620@London 5.8/4.1 3.8/1.6 2.0/0.0

vultr.comのBGP接続について

これは自分の推測の話です。
vultr.comのデータは複数同時にとれたりするのですけども、そのうちひとつのリージョンだけ頻繁にupdateがかかってるように見える時期・時間帯がありました。そのとき追っていくと一旦経路が消えて再updateがかかっているような雰囲気です。消えている時間幅は追えてませんけど消えているときにその経路をshow route forしたときに経路なしと表示されます。このときそのVPSインスタンスからその経路先IPの到達性は保たれています。vultr側のbgpdが再起動したような挙動にみえて、privateASN接続はすこし信頼性を低く設定してあるのかもしれません。コミュニティあるいは経路広報の目的でpublicに接続したときにもこうなのか、それは不明なのですが不安材料です。

独り言

public-route-serverでみれる情報と合わせれば*6勘違いとか減るんでしょうけど、実はそっち先に試してみていてpyexpectを書くのが疲れてこっちに興味が移ってきた、というのがあります。

VPSクラウドのいくつかが提供してくれるBGPsession機能はそもそもfullrouteを見るためでなく、アナウンスをするニーズがあればそれに応えよう、というものと理解しています。現状だと、まず、分散した拠点からIPアナウンスする、という手段の容易化が進んでいる、までは来ているのだと思います。先に書いたことも考えるとVPSベースで効果的なanycastをどれだけ活用できるのかは、まだ分からないこと多そうです。というかASNを持たないと試しようがないんです。

*1:でもlooking-glassポチポチするよりバッチがガリガリ結果をだしてくれるのは楽しい

*2:みるとないわけではなさそうな。。

*3:もうよく知られている話なんですかね?

*4:Vultr.comのAtlantaリージョンは最安値プランとかIPv6専用プランとかあったりしてパイロット的なんだと見えます

*5:でも最近Atlantaロケーションから512Mプランが消えた...

*6:てよりそっちを先に観察すりゃぁ、ってのはなし