■ IS-ISのルーティングテーブル

Integrated IS-ISとは、OSIプロトコル以外に、IPをルーティング対象としたプロトコルだ。

マルチプロトコルルーティングプロトコルっていうんでしたっけ。
EIGRPがそうですよね。

うむ。今回はIntegrated IS-ISを使ったIPルーティングを説明するが。
その前にIS-ISのルーティングプロセスについて説明しておこう。

はぁ、IS-ISのルーティングプロセス。

さて、OSPFのルーティングテーブル作成の手順はこうだったな。

でした。SPFツリーの構築とルーティングテーブルの作成でしたよね。

そう。基本的な動きはIS-ISもOSPFも変わらない。
LSPによりデータベースを更新し、SPFツリーを作成する。

ふむふむ。リンクステートルーティングな感じですね。

どんな感じだ、それは。
違いがあるのは、まずレベル1とレベル2が完全に別のツリーを作成すること。

あ〜。別のデータベースを持つって話なんですから、別のツリーを持つんですね。

うむ。アドバタイズも別、データベースも別、ツリーも別だからルーティングテーブルも別だな。
そしてもう１つのポイントは、PRCだ。

ぴーあるしー？ ぱーしゃるるーとかりきゅれーしょん？

IS-ISのLSPにはESの情報も含まれる。これはいいな？

そうみたいですね。OSPFとかだと、ネットワークの情報しかアドバタイズしないのに。

この情報を使って、各ESへの到達性を計算する。これがPRCだ。

？
ルーティングの段階で、各ESへ届くかどうかも計算するってことですか？

そうだなSPFツリーの末端（葉）にESの情報が入るとでも考えればいい。

なんでそんな面倒なことになってるんですかね。

それは次のルーティングプロセスと合わせて話そう。

あ、はい。

ともかく、各ESへのパスを計算し、それをCLNS転送データベースに載せる、これがIS-ISのルーティングテーブル作成だな。

なんか、OSPFと似てるようで、似てないようでややこしいですね。

■ IS-ISのルーティングプロセス

OSPFよりも階層構造がはっきりとしているのが、IS-ISだ。
まず、レベル1。レベル1は自エリア内のISとESを知るが他エリアは全く知らない。

エリア1ルータはOSPFでいうところのTSA内のインターナルルータでしたっけ。
自分のところしか知らないっていう。

そうだ。エリア1は自エリア内はNSAPのシステムIDだけを見てルーティングする。

システムIDだけ？
え〜っと、システムIDってIPアドレスでいうところのホスト部ですよね。ホスト部って階層構造になってないような気が…。

うむ、なってない。
つまりMACアドレスのみでルーティングするようなものだ。

うわ、なんか無茶だ。

NSAPのところで話したとおり、システムIDはエリア内でユニークだからな。
一方で、もし他エリアへのCLNSパケットだった場合。

場合？

もっとも近いL2ルータをデフォルトルートに設定しておき、そこへパケットを送る。

もっとも近い？
最適ではなく？

もっとも近い、だ。
つまり、レベル1ルーティングとはこうなる。

あ〜、なるほど。だからESの情報をSPFツリーに記載する必要があるんですね。

そうだ。
考えかたとしてはOSPFのエリアはサブネットの集合体だが、IS-ISのエリアはサブネット１つ分なのだよ。

だからシステムIDだけでエリア内をルーティングする、と。なるほど。

さて、レベル2ルーティングだが、こちらはエリアIDを見てのルーティングだ。

ということは、ルーティングテーブルはエリアIDのみ？

事実上、そうなる。
レベル2ルーティングは宛先エリアまでバックボーンパスで転送し、あとはレベル1、レベル0におまかせという形だな。

ふむふむ、これは普通のルーティングっぽいですよね。

そうだな。そう言われれば確かに。
さて、このレベル1・レベル2のルーティングプロセスだが、ポイントは先ほどのネット君の科白だ。

