前話で、隣の AS と話を始めるためには両側の明示的な合意が必要であることに出会った。BGP のピアは、両側で相手を指定して初めて成立する関係。両側で相手の IP と AS 番号を明示的に config し、両方の意思表示が一致して初めてセッションが成立する関係。成立したセッションは TCP の上で 1 対 1 の会話を維持し、その上を経路情報が流れていく、というところまで来た。

けれど、前話の最後で、あなたの手元には、もうひとつの問いが置かれていた。

eBGP セッションが成立して、隣の AS から経路情報を受け取った。けれど、その経路情報は、自分の AS の中の他のルータには、どうやって行き渡るのだろう。AS の中で外の経路を知る必要があるのは、境界ルータだけではないはず。中継ルータも、ゲートウェイの役割を持つルーターも、外の経路を知らなければ、結局は外と通信できない。境界ルータが受け取った経路は、その先で、どう扱われるのだろう。

本話で、その問いに正面から向き合う。

仮に、境界ルータが受け取った経路を、AS の中の他のルータにも行き渡らせたいとしたら、何の仕組みを使えばいいだろうか。AS の中で経路を共有する仕組みは、すでに前のシリーズで学んでいる。OSPF だ。同じ AS の中なら、OSPF で運べばいいのだろうか。それとも、もっと別の発想だろうか。

先に、本話の手土産だけ置いておく。これは、OSPF で運ぶ話ではなかった。

AS の中で外の経路を配布する仕組み = iBGP。外から来た経路を、AS の中の BGP ルータ全員に行き渡らせる、もう一段の BGP セッション関係。

考えてみよう

本論に入る前に、5 秒だけ自分の頭で先に置いてみてほしい。前話で、隣の AS と eBGP セッションを成立させて経路情報を受け取る入口まで来た。けれど、その経路情報が、自分の AS の中の他のルータにどう行き渡るかは、まだ見えていない。さて、AS の中で経路を共有する仕組みは、すでに前のシリーズで学んでいる — OSPF だ。OSPF で外の経路を運べばいい、と素朴に予想したくなるかもしれない。本当にそれで動くだろうか。手探りで構わない、自分なりの答えを 5 秒だけ置いてみてほしい。本話の §2 で、その予想に揺さぶりがかかる。

1. 境界の手元にだけ、経路がある — 中まで行き渡らせる必要

その問いに正面から向き合う前に、AS の中で誰がどんな役割を持っているかを、もう一度整理しておきたい。

AS 65001 の中には、境界ルータ R3 がいる。R3 は AS の境に立ち、隣の AS 65002 の境界ルータ R-X と eBGP セッションを成立させる側。前話で見たセッション確立の主役。

境界ルータの内側には、他のルータがいる。中継ルータ R2 は、AS の中で経路を中継する役割。境界ルータが受け取った経路を、内側のルータに向かわせるための中継点。内部ルータ R1 は、AS の内側の端末(あなたの業務 PC など)を直接つなぐ側。5F セグメントのデフォルトゲートウェイとして、AS の内側の世界の端に立っている。

外と通信する必要があるのは、境界ルータだけではない。中継ルータも、外宛のパケットが通る道として、外の経路を知る必要がある。内部ルータも、AS の内側の端末が外と通信するためには、外の経路を知る必要がある。

ところが、前話で eBGP セッションを成立させて経路を受け取ったあと、その経路は 境界ルータ R3 の手元にだけ ある状態だった。R1 と R2 はまだ知らない。

この状態のままだと、何が起きるか。

AS の内側の端末から外への通信が始まったとして、内部ルータ R1 が外の経路を知らないので、外宛のパケットの宛先が分からない。中継ルータ R2 にパケットが流れてきたとしても、R2 もまだ外の経路を知らないので、どこへ送ればいいかが見えない。境界ルータ R3 まで届いたら、ようやく外の経路が手元にあるので、隣の AS へ送り出すことができる。

