BGPのSoOを真面目に考えてみる

YUKA150701558664_TP_V

CCIEのBlueprintにMPLS/MP-BGP/VPNv4がありまして、その中にBGPのSite of Origin(SoO)の概念があります。

この記事では、このBGPのSoOについて考察していきます。自分の備忘録も兼ねて(こういうパケットの流れとかが重要な設定は覚えるのが難しい。STP/RSTPとかも・・・)

EIGRPのSoOじゃなくて、BGPのSoOです。EIGRPのSoOについて理解を深めたい方は以下のINEのPDFを読んでください。非常に有用です。

INEのEIGRPのSoO資料

ちなみに、この記事は私がCiscoPressやINEなどの情報をもとに結論付けたものなので、仮に間違っていた場合は是非教えてください。記載しているファクトは全て実機検証しましたが、そもそもユースケースから間違っていたとかあったら教えてください。

この記事は、出来るだけ文章を冗長に書いています。テクニカルな説明をするときに・・・・がとか・・・をの部分を省略すると、具体的なフローとか本質がぼやけてしまうので。なので、少しうざったいくらい冗長に書いてるかもですけど、お許しください。

スポンサーリンク
レクタングル大

はじめに:BGPのSoOって詳しいドキュメントがほとんどない

最近、CCIEの復習のために、MP-BGP関係を集中的にやっています。INEのビデオとかCertGuideを読み直すことによって、RDとかRTとか、CCIEの勉強をしている時よりもさらに理解が深まってきました。やっぱり復習って重要です。ITの知識って、ドキュメントを読み直すほど理解が深まります。

で、今回のトピックのSoOですが、前述の通りEIGRPのではなくて、BGPのSoOです。

BGPのSoOってドキュメントがほとんどないんですよね。EIGRPのSoOはINEのブログ(PDF)でそれなりに分かりやすいのがあるのですが(上のやつ)、BGPのSoOで本質的な用途の記載がされているものがほとんど見つかりませんでした。

殆どのドキュメントは「BGPのSoOはCEのallowas-inを使っている時に、PE側で設定することによって、プレフィックスのループを防ぐ」とかのレベルしか書いていません。そんなことは分かっているんですけど・・・もう少し、どんなケースで利用するかが知りたいんですけど。

見つからなかったので、自分で検証してみました。

BGPのCE-PEプレフィックス交換についてのおさらい

念のため、おさらいしておきます。

今回の話は、CE-PE間のプレフィックス交換の話です。PE-PE間のiBGPによるプレフィックス交換の話ではありません。MP-BGPのトピックを話す時、この2つの違いを理解する事は非常に重要ですし、基本です。

CE-PE間のプレフィックス交換をBGP(原則eBGP)で行う時の課題を説明します。

具体的にどんな時かと言うと。

CEとPE間のプレフィックス交換をBGP(原則eBGP)を使って行います。さらに、Customerの拠点が複数あるなどの場合、かつ各拠点のBGPのASが同一だった場合。この条件が合致したとします。

文章で書くと分かりにくいと思いますので、絵で描いてみます。こんな場合です。

IMG_0052

この時、特に特別な設定をしなければ、A拠点のプレフィックスはB拠点のCE2で受け取りません。なぜなら、PE2にA拠点のプレフィックスが到着した時点で、A拠点のプレフィックスには既にCustomerのAS(65000)が属性として付与されているので、BGPのループ防止(自ASの属性が付与されているプレフィックスは受け取らない)メカニズムによってCE2のBGPがA拠点のプレフィックスを拒否するからです。

IMG_0053

CE2で「debug ip bgp update」を入力しプレフィックスのアップデートが見えるようにして、「clear ip bgp * in」とかでPE2からのアップデートを再度要求すれば、以下のメッセージが表示されます。こんな感じで既に自分のASが付与されたプレフィックスは受信を拒否します。

じゃあ、どうやってCE2(もしくはその逆)でA拠点のプレフィックスを受け入れるのか?ですが、大きく2つの方法があります。

CE側にてallowas-inする

CE側のルーター(今回はCE1/CE2)でallowas-inをPEへのneighborステートメントで設定します(neighbor x.x.x.x allowas-inみたいな感じ)。これを設定すると、設定したネイバーから受け取ったプレフィックスの属性に自ASが含まれていても、気にせずBGP-Tableに入れてくれます

IMG_0054

つまり、allowas-inはCustomer側で行う設定です。

PE側にてas-overrideする

PE側のルーター(今回はPE1/PE2)でas-overrideを設定します。これを設定すると、CE側にプレフィックスを送信するときに、まず送信するプレフィックスのAS群を見ます。仮に、AS群の中に送信するCE側のAS番号が含まれていたら、その番号をPEのASに置換(Replace/Override)します。

