30 Minutes NetWorking
No.RT05

30Minutes NetWorking

BSCI

第5回OSPF(1) 概要・特徴

■ リンクステート ルーティングプロトコル

スーパーインター博士

Routingというからには、ルーティングプロトコルの説明をしなければな。

ハイパーネット助手

そういうもんですかね。

スーパーインター博士

不服かね、ネット君?

ハイパーネット助手

いえ、そういうわけでは。
ルーティングプロトコルといえば、RIPとかIGRPですよね。以前3分間の方でやった。

スーパーインター博士

そうだ。その2つはディスタンスベクタ型だったな。
今回はリンクステート型の説明をする。リンクステートの長所はなんだった、ネット君?

ハイパーネット助手

え〜っと。

  • コンバージェンスが速い
  • ルーティングアップデートのパケットが小さく、帯域幅を消費しない
  • トポロジ全体を把握する
スーパーインター博士

うむ。いいぞネット君。 はっきりいって、ディスタンスベクタをすべての面で上回ったルーティングプロトコルだが、高機能なだけにルータの負荷が大きい
よって高性能なルータを使用する必要があるという欠点がある。

ハイパーネット助手

でしたね。
代表的なプロトコルとして、OSPFがありますよね。

スーパーインター博士

ほほぅ、人が言おうと思っていた台詞を奪うとは、偉くなったなネット君よ。

ハイパーネット助手

えっ!? いや、別にそんなつもりでは…

スーパーインター博士

言い訳はいい。今期末の評価がどうなるかは、これからの君の心がけ次第だな。
なお言っておくが、黄金色の饅頭なんかは大好物だ。

ハイパーネット助手

黄金色の饅頭ですか。
いやいやお代官様もお人が悪い。

スーパーインター博士

ふっふっふ。そちも悪よのう、越後屋
…。
それはともかく、今回からしばらくはそのOSPFの説明をする。

ハイパーネット助手

了解です。

スーパーインター博士

まず、OSPFの特徴を知ってもらおう。
先ほどのリンクステートの特徴とかぶることもあるが、リンクステートといえばOSPFなので、当然といえば当然かもしれん。

  • 速いコンバージェンス
  • VLSMに対応
  • ホップカウントによる制限なし
  • 帯域幅を元にしたコストをメトリックとする
  • 効率的なアップデート
  • ルーティングテーブル以外の情報を持つ
ハイパーネット助手

ははぁ。
ルーティングテーブル以外の情報、というとトポロジカルデータベースって奴ですか?

スーパーインター博士

まあ焦るな、ネット君。物事には順序というものがある。まずはOSPFの初期動作を知ってもらおう。
初期動作で重要なのは、Helloパケットだ。

ハイパーネット助手

はろーパケット?
こんにちはパケットですか?

■ HELLOパケット

スーパーインター博士

うむ。こんにちはパケットだ。名は体を現すとはこのことだな。なかなかいいネーミングセンスだぞ、ネット君。
つまり同一サブネットに属する他ルータと挨拶を交わして、知り合いになるのだ。

ハイパーネット助手

へぇ、礼儀正しいルータですね。
ディスタンスベクタが有無を言わさずテーブルを送りつけるのとは対照的ですね。

スーパーインター博士

そうだな。このHelloパケットによって知り合ったルータをネイバーもしくは近接ルータと言う。
ネイバーとはデフォルトでは10秒毎にHelloを送信してお互いの生存を確認しあう。

ハイパーネット助手

ますます仲がいいですねぇ。
定期アップデートによって相手の状態を知るディスタンスベクタとは大違いだ。

スーパーインター博士

うむ。EIGRPとOSPFはHelloによって隣接関係を築くと共に、生存確認を行うのだ。
デフォルトではこのHello間隔(10秒)の4倍の時間、ネイバーからHelloを受け取らなかった場合、ネイバーもしくは、ネイバーとのリンクがダウンしたと認識する。

ハイパーネット助手

ふむふむ。

スーパーインター博士

このように、お友達関係を築いたルータの一覧表をOSPFルータは持つ。ネイバーテーブルとでも言っておくかな。
そしてこの隣接関係を結んだルータとはとても仲がいいので、情報を共有する。

ハイパーネット助手

情報を共有する、ってなんか当たり前のように聞こえるんですけども。
情報を共有しあって、コンバージェンスになるんでしょ?

スーパーインター博士

確かにそうだが。この場合の情報の共有というのは、普通のとは違うのだ。
リンクステート型は何故、トポロジ全体を知ることができるのだ? そして、リンクステート型のルーティングテーブルはどうやって作成された?

