BGP

for CCIE Qualification (350-001E)


BGP概要

パスベクタルーティングプロトコル(ディスタンスベクタをベースにしている)

エンティティ間のルーティングとエンティティ内のルーティングの2種類がある(ここで言うエンティティとは=AS[Autonomous System]と考えてよい)

BGPルータ間ではTCP(ポート179)が信頼性を保証する。

TCPコネクションが確立されたルータ同士の関係は、neighbors (ネイバ)や peers(ピア) と呼ばれる。
IBGPでは他のIGPが動作し、IBGPにリディストリビュートしていれば、2台のルータ同士は直接接続されている必要はない。
EBGPでは直接接続されている必要がある。(多分)

BGPルータ間でピアを確立するために、BGPバージョン・AS番号・ホールドタイム・BGP IDやその他のオプションパラメータをやり取りする。
これらのパラメータにどちらかのルータが同意しない場合はBGPピアにならない。

BGPルータ間でピアを確立すると、まずBGPルーティングテーブル全体を交換。その後は変更があったときだけ増分(インクリメンタル)アップデートのみ送信する。その他キープアライブやノティフィケーション(通知)メッセージ(エラー又は特別な状況への応答メッセージ)を交換する。

BGPピアルータ同士は、UPDATEメッセージをやり取りする。
(UPDATEメッセージにはルーティングテーブルやパスアトリビュートに基づく各ルートの到達可能性(NLRI) が含まれる)

パスアトリビュート:ルートの情報源・優先度が含まれる。

BGPテーブル(ルーティングテーブルとは別のもの)はピアを確立している間は有効で、ルーティング情報に変更があった場合のみ、増分アップデートだけをピアに送る。定期的なアップデートはない。

ピアを保つためのキープアライブは定期的にピア間でやり取りされる。

 


BGP Terminology

AS [Autonomous System] - 同じ管理下に置かれるネットワーク・ルータ・ホストなどの集まり。1つのエンティティ。同じAS内では、同じ管理ポリシーや規則が適用される。Internet registry identifies から各ASにユニークな番号が割り振られる。

External BGP (EBGP) / Internal BGP (IBGP) - 別ASのボーダールータとはEBGPネイバを確立し、同ASルータ間ではIBGPネイバになる。(neighbor sbgp-multihop コマンド以外はEBGPとIBGPの設定コマンドに違いはない)

Network Layer Reachability Information (NLRI) - UPDATEメッセージに含まれる。到達可能な宛先の一覧。
<length , prefix>(プレフィックス長 , プレフィックス)でリストされる。
例えばネットワーク 10.0.0.0/8 は、UPDATEメッセージのNLRI フィールドに <8 , 10.0.0.0> とリストされアドバタイズされる。

Synchronization - BGPがあるAS内のルートを他ASのEBGPネイバに知らせる場合、そのルートのエントリがルーティングテーブルになければならない。
AS内でBGPと同時に、IGP (Interior Gateway Protocol)である RIP/IGRP/OSPF などが動作している状況では、BGPとIGPでAS内ルートの同期が必要になる。

no synchronization コマンド:同期を無効にする事が可能だが、使用には注意が必要。

 


Internal BGP (IBGP)

AS内でBGPアップデートを交換する。

あるルータがIBGPを介して受け取ったアップデートは、EBGPピア(があれば)へは転送されるが、他のIBGPピアに転送されることはない。

従ってAS内のBGPスピーカーは、全てのアップデートが行き渡るようにするため、フルメッシュでなければならない。BGP4ではこの負担を緩和する手法として、ルートリフレクタ(反射)とコンフェデレーション(連合)がある。

IBGPピアを設定するためのneighbor <ip address> remote-as <AS#> コマンドに、ループバックインタフェースアドレスを指定することが多い。物理インタフェースのアドレスを指定すると、そのインタフェースが使用不可になったときにTCPコネクションを確立できなくなってしまうため。(EBGPでは直接接続されているのであまり使用されない)

 


External BGP (EBGP)

シンクロナイゼーション(同期)

