BGP

　相互通信を行うインターネットでは、パケットを正確に宛先にまで届けることが必要です。宛先はパケットに書かれていますので、その宛先を見て正確に宛先のホストにまで届けることができなくてはなりません。そのためには、宛先に届けるための情報を得る仕組みと、その情報を基にして、正確に宛先ホストまでパケットを転送するための仕組みが必要となります。これを経路制御とかルーティングなどといいます。ルーティングの方法はいくつかあります。分け方としては、小さなネットワーク向け、中程度のネットワーク向け、インターネットに対応できるような大規模ネットワーク向けというようにネットワークの規模によって分類する方法や、ルーティングの性質によって分類する方法、あるいはプロトコルを適用するネットワークの性質による分類方法など様々です。
　
　今回紹介するのはインターネットレベルの巨大ネットワークに対応するBGP（Border Gateway Protocol）という方法です。





1　BGPの概要

1．1　EGPとIGP

　ルーティングプロトコルにはEGPとIGPがあります。この2つのプロトコルを分けるポイントはGatewayの外側で適用されるか、内側で適用されるかです。Gatewayの外側で適用されるのがEGPで、EGPの具体的なプロトコルの例がBGPです。

　ルーティング（経路制御）プロトコルの分類方法にはいくつかの方法がありますが、そのうちの1つに、制御するルートの対象によってEGP（Exterior Gateway Protocol）とIGP（Interior Gateway Protocol）に分けるという方法があります。

　IGPにはいくつかのプロトコルがありますので、一般的にはIGPs（Interior Gateway Protocols）と呼ばれます。具体的なプロトコルとしてはRIP（Routing Information Protocol）、OSPF（Open Shortest Path First）、EIGRP（Enhanced Interior Gateway Protocol）、IS-IS（Intermediate System to Intermediate System）などがあります。

　IGPはGatewayの内側でルーティングを行う場合のプロトコルです。Gatewayの内側では、ある特定のポリシーに従ってネットワーク管理が行われますので、外から見ると1つの単位とみなすことができます。このネットワークの単位はAS（Autonomous System、自律システム）と呼ばれます。代表的なASがISPです。一般企業のネットワークや、大学のネットワーク、家庭内LANなどもASと考えることができます。

　EGPsはGatewayの外で使用するルーティングプロトコルです。EGPsにはEGPとBGPという具体的なプロトコルがありますが、EGPは実用性に問題があるということで、現在はほとんど利用されていません。従って、EPGsといえば、BGPということになります。現在のBGPのバージョンは4ですので、BGPといった時にはBGPversion4（RFC4271）を意味します。

　IGPsのRIP、OSPF、EIGRPなどはサブネットの単位でメトリックを使ってルートの評価を行います。これらのルーティングプロトコルはローカルのネットワーク（つまりGatewayの内側）では適切に機能しますが、インターネットの制御はできません。

　例えば、RIPではインターネットの制御は全く不可能です。RIPは、そもそもホップ数が15以上のネットワークの制御ができませんので理論的に不可能です。これは規定の問題で15以上にすれば問題ないと考える方がいるかもしれませんが、ホップ数が増えると実際に使えないので15に限定しているのです。従って、規定を変えればいいという話ではありません。

　OSPFはRIPと比較すると大規模ネットワーク向きですが、OSPFでもインターネットの制御は向いていません。

※OSPFについては、OSPFの章をご覧ください。OSPFでインターネットを制御しようとすると、交換しなくてはならないLSAの量が膨大になり、ネットワーク帯域を圧迫することになるでしょう。リンクステートデータベースが巨大化し、メモリを圧迫します。そして、とてつもなく大きなSPFツリーを解析しなくてはならなくなり、メモリとCPUに大きな負担を掛けることになります。これに耐えうるルータを作るとなると、ルータは極端に高価なものとならざるを得ず、ネットワークの構築には莫大や経費が掛かることになってしまいます。

　インターネットのルーティングにはBGP（Border Gateway Protocol）が利用されます。BGPは、ASを単位としてルートの評価を行います。AS単位の経路は通常ASパスとよばれます。BGPではASを単位としてパスの評価を行いベストパスをルーティングテーブルの注入します。ルーティングテーブルはIGPsのようにネットワークアドレス（IPプリフィックス）でルートを表します。従って、BGPでやり取りされるルート情報は、ネットワークアドレス（IPプリフィックス）情報とASパスに関する情報ということになります。ただし、パスの情報は単純ではありません。パス属性という概念を使って柔軟に経路制御ができるように工夫されています。

※OSPFなどのルーティングプロトコルでもASという言葉が利用されますが、その場合のASと、BGPのルーティングの単位としてのASは全く意味が異なります。



1．2　AS番号

　BGPではGatewayの内側は1つの単位として扱います。こうすることでインターネット全体のルーティングを簡略化することが可能となります。Gatewayの内側を1つの単位として時の単位の呼び方をASといいます。ASを単位としてインターネット全体のルーティングを考えますので、ASの識別子が必要となります。これをAS番号といいます。

　BGPではASを単位としてルーティングを考えますので、ASに何らかの識別子を付けることが必要となります。ASのユニークに識別する識別子がAS番号です。

　各ASはAS番号の割り当て機関に対して申請して、AS番号を割り当ててもらいます。

　AS番号の割り当て機関は、IPアドレスの割り当て機関と同じICANN（Internet Corporation for Assigned Names and Numbers）です。ICANNは世界をいくつかの地域に分けて、下部組織に管理を委ねています。アジア太平洋地域を管理するのがAPNIC（Asia Pacific Network Information Center）で、日本ではJPNICがAPNICの代行を行っています。

　AS番号は16ビットの番号（1～65,535）で、1～64,511までがグローバルAS、64,512～65,535までがプライベートASです。

※ASの定義から言えば、一般の企業の社内ネットワークや、家庭内LANなどもASと捉えることは可能ですが、これらのネットワーク内でBGPを使う必要性はほとんどありませんので、ASの申請はしていないと思います。もし、何らかの理由で一般企業の社内ネットワークや家庭内でBGPを動かす必要があれば、その時にはASの申請をすることになるでしょう。

※AS番号は2バイト長であるため0～65535が利用できますが、AS番号を希望する組織が年々増えています。このままいくとAS番号が枯渇してしまいますので、現在4バイトに拡張する技術が実装され始めています。また、2007年1月から、希望する組織には4バイトのAS番号が配布されています。これからは4バイトのASを理解するルータが増えていくことが期待されています。



1．3　BGPの拡張

