BMPを検証してみました

2014/08/11

ZhouWenting

初めまして、ネットワークエンジニア周ウェンティンと申します。
GREEのサービスネットワークの運用設計を担当しております。
普段ネットワーク業界でストイックの人たちを集まる飲み会で皆の思いを聞くことが好きです。
今回はビジネスやサービスを越えて、世界最大のネットワーク機器開発会社であるCisco Systemsさん、日本大手ISP(Internet Service Provider)であるBIGLOBEさんと一緒にBMPというまだ標準化前段階のプロトコルを共同検証し、その結果をJANOG34で発表してきました。
その内容をご報告できればと思います。

背景

世界中のインタネットはBGP(Border Gateway Protocol)という通信プロトコルで接続してます。
ユーザネットワークを提供するインターネット事業者や企業などの組織間がどのように通信行うか、どの径路を通しているかを全てBGPのアルゴリズムで決められます。径路が変化したり、通信障害が起きたりする時はネットワーク機器間でBGPのやり取りによって検知されます。しかし、BGPはとても複雑で、また、ネットワーク機器によってOSやCLIが異なるためオペレーションも様々です。そのため、エンジニアの経験やスキルによってBGPが取得してくれた情報を完全に理解するのがとても難しいです。
そこで、今回はBMPを注目しました。

BMPとは

BMP(BGP Monitoring Protocol)はBGPをモニタリングするプロトコルです。
本来BGPはネットワーク機器間でしかやり取りを行わないですが、BMPはそのやり取りをサーバでキャプチャし、その結果を表示します。キャップチャしたデータをどのように表示するのがサーバの実装にもよりますが、ネットワーク機器メーカを頼らず、BGPの可視化が期待できます。

プロトコルの標準化

インターネットは無数なネットワーク機器が物理的にケーブルで繋がり、論理的には様々な通信プロトコルを用いて通信し合い構成されます。その様々な通信プロトコルは世界レベルで統一しなければいけません。実は、プロトコル標準化を行う団体が多数います。
例えば、IETF（Internet Engineering Task Force）と呼ばれている団体は主にインターネットで使用される技術（TCP/IPなど）の標準化を行います。また、標準化された文章はRFC(Request for Comments)と呼ばれていて、固有の番号が付与されインターネットで公開されています。
BMPはまだIETFドラフトな段階で、RFCされていません。そのため、対応するネットワーク機器がまだ少なく、BMPを普及させるには、我々サービス側にいる企業たちが「BMPを使ってみたい」、「こう言う機能が欲しい」ともっと声をあげなければいけません。
ちなみに、現在最新のIETFのdraft07ではBMPがVersion3になっています。
BMPのIETFドラフト
http://tools.ietf.org/html/draft-ietf-grow-bmp-07

BMPの共同検証

今回Cisco Systemsさん、BIGLOBEさんと一緒に共同検証を行いました。
最初は社内のラボで軽く検証しました。社内の検証機材ですと、BMP Ver1しか対応しせず、Googleで一般公開されているBMPサーバbmpreceiverでデータをちゃんと取れたことが確認できました。BMPの最新バージョンでもっとがっつり検証やってみようということで、Cisco SystemsさんとBIGLOBEさんがそれぞれハイエンドのネットワーク機器製品を持ち合い、さらにBIGLOBEさんがFull routeも流して頂き、２週間Cisco Systemsさんのラボ環境で三社で共同検証することになりました。

通常の導入検証と違って、BMPはまだ標準化されてないし、サービスへ導入事例もないので、細かい機能が実装されなかったり、メーカや製品によって実装状況が異なったり、上手く動かないのは当たり前、さらに、一般公開なサーバがBMPの最新バージョンを対応しておらず、開発な方に新バージョンの実装をお願いしながら、そのコードを修正する度に検証し、当たり前のように失敗し、まだ開発者に修正を依頼し、また検証の繰り返し、本当に挫折ばっかりでした。
幸いCisco Systemsさんの社内検証用の内製ツールがBMPの最新バージョンを対応しているため、今回BMPの動作確認だけに使ってもいいということで、お借りして最終的に色々確認できました。

検証結果

BMPに期待するものが主に２つ

CLIで確認できなかったものをBMPで確認できる。
CLIで確認できたものの、BMPがよりシンプルに分かりやすく表示する。

また、BMPの評価ポイントが主に以下２点

BMPでしっかりデータを取れるか
- CLIで確認できないのは主に消えた経路情報(withdraw routes)になりますが、しっかり取れたことを確認できた。
- CLIでも確認できるものはFilterする前後の経路情報を保持するデーターベース（Adj-RIB-In、Loc-RIB-In）、BGPのCapability、Notificationなど、そちらのデータも取れたことを確認できた。
その中で、グリーが一番期待しているのはBGP Notificationでした。BGP Notificationに含まれたerror code(cease code)をきちんと表示できればトラブルシューティングがとても楽になります。検証を通じで分かったことは、BMPはあくまでもBGPのキャプチャなので、BGP Notificationの該当機能が実装されないと当然BMPが表示できません。
また、トラブルシュートには時系列(timestamp)がとても重要ですが、ネットワーク機器側も、サーバ側もBMPのtimestampを実装しなければいけません。しかし、timestampはIETFドラフト上は必須機能ではないため、実装しない場合はトラブルシュートには使えなくなります。実際導入する際はネットワーク製品におけるBGPの実装、timestampの実装はキーになってくると思います。
取ったデータを上手く表示できたか
見やすさという観点では、BMPサーバの実装によるものになります。検証の段階では一般公開されているBMPサーバはVer3を対応しているものがありませんでした。

検証結果についてBIGLOBEさんがまとめて頂きました。
http://www.janog.gr.jp/meeting/janog34/doc/janog34-rtabl-taiji-2.pdf

JANOGでの発表

日本でネットワーク運用者を中心に集まるJANOG(JApan Network Operators' Group)というイベントがあります。
BMPがまだ知らない方がたくさんいらっしゃいますし、日本でBMPが検証されたのも今回初めてです。たくさんの方に知って頂いて、運用者たちのフィードバックを頂くため、JANOGの場をお借りしてBMPの検証を紹介させて頂きました。

当日の同セッションでMultifeedさんがBMP以外の技術で経路情報を保持するための工夫を紹介して頂きました。とても面白かったです。セッションの発表については下記リンクをご確認ください。
JANOG34 Meeting ルーティングテーブルを覗きたい┃_・)ジー
http://www.janog.gr.jp/meeting/janog34/program/rtabl.html

JANOGで発表後、BMPサーバを作ってくださった救世主もいらっしゃいました。BIGLOBEさんのエンジニアブログにて詳細を記載しました。
BIGLOBEさんのエンジニアブログ
http://engineer.biglobe.ne.jp/201408/article_1.html

感想

一般の企業において、何かをサービスに導入する際、実績のあるもの、枯れた技術を使う傾向がありますが、サービスプロバイダーを除く、ユーザ企業ではネットワークの新しい技術を検証する機会がとても少ないのではないかと思います。
グリーを入社以来、異なる立場の会社を混ざって一緒に新機能の検証をするのも、またJANOGの発表も初めてでした。同じ技術を検証しても、会社のサービスによって期待する機能や活用する場所が全く異なりますし、サービス側かメーカ側かは立場によって視野も違うとしみじみ感じました。また、JANOGで発表を通して、すぐにサーバを実装して頂ける方も現れました。改めてJANOGというコミュニケーションの場の大切さも実感しました。
今後ともこのような機会がありましたら、ぜひまた参加したいと思います。