BGPではネイバーに関する情報を保持し、プレフィックスとプレフィックス長、およびそれに付随する各アトリビュートの情報をBGPテーブル(RIB:Routing Information Baseと呼ばれることもあります)に格納します。BGPテーブル内に格納されたプレフィックス情報は、原則的にはこれからご説明するBGP同期を満たした場合のみIPルーティングテーブルに反映されます。

BGP同期規則とは、「該当するプレフィックスに一致するルートがルーティングテーブル中にIGPにより確保(学習)されないかぎり、IBGPによって取得された該当プレフィックスをルーティングテーブルに反映させたり、他のEBGPピアに伝えない」というものです。
ただしこの規則は、あるASが他のASの中継点になる場合(下図ではAS65500が中継AS)に当てはまります。

BGP Sync

BGP同期規則はAS間で「ルート情報は取得できているのに、いざその宛先に送ろうとすると到達できない」状態を回避するために存在します。
BGP同期規則がない場合、つまり同期がオフの時にはどうなるか、以下のような状況を例にして考えます。

このような状況で、同期がオフの時は次のような動作になります。

  1. ルータFはネットワーク172.16.0.0に関するアップデートをルータBに送信する。
  2. ルータAとBはIBGPが動作しているので、ルータAはルータBからIBGPを介して、ネットワーク172.16.0.0に関するアップデートを受け取る。
    (IBGPでは他のIGPが動作し、IBGPにリディストリビュートしていれば、2台のルータ同士は直接接続されている必要はない。)
  3. ルータAがネットワーク172.16.0.0に到達しようとする場合、ルータAはトラフィックをルータCに送信する。この時ルータBのIBGPが、ネットワーク172.16.0.0をIGPにリディストリビュートし、ルータCとDがネットワーク172.16.0.0へのルートを学習する前だと、ルータCはネットワーク172.16.0.0を不明の宛先としてトラフィックをドロップしてしまう。

以上のように、IBGPと IGPのリディストリビュートにかかる時間のずれが、「ルート情報は取得できているのに、いざその宛先に送ろうとすると到達できない」状態と言える。AS間トラフィックを"吸い込んで外に吐き出さない"ようになってしまったASのことを「ブラックホールAS」と呼びます。

このような状態をBGP同期規則によって解決できる。あるASが他のASへのトラフィックの中継点になる場合(上図ではAS65000とAS64520間の中継ASはAS65500)、中継AS内の全ルータがIGPを介してルートを学習するまで、BGPはそのルートを他ASへ通知しない。

CiscoルータではデフォルトでBGP同期は有効になっています。

以下のような場合にはBGP同期を無効化(オフ)する事ができる。

BGP同期を無効化には以下のコマンドを設定します。

(config)#router bgp AS番号
(config-router)#no synchronization


ルートマップ

BGPでルートマップは以下の用途に使われる。

グローバルコンフィグレーションモードで route-map コマンド、その後 match コマンドで条件を定義、 set コマンドでその条件に該当するアップデートに行われる操作を定義する。

 


BGPアトリビュート(属性)

BGPでは、アップデートによってピアにルートを通知します。ルートはプレフィックスとプレフィックス長から構成されます。

例:172.16.0.0/16(172.16.0.0がプレフィックス、16がプレフィックス長です。)

ルートには、メトリックとして様々なアトリビュート(attribute:属性)が付加されます。アトリビュートは実装が必須なもの(well-known)と必須ではないもの(optional)の2種類に分類されます。それぞれがさらに2つずつに分類されます。以下にアトリビュートの分類を示します。

○ 周知
(well-known)
BGPスピーカは必ず実装している。
・ 周知強制
(well-known mandatory)
プレフィックスに対し必ず付加される。
・ As-path
・ next-hop
・ origin
・ 周知任意
(well-known discretionary)
プレフィックスに対し必要時に付加される。
・ local-preference
・ atomic aggregate
○ オプション(optional)
BGPスピーカは必要に応じて実装する。
・ オプション通知(optional transitive)
認識できないBGPスピーカが受け取った場合、partialというマークを付加してピアに伝播する。
・ aggregator
・ community
・ オプション非通知(optional nontransitive)
認識できないBGPスピーカが受け取った場合破棄する。
・ Multi-exit-discriminator
(MED)