　BGP4は元々、IPv4アドレスのルーティングのために設計されましたが、IPv6にも対応できるように拡張されています。更にマルチキャストアドレス、MPLS(Multi Protocol Label Switching）にも対応できるように拡張されています。これらの拡張はまとめてBGP4+とか、MBGPなどと呼ばれています（RFC2545、RFC2858など）

1．4　BGPを用いたルーティングの概要

　インターネットはASを相互接続したネットワークです。ASの代表はISPです。ISPは直接接続している場合もありますし、IXを経由して結びついている場合もあります。

　BGPを使ったルーティングでは、AS番号とIPアドレスの割り当てを受け、各ISP同士が接続される必要があります。ISP同士は提携関係などがあり直接接続されている場合もありますが、直接接続されていない場合もあります。このような場合にはＩＸ（Internet eXchange Point、インターネット相互接続点）を介して互いに接続しなくてはなりません。




　各ASが互いに接続してお互いに通信が可能になると、次のようなネットワークになります。

　AS単位で結びつける働きをしているのが、BGPです。BGPはインターネット全体を制御するプロトコルですので、Helloのようなメッセージを使って隣接ルータを探すことは難しくなります。インターネットはそもそもブロードキャストのような通信方式を認めていないことが多いからです。そこで、ルータの設定者が手作業で隣接ルータ同士を結び付けます。結びつける手法はTCPです。2つの間にTCPでコネクションを構築し、TCP上でBGPのセッションを確立します。BGPセションの関係を構築したBGPスピーカ同士をBGPピアといいます。

　各ASではBGPを稼働させます（内部では、IGPsのOSPF、EIGRP、IS-ISが稼働しているかも知れません）。このBGPを他のBGPと接続します。BGPが接続に使うのはTCPです。従って、TCPで接続できるなら、物理ネットワーク的に直接つながっている必要はありません。TCPコネクションではTCPポート179番が利用されます。

　TCPコネクションを構築して、そのコネクション上でBGPセションを確立します。BGPセションを構築しているBGP（ルータ）同士を、BGPピア（Peer）と呼びます。

※BGPスピーカはBGPという言葉をしゃべるルータという意味です。BGPの専門書では、スピーカと呼ぶのが一般的です。

※BGPピアはBGPネイバーという言い方もありますが、ネイバーというと物理的に直接つながっているというイメージを持ちやすいので、本書ではBGPピアという言葉を使うことにします。

　BGPピアはIPプリフィックスと、パス属性を交換します。宛先までの経路の評価はパス属性で行います。パス属性はいくつかありますので、パス属性でパスを評価する場合には、属性の適用の順番が予め決まっています。

　BGPピアの関係を通じて経路制御を行うのがBGPというプロトコルです。経路制御するためには、自ASへの経路をピアを通じて広告する必要があります。これを、「アドレスをアナウンスする」といいます。経路制御では、ネットワークのアドレスが使われますので、ネットワークのアドレスがアナウンスされます。ネットワークのアドレスはIPプレフィックスと呼ばれることもあります。要するにIPアドレスのサブネットマスクの処理をしたアドレスです。しかし、BGPではAS単位でルート（経路）の評価を行います。送信元ASから宛先ASにたどり着くまでに、どのようなASを経由するか（As_Path）というのが基本ですが、評価はAs_Pathを含めた様々な観点から柔軟に行いますので、BGPピアが交換するルート情報もいろいろです。これらをひっくるめてパス属性といいます。

　従って、BGPピア同士が交換するルート情報はサブネットワークのアドレス（IPプリフィックス）だけでなく、バス属性も含まれます。つまり、IPプリフィックスと、パス属性を交換しあいます。

　インターネット全体でルーティングするためには、ルート情報を他のASに伝送する必要があります。他のASから受信したルート情報を他のASに転送するのが基本ですが、このようなASはトランジェットASと呼ばれます。インターネットの外縁に当たるASは必ずしもトランジェットである必要はありません。


　ルート情報は自ASの情報をアナウンスするだけでなく、他のASのルート情報も受け取る必要があります。他のASのルート情報を受け取ったら、その情報を更に、他のASにも流さなくてはなりません。このように他のASから受け取ったルート情報を更にアナウンスするASは「トランジェットAS」と呼びます。

　上流ISPに該当するASはトランジェットASです。

　トランジェットASは必ず複数のASとつながっていますので、マルチホームトランジェットASとも呼ばれます。トランジェットASの典型例はISPです。特に上流のISPはトランジェットASとなっています。上流ISPはインターネットの中心的な存在で、他のAS宛のパケットを転送しなくてはなりませんので、他のASとの間でルート情報をやり取りしなくてはなりません。そのため、トランジェットASではグローバルAS番号が必要となります。

　自ASのルート情報だけを接続先にアナウンスするASは「非トランジェットAS」と呼ばれます。非トランジェットASは一般的にはフルルートを上流ISPから取得する必要があります。このことを「トランジェットを取得する」といいます。

　複数の上流ISPからトランジェットを取得するASはマルチホーム非トランジェットASと呼ばれます。

　インターネット接続を冗長化させたい場合に利用します。複数のASとBGPのルート情報を交換し、自ASのポリシーに基づいて最適なルートを決定することができます。マルチホーム非トランジェットASでは、グローバルAS番号を利用することもあれば、プライベートAS番号を利用することもあります。

　1つの上流ISPからトランジェットを取得しているのがスタブASです。シングルホームASとか、リーフAS、カスタマーASなどと呼ばれることもあります。1つの上流ISPにだけ接続している下流ISPが、これに該当します。


　一般的な企業の社内ネットワークや一般家庭のLANなども形式的にはこの形のASになります。通常はISPと契約して、ISPのASにデフォルトルートで接続しているだけですので、社内ネットワークでBGPを稼働させることはないでしょう。しかし、何らかの理由でBGPを稼働させる場合は、このスタブASとなります。BGPを稼働させますので、AS番号が必要ですが、この場合は、プライベートAS番号を上流ISPから割り当ててもらいます。

※スタブネットワークでBGPスピーカを設置する場合としては、外部クラウドサービスを受ける際にクラウド側からBGPスピーカの設置を要求される場合、あるいは商用のインターネットサービスインフラを運用している場合などが考えられます。

　BGPピアには同じAS内にあるiBGPピアと、異なるAS間のeBGPピアがあります。iBGPピアは何らかの形でTCPコネクションを確立できれば十分ですが、eBGPピア間は1Hopでつながっていなくてはなりません。


　BGPピアを確立するルータが同じASに属している場合と、異なるASに所属している場合があります。同じAS内でのピアをiBGP（内部BGP、Internal BGP）、異なるAS間のピアをeBGP（外部BGP、External BGP）といいます。

　iBGPとeBGPではルート情報の処理の仕方が若干異なります。例えば、同じASに属している場合には、どのASに所属しているかという情報は送信する必要がありません。あるいは、iBGPはTCP接続が可能な範囲なら、物理的に直接接続している必要はありませんが、eBGPは直接接続していることを要求されます（直接接続されていない場合は、eBGPマルチホップという方法を使う必要があります）。

　iBGPは直接接続していないiBGPピアがルート情報を交換しますので、何らかの工夫を施さないとルーティングループを発生させてしまう恐れがあります。iBGPの場合にはスプリットホライズンという手法が採用されています。

　もちろんeBGPでもループ発生の恐れがあります。eBGPではルートをeBGPピアにアドバタイズ（アナウンス）する際に、パス属性のうちの、As_Path属性のリストの先頭に自分のAS値を追加していきます。従って、受け取ったメッセージ（UPDATEメッセージ）のAs_Path属性の値に自分のAS値が含まれているかどうかを確認することができます。As_Path属性に自分のASが含まれている場合は、そのルート情報をそれ以上アドバタイズしないようにすれば、ループの発生を回避することができます。



1．5　BGPメッセージの簡単な説明

　BGPメッセージには、OPEN、KEEPALIVE、UPDATE、NITIFICATIONの4つがあります。ルート情報はUPDATEで送信されます。BGPピアはピア確立時に知っているすべてのルート情報を送信し合い、その後はネットワークの変更時にだけ送信します。

　BGPで使用するメッセージはOPEN、KEEPALIVE、UPDATE、NOTIFICATIONの4つです。

●　OPENメッセージ
　OPENメッセージはTCPコネクションを確立後に、最初に交換するメッセージです。OPENメッセージでは、AS番号や認証情報などの交換を行い、ピアの確立を行います。ピアの確立が済んだら、KEEPALIVEメッセージや、UPDATEメッセージの交換の段階に移ります。

●　KEEPALIVEメッセージ
　KEEPALIVEメッセージはピアが確立されていることを確認するために定期的に交換するメッセージです。KEEPALIVEメッセージの交換頻度はOPENメッセージで交換されるホールドタイマの値の3分の1が一般的です。ホールドタイマの時間が過ぎてもKEEPALIVEメッセージも、UPDATEメッセージも交換されない場合は、ピアがダウンしたとみなされます。

●　UPDATEメッセージ
　UPDATEメッセージはルート情報を伝達するためのメッセージです。BGPピアが確立されたらBGPスピーカは知っているすべてのルート情報をピアに知らせます。UPDATEメッセージで知らせる情報はネットワーク層到達可能性情報（Network Layer Reachability Information、NLRI）とパス属性と、取り消すルートの情報です。最初に交換するのはパス属性とネットワーク層到達可能性情報です。ネットワーク層到達可能性情報というとなんだかややこしそうな感じがしますが、要するにサブネットのアドレスのリスト（IPプレフィックスのリスト）です。ただし、パス属性は同じものになりますので、実際に送信されるのは1つのパスに関する情報だけです。

　いったんUPDATEメッセージでルート情報が交換されると、後は変更箇所（差分情報）だけが送信されます。差分情報のみを送信することで、ネットワーク帯域が過剰に消費しないようになっています。

　BGPスピーカはUPDATEメッセージを受け取ると、それをBGPテーブルに保管します。複数のBGPスピーカから同じNLRIを受信することもありますので、BGPテーブルには必ずしも最適ルートだけが格納されているわけではありません。BGPスピーカは宛先ごとに最適なルート（これをベストパスといいます）を選択し、これをルーティングテーブルに注入します。BGPスピーカは、ピアにルート情報をアドバタイズするときはベストパスに関するUPDATEメッセージだけを送信します。

●　NITIFICATIONメッセージ
　ピアを継続することができないような重大なエラーが発生した場合に送られるのがNOTIFICATIONメッセージです。NOTIFICATIONの送信側は、NOTIFICATIONメッセージを送った後、TCPコネクションを切断します。



1．6　代表的なパス属性

　UPDATEでは、IPプリフィックスとパス属性が交換されます（これ以外にも取り消しルートが交換されますが、これについては後で説明します）。そして、このパス属性によってパスの良しあしが決まってきますので、BGPはパスベクタ型のルーティングプロトコルと呼ばれます。

　BGPスピーカは他のBGPスピーカとの間で交換するBGP情報を保存するためにルーティングテーブルとは別にBGPテーブルを保持しています。複数のBGPスピーカから同じNLRI（到達可能性のあるIPプリフィックス）に関するUPDATEメッセージを受信することもあります。そのため、BGPテーブルに保存されているのは必ずしも最適なパスだけではありません。

　BGPテーブルに保管されたパスのうち最適なパス（ベストパス）が選択されて、これがルーティングテーブルに注入されます。BGPスピーカは、ピアにルート情報をUPDATEする場合は、最適パスに関するUPDATEメッセージだけを送信します。

　BGPテーブルからベストパスを選択する基準がパス属性です。パス属性は複数の値によって構成され、このパス属性を操作することでパス選択を柔軟に制御することができます。

　次にUPDATEメッセージでよく利用される代表的なパス属性について説明します。

■　ORIGIN属性
　ORIGIN属性はそのルート情報の生成元を表します。

属性値 コード（優先度） 意味
IGP 0 ルートが配布元ASの内部にあることを示します
EGP 1 ルートがEGP経由で学習されたことを示します
INCOMPLETE 2 ルートの配布元が不明、あるいは別の方法で学習されたことを示します

ルートが再配布によってBGPに注入されたときは（スタテックであろうと、ダイナミックであろうと）、特に指定しない限りORIGIN属性はINCOMPLETEです。

■　AS_PATH属性
　As_PathはそのNLRI（プリフィックス）が通ってきたASのリストです。UPDATEメッセージを他のASにアドバタイズするBGPスピーカは、As_Path属性値の先頭に自ASの番号を追加していきます。

　AS_PATH属性はそのルート情報が通過したAS番号のリストになります。ピアからUPDATEを受け取ったときにAS_PATH属性の中に自分のAS番号を見つけた場合は、そのルート情報は転送せずに破棄します。こうすることでルーティングループを回避することができます。AS_PATH属性の長さで優先順位を制御することができます。

■　NEXT_HOP属性
　NEXT_HOP属性の値は、特定の宛先に到達するのに使用されるネクストホップのIPアドレスです。IGPsのRIPや、OSPFではそのルートをアナウンスしたルータのインターフェースのIPアドレスですが、BGPの場合はちょっと複雑です。まず、eBGPとiBGPで考え方が少し違います。また、マルチアクセスブロードキャストネットワークや、NBMA（Nonbroadcast Multi Access）環境では、少し注意が必要です。具体例は後で説明します。



■　MULTI_EXIT_DISC属性
　MULTI_EXIT_DISC（Multi_Exit_Discriminator）属性は、複数の出口（Multi_Exit）がある場合に、それを区別して（discriminate）して（優劣をつけて）、特別の出口だけを使うようにするというものです。優先する出口に小さな値を付けてください。ここで、注意しなくてはならないのは出口とは相手のASから見てのことです。eBPGはTTL1のTCPコネクションを確立していますので、相手側の出口を規定することは、自分の側の入り口を指定することと同値になります。

■　LOCAL_PREF属性
　LOCAL_PREF（Local_Preference）属性はローカルな優先度です。AS内部でiBGPピア間で交換する、AS内部だけで通用する優先度です（eBGPピアは無視）。自AS内のポリシーに従って、AS内のどのルートを優先的に使うかを決めるための属性です。

■　WEIGHT属性
　Ciscoルータ独自の属性です。WEIGHT属性はピアにアドバタイズされることはありません。アドバタイズされませんので、タイプ番号も持っていません。

　WEIGHT属性は同じ宛先へのルートが複数ある場合にいずれのパスを優先するかの属性です。WEIGHT属性はBGPピアに対する優先度を、そのルータの独自のルーティングポリシーとして自分の中だけで設定します。

　これ以外にも様々なパス属性がありますが、詳しくは後で説明します。

1．7　ルート選択のアルゴリズム

　ベストパスはパス属性を基準にして選択します。基準が複数ある場合は、予め基準を適用する順番を決めておかなくてはなりません。

　BGPで獲得したルートが複数ある場合に、どのルートをベストパスとして選択するかは次のルールによります。

ステップ 説明
1 Next_HopのBGPスピーカへ到達できない場合は、そのルートは無視します。
※IGPによるルートがない
2 WEIGHTパラメータを設定されているルータは、WEIGHTパラメータが最高のルートを優先します。
3 複数ルートのWEIGHTが同じ場合、あるいはWEIGHTの設定がない場合、LOCAL_PREFが最高のルートを優先します。
4 LOCAL_PREFが同じ場合、自分自身が生成したルートを優先します。
5 複数ルートのLOCAL_PREFが同じで、ローカルルータが生成したルートがない場合は、ASパスが最短のルートを優先します。
6 ASパスの長さが同じ場合、ORIGIN属性コードが最小のルートを優先します。
7 ORIGIN属性が同じ場合は、MED属性を優先します。MEDの優先度が高いコースはコードが小さく設定されています。
8 MED属性が同じ場合は、iBGPピアからアドバタイズされたルートよりも、eBGPによってアドバタイズされたルートを優先します。
9 これでも決まらない場合は、ネクストホップへIGPで最も近いルートを選択します。
10 ルートがeBGPから学習したルートの場合、学習してから最も時間が経過しているルートを優先します。
※これはBGPに関する公式見解ではありませんが、最も古いパスはルートフラッピング（ルートの変動）の影響が最も少ないルートと考えられます（CiscoのTACの見解）
11 以上のプロセスでもベストパスが決まらない場合は、ルータIDが最も小さいBGPピアから学習したルートを選択します。
12 BGPピアのIPアドレスが最小のルートを優先します。

　以上の結果、決定されたベストパスがUPDATEメッセージでピアに伝えられます。また、ルーティングテーブルに注入され、ルーティングに適用されます。

※「11」「12」になるともうどうでもいいという感じです。何かを選ばなくてはならないので、仕方なく決めているということでしょう。

1．8　ルートリフレクタとコンフェデレーション

　大規模で複雑なASを制御する仕組みとして、ルートリフレクタとコンフェデレーションがあります。

　同一AS内のBGPスピーカが多くなると、ループの発生を回避するために、スプリットホライズンという方法を使うことになります。このスプリットホライズンはRIPなどに適用されている方法とはだいぶ違っています（これについては後で説明します）。スプリットホライズン方式を適用すると、同一AS内のiBGPがフルメッシュでセションを構築しないと、ルート情報が伝わりません。このままであれば、膨大な数のBGPセションを構築せざるを得ないことになり、消費される帯域も大きなものになると予想されています。

　さらに、BGPはTCPでコネクションを確立して、このコネクション上でBGPセションを構築しなくてはなりません。従って、HELLOを使って隣接関係を自動的に検出することができません。iBGPピアの構築には手作業が必要となります。従って、大規模なASでは設定作業が大変なことになります。

　これらのiBGPの問題を解決するための導入されるのがルートリフレクタです。ルートリフレクタは同一AS内の全てのiBGPがフルメッシュでiBGPピアを構築するという条件を緩和して、一部だけがIBGPピアを張れば済むようにしたものです。ルートリフレクタでは、iBGPピアから学習したルートを他のBGPスピーカに反射して（リフレクトして）、AS内部のBGPスピーカがフルメッシュでiBGPピアにならなくても済むようにしています。

　ASコンフェデレーションという方法は、AS内部をサブASに分割することで、AS内部でiBGPピアのフルメッシュを回避する方法です。


　以上でBGPの概略の説明を終わります。もっと詳細な、具体的な説明が欲しいという方は、更に読み進めてください。初心者の方は、初読時には省略してもいいと思います。

　今までの説明と重複している部分もありますが、予めご了解ください。








＊＊＊　ここからはBGPの詳細について説明しています。　＊＊＊


2　BGPの情報交換の仕組み

　BGPスピーカは隣接ルータとの間でルート情報の交換をします。ルート情報を交換するBGPスピーカは相互にBGPピア(Peer）といいます。BGPピアはTCPコネクションを確立して、このTCPコネクションを使って情報交換を行います。利用するポート番号は179番です。

　BGPピアはTCPコネクション上で確立しますので、1対1の関係になります。また、TCPコネクションを利用しますので、エラー制御も可能です。エラーが発生しても、失われたセグメントのみ再送すれば事足ります。

　BGPピアの確立・維持・終了には4種類のメッセージが利用されます。この4種類のメッセージは、OPEN、KEEPALIVE、UPDATE、NOTIFICATIONです。

2．1　BGPメッセージの共通ヘッダ

　各メッセージは、共通ヘッダと各メッセージ毎の独自フィールドから構成されます。共通ヘッダは次の通りです。

マーカ(16）
メッセージ長(2) 　　タイプ(1)　　 各メッセージの独自フィールド（可変長）

※表中のカッコ内の数値はバイト数を表しています。

　
　マーカフィールドは、同期とセキュリティ（認証）という2つの用途のために使用されます。

　同期フィールドとして利用されるのはOPENメッセージの場合です。OPENメッセージではマーカフィールドには全て1がセットされます。

　OPENメッセージ以外では、セキュリティ（認証）で使用します。BGPセッションの確立時にセキュリティオプションを指定している場合は、マーカフィールドはそのセキュリティオプションを基にした値となります。セキュリティオプションが指定されていない場合は、全て1で埋め尽くされます。

　メッセージ長フィールドは、共通ヘッダを含めたBGPメッセージ全体の長さを示します。

　タイプフィールドはBGPメッセージを識別するためのフィールドです。OPENメッセージが1、UPDATEメッセージが2、NOTIFICATIONメッセージが3、KEEPALIVEメッセージが4に、それぞれセットされます。

2．2　BGPピアの確立

　最初に3ウェイハンドシェークでTCPコネクションを確立します。最初にSYNビットをセットして、コネクション確立を始めるのはどちらからでも構いません。TCPコネクションを確立したら、いずれかの側からOPENメッセージを送信します。

　OPENメッセージには自分のAS番号、BGP識別子（ルータID）、使用しているBGPのバージョンなどが記述されます。

　OPENメッセージに対してはKEEPALIVEメッセージが返されます。OPENメッセージとKEEPALIVEの交換は反対方向からも行います。これで、BGPピアが確立したことになります。

　BGPピアが確立したら、KEEPALIVEメッセージを交換し合って互いの生存を確認し合います。このKEEPALIVEを交換する間隔もOPENメッセージで合意しておきます。

2．2．1　OPENメッセージ

　OPENメッセージはTCPコネクションが確立した後に最初に送られるメッセージです。OPENメッセージの目的は、BGPスピーカがそれぞれ自分自身を隣接BGPスピーカに認識させ、タイマなどのプロトコルに関するパラメータを一致させることにあります。

　OPENメッセージのフォーマットは次の通りです。

Ver（1) 　　　　　　AS番号(2)　　　　　　　 ホールドタイム(2)
ホールドタイム（続き） BGP識別子(4)
BGP識別子（続き） パラメータ長(1) パラメータ（可変長）

　VerはBGPのバージョンを記述します。

　AS番号は送信元のAS番号です。
　
　ホールドタイムは、ピアからのUPDATEメッセージ、あるいはKEEPALIVEメッセージを受け取ることなしに待つことができる最大時間です。UPDATEもKEEPALIVEも受け取ることなしに、この時間が経過すると、BGPセションが落ちたと判断します。ホールドタイムはネゴシエーションで決めます。互いに送信したホールドタイムが異なっている場合は、小さいほうの値が採用されます。

　BGP識別子は送信元のBGPスピーカのIDです。

※BGPのルータIDはOSPFと同様の方法で決めています。基本的にはルータのインターフェースのIPアドレスのいずれかです（インターフェースのIPアドレスのうち最大のものと決まっているものもあります）。しかし、これはインターフェースがアクティブでなくてはならないという条件がありますので、ルータIDとなっているインターフェースがダウンしてしまうと、最初からやり直しということになります。こういう問題がありますので、最近はメーカによってはコマンドによって明示的にルータIDを決められるものもあります。

　パラメータはオプションで、現在は、認証だけが認められています。

2．2．2　KEEPALIVEメッセージ

　BGPスピーカは、ピアからOPENメッセージを受け取ると、KEEPALIVEメッセージで応答します。それ以降は生存確認のために定期的に送信します。KEEPALIVEメッセージの送信間隔はホールドタイムの3分の1です。

　KEEPALIVEメッセージは共通ヘッダだけで構成されています。タイプフィールドには4がセットされます。

2．3　BGPピアの更新

　BGPピアが確立されたらUPDATEメッセージを使って、互いのルート情報を交換します。BGPピアが確立されて最初のUPDATEメッセージでは、知っているすべてを相手に知らせます。その後は、ネットワークに変更があった場合に、その変更箇所だけをUPDATEメッセージで知らせます。差分情報のみを送信することでネットワーク帯域を過剰に消費しないようにしています。

　各UPDATEメッセージには基本的に1つのパスに関する情報のみが記載されます。UPDATEメッセージに含まれるのは、取り消されたルート、パス属性（アトリビュート）、ネットワーク層到達可能性情報（Network Layer Reachability Information、NLRI）などです。NLRIには、そのパスで到達できるネットワークのリスト（プリフィックスのリスト）が含まれます。

　BGPスピーカはUPDATEメッセージを受け取ると、それをBGPテーブルに保管します。複数のBGPスピーカから同じNLRIを受信することもありますので、BGPテーブルには必ずしも最適ルートだけが格納されているわけではありません。BGPスピーカは宛先ごとに最適なルート（これをベストパスといいます）を選択し、これをルーティングテーブルに注入します。BGPスピーカは、ピアにルート情報をアドバタイズするときはベストパスに関するUPDATEメッセージだけを送信します。


2．3．1　UPDATEメッセージ

　UPDATEメッセージでは1つのメッセージで1つのルートに関する情報を通知します。メッセージ内の全てのフィールドは、そのルートに関するものです。

　次にUPDATEメッセージのフォーマットを示します。

　　取り消しルート長(2)　　 　　取り消しルート（可変長）　　
パス属性全長(2) パス属性（可変長）
ネットワーク層到達可能性情報（NLRI）

●　取り消しルート長/取り消しルート：取り消しルートフィールドには、UPDATEメッセージを送信する側のBGPスピーカがパケットを転送してほしくないと思っているプリフィックスのリストが入ります。取り消しルート長フィールドは、取り消しルートの長さが入ります。

●　パス属性フィールドは、後に続くネットワーク層到達可能性情報フィールド内のルート（プリフィックス）に関するBGPパス属性のリストを含みます。パス属性はIGPsのメトリックに該当するルート評価の基準です。ただ、IGPsのメトリックに比較すると、はるかに多彩で柔軟性に富んでいます。

　パス属性フィールドは次のように構成されています。

　　属性タイプ（2)　　 　　属性長（1or2）　　 　　属性値（可変長）　　

　先頭の属性タイプフィールドは、属性やその他の様々な情報を示すために使用します。属性タイプフィールドの構成は次の通りです。

　　属性フラグ（1)　　 　　属性タイプコード（1)　　