でも、これは厳しい状況。AS の中の他のルータが、自分のところまでパケットが流れてきたときに「どこへ送ればいいか分からない」という状態は、現実には成り立たない。中継ルータも、内部ルータも、最初から外の経路を持っていなければ、AS の内側の端末は外と通信できない。

だから、境界ルータが受け取った経路を、AS の中の他のルータにも行き渡らせる仕組みが必要になる。中継ルータも、内部ルータも、外の経路を知る必要がある。

これが本話の出発点。

ポイント: 境界ルータが eBGP で外から経路を受け取った直後、その経路は境界ルータの手元にだけある状態。中継ルータも、内部ルータも、まだ知らない。けれど、AS の中で外と通信する必要があるのは境界ルータだけではない。中継ルータも、内部ルータも、外の経路を知る必要がある。だから、境界ルータが受け取った経路を、AS の中の他のルータにも行き渡らせる仕組みが必要になる。

2. OSPF で運ぶ、という素朴な発想 — そして、その先

ここで素朴な発想が立ち上がる。

AS の中で経路を共有する仕組みは、すでに前のシリーズで学んでいる。OSPF だ。同じ AS の中で、リンクの状態を全員で共有して、地図を作る仕組み。同じ AS の中の R1 / R2 / R3 は、OSPF で互いに繋がり、内側の地図を持っている。

ならば、境界ルータが外から受け取った経路を、OSPF で運べばいいのではないか。

この問いに正面から向き合いたい。

OSPF で学んだことを思い出す。OSPF は『AS の中のリンクの状態を全員で共有して、内側の地図を作る』ことが仕事だった。AS の中のどこに、どんなリンクが張られていて、それぞれのコストはいくらか、を全員で共有する。最短経路を求める。これが OSPF の世界。

ここで、外から来た経路は何を持っているか。隣の AS から受け取ったその経路には、AS の境界の先の宛先(ある AS のあるネットワーク)がある。これは OSPF の地図とは違う種類の情報。OSPF の地図は AS の内側のリンクの状態を表すための仕組みなので、外から来た経路は別の枠組みで運ぶ必要がある。

OSPF の枠組みでこの経路を運ぶと、こうなる。OSPF の地図は『AS の中のリンクの状態』を表現するために設計されている。外から来た経路は、その表現には収まらない別の種類の情報を持っている。OSPF で運ぼうとすると、OSPF の地図に収まらない情報がそぎ落とされてしまう。

もうひとつの理由がある。OSPF は、AS の内側の規模に最適化されている。AS の中で動く前提だから、扱える地図のサイズも、AS の内側の規模に収まる。外から来た膨大な経路を OSPF に流すと、OSPF が動くための前提が壊れる。少し前に見た 3 つの前提が崩れる場所と、同じ構造。

だから、OSPF で運ぶ、という素朴な発想は、構造的に成立しない。

OSPF は『AS の中の地図』を作る仕事として設計されている。外から来た経路を運ぶ仕事ではない。

では、AS の中で外の経路を運ぶには、どうすればいいか。

答えは、すでに手元にある。前話で学んだ両側合意のセッション確立の作法を、もう一度使えばいい。

AS の中の BGP ルータ同士で、もう一度 BGP のセッションを結ぶ。R3 と R1、R3 と R2 の間に、BGP のセッションを張る。これは前話で見た eBGP と同じ作法 — 両側で相手の IP と AS 番号を明示的に config し、両方の意思表示が一致して初めてセッションが成立する。違うのは、相手が同じ AS の中にいるという文脈だけ。

この『同じ AS の中の BGP ルータ同士で結ばれる BGP セッション』には、名前がある。

iBGP — internal BGP、内部 BGP。前話で見た eBGP(external BGP)に対して、AS の境を越えない、AS の内側で結ばれる BGP セッション。同じ BGP プロトコルを使うが、結ぶ相手が同じ AS の中であるという点が違う。