また、ベストパスの選定に関わる代表的なアトリビュートを以下に示します。 (経路情報=アップデート)

アトリビュート 分類 役割・特徴
weight なし Ciscoオリジナル。他に伝播されることはない。そのルータ内での経路情報に対する"重み付け"に使用される。デフォルトは基本的には0で、そのルータ自身が発生元である場合は32768。
local-preference(ローカル優先度) 周知任意 IBGPでのみ伝播される。経路情報に対するAS内での優先度を設定する。Ciscoルータでのデフォルトは100。
as-path 周知強制 その経路情報が通過してきたAS番号を格納する。
origin(発生元) 周知強制 その経路情報が何を起源として発生したのかを示す。BGPのnetworkコマンドにより発生した場合は"IGP(i)"、EGPからBGPに再配送されたものは"EGP(e)"、IGPやスタティックルートからBGPに再配送されたものは"Incomplete(?)"で示される。
MED オプション非通知 AS間で交換される。BGPv3でのInter-ASアトリビュート。AS間での優先パス制御に使用される。

その他の属性

・ next-hop 属性:特定の宛先に到達するための、次のルータのIPアドレス。通常は、 neighbor コマンドで指定したIPアドレス(イーサネットなどのマルチアクセスメディアでは例外)。

・community 属性:ルーティング決定条件を適用できる宛先をグループ化する。デフォルトで定義されているコミュニティは以下の表。

コミュニティ 意味
no-export このルートはEBGPピアルータに通知しない
no-advertised このルートは全てのピアルータに通知しない
internet このルートをインターネットコミュニティに通知する(ネットワーク内の全ルータはこれに属する)

 

補足

origin(発生元)属性は show ip bgp コマンドで確認。 (i) (e) (?) で表示。

weight属性は、そのルータ毎がローカルに持つもので、アップデートによって伝播しない。それに対し local-preference(ローカル優先度)値は、アップデートの一部なので同じAS内のルータ間で交換される。

 


ベストパス選択

BGPでのメトリックはパスベクタあるいはパスアトリビュートと呼ばれます。何故そう呼ばれるのかを確認します。