　属性タイプコードについてはパス属性の章で説明します。属性フラグは1バイトのうち、先頭の4ビットが使用されます。属性フラグの構成は次のようになります。

ビット 意味 説明
Bit0 Optionalビット 0：Well-Known
1：Optional
Bit1 Transitiveビット 0：Trasitive
1：Transitive
Bit2 Partialビット ルータがオプション属性を理解せず（サポートしていない）に通過させた場合に、このビットを（1に）セットします。
Bit3 長さ 0：属性長が1バイト単位の場合、1：属性長が2バイト単位の場合
Bit4～7 未使用。 常に0

　最初のビットはオプションビットで、パス属性がオプションかどうかを示します。パス属性は、周知属性（Well-Known Attribute）とオプション属性（Optional Attribute）の2つに大きく分けられます。

　2つ目のビットは通過ビット（Transitive bit）を表します。このビットは、その属性を他のBGPピアに転送するのかを指示します。周知属性の場合には必ずBGPピアに渡さなくてはなりませんから、このビットは0になっています。

　3つ目のビットは不完全ビット（Partial bit）です。このビットはあるプリフィックスの通知元とそのプリフィックスを受け取った側を結ぶパス上のBGPスピーカがオプション通過属性（オプションビットと通過属性の両方をセットされている属性）を理解（実装）しているかどうかを示します。