境界ルータ R3 が eBGP で外から経路を受け取ったあと、R3 と R1 / R3 と R2 の間に張られた iBGP セッションを通じて、その経路が AS の中に流れていく。中継ルータ R2 も、内部ルータ R1 も、iBGP 経由で外の経路を受け取る。これで、AS の中の BGP ルータ全員が外の経路を知る状態になる。

本話の核心は、この『AS の中でもう一段結ぶ BGP セッション = iBGP』という発想。前話で身につけた両側合意のセッション確立を、AS の中でもう一度繰り返す。同じ作法、ただし相手は同じ AS の中。外から来た経路を、AS の内部に配布する。

ここでひとつ、補足しておきたい。iBGP で内部ルータが外の経路を受け取ったとき、その経路には『次にどこへ送ればいいか』の情報も付いてくる。けれど、その『次にどこ』は、AS の境界の先 — 隣の AS の境界ルータ — を指していることがある。内部ルータ R1 から見て、その『次にどこ』に到達するためには、AS の中のルーティングで到達できる必要がある。AS の中の到達は、OSPF(IGP)が担当する世界。

つまり、OSPF と iBGP は、片方だけでは動かない。OSPF が AS の中を地図にしてくれているから、iBGP で受け取った経路の『次にどこ』に AS の中で到達できる。OSPF と iBGP は、AS の中で別の仕事を分担しながら、互いに支え合っている。

ポイント: OSPF で外の経路を運ぶ、という素朴な発想は構造的に成立しない。OSPF は『AS の中のリンクの状態の共有』を担う仕事として設計されており、外から来た経路を運ぶ仕事ではない。代わりに、AS の中の BGP ルータ同士でもう一段の BGP セッション = iBGP(internal BGP)を結ぶ。前話で身につけた両側合意のセッション確立の作法を、AS の中でもう一度繰り返す。同じ作法、ただし相手は同じ AS の中。外から来た経路を、AS の内部に配布する。OSPF と iBGP は、AS の中で別の仕事を分担しながら、互いに支え合っている。

3. リンクの状態の共有、AS 内部配布、AS 境界接点 — 役割分担の全体像

ここで、視点を一段引いてみる。

同じ AS の中で、複数のプロトコルが動いている。OSPF と iBGP。さらに、AS の境界では eBGP も動いている。3 つの仕組みが、それぞれ何の仕事をしているのかを整理したい。

OSPF — AS の中のリンクの状態の共有

OSPF の仕事は、AS の中のリンクの状態を全員で共有して、内側の link-state database を作ること。同じ AS の中のすべてのルータが、互いに Hello を投げ合って自動的に繋がり、内側の link-state database を持つ。運んでいるのは、AS の内側のリンクの状態。

iBGP — 外から来た経路の AS 内部配布

iBGP の仕事は、AS の中で外から来た経路を AS 内部に配布すること。同じ AS の中の BGP ルータ同士で、両側の明示的な合意で成立した BGP セッションを通じて、外から受け取った経路を AS の中の他のルータに伝える。運んでいるのは、外の AS から来た経路情報。

eBGP — AS 境界の経路交換接点

eBGP の仕事は、AS の境界の経路交換接点として、隣の AS とセッションを成立させること。異なる AS のルータ同士で、両側の明示的な合意で結ばれる BGP セッション。前話で見た境界セッション確立の主役。運んでいるのは、外の AS から来た経路情報の入口。

3 つを並べて見えてくるもの

この 3 つを並べると、見えてくるものがある。

OSPF と iBGP は、どちらも同じ AS の中で動いている。けれど、運んでいるものが違う。OSPF が運ぶのは『AS の内側のリンクの状態』、iBGP が運ぶのは『外の AS から来た経路情報』。同じ AS の中で動いているから一見似ているように見えても、別の仕事を分担している。

eBGP と iBGP は、どちらも BGP プロトコルを使う。同じ作法の両側合意でセッションを結ぶ。けれど、結ぶ相手が違う。eBGP は異なる AS のルータ同士、iBGP は同じ AS の中の BGP ルータ同士。同じ BGP でも、結ぶ相手と運ぶ目的が違う。