「これは普通のルーティングっぽいですよね」？

もっと前。

「ふむふむ」？

面白じゃないか、ネット君。
あぁ、面白い面白い。これで満足か？

う、うぅぅ。

「もっとも近い？最適ではなく？」だ。
つまり、こういうことが起きる。

あら〜。最短パスじゃないパスを使っちゃうんですか。

うむ、このようなルーティングをアシンメトリックルーティングという。
必ずしも悪いルーティングではない。

そうなんですか？

例えば、エリア1からエリア2へのパケットが多い場合、ルータB−C間が混むわけだ。
ここに返送パケットまでもルータB-C間を使うとなると、輻輳必至になってしまう。

まぁ、そうなりますね。

で、アシンメトリックルーティングなら、違うパスを使うこともある。
多少は輻輳の軽減に役立つ、となるわけだな。

ははぁ。なるほど。

だが、もちろん最短パスを使った方がいいこともある。
ま、場合によるな。基本的には最短パスがベストだけどな。

べストではないけれども、悪いわけではないこともある、ってことですね。

■ Integrated IS-IS

さて、IS-ISでIPルーティングも可能とするIntegrate IS-ISの話をしよう。

ようやっと登場ですね。

Integrated IS-ISは3種類のルーティングを行うことができる。

あ〜、IPのみも可能なんだ。

そうだ。この「IPのみが可能」という点を踏まえて、Integrated IS-ISを説明するが。
Integrated IS-ISのルーティングプロセスはIS-ISと同じだ。

はい。

「はい」？
ここで疑問はわかないのかね？

疑問？
いや、Integrated「IS-IS」って言うんだから、IS-ISと同じってのも別に変じゃない気がしますけど。

ふむ。では聞こう。
IS-ISのルーテッドプロトコルは？

OSIプロトコル。CLNSですよね。

そのアドレスは？

NSAP。なんですか突然？

では、IS-ISのデータベースとSPFツリーの元となる情報のプロトコルは？

元となる情報のプロトコルは？
それもCLNSですよね。

そう、つまりIntegraed IS-ISでもCLNSの情報が元となるのだよ。
そこでさっきのことを聞こう。「IPのみが可能」と言ったな。この場合はどうなる？

「IPのみが可能」の場合。
…IPのみしか使わなくても、CLNSが必要ってことですか？

その通り。隣接関係を結ぶため、データベースの作成、SPFツリーの作成、すべてにおいてIntegrated IS-ISはCLNSを必要とするのだよ。

ははぁ。IS-ISはCNLSによって動くってことですね。

そういうことだ。実際のところをいうと、Integreted IS-ISにおけるIPネットワークのアドバタイズはCLNSのおまけと言ってもいいぐらいだ。

おまけ……。
そんな扱いなんですか？

うむ。Integrated IS-ISではSPFツリーはCLNSを元として作成される。
IPネットワークはESと同じ扱いでSPFツリーの中にある。

ということは、SPFツリーの葉？

そう。CLNSのナローメトリックによりSPFツリーが構成され、ESの到達性を確認する段階のPRCでIPネットワークの計算が行われることとなる。簡略化した例を示そう。

ははぁ。なんか、普通と言えば普通なんですけど。

そうか。
では、レベル2を組み合わせてみよう。

…はい。わかりますけど。

ふむ。わかってもらえたか。
IPのネットワークからSPFツリーを構築するのではなく、CNLSのSPFツリーがあってからIPルーティングという流れだな。

CLNSのSPFツリーがあくまでもメインってことですね。

そうだ。なので逆に言えばIPネットワークの障害の結果、SPFツリーが更新されないこともありうる。
その場合、単純にIPネットワークへの計算（PRC）だけが行われるわけだな。

IPネットワークは「おまけ」に近い立場なんですね。

そういうことだ。
では今回はここまでにしよう。ではまた次回。

はい。
30分間ネットワーキングでした〜♪