　プリフィックスの通知には、途中で中継に関わったBGPスピーカが情報を追加していくものもあります。このような場合に、その属性を理解できないBGPスピーカは必要な情報追加ができないことになります。そこで、その情報をサポートしていないBGPスピーカは、オプション通過属性がセットされたプリフィックスを通過させるときには、この不完全ビットをセットします。これによって、受け取った側は、あるべき情報が途中で何らかの理由で消失してしまったのか、それとも属性を理解しないBGPスピーカが関わっていたためなのかを知ることができます。

　4つ目のビットは長さ拡張ビットです。このフィールドで、属性の長さが1バイト単位なのか、2バイト単位なのかを示します。

●　ネットワーク層到達可能性フィールド
　ネットワーク層到達可能性フィールドは次のようなフォーマットのプリフィックスのリストです。

　　　プレフィックス長（1)　　　 　　　IPプリフィックス（可変長）　　　

　リスト内のプリフィックスの数はBGPスピーカ間で送信することができるパケットサイズに制限されます。1つのUPDATEメッセージで複数のIPプリフィックスを送信することも理論上は可能ですが、その場合にはUPDATEメッセージの全ての属性フィールドは、一緒に送信されるIPプリフィックスの当てはめられることになりますので、1回のUPDATEメッセージで送信されるIPプリフィックスの属性値は全て同じでなくてはなりません。

2．4　ピアの維持

　BGPピアが確立した後は、生存確認のために定期的にKEEPALIVEメッセージを送信し合います。

2．5　ピアの終了　

　エラーを検出した場合は、NOTIFICATIONメッセージを送信して、BGPピアを切断します。

　NOTIFICATIONメッセージのフォーマットは次の通りです。

　エラーコード(1)　 　サブエラーコード(1)　 　　　　データ　　　　

　エラーコードフィールドは、発生したエラーのタイプを識別します。エラーコードとその意味は次の通りです。

コード エラーコード名 説明
1 メッセージヘッダエラー 共通ヘッダのエラー、あるいはメッセージ全般を処理する際にエラーが発生しました。
2 OPENメッセージエラー OPENメッセージの処理する際にエラーが発生しました。
3 UPDATEメッセージエラー UPDATEメッセージを処理する際にエラーが発生しました。
4 ホールドタイム超過 メッセージを受信後、ホールドタイムが経過しました。
5 有限状態マシンエラー 現在の状態に対して不正なイベントが発生しました。
6 終了 他のエラーコードに当てはまらないが、何らかの理由でBGPセションを終了した場合です。


　メッセージヘッダエラーのサブコードは次の通りです。
サブコード エラーサブコード名 説明
1 接続の非同期 マーカフィールドが予期しない値であることを示します。
2 メッセージ長の異常 メッセージ長がプロトコルで規定されたよりも長すぎる、あるいは短すぎる場合です。
3 メッセージタイプの異常 メッセージタイプがOPEN、UPDATE、NOTIFICATION、KEEPALIVE以外の場合です。


　OPENメッセージエラーのサブコードは次の通りです。
サブコード エラーサブコード名 説明
1 非サポートのバージョン番号 OPENメッセージで指定されたBGPバージョンを、受信側のルータがサポートしていません。
2 ピアAS異常 OPENメッセージで指定されているASフィールドが、受信側のASと一致していません。
3 BGP識別子異常 OPENメッセージのBGP識別子フィールドが、受信側システムの設定と一致していません。
4 非サポートのオプションパラメータ NOTIFICATIONメッセージの送信側が、受信メッセージに含まれるオプションパラメータをサポートしていません。
5 認証の失敗 OPENメッセージを送信してきたBGPピアを認証できません。
6 受け入れ不可能なホールドタイム 受信したOPENメッセージに含まれるホールドタイムを拒否します。


　UPDATEメッセージエラーのサブコードは次の通りです。
サブコード エラーサブコード名 説明
1 無効な属性リスト 受信したUPDATEメッセージの解析中にエラーが発生しました。
2 識別不能な周知属性 受信したUPDATEメッセージの属性フラグフィールドが周知属性を示しているにもかかわらず、受信側がサポートしていません。
3 周知属性の消失 UPDATEメッセージの受信側が必要とする属性が全部そろっていません。
4 属性フラグエラー UPDATEメッセージのパス属性フィールドが意味をなしていません。
5 属性長のエラー UPDATEメッセージの属性長が文法的に間違っています
6 無効なOrigin属性 UPDATEメッセージのOrigin属性が決められた3つの値以外です。
7 ASルーティングループ UPDATEメッセージにループしているプリフィックスが含まれています。
8 無効なNext_Hop属性 UPDATEに含まれるNext_Hop属性が無効です。
9 オプション属性のエラー UPDATEメッセージに含まれるオプション属性を処理している途中でエラーが発生しました。
10 無効なネットワークフィールド UPDATEメッセージに含まれるプリフィックスを処理している途中でエラーが発生しました。
11 無効なAs_Path属性 UPDATEメッセージに含まれるAs_Path属性を処理している途中でエラーが発生しました。

　BGPのルート情報には宛先に到達するまでに経由したASの番号のリスト（ASパス）が含まれています。このリストの中に自分の番号が含まれている場合は、そのルートを受け取らないようにすることでループを回避しています。


3　eBGPとiBGP