ハイパーネット助手

ええっと、トポロジ内のルータから届いたリンク情報をもとに、データベースを作成して。
そのデータベースをもとに、ルーティングテーブルを作成する、でしたっけ?

スーパーインター博士

そうだ。
そのトポロジカルデータベースをネイバーと交換するのだ。

ハイパーネット助手

ええっ?それじゃディスタンスベクタと同じじゃないですか。
ルーティングテーブルより小さいリンク情報のみを送るからリンクステートは帯域幅を使用しないんでしょ?

スーパーインター博士

うむ、確かにディスタンスベクタと同じように見えるが、この交換は30分間隔だ。
ディスタンスベクタほど頻繁に行わない分、帯域幅を消費しない。

ハイパーネット助手

ははぁ。そんなに長い間隔ですか。
それなら確かに消費量も相対的に小さくなりますよね。

スーパーインター博士

うむ。
その後、データベースからルーティングテーブルを計算する。
ちょっと文字ばっかりだったので、図で説明しよう。

[FigureRT05-01:ネイバーの確立]

スーパーインター博士

この双方向にHelloを交換し合った2Way Stateになって初めて、データベースの交換が行われる。この状態にならないと、情報を交換しあわないから、コンバージェンスには達しない。

ハイパーネット助手

ははぁ。

スーパーインター博士

上の例は、ポイントツーポイント接続のルータ間での話だ。基本はこの形なので覚えておくように。
だがイーサネット環境のようなマルチポイント接続では事情が少し異なる

ハイパーネット助手

何故ですか?

■ DRとBDR

スーパーインター博士

簡単に言えば、隣接ルータが多くなりすぎるからだ。
下の図をみてくれ。

マルチポイント環境でのネイバー

[FigureRT05-02:マルチポイント環境でのネイバー]

スーパーインター博士

かなり豪快な例だが。
左のような6つのルータを含むイーサネットの場合、隣接関係は右図のような15個の隣接関係が必要となる。

ハイパーネット助手

網の目のように関係を結ばなきゃダメなんですね。

スーパーインター博士

そうだ。
これでは、データベースの交換などで負荷がかかりすぎてしまう。

ハイパーネット助手

確かに。いくら30分間隔とはいえ、数が多いと大変ですものね。

スーパーインター博士

なので、隣接関係を結ぶことは結ぶのだが、アップデート情報の交換だけはリーダーとサブリーダーと結ぶことにする。
一般のルータは、リーダー(もしくはサブリーダー)経由で情報を交換しあうことになる。

ハイパーネット助手

スーパーインター博士

リーダーをデジグネイテッドルータ(DR)。
サブリーダーをバックアップデジグネイテッドルータ(BDR)と呼ぶ。

ハイパーネット助手

??

スーパーインター博士

はははは。
ちょっと急ぎすぎたな。

ハイパーネット助手

えぇ。
ちょっとページングが間に合いません

スーパーインター博士

ハイパー化しても、記憶容量の小さいやつめ。
ま、今回はここまでだ。

ハイパーネット助手

助かります。

スーパーインター博士

うむ。OSPFはかなり難解な部分があるので、じっくり腰をすえてやるつもりだったので丁度いい。
今回は、Helloパケットからの流れを覚えておくように。

ハイパーネット助手

了解。

スーパーインター博士

次回は、DRとBDRについて詳しくやるぞ。

ハイパーネット助手

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

OSPF
[Open Shortest Path First]
IETF が、RIP の後継として開発。
Windows2000Serverのルーティング機能はこれを使っている。
リンクステートと…
他にもIS-ISがこれに当てはまります。
ついにCCNP BSCIの対象プロトコルになりました。
ネイバー
[neighbor]
そのまま近所・近接の意。
生存確認を行う
間違えやすいですが、BGPはKeepAliveで生存確認を行います。
ダウン
この時間のことをデッドインターバル[Dead interval]、もしくはデッドタイマ[Dead Timer]と呼ぶ。
15個
n個のルータがすべて結び合う場合、
( n x (n-1)) / 2
の関係が必要。
DR
[Designated Router]
代表ルータ、の意。
ハイパーネット助手ハイパーネット君の今日のポイント
  • OSPFの特徴を覚えておこう。
  • Helloパケットにより、ネイバーと隣接関係を結ぶ。
  • Helloパケット(10秒間隔)は生存確認にも使われる。
  • 双方向に隣接関係を結んでから、情報の交換が行われる。

30 Minutes NetWorking No.RT05

管理人:aji-ssz(at)selene.is.dream.jp