BGPでのベストパス選択は以下のプロセスに従います。 (ベストパスのみルーティングテーブルに追加される)

  1. ASループのあるもの、ネクストホップに到達するためのルートがルーティングテーブル中にないもの、同期されていないもの(BGP同期がそのルータ上で有効な場合)はベストパス選択対象から外される。
  2. weightアトリビュートが最大のパスを優先する。
  3. local-preferenceアトリビュートが最大のパスを優先する。
  4. ローカルルータが発生元であるパスを優先する。
  5. AS-pathが最短のパスを優先する。
  6. originアトリビュートが最小のパスを優先する。[ 小 IGP - EGP - Incomplete 大 ]  
  7. MED属性が最低のパスを優先する。 (IGPMEDアトリビュートが最小のパスを優先する。
  8. IBGP(内部)パスよりEBGP(外部)パスを優先する。
  9. 最も近いIGPネイバーを経由するパスを優先する。
  10. EBGPパスとして最も古いものを優先する。
  11. ネイバーのBGPルータID(IPアドレス)が最小のパスを優先する。

7.までのプロセスを単純化すると、「まずそのルータ内での都合(weight)が優先され、決めかねた場合は自AS内での都合(local-preference)が優先され、それでも決めかねた場合はAS-pathが最短となるものが優先され、その後パス情報の発生元(origin)や他ASの都合(MED)が優先される」形になります。

つまり、weightやlocal-preferenceに対しての調整を加えていない場合、通常はAS-pathアトリビュートにいくつのAS番号がリストされているかによってベストパスはどれになるのかが決定されます。これがBGPのメトリックはパスベクタであると言われる所以です。

また、必ずAS-pathアトリビュートによってベストパスが決定されるわけではなく、プレフィックス情報(ルート情報)に付加される様々なアトリビュートが順に比較されていくことによりベストパスが決定されることから、BGPのメトリックはパスアトリビュートである訳です。

 

BGPを使用する場合・使用しない場合

BGPを使用するべき状況は以下のような場合です。

逆にBGPを使用するべきではない状況は以下のような場合です。

 


BGPアトリビュート(属性)の値を手動で設定する方法

weight属性

 

local-preference(ローカル優先度)属性

 

Multi-exit-discriminator (MED) 属性

 

community 属性


BGPフィルタリング

アップデートの送受信を制御する。基本的にどの方法でも同じ結果を得られる。ネットワーク構成によって適切な方法を選択。

1,プレフィックス フィルタリング

(拡張)アクセスリストを使うよりも、パフォーマンスがいい、インクリメンタルアップデート(ステートメント単位の変更)をサポート、CLI的に使いやすい、等の利点がある。

シンタックス(構文) ip prefix-list <listname> [ seq ] deny|permit prefix/length [ le | ge length]

[ seq ] は任意。プレフィックスリスト内のエントリ通し番号。指定しないとエントリを書く毎に5,10,15・・・と設定される。

[ le | ge length] はプレフィックス長の範囲で指定するときに使用する。 [ ge = Grater than or Equal to ] [ le = Less than or Equal to ]

構文例

 

2,アクセスリストを利用したフィルタリング

グローバルコンフィグモードでaccess-list を定義してから、ルータコンフィグモードで以下のように、neighborコマンドの中でdistribute-listオプションで適用する。

シンタックス neighbor {ip-address|peer-group-name} distribute-list access-list-number {in|out}

 

3,AS_path フィルタリング

アップデートのASパス・アトリビュートを元にフィルタする。フィルタするASパス・アトリビュートを正規表現で示す。

シンタックス(グローバル) ip as-path access-list access-list-number {permit|deny} as-regular-expression(正規表現)

シンタックス(ルータ) neighbor {ip-address|peer-group-name} filter-list access-list-number {in|out}

 

4,ルートマップ フィルタリング

neighbor 3.3.3.3 route-map stamp in    <- ルートマップ名と送信/受信どちらのアップデートに適用するかを指定
!
route-map stamp permit 10
match as-path 1
set weight 20
!
ip as-path access-list 1 permit ^200$    <- ASパス・アトリビュートが200で始まり200で終わる(正規表現)アップデートを指定。

 

5,コミュニティ フィルタリング

neighbor 3.3.3.1 send-community            <- アップデートにコミュニティ・アトリビュートを含める
neighbor 3.3.3.1 route-map setcommunity out
!
route-map setcommunity permit 10
match ip address 1                    <- アクセスリスト番号を指定。アクセスリスト1に該当するアップデートの
set community no-export                 <- コミュニティ・アトリビュートをno-export に設定
!
access-list 1 permit 0.0.0.0 255.255.255.255


BGP ピアグループ

RTC#
router bgp 300
neighbor internalmap peer-group                   <- ピアグループ  internalmapを定義、以下ピアグループ内の更新ポリシーを定義 
neighbor internalmap remote-as 300
neighbor internalmap route-map SETMETRIC out         <- 更新ポリシー:ピアグループ内の全ルータにルートマップ SETMETRICを適用
neighbor internalmap filter-list 1 out                  <- 更新ポリシー:同様に filter-list 1 をアウトバウンドアップデートに適用
neighbor internalmap filter-list 2 in                   <- 更新ポリシー:同様に filter-list 2 をインバウンドアップデートに適用
neighbor 5.5.5.2 peer-group internalmap
neighbor 5.6.6.2 peer-group internalmap
neighbor 3.3.3.2 peer-group internalmap
neighbor 3.3.3.2 filter-list 3 in                    <- RTEからのインバウンドアップデートのみfilter-list 3 を適用(filter-list 2 を上書き)

BGP ピア グループとは、同じ更新ポリシーを共有する BGP 隣接ルータのグループです。
更新ポリシーは、通常、ルートマップ、ディストリビュート リスト、フィルタ リストなどによって設定します。
隣接ルータごとに同じポリシーを定義する代わりに、ピアグループ名を定義して、これらのポリシーをピア グループに割り当てることができます。
ピアグループのメンバーは、所属するピア グループの設定オプションをすべて受け継ぎます。

ということは、他の隣接ルータでは、ピアグループ名の定義、更新ポリシーを適用する必要はない(んでしょ?)。

RTF#
router bgp 300
neighbor 5.5.5.1 peer-group internalmap
neighbor 5.6.6.3 peer-group internalmap
neighbor 3.3.3.3 peer-group internalmap

 

次に、外部隣接ルータに対してピア グループをどのように使用できるのかを見てみます。上記の例と同じ図で、RTC に peer-group externalmap を設定し、そのピア グループを外部隣接ルータに適用します。

RTC#
router bgp 300
neighbor externalmap peer-group
neighbor externalmap route-map SETMETRIC
neighbor externalmap filter-list 1 out
neighbor externalmap filter-list 2 in
neighbor 2.2.2.2 remote-as 100         
<- remote-as オプションとピア グループ名を1行で指定できないので、2行に分けている
neighbor 2.2.2.2 peer-group externalmap
neighbor 4.4.4.2 remote-as 600
neighbor 4.4.4.2 peer-group externalmap
neighbor 1.1.1.2 remote-as 200
neighbor 1.1.1.2 peer-group externalmap
neighbor 1.1.1.2 filter-list 3 in
          <- RTBからのインバウンドアップデートのみfilter-list 3 を適用(filter-list 2 を上書き)


その他のBGPテクノロジー

*時間があるときもう少し詳しく説明します。少なくともCCIE Lab やBSCIのところで詳しく解説すると思うので、ここでは概要にとどめます。

1,CIDR (Classless InterDomain Routing)

BGP4ではCIDRをサポートしている。CIDRではIPアドレスのクラス概念の制約を受けません。

例えばクラスCのデフォルトのサブネットマスクは、255.255.255.0 ですが、CIDRではデフォルトよりマスクを短くすることが出来ます。

192.150.0.0/16 のようなネットワークアドレスをスーパーネットと呼びます。

 

2,アグリゲート(集約)アドレス

これはアップデートトラフィックを効率化する、またルータのルーティングテーブルのサイズを小さくするための手法です。

複数のネットワーク毎にそれぞれ経路アップデートが発生しないように、あるルータで複数のルートをまとめて1つのルートとして通知するようにします(aggregate-address コマンド)。

BGPはCIDRをサポートすることで、より効率的な集約が可能です。

 

3,コンフェデレーション(連合)

1つのASを、複数のサブASに分けることです。サブAS間ルータはフルメッシュである必要はない。

これにより「AS内の隣接ルータはフルメッシュでなければならない」というIBGPの制約を緩和します。

 

4,ルートリフレクタ(反射)

これも「AS内の隣接ルータはフルメッシュでなければならない」というIBGPの制約を緩和するための手法です。

あるルータをルートリフレクタ(RR)とし、RRの隣接ルータをルートリフレクタ・クライアントとして定義します。

RRがクライアント同士の通信を仲介することで、クライアント同士がピア接続を確立する必要がなくなります。

ルートリフレクタ(RR)とルートリフレクタ・クライアントを会わせて、クラスタと呼ぶ。

 

5,ルートフラップ・ダンプニング(緩衝)

あるルータ上で設定される、ルートフラッピング(一時的にdown/upする)によるルートの不安定を最小限に押さえるための手法。

1回フラッピングが発生したルートに、ある一定数値のペナルティが与えられます。そのペナルティが累積して、基準値(除外:サプレスリミット)を上回ると、そのルートは不安定と見なされ、他のルータに通知されなくなります(サプレスド)。

ある一定期間(ハーフライフタイム)フラップングが起こらないと、累積ペナルティは半分に減らされます。累積ペナルティがもうひとつの基準値(再利用:リユースリミット)を下回ると、そのルートは再び他のルータに通知されるようになる。

 


参照:
Cisco CCIE Lab Practice Kit (Mc Graw Hill)洋書/
CCIE基本ガイドネットワークデザイン&ケーススタディ第2版(Cisco Press)/
シスコネットプロ:トレーナー通信 /
Cisco TAC WEB

inserted by FC2 system