　BGPピアには、同じASに属するBGPスピーカ同士の関係と、異なるASに属するBGPスピーカの関係があります。

　同じASに属するBGPスピーカ同士はInternal BGPピア（iBGPピア）、異なるASに属するBGPスピーカ同士の関係は、External BGPピア（eBGPピア）といいます。

　iBGPでは、パケットヘッダのTTL値が255にセットされて送信されますので、直接接続していないBGPスピーカ同士もピアを確立することができます。これに対して、eBGPは、ピアを確立するBGPスピーカ間は直接物理的に接続されていなくてはなりません。eBGPはTTL=1で、セションの構築を試みます。

　AS内でBGPを有効にしながら、IGPのOSPFやEIGRPなどを動作させると、直接物理的につながっていないBGPスピーカ間でもiBGPピアを確立することができます。これに対して、AS間はASの外の話ですので、IGPを動作させることは考えられず、BGPだけを動かすことになります。従って、eBGPは直接つながっているBGPスピーカ間で機能することになります。

　ASをトランジェットにする場合、それが下流ISPであるなら、IGPsのOSPFやEIGRPなどを動作させることで事足ります。これに対して、上流ISPでは内部でIGPsを動かす事は困難です。IGPsでやり取りする情報は大きすぎますので、上流ISPのような大きなASで適用するとルータに大きな負荷がかかってしまうためです。

　そこで、AS内部で簡略化したBGPを動かしたくなります。この有望に答えるのがiBGPです。iBGPピアは、IP通信が可能なBGPスピーカ同士なら、直接接続していないBGPスピーカ間でも構築することが可能です。ただし、iBGPピアになる前に、BGPスピーカ同士が、IGPsによってパケットをやり取りできるようにしておく必要があります。

■　eBGPマルチホップ
　eBGPを確立するメッセージはパケットヘッダのTTLが1にセットされているため、違うASに属するBGPスピーカ同士は、非BGPスピーカを経由して、ピアになることはできません。ただ、違うASに属するルータ同士を直接接続するのは難しいという場合もあります。この問題を回避する方法がeBGPマルチホップです。

　ルータAとルータB間でeBGPメッセージが直接到達できなくてはなりませんが、このように機能拡張したのがeBGPマルチホップです。ルータAとルータBで、eBGPマルチホップの設定をする必要があります（Ciscoルータの場合は、ebgp-multihopコマンド）。

　通常のeBGPは、直接接続されたIPアドレス以外にはNext_Hop値に指定できませんが、eBGPマルチホップでは、そのアドレスへ到達するための方法がIGPsあるいはスタティックで用意されている限り、直接接続していないIPアドレスでもNext_Hopとして指定できます。

■　iBGPスプリットホライズン
　iBGPでは直接接続されていないBGPスピーカ同士でもUPDATEメッセージを交換しますが、iBGPピアから学習したルート情報を他のiBGPピアにアドバタイズすると、ルーティングループが発生する可能性があります。そこでiBGPではルーティングループの発生を防ぐための、スプリットホライズン規則に従います。

　スプリットホライズンはRIPなどのディスタンスベクタ型ルーティングプロトコルでおなじみですが、iBGPスプリットホライズンは、それとは少し違います。iBGPスプリットホライズンは、「iBGPピアから学習したルートを、iBGPを利用して他のiBGPピアにアドバタイズしてはならない」というものです。

　iBGPでルート情報を転送しないということは、結局全てのiBGPスピーカ同士がiBGPセションを張る必要があることを意味します。AS内のiBGPスピーカが多くなり、全てがフルメッシュでiBGPピアを張ると、CPUやメモリに負荷がかかり過ぎるだけでなく、トラフィック量も帯域を圧迫することになります。この問題を解決する手段がルートリフレクタです。ルートリフレクタについては後で説明します。


4　BGPの同期

　iBGPが引き起こす問題はルーティングループだけではありません。iBGPによって学習したルートを途中の非BGPスピーカがまだ（IGPsで）学習していないとき、そのルートは利用できません。次の図を使って説明します。

　何らかの理由（単なるタイミング？）で、BGPスピーカであるR3が、20.2.2.0のルートをiBGPピアであるR1からアドバタイズされた時点で、R2が20.2.2.0へのルートをまだIGPs（RIP、OSPF、EIGRP、IS-ID等）でアドバタイズを受けていない場合、R3が宛先20.2.2.0のパケットをR2経由で転送しようとすると、R2は宛先アドレス20.2.2.0をを知らないので、パケットを破棄してしまいます。

　このようなことがないようにするためには、R2が20.2.2.0を学習してから、R3が20.2.2.0を宛先とするパケットを送信するべきです。ではそのタイミングはいつでしょうか。R2がIGPsを使ってR3に20.2.2.0に関する情報を送ってきた時点です。このとき、R2が20.2.2.0について学習していることは確実ですから、このタイミングで、20.2.2.0宛のパケットを送れば、破棄されることはありません。

　BGPスピーカは、iBGPによって学習したルートをIGPsからも学習したときに初めて、そのルートを使うこと、あるいはeBGPピアにアドバタイズすることができます。これをBGP同期化（シンクロナイゼーション）規則といいます。

　「中継点となる非BGPスピーカがIGPsを介してルートを学習していない場合は中継パケットが破棄される可能性がある」というのがBGPで同期が要求される理由です。従って、このような可能性がない場合は、同期を要求する理由はありません。

　同期を必要としない場合としては、そのASがトランジェットASでない場合は、トランジェットASでも、そのAS内の全中継ルータがBGPスピーカである場合などがあります。






5　パス属性

　BGPスピーカは、他のBGPスピーカとの間で送受信するルート情報を保存するために、ルーティングテーブルとは別にBGPテーブルを保持しています。BGPスピーカはUPDATEメッセージを受け取るとまず初めにこれをBGPテーブルに格納します。複数のBGPピアから同一のルートについての情報を得ている可能性があります。従って、BGPテーブルに保管されているルートは最適ルートだけとは限りません。

　BGPテーブルから、最適ルートだけを他のBGPピアにUPDATEします。また、ルーティングテーブルに注入するのも、最適ルートだけです。

　BGPテーブルの中から最適ルート（ベストパス）を選択するときの選択基準をパス属性（パスアトリビュート、Path Attribute）といいます。パス属性でルートの評価をしますので、BGPはパスアトリビュート型のルーティングプロトコルと呼ばれることがあります。

※RIPやIGRPは距離（ホップ数、ルータを超えた数）でルートを評価しますのでディスタンスベクタ型、OSPF、IS-ISなどはリンクステートで評価しますのでリンクステート型、EIGRPはそのハイブリッドですので、ハイブリッド型、これに対してBGPはパスアトリビュート型と呼ばれています。

　パス属性は複数の値によって構成され、このパス属性を操作することで、パスの選択を柔軟に制御することができます。

5．1　パス属性の分類

　パス属性には様々なものがありますが、それらは次の3種類に分類されます。

●周知（Well-Known、全てのBGPスピーカがサポートすべきもの）か、オプション（Optional）か
●強制（Mandatory、UPDATEメッセージに必ず含めるべきもの）か任意（Discretionary）か
●通過（Transitive、他のBGPピアに伝えなくてはならない）か、非通過（Nontransitive）か

　これらを全部組み合わせると、8通りの組み合わせができますが、実際に使われているのは次の4通りの組み合わせです。

●Well-Known Mandatory（周知強制）
●Well-Known Discretionary（周知任意）
●Optional Transitive（オプショナル通過）
●Optional Nontransitive（オプショナル非通過）

■　Well-Known Mandatory（周知強制）
　Well-Known Mandatoryは、全てのBGPスピーカがサポートしていて、かつ全てのUPDATEメッセージに含まれなくてはならない属性です。このタイプには次のものがあります。

属性の組み合わせ タイプコード 属性名
Well-Known Mandatory 1 Origin（発生元）
2 As_Path（ASパス）
3 Next_Hop（ネクストホップ）

■　Well-Known Discretionary（周知任意）
　Well-Known Discretionaryは、全てのBGPスピーカがサポートしていなくてはならない属性ですが、それをUPDATEに含めるかどうかは自由裁量で決めていい（Discretionary）というものです。このタイプには次のものがあります。

属性の組み合わせ タイプコード 属性名
Well-Known Discretionary 5 Local-Preference（ローカル優先度）
6 Atomic-Aggregate（アドミック集約）


■　Optional Transitive（オプショナル通過）
　これは全てのBGPスピーカが必ずしもサポートしている必要はないが、たとえ自分がサポートしていなくても、その属性がUPDATEメッセージに含まれている場合は、それを他のBGPピアに伝える必要があるものです。

　自分がその属性をサポートしていないため、その意味を理解できない場合は、属性のフラグをPartialビットをセットしなくてはなりません。

　Optional Transitiveには次のものがあります。

属性の組み合わせ タイプコード 属性名
Optional_Transitive 7 Aggregator（アグリゲータ）
8 Community（コミュニティ）

※Conumity属性はシスコシステムズが定義する属性です。

■　Optional Nontransitive（オプショナル非通過）
　Optional Nontransitiveは、全てのBGPスピーカが必ずしもサポートする必要のない属性で、しかも自分でサポートしていないために理解できない場合は、それを更に別のBGPピアに伝える必要がない属性です。このタイプの属性には次のものがあります。

属性の組み合わせ タイプコード 属性名
Optional Notransitive 4 MED（Multi-Exit-Discriminator）
9 Originator_Id
10 Cluster_List

※Originator_IdとCluster_Listはシスコシステムズが定義する属性です。Cisco IOSではこの他にもWeight属性を定義していますが、このWeight属性はルータに対してローカルに設定されるだけで、UPDATEメッセージに含まれることはありません。そのため、タイプコードも持っていません。

