■ MLSの動作

MLSの詳細な説明を今回行うわけだ。
ネット君、MLSの特徴は？

route-once, switch-many.
スイッチにルーティングを「覚えさせる」んでしたよね。

そうだ。MLS-RPの行ったルーティング結果を、MLS-SEが記憶し、フローの2つ目以降のパケットをスイッチングする、これがMLSだ。

まるちれいやすいっちんぐ。
レイヤ2のスイッチングだけでなく、レイヤ3もスイッチングする、と。

そういうことだ。
では、前回は概略だけだったので、今回は細かい動きを追ってみよう。

は〜。
なんか、新しい用語が増えてるんですけど。

そうか？

MLSP HelloとXTAGって？

MLSP Helloはレイヤ3マルチキャストで送信される、MLS-RPアドバタイズメントの1つだ。
XTAGは1バイトで、MLS-RPを識別する値だな。

XTAGで識別…。

enableエントリの確認や、MLS-RPの障害時のエントリの削除などに使われる。

あ〜なるほど。
他には…candidateパケットとenableパケット？

[candidate]は「候補者」の意味だな。MLSするかどうかの「候補」としてフローの最初で受け取るパケットのことだ。
[enable]は「許可を与える」の意味だから、「候補」に対してMLSの「許可を与える」という形になる。

ははぁ、許可をもらうと、MLSキャッシュのエントリとして確定して、今後MLSの対象となる、という意味ですね。

そういうことだ。
注意事項としては、MLSは一方通行という点だな。

一方通行？

うむ。MLSキャッシュのエントリを見てもわかるとおり、エントリとして登録された内容と逆の向きのパケットはMLSされない、ということになる。

あ〜、確かに。キャッシュには宛先IP、送信元IP、宛先MACがあるから逆向きは適用されませんよね。
ということは、逆向きは、逆向きでまたMLSキャッシュが必要？

そういうことになる。

は〜。

あとは、RPのインタフェースとSEは同じVTPドメインにないとダメだからな。

RPのインタフェース？

そうだ。MLSを設定する際、対象となるインタフェースにはVTPドメイン名を設定しておくコマンドを入力する必要がある、ということだ。

了解です。

■ MLSとACL

さて、前回、異なるネットワーク間の転送でのルータの役割を見てもらったな。

あ〜はいはい。コレですよね。

うむ。この図と、さきほどのMLSの動作の図を見比べると、ルータが行うことで1つ抜けていることがある。
気づいたか？

え〜、そんなのありましたっけ？

ある。
それは、ACLだ。

あくせすこんとろーるりすと？
あ〜、そういえば、ルータが受け取った際のACLの確認ってのがMLSの図ではなかったですね。

そうだろう？ 何故ならばACLがあった場合MLSが上手くいかない可能性があるからだ。

え？ そうなんですか？

例えば、以下の図だ。

ありゃりゃりゃ。

と、こういうことが発生しえることになるわけだな。
ネット君、対処法は？

ACLを使わない。

なるほど、正論だ。そうすればこのようなことは起きえない。
さすがだ、ネット君。

えへへ。

前々から言っているとおり、どうして君は物事を短絡的に解決したがるのかね？
「できない」→「どうにかする」という発想を何故もてない？

はぅっ。

ともかくだ。対処する点は2点。
まず1点、ACLが持つレベルのものをMLSキャッシュに持たせること。

ACLが持つレベルってなんです？

ACLの、拡張ACLで使う条件としてのレベルだ。
つまり、レイヤ3のプロトコル番号、レイヤ4のポート番号などだ。これをMLSキャッシュに記憶させる。

ははぁ、MLSキャッシュにポート番号を入れればさっきのは確かに解決できますね。

そうだろう。もう1つはACL設定時にはMLSキャッシュをクリアさせることも必要だ。
そうでないと、前のキャッシュでスイッチングされてしまう。

なるほど、確かに。

というわけで、MLSでこれらのことを対応するために使うものが、フローマスクだ。

ふろーますく？
どんなマスクです？

■ フローマスク

フローマスクには3種類のものがある。
この3種のうち、MLS-SEは1種類を使う。

ですてねーしょんあいぴー。そーすですてねーしょんあいぴー。あいぴーふろー。
Destinationは宛先、Sourceは送信元、Flowはフローですよね？

うむ。この3種の違いは、MLSキャッシュに記憶する内容だ。
まず、Destination-IP フローマスク。

宛先IPアドレスのみでエントリと比較する。
それ以外の情報は使わない、というマスクだ。

う〜んと。スイッチが受信したパケットをMLSするかどうかの判断で、宛先IPアドレスが一致してればいい、という意味ですね。

そうだ。特にMLS-RPでACLを設定していないならばこれでいい。

そうですね。確かに。

次が、Source-Destination-IPフローマスク。

送信元IPが増えましたけど。
これは宛先IPと送信元IPが一致したパケットをMLSするという意味でよろしいんでしょうか？

そうだ。宛先IP・送信元IPアドレスでエントリと比較する。
標準ACLはどういうものだった、ネット君？

標準ACLは、送信元IPアドレスでフィルタリングします。

そう、Source-Destination-IPを使うことにより、標準ACLのフィルタリングを有効にできることになる。

この結果、Source-Destination-IPフローマスクならば標準ACLがちゃんと効果を発揮するわけだ。

は〜、なるほど。

3つ目のフローマスクは、IP-Flowフローマスクだ。

まぁ、わかると思うが、拡張ACLに対応するため、使用プロトコルと宛先・送信元のポート番号もエントリと比較するわけだ。

ははぁ、それならば拡張ACLの記述が効果を発揮しますね。

だろう？ 動作自体は先ほどのSource-Destination-IPと同じなので割愛する。
さてもう１つ、MLSキャッシュの問題がある。

え〜っと、「前のキャッシュでスイッチング」してしまうことがあるって奴ですか？

そうだ。なのでアクセスリストを設定した段階でMLSPでMLSキャッシュを全クリアする指示を出す。

ふむふむ。

そうすると、それ以後はACLによりenableパケットが届かなくなり、ACLが発揮されるというわけだな。

さっきのC→B間をMLSしないって奴ですね。

そういうことだ。

そういえば、博士。
さっき、enableパケットのこない候補エントリは5秒でクリアってありましたけど、enableエントリはどのぐらいキャッシュに残るんですか？

ネット君にしてはいい質問だ。
enbleエントリは256秒でエイジアウトする。

はぁ。8ビットカウンタですね。

そうなるな。
さてネット君。MLSを使ったルーティングの高速化は理解できたか？

まぁ、なんとか。

よしよし、その自信なさげなところがネット君らしくてよろしい。
ルーティングの高速化という点では、レイヤ3スイッチと、あとCEFがあるが、これは機会があったら説明しよう。

はい。

というわけで、また次回。

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