6月12日(水)1コマ目
今日、やったこと
ARP+イーサネット、IP
今日のホワイトボード
配布資料「フレーム送出までの実際の処理」
ホストAからホストBへデータを送信する際のIP、ARP、イーサネットの処理をシミュレーションしました。
ホストAのIP、ARP
IPでルーティングして送信先が決まる。
送信先のMACアドレスをARPに従って取得する。
 |
| 図 ホストAのIP、ARPでの処理 |
ホストAからデータ送信
取得したMACアドレスをイーサネットヘッダの宛先MACアドレスに書き込んでデータパケット送信。
 |
| 図 ホストAからデータ送信 |
配布資料「イーサネット、IP、ARP 演習１」
ホストAからホストCへデータを送信する際のイーサネット、IP、ARPの処理の流れをシミュレーションしました。
ホストAにて
IPがルーティングし、決定した送信先のMACアドレスをARPに従って取得。
取得したMACアドレスをイーサネットヘッダの宛先MACアドレスに書き込んで送信。
 |
| 図 ホストAでの処理 |
ルーターにて
受信したパケットのイーサネットヘッダの宛先MACアドレスが自分宛になっているため、受信。あとの流れはホストAと同じ。
 |
| 図 ルータでの処理 |
ARPリクエストはルーターを超えない
ホストAはルーティングなんかせずに、ホストCのMACアドレスを調べて直接送信すればいいのではと思う。
ARPリクエストのようなブロードキャストパケットをルーターは別ネットワークに転送しない。よって、ホストAから送信されたARPリクエストパケットはルーターを超えてホストCにはたどり着かない。
 |
| 図 ルーターはブロードキャストパケットを転送しない |
これはネットワーク上のパケット数を抑えるため。
ブロードキャストパケットをルーターが転送すると、アメリカやヨーロッパから送信されたパケットが日本にもやってくる。ネットワーク上は世界中のブロードキャストパケットで溢れてしまい、ネットワークとして機能しなくなる。
次回は
同じようなことをやります。
終盤にテストをします。
