logger：友近(NTT),日高(Telstra) 14:20〜14:40 発表者： 矢萩 茂樹 YAHAGI Shigeki 所 属： インテリジェント・テレコム株式会社 Title ： BGP communityによるトラフィック制御 ０．発表要旨： マルチホーム・ネットワーク環境においては、 「異なったポリシー(運営方針)を持つ以遠ネットワークからの戻りを、 如何に適正なルートから戻させるか？」 が一つの大きな命題となる。インターネットルーティングの最上位階層にて 用いられるBGP4においては、この要件を実現する手段の一つとしてcommunity 属性を規定。AS(自律システム)間にわたるポリシー記述を可能としている。 本プレゼンテーションでは、BGP communityの概要・制御方法などについて 実ネットワークでの使用例をまじえて紹介し、community制御における限界等 について考察する。 プレゼンテーション内容の主な議題は以下の通り。 - BGPによる経路制御方法 - communityとは - communityによる制御方法 - community仕様のご注意 - community制御の限界 １．BGPによる経路制御方法 BGP4(RFC1771)というルーティングプロトコルは、出力するトラヒックの制御は 簡単にできるのだが、帰ってくるトラヒックの制御が難しい。 BGPのattributeはいろいろあるが、経路制御のためのものは大雑把に言って 次の３つがある。 ・local-preference ・MED ・as-path 優先順位は、local-pref → as-path → MED となっている。 AS外のトラヒック制御は困難。 AS内ではそれぞれの独立したポリシーがあるし。 MEDも隣しか効かないし、優先順位も低いのでlocal-prefを設定されていれば 意味ないし。 as-path prependはCisco orientedだし。間接的だし。 ということで、帰りのトラヒックを制御するが、MEDのように伝播範囲 を規定したりしないやつが欲しい→そこで、communityの登場となる。 ２．communityとは community(RFC 1998)について ・32bitのattribute（タイプコード８） ・複数のcommunity messageを同時に転送可能 ・グローバル領域とプライベート領域がある ・0x00000000から0x0000FFFF、および0xFFFF0000から0xFFFFFFFFの範囲は予約 ・well-known communityは２つ no-export(0xFFFFFF01)：伝播範囲ー隣接AS内 no-advertise(0xFFFFFF02)：伝播範囲ー隣接BGP speakerまで ・一般的なのは、上位16bitをAS番号、下位16bitを設定のための番号に使う方法 ・Ciscoではroute-mapにて記述できる。 →route-Mapに記述できるものであればなんでも出来る。 ３．communityにより何ができるか 使用例１ no-exportを使って、隣接ASまでだけ経路をアナウンスする。 N3で使われてたりする。 N2でもある公共組織とで使われてたりする。 使用例２ local-preference制御 communityを「AS:local-prefの値」と送ることによって、 communityがついた経路のlocal-pref-attributeをそのlocal-prefの値 にしたりする。 MCIで70,80,90でユーザ向けにやってたりする（実は80はiBGP専用だったりするが）。 使用例３ as-path-prepend制御 communityをつけることにより、set as-path prepend してくれる。 ４．community仕様のご注意 ・自分が処理するcommunity以外は、ガードしましょう。自分が好む経路 のみ受け付けましょう。 ・隣がcommunityを伝播するとは限らない。 →Ciscoで、neighbor *.*.*.* send-communityが必要(defaultでは communityを伝えない）。 ５．community制御の限界 一度にいちパターンのcommunityしか処理できない。route-mapで一回matchすると 次のroute-mapを見ない。 →route-map内でcontinueすると、次のroute-mapを見に行くかもしれない。 特定communityの削除処理がないので、未処理communityのみの転送が実現できない。 いまの段階では、いまいち便利さにかける。 ６．Ciscoの機能拡張 communityでQoSができる。 set ip precedence (priority等)というのがある。 route-mapでcommunityをmatchさせ、set ip precedenceをするわけ。 ７．まとめ BGPでの経路制御の３つの方法→local-pref,MED,as-path prepend communityの特徴と使用例→範囲を限定すればそれなりに有効 BGP communityによる制御の限界→確実には使えない。 ８．質疑応答 iBGPでどのように使っているのか？（IRI:西野氏） →外から、こっちinterfaceから来た経路情報にはこのcommunity、 あっちのinterfaceから来た経路情報にはあのcommunityをつける というようなことをしている。（学情:松方氏） →どこから来たかによってcommunityをつけるのは、うれしい。 as-path lengthが短くなくても優先させたいときとかに、 非常に有効に活用できた。（IT:矢萩氏） →また、communityを使うと非常にきれいなconfigになり、運用管理 にうれしい。（学情:松方氏） →IGPからiBGPにredistributeするときにつけて、eBGPに流すのは、 あるcommunityだけにするとかいった方法もある。（学情:松方氏） →米国だと、IXもいろいろあるが、IXから来た経路を他のIXに流したく ないということがよくあるので、そのときもcommunityは便利 （GlobalOne:石井氏） あるところから来た経路をcommunityをつけて、それをmatchさせてある 設定をするとする。その設定を、それとは違う経路にも反映させたい と思うとき、どうやったら面倒な設定をせずにできるか？その経路だけ 同じcommunityを付けることを簡単にできるアイデアはないか？ （GlobalOne:石井氏） →よくわかんないけど、その設定が、next-hopを書き換えて実現できるのなら set ip next-hopをするという手もあるが。でもその場合next-hop自体が 消えると、ルーティングテーブルから消えちゃうので嫌だね。（IT:矢萩氏） →next-hopを書き換えるのは嫌だ。（GlobalOne:石井氏） →community でlocal-prefを反映させるのは、すべてのGWで設定する 必要があるし、communityの数だけmatchを書く必要あるし、結構面倒に なることがある。（IT:矢萩氏） 以上