JP6307031B2 - ルートリフレクタおよびルートリフレクタの経路制御方法 - Google Patents

ルートリフレクタおよびルートリフレクタの経路制御方法 Download PDF

Info

Publication number
JP6307031B2
JP6307031B2 JP2015025244A JP2015025244A JP6307031B2 JP 6307031 B2 JP6307031 B2 JP 6307031B2 JP 2015025244 A JP2015025244 A JP 2015025244A JP 2015025244 A JP2015025244 A JP 2015025244A JP 6307031 B2 JP6307031 B2 JP 6307031B2
Authority
JP
Japan
Prior art keywords
route
update information
detailed
aggregate
ibgp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2015025244A
Other languages
English (en)
Other versions
JP2016149634A (ja
Inventor
真子 端地
真子 端地
知茂 島崎
知茂 島崎
紀雄 湯浅
紀雄 湯浅
隆典 岩井
隆典 岩井
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2015025244A priority Critical patent/JP6307031B2/ja
Publication of JP2016149634A publication Critical patent/JP2016149634A/ja
Application granted granted Critical
Publication of JP6307031B2 publication Critical patent/JP6307031B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、ネットワークの経路広告を行うルートリフレクタおよびルートリフレクタの経路制御方法に関する。
近年のインターネットは、人々の情報の流れを支えるインフラとして、その重要性が益々高まっている。このインターネットは、非特許文献1に記載されたような方式で、端末相互の通信を実現している。非特許文献1には、相互に接続された自律システムから構成されるインターネットにおいて、各エンドシステムが相互に通信できるようにするための経路広告という技術が記載されている。「各AS(自律システム)が自分のアドレス空間を広告することによって、また各ASがそのような広告内容を直接的または間接的に習得することによって、インターネット内のそれぞれのエンドシステムは他のエンドシステムと通信ができるようになり、これによってインターネットというグローバルな通信システムが成り立っている。」と記載されている。ここでASとは、Autonomous Systemの略称であり、インターネットに繋がる1または複数のルーティングポリシー配下にあるIPネットワークやルータの集合のことをいう。
特許文献1には、インターネットにおける経路広告に伴う問題が記載されている。特許文献1の課題には、「NW同士を接続するルータ装置において、特定障害時の持続的な通信断を回避しつつ、経路集約を可能にする。」と記載され、解決手段には、「第1のネットワークにおける詳細経路を集約した集約経路情報を第2のネットワークに広告する経路広告手段を備えたルータ装置において、障害を検知した場合に、当該障害がブラックホール問題に該当するか否かを判定する障害判定手段と、前記ブラックホール問題に該当する場合において、障害により消失した経路情報を抽出し、抽出された経路情報に関する予め定めた条件に基づき、第1の動作と第2の動作のうちのいずれを行うかを判定する経路管理手段と、前記第1の動作を行う場合において、前記抽出された経路情報の広告を指示するメッセージを他のルータ装置に送信し、当該経路情報の広告を行わせるメッセージ制御手段と、を備え、前記第2の動作を行う場合において、前記経路広告手段に対し前記集約経路情報の広告を停止させる。」と記載されている。この特許文献1に記載された、いわゆる「ブラックホール問題」について、以下に記載する。
図1は、第1比較例の大規模ネットワーク1Aの構成を示す図である。
大規模ネットワーク1Aには、ネットワークA(3a)および、ネットワークB(3b)、ネットワークC(3c)が、ルータ2−10,2−20とルータ2−0,2−1とを介してバックボーンネットワーク4に接続されて構成されている。なお、図面では、ネットワークのことを、「NW」と省略記載する場合がある。
ルータ2−0,2−1は、エッジルータである。ルータ2−20には更に、ネットワークX(3x)が接続されている。大規模ネットワーク1には、これらと対向する位置にネットワークD(3d)が、ルータ2−30とルータ2−2,2−3とを介してバックボーンネットワーク4に接続されて構成されている。なお、各ネットワークを特に区別しないときには、単にネットワーク3と記載する。また、各ルータ2−0〜2−3,2−10〜2−40を特に区別しないときには、単にルータ2と記載する。
ネットワークA(3a)は、ASであり、不図示の端末(エンドシステム)を含んで構成される。ネットワークB(3b)、ネットワークC(3c)、ネットワークD(3d)、ネットワークX(3x)も、ネットワークA(3a)と同様に構成されたASであるが、それぞれ管理ポリシが異なる。ルータ2−0〜2−3,2−10〜2−40は、各ネットワーク3とバックボーンネットワーク4とを接続する。
バックボーンネットワーク4は、複数のルータ41がネットワーク状に接続されて構成される。図2以下では、各ルータ41を省略して示している。
ネットワークA(3a)、およびネットワークB(3b)、ネットワークC(3c)は、障害等の発生を考慮してルータ2−0,2−1による冗長構成を取るように接続される。ルータ2−0は現用系であり、ルータ2−1は予備系である。同様に、ネットワークD(3d)は、現用系のルータ2−2と、予備系のルータ2−3による冗長構成を取るように接続される。このように通常状態では、現用系のルータ2−0,2−2にトラヒックを流通させる、いわゆる片寄せ運用が行われる。これは、現用系のルータ2−0,2−2から優先度の高い経路情報を広告することによって実現される。
なお、片寄せ運用とは異なる両系運用という方法もある。両系運用では、ルータ2−0,2−1に対して現用系と予備系という定義をせず、通常状態において同じ優先度の経路情報を広告する。これにより、両方のルータ2−0,2−1に分散してトラヒックを流通させることができる。
大規模ネットワーク1Aにおいて、各ネットワーク3の通信を可能とするためには、お互いのネットワーク3が保持する経路情報を交換する必要がある。ネットワークA(3a)は詳細経路(10.0.1.0/24)であり、ネットワークB(3b)は詳細経路(10.0.2.0/24)であり、ネットワークC(3c)は詳細経路(10.0.3.0/24)である。ネットワークX(3x)は、詳細経路(192.168.1.0/24)である。
各ネットワーク3が交換する経路数が多くなると、お互いのネットワーク3内で流通する経路数が増加してネットワークを構成するルータ2等の負荷を増大させてしまう。そのため、交換する経路を極小化するような経路交換制御技術を用いることが多い。
具体的には、自ネットワーク3内に流通する複数の経路情報を集約して、自身に接続される他のネットワーク3へ広告することにより、交換する経路を極小化する。
ルータ2の経路集約処理では、複数のネットワークプレフィックスを含む、より広範囲なネットワークプレフィックスを設定することで、複数のネットワーク3を纏めている。ルータ2は、この纏めたネットワークプレフィックスの情報を接続先のネットワーク3へ広告し、各ネットワーク3の個々のネットワークプレフィックスの情報は広告しない。これにより、接続先のネットワーク3で流通する経路数を抑制することができる。ここで、複数のネットワークプレフィックスを含む、より広範囲なネットワークプレフィックスは、集約経路の情報である。一般的に、集約経路は、集約経路に含まれる詳細経路が一つでも存在すれば生成される。この動作を図2に示す。
図2は、第1比較例の大規模ネットワーク1Aの集約経路を示す図である。
図2の例では、ネットワークA(3a)の詳細経路Ra、ネットワークB(3b)の詳細経路Rb、ネットワークC(3c)の詳細経路Rcのうちいずれかの情報をルータ2−0が保有していれば、これらを含み、より広範囲な集約経路R0を生成する。集約経路R0の情報は、(10.0.0.0/22)である。
これに対してルータ2−0が、ネットワークX(3x)の詳細経路Rxの情報を保有していても、他のネットワークA(3a)、ネットワークB(3b)、ネットワークC(3c)とは集約しない。
図2の構成において、ルータ2−0〜2−3が同一のASに所属している場合、同一のAS内の全てのルータ2−0〜2−3が全てのBGP(Border Gateway Protocol)経路を学習できるように、AS内部でiBGP(internal Border Gateway Protocol)ピアをフルメッシュに張る必要がある。同一のAS内のルータ2の台数が増大するとiBGPピア数が増大し、各ルータ2の負荷を増大させて帯域幅を消費することになる。そのため、図3に示す第2比較例では、iBGPピア数の増大を緩和する手段として、ルートリフレクタという手法を用いる。
図3は、第2比較例の大規模ネットワーク1Bの構成と動作とを示す図である。
大規模ネットワーク1Bは、大規模ネットワーク1Aと同様の構成に加えて更に、ルートリフレクタ5Bを備えている。
このルートリフレクタ5Bは、iBGPピアルータであるルータ2−0〜2−3から受け取った経路情報(BGP UPDATE)を、他のiBGPピアルータに広告(反射)する。同一のAS内のBGPスピーカは、ルートリフレクタ5Bと、このルートリフレクタ5Bから経路情報を受け取るルートリフレクタクライアント、このルートリフレクタ5Bとクライアントのどちらでもないルートリフレクタノンクライアントの3つに分類される。これらの動作は以下のようになる。なお、ルートリフレクタクライアントを単にクライアント、ルートリフレクタノンクライアントを単にノンクライアントと省略記載する。
ルートリフレクタ5Bは、クライアントから広告された経路情報をクライアントとノンクライアントに反射し、ノンクライアントから広告された経路情報をクライアントに反射する。ルートリフレクタクライアント同士では、iBGPピアを張らない。また、ルートリフレクタ5Bからクライアントに広告された経路情報は、クライアントからどのルータにも反射されない。図3の例でいうと、クライアントはルータ2−0〜2−3である。
このように経路広告された結果、ネットワークD(3d)は、ネットワークA(3a)との間にフローFaが流れ、ネットワークB(3b)との間にフローFbが流れ、ネットワークC(3c)との間にフローFcが流れる。各フローFa〜Fcは、それぞれルータ2−0,2−2を経由する。
ルートリフレクタ5Bを利用することで、同一AS内ではルートリフレクタ5BとクライアントのみがiBGPピアを張ればよく、クライアント同士はiBGPピアを張る必要がない。そのため、iBGPピア数を抑制することができる。以下の図4では、ネットワークA(3a)が追加(接続)された場合を想定してルートリフレクタ5Bの内部動作を説明する。
図4は、第2比較例におけるルートリフレクタ5Bの構成と動作とを示す図である。
ルートリフレクタ5Bは、経路受信部51と、経路広告部52と、経路管理部53と、BGPテーブル54とを備えている。
経路受信部51は、各ルータ2からUPDATE情報を受信し、受信したUPDATEを経路広告部52と経路管理部53とに転送する。
経路管理部53は、経路受信部51から転送されたUPDATE情報をBGPテーブル54に反映する。このBGPテーブル54は、ルーティングテーブル作成にも用いるが、ルーティングテーブル作成部分は本発明に関連しないため、記載を省略する。
経路広告部52は、経路受信部51から転送されたUPDATE情報を、各クライアントであるルータ2に広告(反射)する。
図5(a)〜(c)は、ネットワークA(3a)追加時の状態を示す図である。図5(a)は、現用系のルータ2−0から送信されるUPDATE情報8である。図5(b)は、予備系のルータ2−1から送信されるUPDATE情報8である。図5(c)は、BGPテーブル54の構成を示している。
図5(a)に示すように、UPDATE情報8は、送信元フィールド8aと、新たに利用不可となった経路情報を示すWithdrawnフィールド8bと、経路情報の優先度を示すパス属性フィールド8cと、新たに利用可能となった経路情報を示す利用可能経路フィールド8dとを含んで構成される。このUPDATE情報8の送信元フィールド8aには、ルータ2−0を示す「ルータ#0」が格納される。このUPDATE情報8のWithdrawnフィールド8bは空欄であり、代わりに利用可能経路フィールド8dに、新たに利用可能となったネットワークA(3a)への詳細経路情報(10.0.1.0/24)が格納される。なお、Withdrawnフィールド8bに何らかの経路情報が格納されていたならば、その経路が利用不可となったということである。
パス属性フィールド8cには、現用系としての優先度「10」が格納されている。ここではMED(Multi Exit Discriminator)値を例として記載しており、値が小さいほど優先度が高いことを示す。
図5(b)に示すように、予備系のルータ2−1から送信されるUPDATE情報8は、送信元フィールド8aに「ルータ#1」が格納され、パス属性フィールド8cには、予備系としての優先度「20」が格納されている。Withdrawnフィールド8bは空欄であり、利用可能経路フィールド8dに、ネットワークA(3a)への詳細経路情報 (10.0.1.0/24)が格納される。以下、ルータ2−0,2−1から送信されるUPDATE情報8を、同一図に併記する。
図5(c)に示すように、BGPテーブル54は、利用可能経路欄54aと、パス属性欄54bと、送信元欄54cとを含んで構成される。
利用可能経路欄54aには、現在の時点で利用可能な経路情報が格納されている。つまり、利用可能経路欄54aには、UPDATE情報8の利用可能経路フィールド8dの経路情報が追加されると共に、Withdrawnフィールド8bの経路情報と一致する経路情報が削除される。
パス属性欄54bには、上記した経路情報の優先度が格納されている。UPDATE情報8のパス属性フィールド8cに格納される優先度が反映される。
送信元欄54cには、上記した経路情報の送信元の情報が格納されている。つまり送信元欄54cには、UPDATE情報8の送信元フィールド8aの情報が反映される。
図5(c)のBGPテーブル54の状態は、図5(a),(b)で示した各UPDATE情報8が反映されており、その部分に下線を引いている。
以下、集約経路の広告に伴う問題を記載する。ルートリフレクタ5(図3参照)の有無に関わらず経路集約を実施すると、特定の障害パターンにおいては、代替経路が存在するにもかかわらず、代替経路に切り替わらずに持続的に通信断となる状態に陥ってしまう場合がある。この問題は、ブラックホール問題と呼ばれている。
図6は、比較例でのブラックホール問題の発生例を示す図である。
図6においては、ルータ2−10とルータ2−0間で障害9が発生している状態である。ルータ2−0は、ネットワークA(3a)の詳細経路情報(10.0.1.0/24)を保有せず、ネットワークB(3b)の詳細経路情報(10.0.2.0/24)およびネットワークC(3c)の詳細経路情報(10.0.3.0/24)は保有している。そのため、ネットワークA(3a)、ネットワークB(3b)、ネットワークC(3c)を含む集約経路情報(10.0.0.0/22)が生成される。集約経路情報(10.0.0.0/22)は、障害9の発生前と同様に、バックボーンネットワーク4内に広告されることとなる。
この状態において、ネットワークD(3d)からネットワークA(3a)宛の通信が発生した場合、ネットワークA(3a)宛の通信はルータ2−0から広告された集約経路情報(10.0.0.0/22)に従い、ルータ2−0へ転送される。しかしルータ2−0は、ネットワークA(3a)の詳細経路情報(10.0.1.0/24)を保有していないため、この通信は転送先が不明と判断されて破棄される。このようにルータに吸い込まれたパケットが消滅してしまうということから、ブラックホール問題と呼ばれている。
従来の技術では、このような一般的な大規模ネットワーク1A,1Bでブラックホール問題を回避することは不可であった。そのため、特定障害の発生確率等を踏まえて設計者が、「特定障害発生時の持続的な通信断は非許容とし、経路集約を実施しない」を選択するか、「特定障害時の持続的な通信断を許容し、経路集約を実施する。」を選択するかの二者択一であった。
特開2014−154946号公報
Philip Smith,Rob Evans,Mike Hughes、「RIPE ルーティングワーキンググループによる経路集約(Route Aggregation)に関する推奨」、[online]、2006年12月、[平成27年1月30日検索]、<URL: http://www.nic.ad.jp/ja/translation/ripe/20061201.html#id000705>
ネットワーク同士を接続するルータにおいて、経路集約を実施しない場合、及び経路集約を実施する場合、それぞれにおける現状技術での課題を以下に示す。
ルータで経路集約を実施しない場合には、接続先ネットワーク内で大量の経路が流通することとなり、接続先ネットワークを構成するルータの保有経路数が肥大化してリソースを大量に消費する。その結果、リンク障害等が発生した場合の経路切り替えに多くの時間を要し、結果として障害時の通信断時間が長くなり、ネットワーク品質の低下に繋がる。また同時に、各ルータの保有経路数の肥大化が障害発生時の切り分け等の複雑性を増大させ、ネットワークの運用性が低下することも懸念される。
これに対して、ルータで経路集約を実施する場合には、図6に示したように、障害のパターンによっては迂回ルートがあるにも関わらず迂回できないというブラックホール問題が発生し、持続的な通信断となるため、ネットワーク品質の低下に繋がる。
本発明は、前記した問題を解決し、大規模ネットワークにて特定障害時の持続的な通信断を回避しつつ経路集約を可能とするルートリフレクタおよび経路制御方法を提供することを課題とする。
前記課題を解決するため、請求項1に記載の発明では、経路の利用可または利用不可に係るUPDATE情報をiBGP(internal Border Gateway Protocol)ピアから受信する経路受信部と、前記経路を集約経路、集約経路に含まれる詳細経路、集約経路に含まれない詳細経路のいずれかに分類し、前記集約経路と前記集約経路に含まれる詳細経路との対応を集約経路マッピングテーブルにて管理し、前記UPDATE情報および当該集約経路マッピングテーブルに基づき広告用UPDATE情報を計算する経路計算部と、前記経路計算部が計算した前記広告用UPDATE情報を、他のiBGPピアに広告する経路広告部と、を備えており、前記経路計算部は、前記経路受信部により、同一の集約経路に含まれる同一の詳細経路の利用可に係るUPDATE情報を第1のiBGPピアおよび第2のiBGPピアから受信したのちに、前記第1のiBGPピアから当該詳細経路の利用不可に係るUPDATE情報を受信し、かつ、前記第2のiBGPピアの当該詳細経路の優先度が前記第1のiBGPピアの当該詳細経路の優先度よりも低いならば、前記第2のiBGPピアの当該詳細経路の利用可に係る広告用UPDATE情報を計算する、ことを特徴とするルートリフレクタとした。
このようにすることで、ルートリフレクタは、大規模ネットワークにて特定障害であるブラックホール問題の発生時の持続的な通信断を回避しつつ経路集約を可能とする。
請求項2に記載の発明では、前記経路計算部は、前記経路受信部により、同一の集約経路に含まれる同一の詳細経路の利用可に係るUPDATE情報を第1のiBGPピアおよび第2のiBGPピアから受信したのちに、前記第1のiBGPピアから当該詳細経路の利用不可に係るUPDATE情報を受信し、かつ、前記第2のiBGPピアの当該詳細経路の優先度が前記第1のiBGPピアの当該詳細経路の優先度よりも低いならば、前記集約経路マッピングテーブルにおける前記第1のiBGPピアの当該詳細経路に利用不可フラグを設定する、ことを特徴とする請求項1に記載のルートリフレクタとした。
このようにすることで、ルートリフレクタは、第2のiBGPピアを介した詳細経路を代替として使用して、発生した障害がブラックホール問題に該当するか判定することができる。
請求項3に記載の発明では、前記経路計算部は更に、前記経路広告部により前記第2のiBGPピアから受信した詳細経路の利用可に係る広告用UPDATE情報を他のiBGPピアに広告した後に、前記経路受信部により前記第1のiBGPピアから当該詳細経路の利用可に係るUPDATE情報を受信したならば、前記第2のiBGPピアの当該詳細経路の利用不可に係る広告用UPDATE情報を計算する、ことを特徴とする請求項1に記載のルートリフレクタとした。
このようにすることで、ルートリフレクタは、ブラックホール問題に係る障害から回復したときに、元の第1のiBGPピアを介した詳細経路を再び利用することができる。
請求項4に記載の発明では、前記経路計算部は更に、前記経路広告部により前記第2のiBGPピアから受信した詳細経路の利用可に係る広告用UPDATE情報を他のiBGPピアに広告した後に、前記経路受信部により前記第1のiBGPピアから当該詳細経路の利用可に係るUPDATE情報を受信したならば、前記集約経路マッピングテーブルにおける前記第1のiBGPピアの当該詳細経路に設定された利用不可フラグを消去する、ことを特徴とする請求項3に記載のルートリフレクタとした。
このようにすることで、障害回復時の集約経路マッピングテーブルを、障害発生前と同一の状態に戻し、次の障害発生に備えることができる。
請求項5に記載の発明では、前記経路計算部は、前記UPDATE情報のCommunity値により、前記経路を集約経路、集約経路に含まれる詳細経路、集約経路に含まれない詳細経路のいずれかに分類する、ことを特徴とする請求項1に記載のルートリフレクタとした。
このようにすることで、経路の種別を容易に判別することができる。
請求項6に記載の発明では、前記経路計算部は、前記経路受信部によりiBGPピアから集約経路に含まれる詳細経路の利用可に係るUPDATE情報を受信したならば、前記経路広告部に広告させない、ことを特徴とする請求項1に記載のルートリフレクタとした。
このようにすることで、各ルータの保有経路数の肥大化を抑止できる。
請求項7に記載の発明では、経路の利用不可または利用可に係るUPDATE情報をiBGP(internal Border Gateway Protocol)ピアから受信する経路受信部と、前記経路を集約経路、集約経路に含まれる詳細経路、集約経路に含まれない詳細経路のいずれかに分類し、前記集約経路と前記集約経路に含まれる詳細経路との対応を集約経路マッピングテーブルにて管理し、前記UPDATE情報および当該集約経路マッピングテーブルに基づき広告用UPDATE情報を計算する経路計算部と、前記経路計算部が計算した前記広告用UPDATE情報を、他のiBGPピアに広告する経路広告部と、を備えるルートリフレクタが実行する経路制御方法であって、前記経路受信部により、同一の集約経路に含まれる同一の詳細経路の利用可に係るUPDATE情報を第1のiBGPピアおよび第2のiBGPピアから受信するステップと、前記第1のiBGPピアから前記詳細経路の利用不可に係るUPDATE情報を受信するステップと、前記経路計算部により、前記第1のiBGPピアで利用不可となった詳細経路と同じ詳細経路が前記第2のiBGPピアから広告されており、かつ前記第2のiBGPピアの前記詳細経路の優先度が前記第1のiBGPピアの前記詳細経路の優先度よりも低いか否かを判断するステップと、前記判断が成立したならば、前記第2のiBGPピアの前記詳細経路の利用可に係る広告用UPDATE情報を計算するステップと、前記経路広告部により、前記広告用UPDATE情報を、他のiBGPピアに広告するステップと、を含むことを特徴とするルートリフレクタの経路制御方法とした。
このようにすることで、ルートリフレクタは、大規模ネットワークにて特定障害であるブラックホール問題の発生時の持続的な通信断を回避しつつ経路集約を可能とする。
請求項8に記載の発明では、前記経路広告部により前記第2のiBGPピアから受信した前記詳細経路の利用可に係る広告用UPDATE情報を他のiBGPピアに広告した後に、前記経路受信部により前記第1のiBGPピアから当該詳細経路の利用可に係るUPDATE情報を受信するステップと、前記経路計算部により、前記第2のiBGPピアの前記詳細経路の利用不可に係る広告用UPDATE情報を計算するステップと、前記経路広告部により、前記広告用UPDATE情報を、他のiBGPピアに広告するステップと、を含むことを特徴とする請求項7に記載のルートリフレクタの経路制御方法とした。
このようにすることで、ルートリフレクタは、第2のiBGPピアを介した詳細経路を代替として使用して、ブラックホール問題の発生を検知することができる。
本発明によれば、大規模ネットワークにて特定障害時の持続的な通信断を回避しつつ経路集約を可能とするルートリフレクタおよび経路制御方法を提供することが可能となる。
第1比較例の大規模ネットワークを示す概略の構成図である。 第1比較例の大規模ネットワークの集約経路と詳細経路とを示す図である。 第2比較例におけるルートリフレクタの動作を示す図である。 第2比較例におけるルートリフレクタの構成と動作とを示す図である。 第2比較例におけるネットワークA追加時の状態を示す図である。 第2比較例でのブラックホール問題の発生例を示す図である。 本実施形態におけるルートリフレクタの構成と動作とを示す図である。 本実施形態によるブラックホール問題の解決例を示す図である。 通常時かつ集約経路が利用可であるパターン#1を示す図である。 通常時かつ集約経路に含まれる詳細経路が利用可であるパターン#2を示す図である。 通常時かつ集約経路に含まれない詳細経路が利用可であるパターン#3を示す図である。 障害時かつ集約経路が利用不可であるパターン#4を示す図である。 障害時かつ集約経路に含まれる詳細経路が利用不可であるパターン#5を示す図である。 障害回復時かつ集約経路に含まれる詳細経路が利用可であるパターン#8を示す図である。 登録、障害発生から回復までのシーケンスを示す図である。 ルートリフレクタの広告処理(その1)を示すフローチャートである。 ルートリフレクタの広告処理(その2)を示すフローチャートである。
次に、本発明を実施するための形態(「実施形態」という)について、適宜図面を参照しながら詳細に説明する。
一般的な大規模ネットワークでブラックホール問題を回避し、かつ経路集約を実施するための手法として、ルートリフレクタに以下の3つの新機能を追加することを考案した。
(1) iBGPピアから集約経路と詳細経路(集約経路の元となる経路も含む)を受信し、集約経路と、集約経路に含まれない詳細経路とを抽出して他のiBGPピアに広告する。
(2) 障害発生時、iBGPピアから経路消失を示すWithdrawnを受信した場合、ブラックホール問題に該当するかを判定する。
(3) ブラックホール問題に該当する場合、予備系のルータから受信している消失した経路(ネットワークAの経路)を、ルートリフレクタ5(図8参照)から他のiBGPピアに広告する。
図7は、本実施形態におけるルートリフレクタの構成と動作とを示す図である。
ルートリフレクタ5は、経路受信部51と、経路広告部52と、経路管理部53と、BGPテーブル54と、経路計算部55と、集約経路マッピングテーブル56とを備えている。
経路受信部51は、各ルータ2からUPDATE情報を受信し、受信したUPDATE情報を経路管理部53と経路計算部55とに転送する。
経路管理部53は、経路受信部51から転送されたUPDATE情報をBGPテーブル54に反映する。
経路計算部55は、経路受信部51から転送されたUPDATE情報を集約経路マッピングテーブル56に記録すると共に、ブラックホール問題を回避するための広告用UPDATE情報を計算する。集約経路マッピングテーブル56は、集約経路に対して、この集約経路に含まれる詳細経路をマッピングしたものである。
経路広告部52は、経路計算部55から転送された広告用UPDATE情報を、各クライアントであるルータ2に広告(反射)する。
図8は、本実施形態によるブラックホール問題の解決例を示す図である。
図8に示すように、ルータ2−10とルータ2−0間で障害9が発生している。このとき、ネットワークD(3d)とネットワークA(3a)との間のフローFAは、予備系のルータ2−1を介して流れる。フローFbと、フローFcは、現用系のルータ2−0(第1のiBGPピア)を介して流れる。
この状態において、ネットワークD(3d)からネットワークA(3a)宛の通信が発生した場合、ネットワークA(3a)宛の通信はルータ2−1(第2のiBGPピア)へ転送される。ルータ2−1は、ネットワークA(3a)の詳細経路情報(10.0.1.0/24)を保有しているため、この通信は転送先がネットワークA(3a)と判断されて転送される。このようにしてブラックホール問題を解決することができる。
新規機能を追加したルートリフレクタ5がクライアントからUPDATE情報を受け取った際の挙動には、以下の表に示す9つのパターンがある。それぞれのパターンにおける新規機能を追加したルートリフレクタ5の内部動作について、具体例を用いて詳細に説明する。なお、以下では、例えは集約経路情報(10.0.0.0/22)で示される集約経路などを、単に集約経路(10.0.0.0/22)と記載する場合がある。
Figure 0006307031
<パターン#1>
通常時に集約経路(10.0.0.0/22)がルータ2−0で利用可となった際の本実施形態のルートリフレクタ5の内部動作について、以下に示す。
経路受信部51は、各ルータ2から受信したUPDATE情報8を経路管理部53と経路計算部55とに転送する。経路管理部53は、経路受信部51から転送されたUPDATE情報8をBGPテーブル54に反映する。
経路計算部55は、BGPテーブル54から集約経路(Community値で判別)とそこに含まれる詳細経路をマッピングした集約経路マッピングテーブル56を作成して保持する。経路計算部55は更に、集約経路マッピングテーブル56に基づき集約経路のみを掲載した広告用UPDATE情報81を生成し、経路広告部52に転送する。
経路広告部52は、経路計算部55から転送された広告用UPDATE情報81をクライアントに広告する。これらの動作に伴う状態について、以下の図9に示す。
図9(a)〜(d)は、通常時かつ集約経路が利用可であるパターン#1を示す図である。ここでは、ルータ2−0,2−1において、集約経路(10.0.0.0/22)が利用可となった際の本実施形態のルートリフレクタ5の内部状態とその動作について説明する。
図9(a)の1行目は各フィールド名を示し、2〜4行目は、ルータ2−0(ルータ#0)から受信したUPDATE情報8を示している。5〜7行目は、ルータ2−1(ルータ#1)から受信したUPDATE情報8を示している。
UPDATE情報8は、送信元フィールド8aと、Withdrawnフィールド8bと、パス属性フィールド8cと、利用可能経路フィールド8dとを含んで構成される。このUPDATE情報8は、経路受信部51によって各ルータ2から受信され、経路管理部53と経路計算部55に転送される。
2〜4行目のUPDATE情報8は、ルータ2−0から詳細経路情報(10.0.1.0/24)と、詳細経路情報(10.0.2.0/24)と、集約経路情報(10.0.0.0/22)とを受信したことを示している。パス属性フィールド8cには、MED属性と、経路種別を示すCommunity属性とが格納されている。Community属性は4オクテットからなり、上位2オクテットにAS番号が入り、残りの下位2オクテットにポリシを表す数値が入る、上位2オクテットと下位2オクテットの間は「:」で区切られる。
2行目と3行目のCommunity値(100:300)は、AS番号100においてポリシ値300が適用される経路であることを示し、ポリシ値(300)が、集約経路およびその集約経路に含まれる詳細経路のグループを示している。4行目のCommunity値(100:1000)は、前述のグループのうち、この経路が集約経路であることを示している。
UPDATE情報8の5〜7行目は、ルータ2−1から情報(10.0.1.0/24)の詳細経路と、情報(10.0.2.0/24)の詳細経路と、情報(10.0.0.0/22)の集約経路を受信したことを示している。パス属性フィールド8cには、MED(Multi Exit Discriminator)属性と、経路種別を示すCommunity属性とが格納されている。
UPDATE情報8の5行目と6行目のCommunity値(100:300)は、AS番号100においてポリシ値300が適用される経路であることを示している。7行目のCommunity値(100:1000)は、前述のグループのうち、この経路が集約経路であることを示している。
図9(b)は、図9(a)のUPDATE情報8によって更新されたBGPテーブル54を示している。BGPテーブル54には、経路管理部53により図9(a)で示したUPDATE情報8が反映される。
図9(c)は、図9(b)のBGPテーブル54に基づいて更新された集約経路マッピングテーブル56を示している。集約経路マッピングテーブル56は、集約経路欄56aと、集約経路パス属性欄56bと、集約経路送信元欄56cと、詳細経路欄56dと、詳細経路パス属性欄56eと、詳細経路送信元欄56fと、Withdrawnフラグ欄56gとを含んで構成される。
経路計算部55は、BGPテーブル54のパス属性欄54bのCommunity値により、集約経路であるか、または集約経路に含まれる詳細経路であるかを判別し、集約経路とこれに含まれる詳細経路とをマッピングした集約経路マッピングテーブル56を作成する。
集約経路欄56aは、BGPテーブル54における集約経路の利用可能経路欄54aの情報が格納される。集約経路パス属性欄56bは、BGPテーブル54における集約経路のパス属性欄54bのMED属性が格納される。集約経路送信元欄56cは、BGPテーブル54における集約経路の送信元欄54cの情報が格納される。
詳細経路欄56dと詳細経路パス属性欄56eと詳細経路送信元欄56fには、集約経路欄56aに含まれる詳細経路の、BGPテーブル54における利用可能経路欄54aとパス属性欄54bのMED属性と送信元欄54cの情報が格納される。このときWithdrawnフラグ欄56gは、いずれも空欄である。
図9(d)は、広告用UPDATE情報81を示している。広告用UPDATE情報81は、UPDATE情報8と同様に、送信元フィールド81aと、Withdrawnフィールド81bと、パス属性フィールド81cと、利用可能経路フィールド81dとを含んで構成される。経路計算部55は、作成した集約経路マッピングテーブル56(図9(c)参照)に基づき、集約経路のみを掲載した広告用UPDATE情報81を作成して経路広告部52に転送する。経路広告部52は、経路計算部55から転送された広告用UPDATE情報81をクライアントに広告する。
<パターン#2>
既にルートリフレクタ5からクライアントに広告されている集約経路(10.0.0.0/22)に含まれる詳細経路(10.0.3.0/24)がルータ2−0,2−1で新たに利用可となった際の本実施形態のルートリフレクタ5の内部動作について、以下に示す。
経路受信部51は、各ルータ2から受信したUPDATE情報8を経路管理部53と経路計算部55とに転送する。
経路管理部53は、経路受信部51から転送されたUPDATE情報8をBGPテーブル54に反映する。
経路計算部55は、UPDATE情報8に記載された利用可能経路(10.0.3.0/24)が集約経路(10.0.0.0/22)に含まれるため、集約経路マッピングテーブル56を更新する。集約経路は既に広告済であるため、広告用UPDATE情報81の経路広告部52への転送は実施しない。
図10(a)〜(c)は、通常時かつ集約経路に含まれる詳細経路が利用可であるパターン#2を示す図である。ここでは、ネットワークC(3c)が新たに接続された場合を示している。
図10(a)の1行目は各フィールド名を示し、2行目はルータ2−0(ルータ#0)から受信したUPDATE情報8を示し、3行目はルータ2−1(ルータ#1)から受信したUPDATE情報8を示している。
UPDATE情報8の2行目は、ルータ2−0からネットワークC(3c)の詳細経路(10.0.3.0/24)を受信したことを示している。パス属性フィールド8cには、MED属性と、経路種別を示すCommunity属性とが格納されている。MED属性(10)は、ルータ2−0を介する経路が現用系の優先度を持つことを示している。Community値(100:300)は、AS番号100においてポリシ値300が適用される経路であることを示し、よって集約経路(10.0.0.0/22)に属することを示している。
UPDATE情報8の3行目は、ルータ2−1からネットワークC(3c)の詳細経路(10.0.3.0/24)を受信したことを示している。パス属性フィールド8cには、MED属性と、経路種別を示すCommunity属性とが格納されている。MED属性(20)は、ルータ2−0を介する経路が予備系の優先度を持つことを示している。Community値(100:300)は、AS番号100においてポリシ値300が適用される経路であることを示し、よって集約経路(10.0.0.0/22)に属することを示している。
図10(b)は、図10(a)のUPDATE情報8によって更新されたBGPテーブル54を示している。BGPテーブル54には、経路管理部53により図10(a)で示したUPDATE情報8が反映される。
図10(c)は、図10(b)のBGPテーブル54に基づいて更新された集約経路マッピングテーブル56を示している。
経路計算部55は、BGPテーブル54の2行目のパス属性により、集約経路(10.0.0.0/22)かつMED属性(10)に含まれる詳細経路であることを判別し、集約経路マッピングテーブル56に追加する。
経路計算部55は、BGPテーブル54の3行目のパス属性により、集約経路(10.0.0.0/22)かつMED属性(20)に含まれる詳細経路であることを判別し、集約経路マッピングテーブル56に追加する。
<パターン#3>
集約経路(10.0.0.0/22)に含まれない詳細経路(192.168.1.0/24)がルータ2−0,2−1において新たに利用可となった際、本実施形態のルートリフレクタ5の内部動作について、以下に示す。
ここでは集約経路に含まれる詳細経路(10.0.1.0/24,10.0.2.0/24,10.0.3.0/24)がルータ2−0で利用不可となり、集約経路が生成されなくなった場合を例にとって記載する。
経路受信部51は、各ルータ2から受信したUPDATE情報8を経路管理部53、経路計算部55に転送する。
経路管理部53は、経路受信部51から受信したUPDATE情報8をBGPテーブル54に反映する。
経路計算部55は、UPDATEされた利用可能な経路(192.168.1.0/24)が集約経路に含まれないため、集約経路マッピングテーブル56をアップデートしない。そして経路計算部55は、経路受信部51から転送されたUPDATE情報8を広告用UPDATE情報81として経路広告部52に転送する。
経路広告部52は、経路計算部55から転送された広告用UPDATE情報81をクライアントに広告する。
図11(a)〜(d)は、通常時かつ集約経路に含まれない詳細経路が利用可であるパターン#3を示す図である。
図11(a)の1行目は各フィールド名を示し、2行目はルータ2−0(ルータ#0)から受信したUPDATE情報8を示し、3行目はルータ2−1(ルータ#1)から受信したUPDATE情報8を示している。
UPDATE情報8の2行目は、ルータ2−0からネットワークX(3x)の詳細経路(198.168.1.0/24)を受信したことを示している。パス属性フィールド8cには、MED属性が格納されている。MED属性(10)は、ルータ2−0を介する経路が現用系の優先度を持つことを示している。このパス属性フィールド8cには、Community値が格納されておらず、この経路が集約経路に含まれない詳細経路であることを示している。
UPDATE情報8の3行目は、ルータ2−1からネットワークC(3c)の詳細経路(10.0.3.0/24)を受信したことを示している。パス属性フィールド8cには、MED属性が格納されている。MED属性(20)は、ルータ2−0を介する経路が予備系の優先度を持つことを示している。このパス属性フィールド8cには、Community値が格納されておらず、この経路が集約経路に含まれない詳細経路であることを示している。
図11(b)は、図11(a)のUPDATE情報8によって更新されたBGPテーブル54を示している。BGPテーブル54には、経路管理部53により図11(a)で示したUPDATE情報8が反映される。
図11(c)は、図11(b)のBGPテーブル54に基づいて更新された集約経路マッピングテーブル56を示している。
経路計算部55は、BGPテーブル54の2行目と3行目のパス属性欄54bにCommunity値が格納されていないことから、この経路が集約経路に含まれない詳細経路であると判断する。よって、経路計算部55は、集約経路マッピングテーブル56を書き換えない。
図11(d)は、広告用UPDATE情報81を示している。この広告用UPDATE情報81は、図11(a)に示すUPDATE情報8と同様である。
<パターン#4>
障害発生により、集約経路(10.0.0.0/22)がルータ2−0で利用不可となった際の本実施形態のルートリフレクタ5の内部動作について、以下に示す。
ここでは集約経路に含まれる詳細経路(10.0.1.0/24,10.0.2.0/24,10.0.3.0/24)がルータ2−0で利用不可となり、集約経路が生成されなくなった場合を例にとって記載する。
経路受信部51は、各ルータ2から受信したUPDATE情報8を経路管理部53と経路計算部55に転送する。
経路管理部53は、経路受信部51から転送されたUPDATE情報8をBGPテーブル54に反映する。
経路計算部55は、UPDATE情報8で利用不可(Withdrawn)となった集約経路(10.0.0.0/22)を集約経路マッピングテーブル56から削除する。そして経路計算部55は、経路受信部51から転送されたUPDATE情報8と同一の広告用UPDATE情報81を経路広告部52に転送する。
経路広告部52は、経路計算部55から転送された広告用UPDATE情報81をクライアントに広告する。
図12(a)〜(d)は、障害時かつ集約経路が利用不可であるパターン#4を示す図である。
図12(a)の1行目は各フィールド名を示し、2〜5行目は、ルータ2−0(ルータ#0)から受信したUPDATE情報8を示している。このUPDATE情報8は、経路受信部51によって各ルータ2から受信され、経路管理部53と経路計算部55に転送される。
UPDATE情報8の2〜4行目は、ルータ2−0から詳細経路(10.0.1.0/24)の利用不可、詳細経路(10.0.2.0/24)の利用不可、および詳細経路(10.0.3.0/24)の利用不可を受信したことを示している。パス属性フィールド8cには、MED属性(10)と、経路種別を示すCommunity属性(100:300)とが格納されている。
UPDATE情報8の5行目は、ルータ2−0から集約経路(10.0.0.0/22)の利用不可を受信したことを示している。パス属性フィールド8cには、MED属性(10)と、経路種別を示すCommunity属性(100:300)とが格納されている。
図12(b)は、図12(a)のUPDATE情報8によって更新されたBGPテーブル54を示している。BGPテーブル54には、経路管理部53により図12(a)で示したUPDATE情報8が反映され、対応する行(レコード)が削除される。
図12(c)は、図12(b)のBGPテーブル54に基づいて更新された集約経路マッピングテーブル56を示している。
図12(d)は、広告用UPDATE情報81を示している。この広告用UPDATE情報81は、図12(a)に示すUPDATE情報8と同様である。
<パターン#5>
障害発生により、ルータ2−0で集約経路に含まれる詳細経路(10.0.1.0/24)が利用不可となった際の本実施形態のルートリフレクタ5の内部動作について、以下に示す。
経路受信部51は、各ルータ2から受信したUPDATE情報8を経路管理部53と経路計算部55とに転送する。
経路管理部53は、経路受信部51から受信したUPDATE情報8をBGPテーブル54に反映する。
経路計算部55は、UPDATE情報8で利用不可(Withdrawn)となった経路(10.0.1.0/24)を元に集約経路マッピングテーブル56を探索する。経路計算部55は、利用不可となった経路が集約経路に含まれ、かつ別の装置(この場合はルータ2−1)からも広告されており、かつ別の装置(ルータ2−1)から広告されている詳細経路のパス属性の優先度が利用不可となった経路の優先度よりも低いという条件を満たす時に、ブラックホール問題に該当すると判定する。このとき、別の装置(ルータ2−1)から広告されている詳細経路(10.0.1.0/24)を広告用UPDATE情報81に掲載して更新し、経路広告部52に転送する。
経路広告部52は、経路計算部55から転送された広告用UPDATE情報81をクライアントに広告する。
図13(a)〜(c)は、障害時かつ集約経路に含まれる詳細経路が利用不可であるパターン#5を示す図である。
図13(a)の1行目は各フィールド名を示し、2行目はルータ2−0(ルータ#0)から受信したUPDATE情報8を示している。
UPDATE情報8の2行目は、ルータ2−0からネットワークA(3a)の詳細経路(10.0.1.0/24)の利用不可を受信したことを示している。パス属性フィールド8cには、MED属性と、経路種別を示すCommunity属性とが格納されている。MED属性(10)は、ルータ2−0を介する利用不可の詳細経路が、現用系の優先度を持つことを示している。Community値(100:300)は、AS番号100においてポリシ値300が適用される経路であることを示し、よって集約経路(10.0.0.0/22)に属することを示している。
図13(b)は、図13(a)のUPDATE情報8によって更新されたBGPテーブル54を示している。BGPテーブル54には、経路管理部53により図13(a)で示したUPDATE情報8が反映され、対応する行(レコード)のが削除される。
図13(c)は、図13(a)のUPDATE情報8に基づいて更新された集約経路マッピングテーブル56を示している。集約経路マッピングテーブル56において、詳細経路(10.0.1.0/24)に係るレコードのWithdrawnフラグ欄56gに1が設定される。これにより、この詳細経路が削除されたことを示すことができる。
図13(d)は、広告用UPDATE情報81を示している。経路計算部55は、作成した集約経路マッピングテーブル56(図14(c)参照)に基づき、Withdrawnフラグ欄56gが1に設定された詳細経路よりも優先度の低い予備系の詳細経路を掲載した広告用UPDATE情報81を作成し、経路広告部52に転送する。経路広告部52は、経路計算部55から転送された広告用UPDATE情報81をクライアントに広告する。
<パターン#6>
障害発生により、ルータ2−0で集約経路に含まれない詳細経路(192.168.1.0/24)が利用不可となった場合の本実施形態のルートリフレクタ5の内部動作については、前記したパターン#3と同様となるため、記載を省略する。
<パターン#7>
障害発生後にその障害が回復し、集約経路(10.0.0.0/22)がルータ2−0で利用可となった際の本実施形態のルートリフレクタ5の内部動作については、前記したパターン#1と同様になるため、記載を省略する。
<パターン#8>
図13で示す障害時の状態の後に、その障害が回復し、ルータ2−0で集約経路(10.0.0.0/22)に含まれる詳細経路(10.0.1.0/24)が利用可となった際のルートリフレクタ5の内部動作について、以下に示す。
経路受信部51は、各ルータ2から受信したUPDATE情報8を経路管理部53と経路計算部55とに転送する。経路管理部53は、経路受信部51から転送されたUPDATE情報8をBGPテーブル54に反映する。
経路計算部55は、UPDATE情報8で利用不可(Withdrawn)となった経路(10.0.1.0/24)を元に集約経路マッピングテーブル56を探索し、利用可能となった経路(10.0.1.0/24)について集約経路マッピングテーブル56にて利用不可フラグが付与されている場合にブラックホール問題が解消したと判定し、この利用不可フラグを削除する。更に別の装置(ルータ2−1)から広告されている詳細経路(10.0.1.0/24)を、広告用UPDATE情報81のWithdrawnフィールド81bに掲載して更新し、経路広告部52に転送する。
経路広告部52は、経路計算部55から転送された広告用UPDATE情報81をクライアントに広告する。
図14(a)〜(d)は、障害回復時かつ集約経路に含まれる詳細経路が利用可であるパターン#8を示す図である。
図14(a)の1行目は各フィールド名を示し、2行目はルータ2−0(ルータ#0)から受信したUPDATE情報8を示している。
UPDATE情報8の2行目は、ルータ2−0からネットワークA(3a)の詳細経路(10.0.1.0/24)の利用可を受信したことを示している。パス属性フィールド8cには、MED属性と、経路種別を示すCommunity属性とが格納されている。MED属性(10)は、ルータ2−0を介する利用不可の詳細経路が、現用系の優先度を持つことを示している。Community値(100:300)は、AS番号100においてポリシ値300が適用される経路であることを示し、よって集約経路(10.0.0.0/22)に属することを示している。
図14(b)は、図14(a)のUPDATE情報8によって更新されたBGPテーブル54を示している。BGPテーブル54には、経路管理部53により図14(a)で示したUPDATE情報8が反映され、対応する行(レコード)が追加される。
図14(c)は、図14(a)のUPDATE情報8に基づいて更新された集約経路マッピングテーブル56を示している。集約経路マッピングテーブル56には、詳細経路(10.0.1.0/24)に係るレコードのWithdrawnフラグ欄56gが空白に設定される。これにより、この詳細経路(10.0.1.0/24)が追加されたことを示すことができる。
図14(d)は、広告用UPDATE情報81を示している。経路計算部55は、作成した集約経路マッピングテーブル56(図14(c)参照)に基づき、Withdrawnフラグ欄56gが空白に設定された詳細経路を掲載した広告用UPDATE情報81を作成し、経路広告部52に転送する。経路広告部52は、経路計算部55から転送された広告用UPDATE情報81をクライアントに広告する。
<パターン#9>
障害発生後に障害が回復し、ルータ2−0で集約経路に含まれない詳細経路(192.168.1.0/24)が利用可となった場合の本実施形態のルートリフレクタ5の内部動作については、<パターン#3>と同様となるため、記載を省略する。
図15は、登録、障害発生から回復までを示すシーケンス図である。
シーケンスQ10〜Q13は、ネットワークの登録を示すシーケンスである。ネットワークA(3a)が接続されると、大規模ネットワーク1は、シーケンスQ10,Q11の何れかを実行する。
シーケンスQ10において、第1のiBGPピアであるルータ2−0(ルータ#0)は、詳細経路(10.0.1.0/24)と集約経路(10.0.0.0/22)の利用可をルートリフレクタ5に広告する。
シーケンスQ11において、第2のiBGPピアであるルータ2−1(ルータ#1)は、詳細経路(10.0.1.0/24)と集約経路(10.0.0.0/22)の利用可をルートリフレクタ5に広告する。このとき、ルータ2−0は現用系であり優先度が高い。ルータ2−1は予備系であり優先度が低い。
シーケンスQ12において、ルートリフレクタ5は、ルータ2−0を送信元とする集約経路(10.0.0.0/22)の利用可をルータ2−2,2−3に広告する。
シーケンスQ13において、ルータ2−0,2−1は、ネットワークA(3a)のフローを、ルータ#0(ルータ2−0)経由に設定する。
シーケンスQ20〜Q23は、ネットワークの障害発生を示すシーケンスである。
シーケンスQ20において、ルータ2−0(ルータ#0)は、詳細経路(10.0.1.0/24)の障害を検知し、シーケンスQ21にてルートリフレクタ5に詳細経路(10.0.1.0/24)の利用不可を広告する。
シーケンスQ22において、ルートリフレクタ5は、ルータ2−1を送信元とする代替の詳細経路(10.0.1.0/24)の利用可をルータ2−2,2−3に広告する。
シーケンスQ23において、ルータ2−2,2−3は、ネットワークA(3a)のフローを、ルータ#1(ルータ2−1)経由である代替の詳細経路(10.0.1.0/24)に設定する。
シーケンスQ30〜Q33は、ネットワークの障害からの回復を示すシーケンスである。
シーケンスQ30において、ルータ2−0(ルータ#0)は、詳細経路(10.0.1.0/24)の障害からの回復を検知し、シーケンスQ31にてルートリフレクタ5に詳細経路(10.0.1.0/24)の利用可を広告する。
シーケンスQ32において、ルートリフレクタ5は、ルータ2−1を送信元とする代替の詳細経路(10.0.1.0/24)の利用不可をルータ2−2,2−3に広告する。
シーケンスQ33において、ルータ2−2,2−3は、ネットワークA(3a)のフローを、ルータ#0(ルータ2−0)経由である代替の詳細経路(10.0.1.0/24)に設定する。
図16と図17とは、ルートリフレクタ5の広告処理を示すフローチャートである。
いずれかのルータ2がルートリフレクタ5にUPDATE情報を送信したならば、図16のステップS10の処理が開始する。
ステップS10において、経路受信部51は、UPDATE情報8を受信する。経路受信部51は、このUPDATE情報8を経路管理部53と経路計算部55に転送する。
ステップS10において、経路管理部53は、このUPDATE情報8が利用可能経路に係るものであるか否かを判断し、当該判断条件が成立したならば(Yes)、ステップS12にてBGPテーブル54に経路情報を追加する。経路管理部53は、当該判断条件が成立しなかったならば(No)、図17のステップS30に進む。以下に示すステップS13〜S20の処理は、利用可能経路の更新に係るものである。
ステップS13において、経路計算部55は、経路の種別を判断して、集約経路ならばステップS14に進み、集約経路に属さない詳細経路ならばステップS16に進み、集約経路に属する詳細経路ならばステップS17に進む。
集約経路と判断した場合、経路計算部55は、ステップS14にて、この経路を集約経路マッピングテーブル56に集約経路として追加する。ステップS15において、経路広告部52は、集約経路に限定したUPDATE情報を広告し、図16と図17の処理を終了する。
集約経路に属さない詳細経路と判断した場合、経路計算部55はUPDATE情報8を広告用UPDATE情報81とし、ステップS16において、経路広告部52は、UPDATE情報8と同一である広告用UPDATE情報81を広告する。
集約経路に属する詳細経路と判断した場合、ステップS17にて経路計算部55は、この詳細経路に係る集約経路マッピングテーブル56のWithdrawnフラグ欄56gに1が設定されているか否かを判断する。経路計算部55は、当該判断条件が成立しないならば(No)、ステップS18において、この経路を詳細経路として集約経路マッピングテーブル56に追加し、図16と図17の処理を終了する。
経路計算部55は、ステップS17の判断条件が成立したならば(Yes)、ステップS19に進み、集約経路マッピングテーブル56のWithdrawnフラグ欄56gを0または空白に設定する。ステップS20にて、経路広告部52は、予備系ルータを介した代替の詳細経路の利用不可を広告し、図16と図17の処理を終了する。
図17は、ルートリフレクタ5の広告処理(その2)を示すフローチャートである。以下に示すステップS30〜S37の処理は、利用不可の経路の更新に係るものである。
ステップS30において、経路管理部53は、BGPテーブル54からこの経路情報を削除する。
ステップS31において、経路計算部55は、経路の種別を判断して、集約経路ならばステップS32に進み、集約経路に属さない詳細経路ならばステップS33に進み、集約経路に属する詳細経路ならばステップS34に進む。
ステップS31にて集約経路と判断した場合、経路計算部55は、ステップS32にて、この経路を集約経路マッピングテーブル56から削除して、UPDATE情報8を広告用UPDATE情報81とする。ステップS33にて経路広告部52が、この広告用UPDATE情報を広告し、図16と図17の処理を終了する。
ステップS31にて集約経路に属さない詳細経路と判断した場合、経路計算部55は、UPDATE情報8を広告用UPDATE情報81とし、ステップS33にて経路広告部52が、この広告用UPDATE情報を広告し、図16と図17の処理を終了する。
ステップS31にて集約経路に属する詳細経路と判断した場合、経路計算部55は、ステップS34にてこの詳細経路に他のルータ2を介した代替の詳細経路が有るか否かを判断する。経路計算部55は、当該判断条件が成立しないならば(No)、図16と図17の処理を終了し、当該判断条件が成立したならば(Yes)、ステップS35の処理に進む。
ステップS35において、経路計算部55は、この経路の代替経路の優先度の方が低いか否かを判断し、当該判断条件が成立しなかったならば(No)、図17の処理を終了する。当該判断条件が成立したならば(Yes)、経路計算部55は、ステップS36にて、この経路を集約経路マッピングテーブル56に追加してWithdrawnフラグを1に設定する。更にステップS37において、経路広告部52が、予備系ルータ2が代替する詳細経路の利用可を広告し、図17の処理を終了する。
(1) ルートリフレクタ5は、クライアントから受信した経路を、集約経路と、集約経路に含まれる詳細経路と、集約経路に含まれない詳細経路とに分類する。更に、集約経路と集約経路に含まれる詳細経路とのマッピングを実施し、新たに集約経路マッピングテーブル56を作成・保持し、ルートリフレクタ5自身が広告する集約経路と集約に含まれない詳細経路とを抽出して広告する機能を有している。
(2) ルートリフレクタ5は、障害発生時にクライアントから送付されるUPDATE情報から、発生した障害がブラックホール問題に該当するか否かを判断し、広告が必要な経路情報を抽出して広告する機能を有している。
(3) ルートリフレクタ5は、障害回復時にクライアントから送付されるUPDATE情報から、ブラックホール問題が解消したかを判定し、ブラックホール問題に該当する障害発生時に広告した経路情報を、利用不可な経路情報として広告する機能を有している。
(本実施形態の効果)
集約経路の広告と集約経路に含まれる詳細経路の経路広告を状況に応じてダイナミックに制御することにより、経路集約およびルートリフレクタ5を使用しつつ、特定の障害パターンにより発生するブラックホール問題を回避することが可能となる。
その結果、経路数の増大とiBGPピア数の増大を抑制することで、ルータ負荷の増大や経路数の増大が招くネットワーク品質の低下(ルータ処理能力の低下や経路数増加による障害時の切替時間の長期化等)や運用性の低下(経路数が多いことにより、切り分けが複雑化し、迅速な対応が困難となる等)を回避し、大規模ネットワークにおける最適な運用が可能となる。
(変形例)
本実施の形態に係るルートリフレクタは、前記したような処理を実行させるプログラムによって実現することができ、そのプログラムをコンピュータによる読み取り可能な記録媒体(CD−ROM等)に記憶して提供することが可能である。また、そのプログラムを、インターネット等のネットワークを通して提供することも可能である。
1,1A,1B 大規模ネットワーク
2,2−0〜2−3,2−10〜2−40 ルータ
2−0 ルータ (第1のiBGPピア)
2−1 ルータ (第2のiBGPピア)
3 ネットワーク
4 バックボーンネットワーク
41 ルータ
5 ルートリフレクタ
5B ルートリフレクタ
51 経路受信部
52 経路広告部
53 経路管理部
54 BGPテーブル
55 経路計算部
56 集約経路マッピングテーブル
56g Withdrawnフラグ欄
8 UPDATE情報
81 広告用UPDATE情報
9 障害
R0,Ra〜Rc,Rx 詳細経路
Fa〜Fc,FA フロー

Claims (8)

  1. 経路の利用可または利用不可に係るUPDATE情報をiBGP(internal Border Gateway Protocol)ピアから受信する経路受信部と、
    前記経路を集約経路、集約経路に含まれる詳細経路、集約経路に含まれない詳細経路のいずれかに分類し、前記集約経路と前記集約経路に含まれる詳細経路との対応を集約経路マッピングテーブルにて管理し、前記UPDATE情報および当該集約経路マッピングテーブルに基づき広告用UPDATE情報を計算する経路計算部と、
    前記経路計算部が計算した前記広告用UPDATE情報を、他のiBGPピアに広告する経路広告部と、
    を備えており、
    前記経路計算部は、
    前記経路受信部により、同一の集約経路に含まれる同一の詳細経路の利用可に係るUPDATE情報を第1のiBGPピアおよび第2のiBGPピアから受信したのちに、前記第1のiBGPピアから当該詳細経路の利用不可に係るUPDATE情報を受信し、かつ、前記第2のiBGPピアの当該詳細経路の優先度が前記第1のiBGPピアの当該詳細経路の優先度よりも低いならば、前記第2のiBGPピアの当該詳細経路の利用可に係る広告用UPDATE情報を計算する、
    ことを特徴とするルートリフレクタ。
  2. 前記経路計算部は、
    前記経路受信部により、同一の集約経路に含まれる同一の詳細経路の利用可に係るUPDATE情報を第1のiBGPピアおよび第2のiBGPピアから受信したのちに、前記第1のiBGPピアから当該詳細経路の利用不可に係るUPDATE情報を受信し、かつ、前記第2のiBGPピアの当該詳細経路の優先度が前記第1のiBGPピアの当該詳細経路の優先度よりも低いならば、前記集約経路マッピングテーブルにおける前記第1のiBGPピアの当該詳細経路に利用不可フラグを設定する、
    ことを特徴とする請求項1に記載のルートリフレクタ。
  3. 前記経路計算部は更に、
    前記経路広告部により前記第2のiBGPピアから受信した詳細経路の利用可に係る広告用UPDATE情報を他のiBGPピアに広告した後に、前記経路受信部により前記第1のiBGPピアから当該詳細経路の利用可に係るUPDATE情報を受信したならば、前記第2のiBGPピアの当該詳細経路の利用不可に係る広告用UPDATE情報を計算する、
    ことを特徴とする請求項1に記載のルートリフレクタ。
  4. 前記経路計算部は更に、
    前記経路広告部により前記第2のiBGPピアから受信した詳細経路の利用可に係る広告用UPDATE情報を他のiBGPピアに広告した後に、前記経路受信部により前記第1のiBGPピアから当該詳細経路の利用可に係るUPDATE情報を受信したならば、前記集約経路マッピングテーブルにおける前記第1のiBGPピアの当該詳細経路に設定された利用不可フラグを消去する、
    ことを特徴とする請求項3に記載のルートリフレクタ。
  5. 前記経路計算部は、
    前記UPDATE情報のCommunity値により、前記経路を集約経路、集約経路に含まれる詳細経路、集約経路に含まれない詳細経路のいずれかに分類する、
    ことを特徴とする請求項1に記載のルートリフレクタ。
  6. 前記経路計算部は、
    前記経路受信部によりiBGPピアから集約経路に含まれる詳細経路の利用可に係るUPDATE情報を受信したならば、前記経路広告部に広告させない、
    ことを特徴とする請求項1に記載のルートリフレクタ。
  7. 経路の利用不可または利用可に係るUPDATE情報をiBGP(internal Border Gateway Protocol)ピアから受信する経路受信部と、
    前記経路を集約経路、集約経路に含まれる詳細経路、集約経路に含まれない詳細経路のいずれかに分類し、前記集約経路と前記集約経路に含まれる詳細経路との対応を集約経路マッピングテーブルにて管理し、前記UPDATE情報および当該集約経路マッピングテーブルに基づき広告用UPDATE情報を計算する経路計算部と、
    前記経路計算部が計算した前記広告用UPDATE情報を、他のiBGPピアに広告する経路広告部と、
    を備えるルートリフレクタが実行する経路制御方法であって、
    前記経路受信部により、同一の集約経路に含まれる同一の詳細経路の利用可に係るUPDATE情報を第1のiBGPピアおよび第2のiBGPピアから受信するステップと、
    前記第1のiBGPピアから前記詳細経路の利用不可に係るUPDATE情報を受信するステップと、
    前記経路計算部により、前記第1のiBGPピアで利用不可となった詳細経路と同じ詳細経路が前記第2のiBGPピアから広告されており、かつ前記第2のiBGPピアの前記詳細経路の優先度が前記第1のiBGPピアの前記詳細経路の優先度よりも低いか否かを判断するステップと、
    前記判断が成立したならば、前記第2のiBGPピアの前記詳細経路の利用可に係る広告用UPDATE情報を計算するステップと、
    前記経路広告部により、前記広告用UPDATE情報を、他のiBGPピアに広告するステップと、
    を含むことを特徴とするルートリフレクタの経路制御方法。
  8. 前記経路広告部により前記第2のiBGPピアから受信した前記詳細経路の利用可に係る広告用UPDATE情報を他のiBGPピアに広告した後に、前記経路受信部により前記第1のiBGPピアから当該詳細経路の利用可に係るUPDATE情報を受信するステップと、
    前記経路計算部により、前記第2のiBGPピアの前記詳細経路の利用不可に係る広告用UPDATE情報を計算するステップと、
    前記経路広告部により、前記広告用UPDATE情報を、他のiBGPピアに広告するステップと、
    を含むことを特徴とする請求項7に記載のルートリフレクタの経路制御方法。
JP2015025244A 2015-02-12 2015-02-12 ルートリフレクタおよびルートリフレクタの経路制御方法 Active JP6307031B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2015025244A JP6307031B2 (ja) 2015-02-12 2015-02-12 ルートリフレクタおよびルートリフレクタの経路制御方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2015025244A JP6307031B2 (ja) 2015-02-12 2015-02-12 ルートリフレクタおよびルートリフレクタの経路制御方法

Publications (2)

Publication Number Publication Date
JP2016149634A JP2016149634A (ja) 2016-08-18
JP6307031B2 true JP6307031B2 (ja) 2018-04-04

Family

ID=56691760

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015025244A Active JP6307031B2 (ja) 2015-02-12 2015-02-12 ルートリフレクタおよびルートリフレクタの経路制御方法

Country Status (1)

Country Link
JP (1) JP6307031B2 (ja)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010178310A (ja) * 2009-02-02 2010-08-12 Kddi Corp 経路制御システムおよび経路制御装置
JP2011087302A (ja) * 2009-10-19 2011-04-28 Ip Infusion Inc Bgp経路監視装置、bgp経路監視方法、およびプログラム
JP5913146B2 (ja) * 2013-02-05 2016-04-27 日本電信電話株式会社 現用系ルータ装置、通信システム、経路制御方法、及びプログラム

Also Published As

Publication number Publication date
JP2016149634A (ja) 2016-08-18

Similar Documents

Publication Publication Date Title
US7532631B2 (en) Method and apparatus for accelerating border gateway protocol convergence
US8687522B2 (en) Distributed storage of routing information in a link state protocol controlled network
US20210203562A1 (en) System and method to recover from link or node failure in a network
US8243588B2 (en) Disaster recovery for active-standby data center using route health and BGP
TW202026901A (zh) 在網路路由環境中的獨立資料儲存空間
US8908676B2 (en) Automatically detecting best paths from shadow route reflectors
US20070008880A1 (en) Router redundancy in data communication networks
EP2974166B1 (en) Method and apparatus for ip/mpls fast reroute
US9143431B2 (en) Hiding a service node in a network from a network routing topology
EP1461882A2 (en) Method and system for topology construction and path identification in a two-level routing domain operated according to a simple link state routing protocol
JP2011053918A (ja) ネットワークシステム、ネットワーク中継装置、それらの制御方法
US9531598B2 (en) Querying a traffic forwarding table
JP7306642B2 (ja) ループ回避通信方法、ループ回避通信デバイスおよびループ回避通信システム
US11431619B2 (en) Hierarchical ECMP control plane for dense topologies
US9160648B2 (en) Content-centric network and method of performing routing between domains therefor
US8364822B2 (en) VPN communication control device, communication control method in VPN, and virtual dedicated network management device
EP2991288B1 (en) Method and device for determining next hop and distributing routing information
CN109412942B (zh) 云网传输路由方法和系统
JP6307031B2 (ja) ルートリフレクタおよびルートリフレクタの経路制御方法
US20080212585A1 (en) Preventing Loops during Recovery in Network Rings Using Cost Metric Routing Protocol
US20240243997A1 (en) Synchronization for border gateway protocol (bgp) processes
TW202232920A (zh) 網路運算環境之最佳路徑運算卸載系統及其方法與非暫態電腦可讀取儲存媒體
CN115622937A (zh) 一种基于不相交路径的路由保护方法及相关设备
WO2003049340A2 (en) Method and system for topology construction and path identification in a two-level routing domain operated according to a simple link state routing protocol
JP2005020603A (ja) 経路制御方法、そのデータ集約装置および経路制御システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170307

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180125

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180306

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180309

R150 Certificate of patent or registration of utility model

Ref document number: 6307031

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150