前話で、OSPF が AS の中で動けたのは、3 つの前提(地図を共有してくれる仲間 / 揃った管理ポリシー / 扱える規模)が揃っていたから、そして AS の境を越えると、その 3 つがすべて崩れることに出会った。3 つの前提と 3 つの場所は 1 対 1 で対応していて、独立にあるのではなく、OSPF の動作が依拠していた前提が境で同時に崩れる構造だった。

地図とは違う発想で組み上がる仕組みが要る。そこまで、見えた。

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

AS と AS は、具体的にどんな関係を結んで経路を伝え合っているのだろう。地図を共有しない者同士で経路を伝え合うとは、どんな取り決めの形をしているのだろう。3 つの前提が崩れる場所では、3 つの場所のどれにも対応できる別の組み立て方が必要になるはず。その組み立て方は、どんな姿をしているのだろう。

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

仮に、隣の AS と話を始めようとしたら、最初に何をすればいいだろうか。OSPF の Hello のように、自動で隣を見つけるのだろうか。それとも、もっと別の発想だろうか。

先に、本話の手土産だけ置いておく。これは、自動発見の話ではなかった。

BGP のピアは、両側で相手を指定して初めて成立する関係。

考えてみよう

本論に入る前に、5 秒だけ自分の頭で先に置いてみてほしい。前話で、AS の境では地図を共有する前提が崩れることに出会った。では、隣の AS と話を始めるためには、何が必要だろうか。OSPF の Hello のように、自動で隣を見つけるのだろうか。それとも、もっと別の発想だろうか。手探りで構わない、自分なりの答えを 5 秒だけ置いてみてほしい。本話の §1 で、その予想に揺さぶりがかかる。

1. 自動発見が成立しない場所 — Hello は同じ管理範囲の中だけ

その問いに正面から向き合う前に、前のシリーズで身についた感覚を一度だけ呼び戻したい。

OSPF の neighbor 関係は、どう成立していたか。ルータが自分のインターフェースから Hello packet を multicast で投げる。同じセグメントにいる他の OSPF ルータが、その Hello を受け取って応答する。双方向通信が確認されると、neighbor 関係が成立する。

あなたが config したのは「OSPF を動かす」という最小限の宣言だけだった。隣のルータを名指しで指定する必要はなかった。「私はここにいる」を勝手に投げる挨拶。同じセグメントの仲間が拾ってくれる前提で、関係が始まる。

これは、当たり前に動いていたわけではなかった。

前話で確認したとおり、Hello が自動で成立する裏側には、ひとつの前提があった。同じ管理範囲の中の仲間。同じ AS の中、同じ運用ルールの下、地図を共有してもいい仲間同士。その範囲でのみ、Hello は自動で関係を作ることができた。

AS の境を越えると、その前提が崩れる。

隣の AS は、別の運用主体。あなたが「私はここにいます」を勝手に投げ合っても、相手は「あなたと話します」とは決めていない。相手は相手の運用方針で、誰と経路を伝え合うかを自分で決めたい。あなたが片側で勝手に決めて関係を作る発想は、相手の自律 — 自分の管理範囲は自分で決める — に反する。

だから、AS の境を越えるための取り決めは、自動発見ではなく、別の発想で組み上がる必要があった。両側の管理者が「あなたと話します」と明示的に同意して、初めて関係が始まる。

その『AS の境を越えるための取り決め』として組み上がった仕組みには、名前が与えられている。

BGP — Border Gateway Protocol、境界ゲートウェイプロトコル。前話の最後で『地図とは違う発想で組み上がる仕組み』として抽象的に予告した、その仕組みの正体。BGP は AS と AS の間で経路情報を伝え合うために設計された。

本話で、BGP の最初の姿 — 隣の AS とのセッション確立(両側で相手を指定して合意する関係) — に正面から向き合う。

ポイント: OSPF の Hello は『同じ管理範囲の中の仲間』が前提で自動成立した。AS の境を越えるとその前提が崩れるため、自動発見は成立しない。代わりに必要なのが『両側の明示的な合意』という別の発想。AS の境を越えるための取り決めとして組み上がった仕組みが BGP。