　Originator_IdとCluster_Listはルートリフレクタに関係しますので、ルートリフレクタのところで説明します。

5．2　Origin属性

　Origin属性は、Well_Known Mandatory（周知強制）の属性の1つで、必ずUPDATEメッセージに含まれ、しかもiBGPピアおよびeBGPピアに送信されます。

　Origin属性はUPDATEメッセージに含まれるルート（NLRI、ネットワーク層到達可能性情報）の発生元（起源、Origin）を示します。

　Origin属性で示される値は次の3つです。

属性値 コード（優先度） 意味
IGP 0 ルートの配布元がASの内部にあることを示します
EGP 1 ルートがAS外部で生成されたことを示します
INCOMPLETE 2 ルートの配布元が不明、あるいは別の方法で学習されたことを示します

　ルートの発信元がそのルートがAS内部で学習した場合は、IGPとなります。iBGPで学習されたルートや、IGPsで学習されたルートがBGPに再配布された場合などが該当します。

※Ciscoルータの場合は、networkコマンド、aggregate-addressコマンドなどでBGPルートが生成された場合にOrigin属性がIGPにセットされます。Ciscoルータでは、AS内のIGPルートをBGPに再配布してBGPルートを生成した場合はOrigin属性はINCOMPLETEにセットされます。ただし、他のASにアドバタイズする時には、INCOMPLETEのままではまずいので、Origin属性をIGPに変更してから、送信します。

　BGPルートがEGP（Exterior Gateway Protocol）から生成されたときは、Origin属性はEGPとなります。

　ルートの配布元が不明であるか、"IGP"、"EGP"以外から学習したときは、Origin属性はINCOMPLETEとなります。例えば、スタテックルートを再配布した場合などが該当します。

5．3　As_Path属性

　As_Path属性は、Well-Known Mandatory属性なので、全てのUPDATEメッセージに含まれ、全てのBGPピアに伝わっていきます。As_Path属性は、そのNLRI（IPプリフィックス）が通ってきたASのリストです。最初に、networkコマンド等でBGPルートが生成されたとき、As_Path属性は空白です。その後、eBGPピアにUPDATEする際に、自ASの番号をAs_Path属性の左端に追加していきます。この動作を特に「プリペンド（prepend）」といいます。As_Path属性の右端はルートの生成元とみなされます。

　ただし、AS番号を追加するのは、eBGPピアにアドバタイズするときだけです。iBGPピアにアドバタイズする際には、AS番号を追加しません。

　UPDATEメッセージを受信したルータは、それをBGPテーブルに保存し、それをBGPピアに伝えます。同じルートが複数保存されている場合には、そのルートを評価して、ベストのルート（（ベストパス）のみをUPDATEします。

　何をもってベストパスとするかは、予め定められた優先順位によってパス属性を適用することで決めていきます。明示的な指示がない場合は、このAs_Path属性でベストパスが決まります。

　次の図は1度示したものですが、念のためにもう一で示します。As_Path属性ではいくつのASをポップするかでパスが評価されます。ホップする数が少ないほど優れたパスと評価されます。また、ベストパスはUPDATEでアドバタイズされるだけでなく、ルーティングテーブルに抽出されてルーティングに使用されます。
　

　As_Path属性はベストパスを選択する際の基準になるだけでなく、ルーティングループを防ぐ役割も果たします。次の図で分かるように、BGPスピーカはピアから受信したUPDATEメッセージのAs_Path属性の中に自分のAS番号を見つけたら、そのメッセージを破棄することで、ループを回避します。

　As_Path属性は非常に重要な属性です。ベストパス選択の際の重要な要素となるだけでなく、ルートをフィルタしたり、他の属性を追加したりする際に、As_Pathを基準とすることがあります。

　As_Path属性を参照してBGPルートの制御を行うためには、As_Pathアクセスリストという特殊なリストを利用します。As_Pathアトリビュートの文字パターンを正規表現で指定することで、As_Path属性を基準としたルート情報を識別することができます。

●　パスセグメントタイプ
　As_Path属性の場合、属性値フィールドはAs_Pathセグメント（segment）が連続したものとしてエンコードされます。各セグメントは、パスセグメントタイプ、パスセグメント長、パスセグメント値から構成されます。As_Pathセグメントのパスセグメントタイプは次の通りです。

コード パスセグメントタイプ
1 AS_SET
2 AS_SEQUENCE
3 AS_CONFED_SET
4 AS_CONFED_SEQUENCE

　BGPでやり取りされる通常のUPDATEメッセージのパスセグメントタイプはAS_SEQUENCEです。AS_SEQUENCEの値は、そのUPDATEメッセージが通ってきたASの番号が順番に並んだ文字列になります。AS_SETが使われるのは、ルートの集約を行う場合です。AS_SETには、UPDATEメッセージが通過したASの番号が通過してきた順番とは関係なく格納されます。
　AS_CONFED_SETとAS_CONFED_SEQUENCEの2つはASコンフェデレーションで利用されます。

5．4　Next_Hop属性

　Next_Hop属性は、Well-Known Mandatory属性の1つで、必ずUPDATEメッセージに含まれます。Next_Hopは、宛先ネットワークへのネクストホップのIPアドレスを表す属性です。ネクストホップに関しては、IGPsと考え方が少し異なり、eBGPとiBGPで扱いが異なります。

■　eBGPのネクストホップ
　eBGPでは、宛先パスをAS単位で考えますので、eBGPで送り出すインターフェースがネクストホップとなります。途中iBGPピアで送信する場合があっても、ネクストホップは変更されません。

　ただし、R3は何らかの方法で、2.2.2.254へのルートを知っている必要があります。IGPsやスタテックルートなどのBGP以外の方法で、2.2.2.254へのルートを知っていないと、20.2.2.0宛のパケットはR3によって破棄されてしまいます。

※Ciscoルータでは、R2で設定コマンド（neighbor next-hop-self）を使って、明示的に自分のインターフェースを指定することで、R3の（20.2.2.0宛の）ネクストホップを自分自身（R2）にすることができます。

■　iBGPピアへのネクストホップ
　AS内で発生したルートを、AS内にアドバタイズするときは、IGPsのネクストホップと同じ考え方になります。AS内で発生したルートを、AS内でアドバタイズするときは、Next_Hop属性を自分のIPアドレスにして送信します。

■　マルチアクセスネットワークでの注意点
　マルチアクセスネットワークではまた違った配慮が必要となります。

≪マルチアクセスブロードキャストネットワークの場合≫
　次の図はマルチアクセスブロードキャストネットワークでR1とR2、R3がつながっています。そして、R1とR2はeBGPピア、R2とR3はiBGPピアです。この時、R2はR3から受信した18.8.8.0に関するUPDATEメッセージのNext_Hop属性を、書き換えずにそのまま送信します。このことで、ルーティングに余計やホップが挿入されることを防いでいます。

　そこで、BGPでは、ルートの情報源が同じマルチアクセスメディア上にある場合は、常にルートの発信元ルータ（この場合はR3）をネクストホップとしてアドバタイズしなくてはならないと規定しています。

※上の図では、R2とR3はiBGPピアとなっていますが、R3がBGPスピーカでなく、R2とR3がIGPsでルート情報を交換している場合でも同様です。

≪NBMAネットワークの場合≫
　マルチアクセスネットワークであっても、フレームリレーなどのNBMA（Nonbroadcast Multi Access）環境では、全てのルータ間で仮想回線（VC、Virtual Circuit）が構築されていない限り、マルチアクセスメディア上での規則を適用すると不都合が発生します。全てのルータ間でPVC（相手先固定接続、Permanent Virtual Circuit）を構築した状態をフルメッシュトポロジといいますが、このフルメッシュトポロジは様々な理由から、常に実装されているとは限りません。

※フルメッシュではない状態をパーシャルメッシュといいます。

　上のようなパーシャルメッシュでも、マルチアクセスメディアですから、R2はR3から受信したUPDATEのNext_Hop属性を書き換えずに、R1にアドバタイズしてしまいます。

　上のネットワークで、R1はプリフィックス18.8.8.0へのネクストホップを11.2.2.3と認識しますが、R1とR3の間にはPVCが確立されていないので、R1は宛先18.8.8.0宛のパケットをネクストホップ不明という理由で破棄することになります。

※Cisco IOSでは、R2上でnext-hop-selfコマンドを実行することで、Next_Hop属性を自分に書き換えることができます。

5．5　MED属性

　MED（Multi-Exit Discriminator）属性はOptional Nontransitive（オプショナル非通過）ですから、必ずしも全てのBGPスピーカがサポートしている必要はなく、しかもそのUPDATEメッセージを受信したピアは、他のeBGPピアにアドバタイズする必要はありません。

　Multi-Exitですから、出口が複数ある場合に、Discriminate（区別する）するということです。UPDATEメッセージをアドバタイズするという面から見ると出口ですが、ルーティングトラフィックの面から見ると入り口になります。
　
　MED属性を使うと、異なるASのルータに対して、特定の宛先への経路を強引に指定することができます。優先度の大きいほうに小さな値をセットします。

　MED属性を使うと、ネットワークの負荷分散を行うこともできます。次の例は、20.2.1.0宛のパケットはR4経由、20.2.2.0宛のパケットはR5経由でルーティングさせようとしています。

5．6　Local_Preference属性

　Local_Preference（LOCAL_PREF）属性は、Well-Known Discretionary（周知任意）な属性ですので、全てのBGPスピーカがサポートしていなくてはなりませんが、それをUPDATEに含めるかどうかは自由裁量で決めていいということになります。

　Local_Preference属性はローカルの優先度ということです。この場合のLocalとはASの内部です。つまり、Local_Preference属性は、iBGPピア間だけで交換され、AS内部だけで通用する優先度です。優先度の大きな方に大きな値を付けてください。

