フルラインルーター






延命策３：
フルラインルーターの開発
フルラインルーターとは、筆者（＝岡島）の造語ですが、 ようは、40億個に経路が爆発しても問題のないルーターです。 （というか、もともと40億個固定的に経路を持っている） ここに関しても、別紙にまとめてあります。
なお、私事を申せば、これが、新しい概念であることに私は驚きましたね。 電子工学的にはきわめて常識的なことをいっているだけなんですが、 どうも、だれも電子工学の初歩の初歩すら知らないようです。


フルラインルーター
定義：
「Dest IP ： 出力先I/F番号」のインデックスを4G個持っているルーター。
利点：
経路集約が不要になる。
欠点：
特になし。
解説：
通常、TCP/IPのルーティングでは、ツリー状の ルーティングテーブルを作りますよね。 H/W的には、TCAMとかいう変なメモリをつかって。 で、なんで、ツリー状にルーティングテーブルを作るか、というと、 これは、インターネット創世記のころ、メモリが少なかったからなんですよ。 IPアドレスの数だけ要素数のある配列を用意すれば、ツリーなんて不要ですが、 そんなのはその当時は不可能。 でも、いまなら簡単 ようは、4Gbyte のルーティングテーブルを作ればいいんですよ。
正確に言えば、この場合、インターフェースの数が129-256本の場合ですが、 そんなことはどうでもいいですし、 もっというと、気合で、16Gbyte ルーティングテーブルのルータを作れば、 I/F40億本いけます。いらねぇけど。 なお、ルーティングテーブル、という言い方は正しいかどうか微妙で、 インデックス、というほうがいいような気がする。 ようは、Dest IPから、パケット送出先のイーサポートの番号を引いてくる インデックスです。
これを 4G個用意すれば、いわゆるTCAM溢れなんて考える必要性はなくなります。
C の適当コードで適当に説明すれば、
static uchar array[1<<32];

inline int get_if( uint32 IP)
{
	return array[IP];
}
こんな感じ？
とにかく、ツリー構造なんて作らなくても、メモリ4G浪費しちゃえばOKなんです。





細かいこと：
実際には、各スイッチチップで、4096エントリとかをキャッシュすべきでしょう。 4Gのインデックスは一個だけにして、 そのなかで必要な部分をスイッチチップでキャッシュ。 普通のルータにおける、TCAMとキャッシュの関係と同じですな。 あと、この4Gメモリですが、ルータ専用特別製超高速SRAM とかが 必要なるかもしれず、 ギガバイト単価は、対DRAM比で100倍ぐらいになるかも。 といっても、DRAMが ギガバイト1000円時代のいま、そんなのどーでもいいとおもいますけどね。 超高速SRAM 4GB っていっても、100万円以下で買えるでしょ。
で、重要なのは、これはIXでフルメッシュ張ってる 超高速ルータにしかいらないわけで、 そして、そんなルータ、どうせ何千万円とするわけで、 ようは、せいぜい100万円の部品コストなんて 激しくどうでもいいんです。 第一、いまの方式なら、TCAMとかいう変な連想メモリっぽい部品が必要で、 これが量産効果がまったくなくすげぇ高い、 と聞いたんですが、どうなんでしょう。 そうなると、TCAM廃止によりかえって安くなったら笑いますね。


・ BGPの再計算をどうやるんだ？
実は、このルータ（というか、正確に言えば、 サマらないことによる経路爆発）には、 ひとつだけ未解決の問題点があります。 それは、BGP（に限らず、とにかく、ルーティング情報配布プロトコル）に 関する、ルーティングテーブルの 再計算が爆発する可能性（あくまで可能性だけど）があることです。
まず、とりあえず言い訳をしておくと、 BGPの数学的基本的理論、 つまり、数学用語で言えば有向性グラフ理論（というのか？） とかになるんだろうし、インターネット技術用語ではパスベクタ理論、 とかになるんだろうけど、 とにかく、BGPの背景になる数学理論に関しては、私はあまり詳しくありません。 さらに、BGPが真価を発揮するのは、 IXのコアルーターなわけだけど、そっちの設定もやったことはありません。 （というか、この経験者なんて日本に何名いるんだ？） 正直、エッジのルータで設定したら なんか動いた、という以上の経験はないんで・・・。 よって、すげぇ大間違いがあるかもしれませんが、、、。
で、その問題点ですが、 BGPの広報内容を受信したあと、 ホップ数を元に、自分にとっての最適なルートを再計算しないといけない （というか、これが目的）なのですが、 ここが問題。 ZEBRAのソースとか見ずにいうのもアレですが、 ようは、ツリー構造に展開し、そのあとで適当に 枝を畳んでますよね。 その、ツリー構造への展開に必要なメモリが爆発するかも。

対策としては、いろいろ考えられます。 簡単な方法としては、 再計算サーバみたいなのを建て、 そこに集約することでしょうね。 ルータ上で再計算するよりはよほどいいはず。
そんな奇妙な運用をやっているやつは見たことないですが、 ZEBRAは一応、再計算をする部分とスイッチングをする部分 （というか、Linuxの実装ではスイッチング条件をLinuxに伝えてるだけだけど）が 分離できる構造になっているっぽいので、 再計算サーバに集約することにより、効率化できると思います、知らんけど。 この場合、単に、大容量サーバを共同利用できる、ということではなく、 再計算って、同じようなトポロジをもっているルータ、プロバイダでは 大体同じような計算をするでしょ？ よって、うまくやれば、このあたりの 計算を集約できるんじゃないかな。知らんけど。 が、もっというと、たとえルータ上で 再計算しても、単に、メモリをめちゃくちゃつめばそれでOKかも。 すくなくとも、再計算サーバは単にメモリが多いだけでOKかも。
また、根本的な対策としては、再計算を分割し、 必要な部分だけ行う、といった対策により、 メモリ使用量を削減することです。 これは、多分、グーグルのページランクの計算方法の改良と 似た部分があるような気がします。 まあ、だれか、やってくれると嬉しいかな、と。
それ以外に細かいことを言うと、 経路集約をしないと、BGPで広報してくる内容（なんていうんだ？）が めちゃくちゃにデカくなるでしょう。 いまのデータの持ち方だと、圧縮しても何十ギガバイト、とか。 データの持ち方を変えても、やはり、何ギガバイトとかになるかも。 ただ、このサイズについては、回線も速くなってますし、 なにより、（たとえば rsync のような）差分転送すればいいので、 あまり問題にはならないと思います。

まあ、いずれにせよ、どれをとってもたいした問題じゃないので、 なんとでも解決するでしょう。
某日本製ルータは、IPv6完全対応、とかがウリでしたが、 あいかわらずズレたマーケティング感覚。 いい技術はあっても売れる製品がないのがこの会社。 わたしは、フルライン対応のほうが売れると思うよ。