2. 隣の AS とセッションを成立させる — eBGP の最小モデル

AS 65001 の境界ルータ R3 が、隣の AS 65002 の境界ルータ R-X と関係を結ぶ場面を想像してみる。

R3 と R-X は、別の AS のルータ。同じ管理範囲の中にはいない。Hello のように自動では繋がらない。

では、どうやって関係を結ぶのか。

R3 の側で、相手を明示的に指定する。「相手は AS 65002 の R-X、IP は 203.0.113.2」と config する。これは「私は R-X と話す約束をします」という意思表示。

けれど、それだけでは関係は成立しない。

R-X の側でも、同じ意思表示が必要だ。「相手は AS 65001 の R3、IP は 10.1.1.3」と config する。「私は R3 と話す約束をします」という意思表示。

両側の意思表示が一致して、初めて関係が始まる。

この関係には名前がある。eBGP — external BGP、外部 BGP。異なる AS のルータ同士で結ばれる BGP セッションを、こう呼ぶ。R3 と R-X の間に結ばれる関係は、eBGP セッションの最小モデル。

ここで、関係を結ぶ相手のことを ピア (peer) と呼ぶ。R-X は R3 から見たピア、R3 は R-X から見たピア。両側が互いに『ピア』として相手を指す関係。BGP の世界では、neighbor という語と peer という語が交換可能に使われることが多い。

けれど、OSPF の neighbor が Hello で自動成立する関係だったのに対して、BGP の peer は両側の明示的な合意で成立する関係。同じ単語を使っていても、関係の作り方は根本的に違う。

だから、本話では場面の補助として『握る』『握手』という言葉を併用したい。BGP のピアは、両側で相手を指定して、両側が「あなたと話す約束をします」を交わすことで成立する。橋渡しのイメージとしての握手は、両側で同時に手を伸ばさなければ完成しない、と言い換えてもいい。

ここで大事なのは、セッション確立は 両側で相手を指定し合って、初めて成立する ということ。

仮に、R3 の側だけが「相手は R-X」と config して、R-X の側がまだ「相手は R3」と config していなかったとしたら、何が起きるか。

R3 が R-X に向かって「会話を始めましょう」と試みても、R-X 側はその会話を受け付ける準備をしていない。または、トランスポートのレベルでは到達しても、BGP のレベルで「あなたをピアとして登録していません」と弾かれる。R3 の手元では、セッションが「成立していない」状態のまま、何度も試みが続く。

反対側だけが指定しても、同じこと。両側が同時に相手を指定し合って、ようやくセッションが成立する。これが、明示的な合意による関係の根本的な性質。

セッションが成立したあとは、そのセッションの上で 1 対 1 の会話が維持される。BGP はこの会話を、TCP の上に乗せて動かす。OSPF が IP の上に直接乗っていたのとは違う設計。信頼性のあるトランスポート(順序保証 / 再送 / フロー制御)を TCP に任せて、BGP 本体は経路情報の交換のロジックに集中する。

なぜ TCP の上に乗せるか、という問いに正面から踏み込むことは本話ではしないけれど、向きだけ置いておきたい。経路情報を流す会話では、途中で欠けたり順序が崩れたりしたときに、下の層で回復できる枠組みがほしい。その順序保証と再送の土台を TCP に任せている。BGP 本体は、その土台の上で経路情報の交換のロジックに集中できる。

具体的なポート番号や TCP の細部は、本話の射程からは外しておく。本話で受け取りたいのは、『TCP の上で 1 対 1 の会話を維持する関係』という構造まで。

成立したセッションの上を、経路情報が流れていく。BGP の世界では、その経路情報の伝達は Update という名前で運ばれる。けれど、Update の中身が具体的にどんなフォーマットで、どんな情報を含んでいるかは、本話の射程外。本話で受け取りたいのは、『成立したセッションの上を、経路情報が流れていく』という構造まで。