　MED属性はルートの発信元のAS側で、隣接ASに対して、強引にパスを押し付けるという少し例外的な約束事でしたが、Local_Preferenceの方は、UPDATEを受信する側、つまりパケットを送信する側のAS内で、パスの良しあしを独自に決めるという方法です。

5．7　Weight属性

　Weight属性は、同じ宛先へのルートが複数ある場合にいずれのパスを優先するかについての、Cisco独自の属性です。Weight属性はピアにアドバタイズされませんので、タイプコードを持っていません。

　Weight属性はBGPピアに対する優先度を、そのルータ独自のルーティングポリシーとして自分の中だけで設定します。また、Weight属性はピアに対してだけでなく、プリフィックス単位でも割り当てることができます。

5．8　Community属性

　Community属性は、BGPのベストパス選択のアルゴリズムとは関係のない属性です。Community属性はBGPルートに対してタグ付をすることができるので、タグ情報に基づいてルートをグループ化してフィルタリングすることなどができます。

　Community属性は32ビットの数値であり、以下のいずれかのパターンでCommunity属性を扱うことができます。

①　32ビットの任意の整数
②　AS番号（16ビット）＋識別子（16ビット）
③　32ビットのWell-Known Community値

　Community属性によりグループ化したルート情報をフィルタリングしたり、LOCAL_PREF値やMED値などを再定義することもできます。

※②の形式で扱いたい場合は、ip bgp-community new-formatコマンドで設定します。

　③のWell-Known Communityを使用した場合は、その値に基づくだけで、自動的にルートフィルタリングが可能です。Well-Known Communityには次のものがあります。

Well-Known Community 値 動作
no-export 0xFFFFFF01 このルートをeBGPピアに通知しません。
no-advertise 0xFFFFFF02 このルートをどのピアにも通知しません（iBGPピア、eBGPピアに関わらず）。
local-as 0xFFFFFF03 BGPコンフェデレーションで、異なるサブASにはルート情報を通知しません。

●　Communityがno-exportの場合

●　Communityがno advertiseの場合

●　Communityがlocal asの場合

5．9　Atomic_Aggregate属性

　Atomic_Aggregator属性はWell-Known Discretionary（周知任意）ですので、全てのBGPスピーカがサポートしていなくてはいけませんが、それをUPDATEに含めるかどうかは自由裁量の範囲内です。

　BGPはversion4（現時点のversion）から、CIDRをサポートしています。そのため、BGP4のUPDATEメッセージにはプリフィックスとプリフィックス長の両方を含みます。また、BGPスピーカはルートをアドバタイズするときに集約することができます。

　異なるパス属性を持つ様々なルートを集約すると、属性の情報が失われる可能性があります。このような場合はAtomic_Aggregate属性を使ってこのことを示します。

　Atomic_Aggregate属性のUPDATEを受信したルータはこの属性を削除してはいけません。また、このルートとオーバラップするような、よりプリフィックス長の長いルートを作成してはいけません。このようなことをすると、ループを作ってしまう可能性があります。

　Atomic_Aggregate属性は、属性値を持ちません。タイプコードが6であることさえわかれば、Atomic_Aggregateされたものと分かるので、属性値は必要ありません。ベストパスの選択の基準にもなりません。

5．10　Aggregator属性

　Aggregator属性は、Optional Transitive（オプショナル通過）属性です。全てのBGPスピーカがサポートしている必要はありませんが、たとえ自分がサポートしていなくても、その属性がUPDATEに含まれている場合には、それを他のBGPピアに伝えなくてはなりません。

　Aggregator属性は、ルート集約を行った時に、集約ルートを生成したASやルータを示すものです。

　集約（Aggregation）は異なったルートを1つのルートとしてアドバタイズすることですので、集約の対象となるルートは同じ属性、あるいは似通った属性を持つもの同士でなくてはなりません。1つにまとめた時に、パス属性や、NLRIが矛盾しないことが必要です。集約するパス同士は、MED属性とNext_Hop属性が同じでなくてはなりません。

　Origin属性は1つでもINCOMPLETEのものがあれば、集約後のルートもINCOMPLETEになります。EGPがあれば、集約後のルートのOrigin属性はEGPとなります。それ以外の場合は、IGPです。

　As_Path属性は、集約するルートの属性が同じなら、それがそのまま集約後のルートのAs_Path属性になります。As_Path属性が違う場合は、そのまま集約するわけにはいきません。

　ASパスの集約の場合に、As_Pathセグメントタイプは、AS_SETが利用されます。AS_SETは集約したパスを表します。上の例では、AS50とAS60を集約していますので、AS_SETは{50 60}と表すことができます。その後、AS10はAS_SEQUENCEとして扱われますので、As_Path 10 ｛50 60｝となります。


6　経路選択のアルゴリズム

　ベストパスの選択アルゴリズムは、「1.7　ルート選択のアルゴリズム」で説明しましたので、そちらをご覧ください。


7　BGPのスケーラビリティ

7．1　iBGPのスケーラビリティ

　iBGPにはスケーラビリティの点でいくつかの問題があります。

≪フルメッシュのiBGPセッション≫
　iBGPピアから受信したUPDATEメッセージを更に別のiBGPピアに転送すると、ループが発生する可能性がありますので、これを防止するためにiBGPスプリットホライズンという規則に従います。

　iBGPスプリットホライズンは、iBGPピアから受信したUPDATEメッセージを転送してはならないというものです。iBGPピアから学習したルートを別のiBGPピアに転送することができないとすると、AS内のＢＧＰスピーカ同士はフルメッシュのiBGPピアを確立しなくてはなりません。AS内のn台のルータがフルメッシュで結びつくと、n＊（n-1）/2のピアを構築しなくてはなりません。もし、2000台のルータがフルメッシュでピアを構築すると、約200万のピアが構築されます。

≪設定の手間≫
　OSPFやEIGRPなどのIGPsでは、Helloプロトコルを使うことで隣接を自分で検知し、隣接関係を自動的に構築できます。しかし、BGPはHelloを使えませんので、BGPスピーカ間でiBGPピアを確立するには、手動設定で相手を明示的に指定しなくてはなりません。これは、大きなネットワークでは大変な作業となります。

≪帯域の消費≫
　BGPはTCPコネクション上でBGPセションを構築しますので、ネットワークとルータには大きな負荷がかかります。更に、ASのトポロジにWANリンクが含まれたりすると、WANリンク上で実行されるiBGPセションはかなりの帯域を消費し、AS内のネットワークを混乱に陥れる可能性があります。

7．2　ルートリフレクタ

　AS内の全てのBGPスピーカが相互にiBGPを張らなくてはならないとなると、iBGPのスケーラビリティに支障を生じます。全てのBGPスピーカが相互にiBGPを張るという条件を緩和して、AS内の一部だけがiBGPピアを張れば済むようにしたのがルートリフレクタという考え方です。

　リフレクタ（reflector）は「反射するもの」という意味ですので、ルートリフレクタは、「ルートを反射するものということになります。ピアから学習したルートをAS内部のBGPスピーカに反射し、AS内部のBGPスピーカがフルメッシュiBGPピアにならなくても済むようにしています。

7．2．1　ルートリフレクタの用語


●　ルートリフレクタ
　ルートリフレクタは、iBGPから学習したルートを他のiBGPピアにアドバタイズすることを許可されたBGPスピーカです。ルートリフレクタは、同一AS内に複数存在することができ、その場合は、同一AS内のルートリフレクタ同士は、フルメッシュでiBGPピアの関係を構築しなくてはなりません。

●　Originator_Id属性
　Optionalのnon transitiveの属性です。ルートリフレクタによって生成される4バイトの情報で、ローカルAS内でルートの生成元のルータを示すために使用されます。Originator-Id属性が同じUPDATEを無視することで、ループを回避することができます。ベストパス選択のアルゴリズムでは、Originator-Idが小さい値のルートが優先されます。

●　クライアント
　ルートリフレクタがルーティング情報をリフレクト（反射）する相手のBGPスピーカがクライアントです。ルートリフレクタがクライアント間のアドバタイズメントを転送しますので、クライアント同士はiBGPピアを張る必要はありません。

●　クラスタ
　ルートリフレクタとクライアントの集まりのことを、クラスタと呼びます。同一AS内に複数のクラスタが存在できます。

●　ノンクライアント
　ルートリフレクタではなく、ルートリフレクタのクライアントでもないルータで、ルートリフレクタと通常のiBGPピアの関係にあるBGPスピーカです。

●　Cluster Id
　Cluster Idはルートリフレクタにのみ設定されたIdです。

●　Cluster_List属性
　ルートリフレクタを冗長化させるとループが発生する可能性がありますので、それを防ぐために使われるのが、Cluster_List属性です。Cluster_List属性は、クラスタのIDのリストです。ルートリフレクタは、クラスタ外部の非クライアントへルート情報をUPDATEする時に、Cluster_Listの最後に自分のCluster_Idを追加します。クラスタ内のクライアントへのリフレクトの場合にも同様です。もし、Cluster_Listに自分のCluster Idと同じ値が入っていた場合は、そのルート情報を無視します。同一クラスタ内のルートリフレクタは同一のCluster_Idを与えられます。

7．2．2　ルートリフレクタの動作

　ルートリフレクタの動作は、ルートリフレクタに対してUPDATEメッセージを送信したピアのタイプに応じて異なります。ルートリフレクタに対してUPDATEメッセージを送信する可能性があるのは、eBGPピア、クライアント、ノンクライアントです。

　ルートリフレクタとノンクライアントの関係は、ここまで説明したiBGPピアの関係と同じです。クライアントとの関係は、これまでと少し違います。これらの関係について次に説明します。

■　単一クラスタの場合

