最近行き詰っている。
ルーティングとは何か?ルータとは何か?インターネットとは何か?
TCP/IPとは?ウェブとは?クラウドとは?L3スイッチとは?
BGPとは?OSPFとは?
冗長?経路?アドレス?
一応、どんなものでどんな風に使われどんな風に設定しどんな風に動くのかはなんとなく理解している。
しかし、なぜこうでなくてはならないのか、ほかにもっといい方法がないのか、とか、
どうしてOSPFなのか、どうしてBGPなのか、
なぜ冗長化するのか、なぜcatalystなのか、nexusなのか、という、根拠というか理由というか、
動機というのか、そういうものがわからない。
そもそも、ネットワークとはなんだろう。
そんなことすら考える。
ネットワークとは、「接続」のことか。
一番単純なネットワークは、2点間の間を結ぶことだ。
糸電話のような。
「通信」とはなにか。「接続」と「通信」の何が違うのか。
ルーティングとスイッチングとは、それぞれどういうことか。
両方「ネットワーク」に分類されるが、違うものである。
よく言われるのはL3(えるさん)、L2(えるに、えるつー)であるが、
果たしてそれらはそれぞれどういうものなのか。
本当にみんなわかっているのか?
1秒の通信断が発生すると、何が起きるのか。
パケットが一つ落ちると、どうなるのか。
電車の中でスマホでウェブを見ている人に何が起きるのか。
家のパソコンでオンラインゲームをしている人にどんな影響があるのか。
メールを受信中に、メールサーバとクライアントの間のどこかで0.5秒の通信断が発生したら、
どうなるのか。
「TCPは再送機能があるがUDPにはないからドロップする」というが、
youtubeを視聴中にパケットが一個おちたらどうなるのか。
マルチキャストを利用した通信というかサービスは具体的に何か?
ウェブ(グーグル)で検索して得られる情報、資格試験受験のための参考書に書いてあること、
その他一般的に言われること、
それらと自分がインターネットやATMやiPhoneや漫画喫茶などで通信・サービスを利用していることの間に、もやもやとしたものがある。
もしかして私は重要な誤解をしている、あるいは重大な認識不足があるのではないか?
そんな気がしてならない。
とりあえず、「インターネットルーティング入門」という本を買った。
このブログを検索
2014/10/23
2008/04/10
rsvpのなぞ
rsvpとは、Intserv方式のQOSを行うプロトコルである。通信を開始する前に、網の入り口のルータが、経路上の通過するすべてのルータに必要な帯域を通知し、経路上のルータは要求された帯域があればそれを確保するという仕組みである。このようなことは用語集などにも載っていることで調べればすぐわかるが、実際に動作させてみるのは大変であった。
以下、ciscoでの設定方法を記す。
1.予約を受け付ける準備
さて問題のRSVPの有効化であるが、これはI/Fモードで下記のようにコマンドを入力する。
if2(config-if)ip rsvp bandwidth 50000
これはif2において、50000kbpsつまり50Mbpsの帯域を予約可能帯域として確保します、という意味である。数値は指定しなければI/Fの帯域の75%となる。この設定を、経路上のルータのすべてのI/Fで設定しておく。これで帯域の予約を受け付ける準備が整った。
2.帯域の予約
予約を行う経路のことを、tunnelと言う。R1で、仮想のtunnelI/Fを作成する。
tunnel source: unnumbered
理由はよくわからないがunnumberedにするのが慣例らしい。
tunnel destination: 予約が必要な経路の終端のルータのloopback address
(3.3.3.3)
必要な帯域:50Mbps(50000kbps)
このトンネルを作成すると、帯域を予約しにいく「PATHメッセージ」というものが送信される(いつ送信されるのか正確には未確認)。経路上のルータはPATHメッセージを受け取ると帯域が確保できれば確保する。RESVメッセージで返事をする(?)。PATHメッセージは経路の終端まで転送され、終端のすべてのルータで帯域が確保できれば、tunnelがupする。tunnelに終端のルータのloopbackアドレスをルーティングするか、autoroute announceを設定することで、tunnelインタフェースを通って通信が行われるようになる。
2.予約の競合
予約可能帯域が50Mbpsであるところに、30Mbpsの予約が二本入ったらどうなるか。priorityが同じであれば、先に予約したtunnelのみがupする。priorityが異なり、予約可能帯域が足りない場合、後から予約したtunnel priorityが予約済みtunnelより高ければ、予約済みtunnelがdownして、後のtunnelがupする。
3.実際の通信
当たり前のことであるが、予約というのは、「誰かにとられないようにとっておく」ものである。上記の経路を誰も使用しないのだったら、予約してもしなくても、10Mのトラフィックは流れる。それどころか帯域とルータの処理能力が許せばそれ以上のトラフィックが流れる。
だから、予約できたかどうかを確認するには、今回の場合であれば、予約をしていないものがこの経路に残り10Mbpsより少なくなるような、FastEtherであれば90Mbpsを超えるトラフィックを流していて、そこに予約したものが10Mbpsのトラフィックを流したら、前者の過剰なトラフィックが破棄されて、後者の10Mbpsのトラフィックが通ればよい・・・が、結論から言うとそうはならなかった。予約は全く形だけで、実際にはベストエフォートの通信しか行われない。
人間社会にたとえるなら、以下のようになる。100個の席があって、10の団体が10席ずつ予約をする。予約どおりに各団体が10人ずつ来れば、予約どおりに全員が座れる。しかし、もしある団体で急遽人が増えて15人で来たとする。当然余分な5人分の席は提供されない。もし他の予約済みの席が空いていたらとりあえず座らせることがあったとしても、その後予約客が来たら当然立ってもらわねばならない。
しかしRSVPプロトコルだけではそこまでやってくれないのだ。予約を取るだけとって、いざとなったら予約を無視してしまうのである。そんなことなら最初から予約など受け付けるな、という話である。忘れてはならないのは、intservでの予約というのは、自分が使用する帯域の上限の申告ではない、ということである。どんなに混雑しても、最低この帯域だけは保証してください、というものである。
「10Mbps予約したのに10Mbps以上流すな」というのもわからなくもないが。
以下、ciscoでの設定方法を記す。
1.予約を受け付ける準備
if2 if1 if2 if1 if2 ( R1 )---( R2 )---( R3 ) 1.1.1.1 3.3.3.3R1が、R1からR3までの間で10Mの帯域の予約を行うとする。まず、あらかじめ各ルータではIGPが設定され、R1はR3のloopbackアドレスに到達可能である必要がある。今回はIGPにはOSPFを使用した。OSPFではTE(traffic engineering)機能を有効にし、TE機能を有効にするエリアとI/Fも指定する。
さて問題のRSVPの有効化であるが、これはI/Fモードで下記のようにコマンドを入力する。
if2(config-if)ip rsvp bandwidth 50000
これはif2において、50000kbpsつまり50Mbpsの帯域を予約可能帯域として確保します、という意味である。数値は指定しなければI/Fの帯域の75%となる。この設定を、経路上のルータのすべてのI/Fで設定しておく。これで帯域の予約を受け付ける準備が整った。
2.帯域の予約
予約を行う経路のことを、tunnelと言う。R1で、仮想のtunnelI/Fを作成する。
tunnel source: unnumbered
理由はよくわからないがunnumberedにするのが慣例らしい。
tunnel destination: 予約が必要な経路の終端のルータのloopback address
(3.3.3.3)
必要な帯域:50Mbps(50000kbps)
このトンネルを作成すると、帯域を予約しにいく「PATHメッセージ」というものが送信される(いつ送信されるのか正確には未確認)。経路上のルータはPATHメッセージを受け取ると帯域が確保できれば確保する。RESVメッセージで返事をする(?)。PATHメッセージは経路の終端まで転送され、終端のすべてのルータで帯域が確保できれば、tunnelがupする。tunnelに終端のルータのloopbackアドレスをルーティングするか、autoroute announceを設定することで、tunnelインタフェースを通って通信が行われるようになる。
2.予約の競合
予約可能帯域が50Mbpsであるところに、30Mbpsの予約が二本入ったらどうなるか。priorityが同じであれば、先に予約したtunnelのみがupする。priorityが異なり、予約可能帯域が足りない場合、後から予約したtunnel priorityが予約済みtunnelより高ければ、予約済みtunnelがdownして、後のtunnelがupする。
3.実際の通信
当たり前のことであるが、予約というのは、「誰かにとられないようにとっておく」ものである。上記の経路を誰も使用しないのだったら、予約してもしなくても、10Mのトラフィックは流れる。それどころか帯域とルータの処理能力が許せばそれ以上のトラフィックが流れる。
だから、予約できたかどうかを確認するには、今回の場合であれば、予約をしていないものがこの経路に残り10Mbpsより少なくなるような、FastEtherであれば90Mbpsを超えるトラフィックを流していて、そこに予約したものが10Mbpsのトラフィックを流したら、前者の過剰なトラフィックが破棄されて、後者の10Mbpsのトラフィックが通ればよい・・・が、結論から言うとそうはならなかった。予約は全く形だけで、実際にはベストエフォートの通信しか行われない。
人間社会にたとえるなら、以下のようになる。100個の席があって、10の団体が10席ずつ予約をする。予約どおりに各団体が10人ずつ来れば、予約どおりに全員が座れる。しかし、もしある団体で急遽人が増えて15人で来たとする。当然余分な5人分の席は提供されない。もし他の予約済みの席が空いていたらとりあえず座らせることがあったとしても、その後予約客が来たら当然立ってもらわねばならない。
しかしRSVPプロトコルだけではそこまでやってくれないのだ。予約を取るだけとって、いざとなったら予約を無視してしまうのである。そんなことなら最初から予約など受け付けるな、という話である。忘れてはならないのは、intservでの予約というのは、自分が使用する帯域の上限の申告ではない、ということである。どんなに混雑しても、最低この帯域だけは保証してください、というものである。
「10Mbps予約したのに10Mbps以上流すな」というのもわからなくもないが。