IMG_0055

つまり、as-overrideはISP側で行う設定です。

allowas-inとas-overrideはどちらか1つでよい

上記のコンセプトが理解出来たら、どちらかの設定だけでよい(拠点間でのBGPを利用したプレフィックスのやりとりができる)ことがわかるはずです。

私のSoOの勘違い

ここまでは、多分CCIEを勉強していると誰でも知っている事かと思います。私もここまではすんなりと理解できました。

でも、SoOの理解が難しかった。SoOの理解というよりも、どんな時にSoOを使うか?が分からなかったので、本質的なコンセプトを理解出来なかったのです。

殆どのドキュメントには「CE側でallowas-inするときに、PE側でSoO設定をすることによって、ループを防ぐことが出来る」と書いています。

でも、ループってプレフィックスループの事?データループの事?どんなときにそんな状況が発生するの?ってところを具体的にかいている資料がない(見つからなかった)。

SoOはPE-PE間でプレフィックスをやり取り数と気のVPNv4プレフィックスに含める事によって、対向側PEで同一SoOプレフィックスをCE側に送りません。でも、そもそも、CEはプレフィックスを別拠点から受け取りたいのに、そのミッションが達成できないではないか。とか考えていました。

その時に私が頭の中に想像していたトポロジは、これです。

IMG_0056

ドキュメントによっては、「拠点間を別のリンクでバックドアを持っている場合」とか書いていました。iBGPとかIGPとかで。でも、実際にそういうトポロジを作ってみたのですが、どうしてもルーティングループを作り出すことが出来ませんでした。

その時のトポロジが、これです。

IMG_0057

で、さらに色々調べた結果、以下のリンクを見つけました。

上記のモハメドさんの発言

The BGP- SOO is a loop prevention mechanism for MULTIHOMED Site to the MPLS backbone, or for a sites that are single homed to the MPLS Backbone but share a backdoor link between them.

ふむふむ、なるほど!拠点内でマルチホームをしているケースか。と、閃いたわけです。

マルチホームでのVPNの場合に利用する・・らしい

つまり、以下のようなトポロジです。INEのトポロジを拝借してます。GNS3での再現なので、G1/XXはG1/0.XXに読み替えてください。

IMG_0061

また、通常のINEトポロジに以下のループバックを加えています。

  • R10:lo10(10.10.10.10/32)
  • R2:lo2(2.2.2.2/32)
  • R9:lo9(9.9.9.9/32)

上記はCustomer内のIGP(OSPF)に含めています。このループバック間での通信で検証して行きます。

念のため、全RTのコンフィグを残しておきますね。(今回の内容に関連するところだけ。なので、DMVPNとかは除く)

R1:

R2:

R3:

R4:

R5:

R6:

R7:

R8:

R9:

R10:

CE(R7,R3,R8)は全てallowas-inしています。

試しに、R9(lo9)からR10(lo10)にtraceしてみます。これは、MPLSコアを通って拠点2のPE(R5)経由でR10に届くはず。

美しいですね!

次に、R9(lo9)からR2(lo2)へtraceしてみます。これは、同じ拠点内(R9-R7-R3-R2)を通るはず。通るはず?

残念ながら、ループしました。ループしたので最後は切りました。でも、ついにループを作ることに成功しました!現実だと怖いけど、問題を再現出来たのでまずは一歩前進です。

では、なぜループしたのか?です。

traceの結果を見たところ、R9-R7-R3までのルーティングは正しく見えます。そのあとに、R1にルーティングしているのがおかしいです。R3はR2にルーティングしないと。

では、なぜR3はR1にルーティングしているのか?

それを確認する為に、R3の情報を見てみます。

初めの出力は、R3のBGP-Tableです。結果は明らかですね。R3からみたR2(2.2.2.2)の向きがR1側になっていますね!

つまり、プレフィックス(R2の2.2.2.2/32)の交換が以下の流れで行われました。データじゃないですよ。プレフィックスの交換です。
・(OSPF)R2->R3
・(OSPF)R3->R7
(OSPF redistribute to BGP)R7->R6
・(BGP)R6-R1。厳密にはRoute reflector経由だけど今回のトピックの本質じゃないので割愛。
・(BGP)R1-R3

つまり、R7がIGP経由でR3からR2のプレフィックス(R2の2.2.2.2/32)を受信し、BGP-Tableに入れちゃった。これは、自分でBGP-Tableに挿入したルートだからWeightが32768になってベストパスになる。R7はベストパスのR2プレフィックスをピアであるR6に広報する。回り回ってそのプレフィックスがR6経由でR3に到達した。

絵的にはこんな感じ?(どんどん汚くなってきた)

