読者です 読者をやめる 読者になる 読者になる

LGTM

Looks Good To Me

BGP Community を透過する事業者がどれくらいいるか調べた

11月末にInternet Week 2016 というイベントで,「BGP Community の基本設計」について発表してきた.内容については 発表スライド をご覧いただければ良いかな と思うが,壇上から挙手アンケートを取ってみてびっくりした.

「顧客から受信したBGP Community を消さずに透過しているかた,どのくらいいますか?」の結果が 1%ほどだった.

該当するけど手を上げられなかった方もいると思うし,母数として全員がAS 運用者じゃなかったかもしれない.が,「えっ! 少なすぎる!」と思った.世の中そんなもんなのかな,と思ってざっと調査した内容を書いておく.

結果から書いておくと「割合的にはまあそんなもん」だった.

BGP Community は API なんですよ

BGP Community は「便利なタグ」だったり「他社ネットワーク内での自社経路のふるまいを定義できるノブ」だったりする.たとえば

  • 経路がネットワークに入ってきたのはどの国か,顧客に伝えるタグ
  • 他社ネットワーク内でLocal Preference を下げるためのノブ

のように,BGP プロトコルの範囲のなかで付加価値をつけることができる.「HTTP(S) でやれば?」という考えも頭をよぎるが,IP レイヤーの操作をさらに上のレイヤーに依存するのは危険かもしれないし,レイヤーをまたぎすぎている感がある.「HTTP(S) でもできる」が理想だけれど,IP ならではの柔軟性と拡張性を得るためにもBGP プロトコルでやりたいところ.

上のように AS65000 がBGP Community に乗せて便利情報を提供してくれている場合,AS65001 の立場からすると「自社に不利益がある」「AS65000 の利用規約に反する」ような場合を除いてAS65002 に透過しない理由はないはず.逆もしかりで,AS65002 が「AS65000 内での経路のふるまいを制御したい」と考えているとしてAS65001 がそれを遮断する理由はないように思う.

が,アンケート結果では「でも止めてる」だし,観測範囲内でも止めてる事業者がほとんどに見える.

特にAS65002 がAS65001 の顧客だった場合,情報を透過するほうがAS65001 サービスの付加価値につながりそうだし,ぜんぶ透過しなくても工夫してやればいいのに…と思う.

「将来,トランジット事業者(上の絵でいえばAS65000) を変えるかもしれない」という懸念はあるが,トランジット事業者が似たAPI を提供してさえすればAS65001 で変換するのがよさそう.他社のサービスや製品を組み合わせてうまいこと抽象化することは,サービスを作る側の手腕の見せ所かな と思う.

調査結果

AS間の関係を transit / peer / customer / unknown に分類し「X から受信したBGP Community をY に透過する事業者数」を数えた.調査の方法はあとで.

たとえば transit からcustomer に向かう矢印は93 だが,「transit から受信したBGP Community をcustomer に透過するAS は93 個あった」という意味.4バイトAS は除外してカウントしている.

BGPlay コレクターの配置的にすべてのAS をカバーしていないかもしれないが,フルルートの1/11 ほどのサンプル数.

  • customer から受信した経路を透過する事業者が比較的多そう
    • 送信先によって透過 / 不透過を区別してそう
    • 特にtransit 方向にはフィルターしてそう
  • 実際に使われている2バイトAS 約6万個に対して,透過しているAS はおよそ1% 程度しかない

ということがわかる.unknown が多いのは,参照したAS間の関係データベースが良くなかったかもしれない.

調査方法

BGPlayThe CAIDA UCSD as-relationships - 20161201 のデータを使った.

2バイトAS のすべてについて

  1. そのAS がoriginate している適当な1 prefix を選ぶ
  2. BGPlay でBGP Community が透過しているかどうか調べ,AS_PATH 上の各AS について transit / peer / customer のどれからどれに送信する際に透過するかをマークする
  3. AS 間の関係についてはCAIDA のas-relationships を参照する

仮定として

  • BGPlay コレクターはcustomer 相当と考える
  • BGP Community のGlobal Administrator がAS_PATH 上に現れるもののみをカウント
    • 現れない場合,BGP Community がどこでつけられたか判別できない
    • そのBGP Community は,AS_PATH 上のGlobal Administrator より右でつけられたものと考える

たとえば

  • AS_PATH: 65000 65001 65002 65003
  • BGP Community: 65002:100

の場合

  • Community は65002 か65003 でつけられたと仮定
    • → 65001 はCommunity を透過する
  • 65001 から見て65002 は transit で,65000 は customer
    • → 65001 は transit から受信したBGP Community を customer に透過する
  • 65000 から見て65001 は customer で,BGPlay コレクターも customer
    • → 65000 は customer から受信したBGP Community をcustomer に透過する

経路数でいえばフルルート68万経路に対して6万経路分,1/11 サンプルを調査した.BGPlay コレクターの配置から「透過しているんだけど観測できない」AS があることにも注意.

なお,今回は割合を概算したかったので 4バイトAS は除外してカウントしている.

Internet Week 2016 発表スライド

発表スライドをリンクしておきます.

  • AS 運用者向け
  • BGP Community 設計のコツ
  • API と思って設計しよう

のような内容です.よければご覧ください.

https://speakerdeck.com/codeout/bgp-communityfalse-ji-ben-she-ji