これとかこれのやつで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との使い分けが分からない)
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を持たないと試しようがないんです。