IMG_0062

ちなみに、これはR7やR3がプレフィックスを受信するタイミングによって挙動が変わります。例えば、R7のOSPFをリセットすると、R7はR3からOSPFで受信するR2の経路より先にR6からBGPで受信するR2の経路をBGP-Tableに入れます。そして、Routing-TableにもR6経由のR2プレフィックス(2.2.2.2/32)が入ります。

この後に、R7でOSPFが有効化されたとします。OSPFがR3経由のR2プレフィックスをRouting-Tableに入れようとします。しかし、すでに上述のとおりeBGP経由(R6経由)のR2のプレフィックスがRouting-Tableに入っています。OSPFとeBGPだと、eBGPの方がAD値が低い(20<110)。なので、OSPFのプレフィックスはRouting-Tableに入れれません。R7はR2の経路としてR6をルーティングテーブル上示すようになります。すると、今度はISP経由でパケット(データ)が流れます。

以下は、R7のOSPFをリセットした後のR7のBGP-TableとR9からTraceを実行した結果です。

結果的に、Traceは成功していますが、これは期待した結果ではありません。期待した結果はIGPを利用した拠点内ルーティングですから。

他にもBGP/OSPFの動作でどちらが先にRouting-Tableにルートを入れるかによってさまざまなケースが考えられます。が、要するに上記の通りループが発生するケースがあります。Brian的に言うと、unexpected conditionってとこでしょうか。

では、本質的な問題が何かと言うと、そもそもR7がR6経由でR2の経路(2.2.2.2/32)を受信すること自体がおかしいんです。R7とR3は拠点Aのデュアルホーム目的でPEに繋がっています。

R7はISP経由でR10のプレフィックスは欲しいです。R2のプレフィックスは貰ってはいけないです。

それを実現するためにSoOがある(はず・・)です。考えてみたら名前も「Site of Origin」ですからね。Customer of Originでもなく、Site(拠点)ですから。

後は、どこにでも書いているSoOの内容です。

SoOを付ける方法ですが、これは「拠点ごと」にユニークなSoO値をPEに設定します。こんな感じです。

R6:

R1:

R5:

R5の方(拠点B)はデュアルホームではないので、SoOは設定不要ですが、方針を合わせるという意味で設定しておきました。

これを設定する事で、PEであるR1はR6から来た拠点Aの経路(主にR9のプレフィックス9.9.9.9/32)をCEであるR3側に送りません。また、PEであるR6はR1から来た拠点Aの経路(主にR2のプレフィックス2.2.2.2/32)をCEであるR7に送りません。でも、R1とR6はR5から来た拠点Bの経路(主にR10)は受信して後ろのCE(R3/R7)に送ります。

SoOは以下のコマンドで確認できます。

Extended Communityの個所にSoOがありますね。

SoOを設定した後(念のため、clear ip bgp * をするとなお良し。本番ではダメですよ。)、R7のBGP-Tableを見てみます。

R2のプレフィックス(2.2.2.2/32)はR3から(IGPのプレフィックスを挿入)しかありませんね。つまり、R6から回り回って届いたR2のプレフィックスはなくなりました。

では、R9からR2へ、再度Traceをかけてみます。

OKです!拠点AのIGPでルーティングが完結しました。

デュアルホームを設定している目的は、CEであるR7かR3のどちらかがISP(PE)に繋がらなくなった時に、別の経路から別拠点と通信できる事です。SoOを設定していても、もちろんこれは実現されます。R9から再度R10へtraceかけてみます

R7のR6向きのインターフェース(g1/0.67)をshutしてみます。これで、CEであるR7はPEであるR6との経路がなくなりました。

BGPタイマーを調整していないので3分待ちます。3分後再度traceしてみると・・・

もともとはR7->R6経由でR10へルーティングされていたのが、R7->R3->R1->コア->以下省略の流れになりました。成功です。

IMG_0063

結論:SoOは拠点毎にマルチホームするときに有用

マルチホーム構成だと、拠点内のプレフィックスがISP経由で周ってくる可能性があります。SoOを設定するとこの課題のワークアラウンドになります。

詳しい人、教えて欲しいのですが、これってつまり、例えばR7-R3間の経路が切れたとして、するとR9->R2の通信はできなくなると思うのですが、それは仕方ない(コア間を経由出来ない)ということですよね?

何度も言いますが、これ以外にSoOが有効なユースケースや、私の検証で間違っていることが合ったら教えてくださいね。

あ、あと「お前のこの記事良かったよ!」って感想があればコメントください。久しぶりにCCIEネタを気合い入れて書いてみたので・・・

勉強を再会する方へ
スポンサーリンク
レクタングル大
  • このエントリーをはてなブックマークに追加