ポイント: eBGP は、異なる AS のルータ同士で結ばれる BGP セッション。両側で相手の IP と AS 番号を明示的に config し、両方の意思表示が一致して初めてセッションが成立する。BGP のピアは、両側で相手を指定して初めて成立する関係。片側の合意だけではセッションは成立しない。成立したセッションは TCP の上で 1 対 1 の会話を維持し、その上を経路情報が流れていく。

3. Hello と eBGP セッション確立 — 同じ「隣を見つける」でも、根本が違う

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

OSPF の Hello と BGP の eBGP セッション確立は、どちらも『隣との関係を作る』という機能を持つ。同じカテゴリに属しているように見える。実際、neighbor / peer という語が両方の世界で使われている。

けれど、その作り方は根本的に違う。

違いを 5 つの軸で並べてみる。

軸 1: 発見方法

OSPF の Hello は、自動。Hello packet を multicast で投げ、相手が拾って応答する。ルータの側で、隣を名指しで指定する必要はない。同じセグメントの誰かが拾ってくれる前提で動く。

BGP の eBGP セッション確立は、手動。両側で相手の IP と AS 番号を明示的に config する。「あの人と話す」を両方が決めて、初めて関係が始まる。

軸 2: 前提

OSPF の Hello の前提は、同じ管理範囲の中の仲間。地図を共有してもいい関係、運用方針が揃っている関係。同じ AS の中で動く前提だから、自動発見が成立する。

BGP の eBGP セッション確立の前提は、異なる管理主体(AS)同士。それぞれが自分の運用方針を持ち、内側を見せたくない関係。だから、両側の合意がない限り、関係は始まらない。

軸 3: 関係の数

OSPF の Hello は、N 対 N の関係を作る。マルチアクセス LAN 上で動く OSPF なら、セグメントにいるすべてのルータが互いの隣として登録される。一度の Hello のやりとりで、複数の neighbor 関係が同時に成立する。

BGP の eBGP セッションは、1 対 1 の関係。R3 と R-X の間で結ばれるのは、まさに R3 と R-X の関係だけ。別のルータと話したければ、別のセッションを別途結ぶことになる。

軸 4: トランスポート

OSPF の Hello は、IP の上に直接乗る。OSPF プロトコルは IP の上で動くことを前提に設計されている。

BGP のセッションは、TCP の上で 1 対 1 の会話を維持する。信頼性のあるトランスポートを TCP に任せ、BGP 本体は経路情報の交換のロジックに集中する。

軸 5: 失敗の形

OSPF の Hello は、Hello が届かなければ neighbor 不成立。物理的にリンクが切れた、セグメントが壊れた、あるいは認証や area 設定が一致しなかった、といった理由で Hello が届かなければ、関係は始まらない。

BGP の eBGP セッション確立は、片側の合意だけでは成立しない。両側で config が揃っていない、相手の IP / AS 番号が一致しない、トランスポートの到達性が片方向しか確保されていない、といった理由で、どちらか片側が相手を指定していなければ、セッションは成立しない。

5 軸の失敗の形を並べると、見える違いは「届いていないのか / 受け入れられていないのか」という性質の差だ。OSPF の Hello の失敗は、たいてい『届いていない』として現れる。物理レイヤや一致設定の不備で、挨拶そのものが相手のところに到達しない。一方、BGP の eBGP セッション確立の失敗は、『届いてはいるが、相手側で自分を登録していない』としても起こりうる。あなたの方は試みているのに、相手側で「あなたを話す相手として登録していない」状態のままだと、セッションは宙ぶらりんで止まる。同じ『関係が作れない』でも、見るべき場所がずれるのは、そのため。

5 軸を並べて見えてくるもの

5 つの軸を並べて見ると、OSPF の Hello と BGP の eBGP セッション確立は、機能の名前は似ていても、作り方も性質も根本的に違うことが見えてくる。

違いの根は 1 つ。

管理範囲の中 vs 管理範囲を越える。

同じ管理範囲の中の仲間との関係は、自動で結べる。別の管理主体との関係は、両側の明示的な合意でしか結べない。

Hello は『私はここにいる』を投げる。eBGP セッション確立は『あなたと話す』を両側で交わす。

