顧客サイトAの CE から、離れた顧客サイトBの CE へ通信が向かう。

図の真ん中には provider backbone があり、入口と出口に PE がいる。その内側に P ルータが並んでいる。

途中にいる P ルータは、顧客Aの経路も、顧客Bの経路も、全部知っているのだろうか。もしそうなら、provider backbone の中にある全ての中継装置が、顧客ごとの経路表を背負うことになる。

BGP/MPLS IP VPN の要点は、顧客ごとの状態を PE 側で扱い、P ルータには VPN routes を背負わせないことにある。

顧客が増えるたびに全ての中継装置へ経路を広げると、provider backbone の読み方が重くなる。だから顧客の状態を入口に寄せて、中継は中継の仕事に絞る。

顧客と向き合うのは、backbone 全体ではない

CE は顧客サイト側にいる。顧客の拠点、顧客の LAN、顧客の routing policy に近い場所だ。

PE は provider 側の入口にいる。CE から見ると、ここで provider に通信を預ける。provider から見ると、ここで「どの顧客から来た通信か」を受け取る。

P ルータは、そのさらに内側にいる。顧客の CE と直接向き合う入口ではなく、provider backbone の中を進める中継側だ。

顧客サイトAの CE は、provider の PE と向き合う。顧客サイトBの CE も、別の PE と向き合う。顧客サイトAと顧客サイトBの CE が、provider backbone の中で直接 routing peer になるわけではない。

顧客の経路を受け取り、別の顧客や別の site と混ざらないように扱う入口は PE だ。backbone 全体が、顧客ごとの routing policy を同じ粒度で持つわけではない。ここを取り違えると、P ルータまで顧客の経路を全部知っているはずだ、という読み方になる。

PE は、顧客ごとの表を見る

PE は、顧客ごとの VRF を持てる。VRF は、同じ装置の中で forwarding table を分けるための入れ物だ。顧客Aから来た通信は顧客Aの表で見る。顧客Bから来た通信は顧客Bの表で見る。同じ 10.0.0.0/8 という表記が出てきても、どの顧客の入口から来たかで意味が変わる。

PE は、CE から受け取った通信を、どの入口から来たかに基づいて適切な VRF へ入れる。そこで宛先を見て、どの site へ向けるべきかを判断する。

別の PE に接続された site へ届ける必要があるなら、PE 間で VPN route を扱う。ここで BGP が出てくる。BGP は顧客ごとの route を PE 間で配るために使われる。

どの route をどの VPN に入れるか、どの site に見せるか、といった細かい policy はたしかに重要だ。ただ、この入口では一段だけ手前に止める。顧客ごとの表と VPN route を扱う主な場所は PE であり、P ルータではない。

PE は顧客の近くで細かく見る。P ルータは、その細かさを同じようには持たない。

P ルータが知らないことには意味がある

もし provider backbone の全ルータが、全顧客の VPN routes を持つとしたらどうなるか。

新しい顧客が増えるたびに、顧客ごとの経路が backbone の中継装置へ広がっていく。顧客の site が増えるたびに、P ルータの経路表にも顧客の細部が増えていく。障害時に図を見る人も、どの装置が顧客ごとの経路を持っているのかを毎回追う必要が出る。それは、provider backbone の中継に持たせたい仕事ではない。

だから P ルータは、顧客の VPN routes を知らなくてよい。顧客Aの site 宛て prefix、顧客Bの site 宛て prefix、顧客ごとの policy を、P ルータが一つひとつ持つ必要はない。

途中で転送する装置なのに、顧客の宛先を知らないと進められないのではないか。そう思うのは自然だ。けれど P ルータは、provider backbone の中で packet を次へ送るための情報を見る。宛先の PE へ進むための provider 側の到達性や、backbone 内で使う転送上の印を扱う。

顧客の細部を知らないことと、provider backbone の中継として何も知らないことは違う。入口の PE は、顧客ごとの VRF と VPN route を扱う。出口の PE は、受け取った通信を適切な顧客側へ戻す。途中の P ルータは、顧客の宛先表ではなく、provider backbone の中で次へ送る仕事に寄る。

顧客の状態は PE に置き、P ルータは provider backbone の転送に集中する

ここまでで、顧客の通信を分けて運ぶ骨格が見えてくる。同じ L3VPN の図を、見る順番を決めて読み直せる。

まず CE と PE の境界を見る。顧客サイトの CE が provider の PE と向き合っている。次に、PE の中で顧客ごとの VRF を見る。顧客Aと顧客Bの表が分かれている。PE 間で VPN route が配られることを見る。最後に、P ルータは顧客の細部ではなく backbone の中継側に残る。

P ルータが VPN routes を知らないのは欠落ではない。顧客の文脈を入口の PE が受け持つから、中継は provider backbone を次へ進める仕事に集中できる。同じ顧客が何拠点に増えても、中継装置の経路表に顧客の細部は積み上がらない。

まだ、通る道を細かく指定する話には入っていない。今残すのは、顧客状態は PE 側、backbone の中継は P 側という分担だけでよい。通る道を先に決めたい場合、どこに状態と制約が増えるのか。