顧客Aの経路表にも、顧客Bの経路表にも、同じ 10.10.0.0/16 がある。

企業内ネットワークだけを見ていると、この行は少し不穏に見える。同じ宛先が二つあるなら、どちらかが間違っている。どちらかを変えないと、packet は行き先を決められない。そう読みたくなる。

けれど provider の立場では、顧客Aの 10.10.0.0/16 は顧客Aの拠点を指し、顧客Bの 10.10.0.0/16 は顧客Bの別の拠点を指している。文字列は同じでも、顧客が違えば宛先の意味が違う。

同じ IPv4 prefix は、provider backbone の中で一つの意味に潰して読めない。PE は顧客ごとの文脈で packet を読む必要がある。

これは、provider が顧客の address plan を一つに統一してから通信を預かるわけではないからだ。別々の顧客が、それぞれの都合で同じ private address を使っていても、その両方を同じ backbone の上で扱う必要がある。企業内ネットワークなら、同じ address が重なった時点で設計を直す話になりやすい。けれど provider にとって最初に必要なのは、prefix を書き換えることではなく、同じ prefix をどの顧客の文脈で読むのかを分けることだ。

入口で表を分けると、同じ prefix の衝突が消える

前話で見た CE / PE / P の境界を思い出すと、今回の違和感は PE の入口で起きている。CE は顧客側にいて、PE は provider 側で顧客の通信を受け取る入口にいる。顧客Aの CE から入った packet と、顧客Bの CE から入った packet が、同じ宛先 prefix を持って PE に届くことがある。このとき PE が宛先 prefix の文字列だけを見ると、10.10.0.0/16 という行が顧客Aの支社なのか、顧客Bのデータセンターなのかを決められない。

ここで出てくるのが VRF だ。VRF は、PE が持つ顧客ごとの forwarding table として見ると分かりやすい。ひとつの大きな経路表に全顧客の prefix を放り込むのではなく、顧客の入口ごとに見る表を分ける。

顧客Aの CE から PE に packet が入ると、PE はその packet がどの入口から来たかを見る。顧客A用の入口から来たなら、顧客A用の VRF で宛先を探す。そこで見つかる 10.10.0.0/16 は、顧客Aの宛先を指す。顧客Bの CE から同じ宛先 prefix の packet が入れば、今度は顧客B用の VRF で探し、そこにある 10.10.0.0/16 は顧客Bの宛先を指す。prefix の文字列は同じでも、検索している表が違う。だから意味も違う。

VRF は単なる名前の飾りではない。PE が packet を受け取った瞬間に、どの顧客の表で宛先を読むかを決める実際の分かれ目になる。だから同じ 10.10.0.0/16 が二つあっても、PE の中では同じ行として衝突しているわけではない。顧客Aの VRF にある行と、顧客Bの VRF にある行として、別々に置かれている。

PE 間で運ぶときは、prefix に識別子を添える

VRF で入口の読み方は分けられた。では、顧客Aの別サイトへ向かう経路を、遠くの PE へどう伝えるのか。

PE の中では、顧客A用の VRF と顧客B用の VRF に分けて同じ prefix を置ける。けれど PE 同士で経路を運ぶとき、どちらもただの 10.10.0.0/16 として並べてしまうと、同じ宛先への候補に見えてしまう。顧客Aの 10.10.0.0/16 と顧客Bの 10.10.0.0/16 は、実際には別の system へ向かう別 route だ。それを同じものとして比較して片方だけを選ぶと、もう一方の顧客の宛先へ届かなくなる。

そこで PE 間で運ぶ経路には、IPv4 prefix だけではなく、別 route として扱うための識別子を添える。その形が VPN-IPv4 だ。IPv4 prefix に RD を組み合わせることで、同じ 10.10.0.0/16 でも、顧客A側の route と顧客B側の route を別々に運べる。

VRF は、PE が packet をどの表で読むかを分ける。VPN-IPv4 は、PE 間で経路を運ぶときに、同じ IPv4 prefix を別 route として見せる。RD は、その区別を作るために IPv4 prefix へ添える識別子だ。

RD は同じ IPv4 prefix を別 route にするための識別子

RD という名前を見ると、顧客を識別する札のように読みたくなる。現場でも「この顧客の RD」のように言うことがある。けれど最初の理解では、そこへ寄せすぎない方がいい。

RD は route の出どころを説明する札ではない。どの顧客へ配るかを決める札でもない。どの VRF へ入れるかの policy をここで全部背負っているわけでもない。RD がしているのは、同じ IPv4 prefix を別 route として並べられるようにすることだ。顧客Aの 10.10.0.0/16 と顧客Bの 10.10.0.0/16 は、IPv4 prefix だけなら同じに見える。RD を添えると、PE 間で運ぶ経路としては別々の VPN-IPv4 route になる。

その route をどの VRF へ入れるか、どの顧客サイトへ届かせるかには、別の policy が関わる。今は、RD を「同じ prefix を別 route にするための識別子」として止めておく。RD に顧客分離のすべてを背負わせると、VRF、VPN-IPv4、配布 policy の役割が混ざってしまう。最初は、役割を小さく分けて読む。

顧客を分けたあと、provider backbone ではどこを見て転送するのか

冒頭の 10.10.0.0/16 は、顧客Aにもあり、顧客Bにもあった。文字列だけなら同じ行に見えても、provider はまず顧客の文脈を混ぜず、PE は顧客ごとの VRF で宛先を読み、PE 間では RD を添えた VPN-IPv4 route として同じ prefix を別々に運ぶ。同じ IPv4 prefix が別の顧客で別の意味を持っても矛盾しないのは、この三段で読み分けているからだ。

残っている問いは、ひとつだけでいい。こうして分けた顧客の文脈を、provider backbone の中でどう運ぶのか。