ポイント: OSPF Hello と BGP の eBGP セッション確立は、どちらも『隣との関係を作る』機能を持つが、根本的に違う関係。発見方法 / 前提 / 関係の数 / トランスポート / 失敗の形の 5 軸で性質が分かれる。違いの根は『管理範囲の中 vs 管理範囲を越える』。同じ管理範囲の中の仲間とは自動で結べる、別の管理主体とは両側の明示的な合意でしか結べない。

4. BGP ピアの成立 — 両側で相手を指定して初めて関係が始まる

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

前話で OSPF の前提が AS の境で同時に崩れることに出会ったとき、地図とは違う発想で組み上がる仕組みが必要だ、というところまで来た。本話で出会ったのは、その『地図とは違う発想で組み上がる仕組み』の最初の姿だった。

BGP — Border Gateway Protocol。AS の境を越えるための取り決め。BGP の最初の関係は、eBGP — 異なる AS のルータ同士で結ばれる BGP セッション。

その関係は、自動発見では成立しなかった。両側で相手の IP と AS 番号を明示的に config して、両方の意思表示が一致して、初めてセッションが成立する。BGP のピアは、両側で相手を指定して初めて成立する関係。片側の合意だけではセッションは成立しない。成立したセッションは TCP の上で 1 対 1 の会話を維持し、その上を経路情報が流れていく。

OSPF の Hello と BGP の eBGP セッション確立は、機能の名前は似ていても、作り方も性質も根本的に違う。Hello は『私はここにいる』を勝手に投げる挨拶、eBGP セッション確立は『あなたと話す』と両側で交わす合意。違いの根は『管理範囲の中 vs 管理範囲を越える』にあった。

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

BGP のピアは、両側で相手を指定して初めて成立する関係。

この 1 行は、AS の境を越える経路の伝え合いが、両側の明示的な合意の上に組み上がっていることを支える。あなたは今、eBGP セッション成立の入口に立っている。成立したセッションの上で、ここから経路情報が流れ始める。

ポイント: 本話であなたの手元に残るのは「BGP のピアは、両側で相手を指定して初めて成立する関係」の 1 行。両側の明示的な合意で成立する 1 対 1 の関係、OSPF Hello との根本的な違い、片側の合意だけではセッションは成立しないこと、合意済みのセッションが TCP の上で 1 対 1 の会話を維持することを腹に置く。

eBGP ピアの作法を、明日の現場へ持ち帰る

BGP のピアは、両側で相手を指定して初めて成立する関係。両側の明示的な合意で初めて成立する関係まで、腹に置けた。OSPF Hello との根本的な違い、片側の合意だけではセッションは成立しないこと、合意済みのセッションが TCP の上で 1 対 1 の会話を維持することも、見えた。

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

「BGP のピアは、両側で相手を指定して初めて成立する関係。両側で相手の IP と AS 番号を明示的に config し、両方の意思表示が一致して初めてセッションが成立する」

「OSPF の Hello と BGP の eBGP セッション確立は、5 軸で根本的に違う関係。違いの根は『管理範囲の中 vs 管理範囲を越える』にある」

「片側の合意だけではセッションは成立しない。両側で相手を指定し合って、ようやく関係が始まる」

明日、現場で BGP のピアという言葉に出会ったら、まず一旦立ち止まってほしい。OSPF の neighbor と同じ感覚で受け取る前に、それが両側の明示的な合意で成立する関係だ、ということを思い出してほしい。「片側だけ config したか」「相手の IP と AS 番号は両側で揃っているか」「相手側でも自分のことを設定し終えたか」 — どの観点も、同じ管理範囲の中の自動成立とは違う、eBGP セッション成立の入口で見るべき場所。

けれど、AS の境界の内側からは、もうひとつの問いが立ち上がっている。

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

その問いに、次の話が正面から向き合う。本話で受け取った『BGP のピアは、両側で相手を指定して初めて成立する関係』を、次の話への足場として手元に残してほしい。

次は、AS の内部での経路配布の仕組みに踏み込む。