OSPF / iBGP / eBGP の役割分担を 1 文で言うなら、こうなる。

OSPF は『中のリンクの状態の共有』、iBGP は『外から来た経路の AS 内部配布』、eBGP は『AS 境界の経路交換接点』。

同じ AS の中で複数のプロトコルが、それぞれ別の仕事を分担しながら動いている。これが、AS の中の経路情報の流れの構造。

フルメッシュ — AS の中の BGP ルータ全員と握り合う

iBGP の最小モデルを、もう少し具体的に見ておきたい。

AS 65001 の中に R1 / R2 / R3 の 3 台の BGP ルータがいる場面を想像する。R3 は境界ルータで、AS 65002 の R-X と eBGP セッションを成立させる側。R1 と R2 は AS の内側で動く。

AS の中の BGP ルータ全員が外の経路を知る必要があるなら、R1 と R2 と R3 の間でどう iBGP セッションを張ればいいか。

最小モデルは、全員が互いに iBGP セッションを張り合う こと。

• R1 と R2 の間に iBGP
• R1 と R3 の間に iBGP
• R2 と R3 の間に iBGP

3 台で 3 本のセッション。三角形の関係。これを フルメッシュ と呼ぶ。AS の中の BGP ルータが全員、互いに直接 iBGP セッションを張り合う構造。

フルメッシュは素朴で分かりやすい。AS の中の BGP ルータが全員、互いに直接セッションを成立させるので、外から来た経路は全員に届く。境界ルータが受け取った経路は、iBGP のフルメッシュを通じて、AS の中の BGP ルータ全員に行き渡る。

規模が増えると、別の組み立て方が必要になる

フルメッシュには、ひとつの性質がある。AS の中の BGP ルータの数が増えると、関係の数が 二次のオーダー で増える。3 台なら三角形の関係で済む。けれど台数が増えると、必要な関係の数はルータの数より速く増えていく。

小さい AS なら、フルメッシュで十分。けれど、AS の中の BGP ルータの数が増えていくと、関係の数の増え方が現実的でなくなる場面がある。そういう場面では、フルメッシュとは別の組み立て方が必要になる。

ここで、別の組み立て方の具体的な仕組みには踏み込まない。本話で受け取りたいのは、『フルメッシュが素朴な最小モデル / 規模が増えると別の組み立て方が必要になる場面がある』という構造の存在まで。具体的な解は、別の旅で扱う。

ポイント: OSPF / iBGP / eBGP は、それぞれ別の仕事を分担している。OSPF は『中のリンクの状態の共有』、iBGP は『外から来た経路の AS 内部配布』、eBGP は『AS 境界の経路交換接点』。同じ AS の中で複数のプロトコルが、それぞれ別の役割で動いている。iBGP の最小モデルは、AS の中の BGP ルータ全員が互いにセッションを張り合うフルメッシュ。3 台なら 3 本、シンプル。ただし規模が増えると関係数が二次で増えるため、別の組み立て方が必要になる場面もある(具体的な解は別の文脈で扱う)。

4. iBGP の役割分担が、AS 内部の経路配布を完成させる

本話の手土産を、自分の言葉で 1 度だけ置き直す。

前話で、隣の AS と eBGP セッションを成立させて経路情報を受け取る入口に立ったとき、もうひとつの問いが残されていた。受け取った経路は、自分の AS の中の他のルータにどう行き渡るのか。本話で出会ったのは、その問いへの最初の具体的な答えだった。

OSPF で運ぶ、という素朴な発想は構造的に成立しない。OSPF は『AS の中のリンクの状態の共有』を担う仕事として設計されている。外から来た経路を運ぶ仕事ではない。

代わりに、AS の中の BGP ルータ同士でもう一段 BGP セッションを結ぶ。同じ作法 — 両側の明示的な合意 — で成立する BGP セッション。ただし相手は同じ AS の中。これが iBGP(internal BGP)。境界ルータが受け取った経路は、iBGP のセッションを通じて、AS の中の他のルータに配布される。