≪クライアントからUPDATEメッセージが送られてきた場合≫
　UPDATEメッセージがクライアントからのものであるとき、ルートリフレクタはUPDATEメッセージを全てのノンクライアントと、全てのクライアント（ルートの発生元を除く）に送信します。

　ノンクライアント同士はiBGPピアですが、スプリットホライズン規則が働きますので、ノンクライアントはルートリフレクタから学習したルートを他のiBGPピアに転送しません。

　クライアント同士はiBGPピアの関係を構築できません。

　eBGPピアであるルータR6にアドバタイズするかはBGP同期によって決まります。

≪ノンクライアントからUPDATEメッセージが送られた場合≫
　UPDATEメッセージがノンクライアントから発生している場合は、発生元のiBGPピアはiBGPピアの規則に従ってアドバタイズします。

　発生元のiBGP（ノンクライアント）とルートリフレクタは通常のiBGPピアの関係です（iBGPピアの関係に従って転送）。UPDATEを受信したルートリフレクタはUPDATEメッセージをクラスタ内の全てのクライアントに送信します。
　R5はiBGPで受信したUPDATEはスプリットホライズン規則に従って、他にアドバライズしません。また、R1もクライアントへは転送しますが、iBGPピアであるR5にはアドバタイズしません。

≪eBGPピアからUPDATEメッセージを受けた場合≫
　UPDATEメッセージがeBGPピアからのものである場合、ルートリフレクタはUPDATEメッセージを全てのノンクライアントと、全てのクライアントに送信します。

　ノンクライアント同士は、スプリットホライズン規則に従って、ルートリフレクタから学習したルートを他のiBGPピアに転送することはありません。


■　1つのクラスタに複数のルートリフレクタが存在する場合
　クラスタは1つ以上のルートリフレクタを持つことができます。複数のルートリフレクタを持つことによって、一方のルートリフレクタが故障しても、ルート・リクレクションの機能停止を防ぐことができます。

　同一クラスタ内のルートリフレクタは同一のCluster_Idをセットされています。ルートリフレクタはルートのUPDATEの際に、自分のCluster_IdをCluster_List属性の先頭に追加してアドバタイズします。UPDATEを受信したルートリフレクタは自分と同じCluster_Idを、UPDATEのCluster_Listに見つけた時は、そのUPDATEはアドバタイズしません。これによってループの発生を防ぐことができます。

■　クラスタの分割
　BGPスピーカが多い時などには、AS内を複数のクラスタに分割することもできます。AS内を複数のクラスタに分割するときは、個々のクラスタには必ず1つ以上のルートリフレクタとクライアントを持たせる必要があります。クラスタの分割では、ルートリフレクタ同士をフルメッシュiBGPピアにして、学習されたすべてのルートが他のルートリフレクタに伝搬するようにしておく必要があります。
　
　クラスタが複数になると、UPDATEメッセージがどのクラスタを通ってきているかを識別する標識が必要となります。この標識に当たるのがCluster_List属性です。Cluster_List属性は、そのUPDATEメッセージが通過したCluster_Idのシーケンスです。

　ルートリフレクタが受信したUPDATEメッセージのCluster_List属性が空だった場合、Cluster_List属性を作成し、自クラスタのIDを記載します。Cluste_List属性を持つUPDATEメッセージを受信した場合は、自クラスタのCluster_Idをリストの先頭に追加します。

　ルートリフレクタはUPDATEを受信し、そのUPDATEの中に自分のCluster_Idを見つけた時は、そのUPDATEを無視します。これによって、ルーティングループの発生を防ぐことができます。

7．2．3　物理トポロジーとの整合性

　物理トポロジを全く無視してルートリフレクタとクライアントの設計を行うと、ルーティングループを発生させる可能性があります。

■　ルートリフレクタの設計が不適切な場合
　次の図はルートリフレクタの設計が不適切な場合です。物理接続を全く無視してiBGPピアを張っているため、ループが発生しています。

　ルータR3とR4はルートリフレクタで、R2はR3のクライアント、R1はR4のクライアントとなっています。また、ルータR5はR3とR4の両方のクライアントです。

　ルータR5が3.3.3.0に関するUPDATEを、Next_Hop属性をR5のS0にしてルートリフレクタR4に、Next_Hop属性をR5のS1にしてルートリフレクタR3にそれぞれUPDATEします。

　ルートリフレクタR4はnext_hopをR4に書き換えて、クライアントのR1に、ルートリフレクタR3はnext_hopをR3に書き換えて、クライアントのR2にそれぞれアドバタイズします。

　ここで、IGPsを利用して、R1がR4へのルートのネクストホップをR2、R2がR3へのネクストホップをR1と学習したとします。

　R1が宛先3.3.3.0のパケットを送信しようとする場合、iBGPによりNext_Hop属性をR4と学習しています。そして、R4へのルートをIGPsでネクストホップR2と学習します。つまり、宛先3.3.3.0のパケットは、R2に転送します。

　これに対して、R2はどうでしょうか。R2は宛先3.3.3.0のルートに関して、iBGPによってNext_Hop属性をR3と学習しています。そして、R3へのルートをIGPsによってネクストホップR1と学習しています。従って、宛先3.3.3.0のパケットはR1とR2の間で、ピンポン玉のようにやり取りされることになります。

■　 ルートリフレクタの設計が適切な場合
　次の例は、物理的な構造にマッチするように、ルートリフレクタとクライアントの関係を定めています。そのため、上の例でみたようなループは発生していません

7．3　ASコンフェデレーション

　ASコンフェデレーションもルートリフレクタと同様に、iBGPフルメッシュの問題を解決する手段として開発されました（RFC 3065 AS Confederations for BGP）。

　コンピュータサイエンスやコンピュータネットワークの分野では、管理を簡単にするために、階層構造や分割管理などの手法が古くから研究/応用されています。ルートリフレクタは階層構造を、ASコンフェデレーションは分割管理の手法を採用しています。ルートリフレクタはAS内部にルートリフレクタとクライアントという階層構造を持ち込んで、iBGPフルメッシュの問題を回避しています。これに対して、ASコンフェデレーションは、AS内部をサブASに分割することで、AS内部のiBGPフルメッシュを回避しています。

■　ASコンフェデレーションの基本
　ASコンフェデレーションの基本的な考え方を次の図で説明します。
　
　　ASコンフェデレーションとは、1つのASを複数のサブASに分割することです。分割の結果できたサブAS内では、フルメッシュのiBGPピアを張る必要がありますが、各サブAS間ではその必要はありません。

　異なるサブASのBGPスピーカ間に張られるセションは、eiBGPセションと呼ばれることもありますが、基本はeBGPセションです。

　AS1の外のAS2内のルータからは、サブAS14やサブAS12などのサブASは見えません。ASコンフェデレーションは、外に対してはあくまで1つのASとして動作します。

■　ei-BGPとeBGPの違い
　eiBGPセションは基本的にはeBGPセションですが、いくつかの違いがあります。

≪Local_Preference属性の扱い≫
　通常のeBGPセションでは、UPDATEメッセージに付加されるLocal_Preference属性は無視されますが、eiBGPセションでは伝搬されます。

　下の図で、ルータR1がルータR2からAS2内のルートをアドバタイズされている場合、ルータR1でポリシーに基づいてLocal_Preference値をセットされ、そのLocal_Preference値はAS1内全体に伝搬されます。


≪Next_Hop属性の扱い≫
　Next_Hop属性はAS毎に書き換えてアドバタイズされますが、サブAS間では変更することなくアドバタイズされます。外から見るとASコンフェデレーションは1つのASにすぎませんので、UPDATEメッセージのNext_Hop属性は外部ASからASコンフェデレーションに入るときに書き換えられ、後はNext_Hopが書き換えられることなくASコンフェデレーション内をアドバタイズされていきます。更に、ASを出ていくときに書き換えられます。

≪MED属性の扱い≫
　MED属性は隣接ASに対して、自ASに入ってくるときに使って欲しいルートを指示するパス属性ですから、隣接を超えて更にその向こうまで伝搬させても無意味です。しかし、ASコンフェデレーションの場合は、サブASを超えてアドバタイズされます。

≪As_Path属性の扱い≫
　ASコンフェデレーションでは、サブAS間のルートにループを発生させないことが重要です。AS間のルートにループを発生させないためには、As_Path属性が重要です。

　通常のAs_Path属性では、AS_SEQUENCEとAS_SETというパスセグメントタイプが利用できます。AS_SEQUENCEは、そのUPDATEメッセージが通過したASのシーケンシャルなリストで、ループの発生を防止することができます。AS_SETはUPDATEメッセージが通過してきたASの集合で、ルートの集約をする場合に使用されます。

　ASコンフェデレーションでは、サブAS間でのUPDATEメッセージのアドバタイズでAS_SEQUENCEとAS_SETと同じ機能を発揮させるために、AS_CONFED_SEQUENCEとAS_CONFED_SETという2つのパスセグメントタイプが導入されました。

　AS_CONFED_SEQUENCEとAS_CONFED_SETはAS_SEQUENCE、AS_SETと同様の働きをしますが、ASコンフェデレーション内でのみ使用されます。

　サブAS14のルータR1が、eBGPピアであるR2から受信したルートをeiBGPセションでサブAS12にアドバタイズする場合は、As_Path属性にAS_CONFED_SEQUENCEを追加して、AS14をセットします。サブAS12のBGPスピーカが他のサブASにそのUPDATEメッセージをアドバタイズするときは、AS_CONFED_SEQUENCEの先頭に更にAS12をセットします。

　ASコンフェデレーション内のBGPスピーカがコンフェデレーション外のeBGPピアにルートをアドバタイズするときは、As_Path属性からAS_CONFED_SEQUENCE（場合によってはAS_CONFED_SETも）を取り除き、As_Path属性に自ASの番号を追加してアドバタイズします。




更新記録

2016/10/12　　　　　作成










































































































































































ページの先頭