OSPF と iBGP と eBGP は、それぞれ別の仕事を分担している。OSPF は『中のリンクの状態の共有』、iBGP は『外から来た経路の AS 内部配布』、eBGP は『AS 境界の経路交換接点』。同じ AS の中で複数のプロトコルが、それぞれ別の役割で動いている。

iBGP の最小モデルは、AS の中の BGP ルータ全員が互いにセッションを張り合うフルメッシュ。3 台なら 3 本、シンプル。規模が増えると関係数が二次で増えるため、別の組み立てが必要になる場面もあるが、それは別の文脈で扱う。

本話であなたの手元に残るのは、この構造に集約される。

AS の中で外の経路を配布する仕組み = iBGP。外から来た経路を、AS の中の BGP ルータ全員に行き渡らせる、もう一段の BGP セッション関係。

この 1 行は、境界ルータが受け取った経路が AS の中で全員に届く構造を支える。あなたは今、AS 内部の経路配布の入口に立っている。AS の中の BGP ルータ全員が、外の経路を持っている状態になった。

ポイント: 本話であなたの手元に残るのは「AS の中で外の経路を配布する仕組み = iBGP」の 1 行。OSPF が外の経路を運ぶ仕事ではないこと、AS の中の BGP ルータ同士で同じ作法のセッションをもう一段結んで外の経路を AS 内部で配布する関係、OSPF / iBGP / eBGP の役割分担、フルメッシュの最小モデルと規模の渇り、を腹に置く。

OSPF / iBGP / eBGP の三分担を、明日の現場の語彙にする

AS の中で外の経路を配布する仕組み = iBGP。前話で身につけた BGP セッション確立の作法を、AS の中でもう一段繰り返す関係まで、腹に置けた。OSPF は中のリンクの状態の共有を担う仕事として設計されており、外から来た経路を運ぶ仕事ではないこと、OSPF / iBGP / eBGP の役割分担、フルメッシュの最小モデル、規模が増えると別の組み立てが必要になる場面もあることも、見えた。

明日、自分の手元に残るのは、次の 3 行だ。

「AS の中で外の経路を配布する仕組み = iBGP。前話で身につけた BGP セッション確立の作法を、AS の中でもう一段繰り返す関係。同じ作法、ただし相手は同じ AS の中」

「OSPF は『中のリンクの状態の共有』、iBGP は『外から来た経路の AS 内部配布』、eBGP は『AS 境界の経路交換接点』。同じ AS の中で複数のプロトコルが、それぞれ別の仕事を分担している」

「iBGP の最小モデルは、AS の中の BGP ルータ全員が互いにセッションを張り合うフルメッシュ。規模が増えると関係数が二次で増えるため、別の組み立て方が必要になる場面もある」

明日、現場で iBGP という言葉に出会ったら、まず一旦立ち止まってほしい。OSPF と同じ感覚で受け取る前に、それが『AS の中で外から来た経路を AS 内部に配布する仕組み』だ、ということを思い出してほしい。「OSPF で運べばいい?」「境界ルータだけが知っていればいい?」「フルメッシュのセッション数は?」 — どの観点も、OSPF のリンクの状態の共有とは違う、AS 内部の経路配布の入口で見るべき場所。

けれど、AS 内部に配布された経路情報の中身を見ると、もうひとつの問いが立ち上がっている。

外から受け取った経路は、自分の AS の中で配布できるようになった。AS の中の BGP ルータ全員が、外の経路を持っている状態になった。けれど、その経路がどこから来て、どの AS を通ってきたのかは、どうやって伝えられているのだろう。隣の AS だけから来たのか、その隣の AS を経由してきたのか。経路情報には、どこから来たかの目印が付いているのだろうか。

その問いに、次の話が正面から向き合う。本話で受け取った『AS の中で外の経路を配布する仕組み = iBGP』を、次の話への足場として手元に残してほしい。

次は、経路情報に付随する『出自の証跡』に踏み込む。