読者です 読者をやめる 読者になる 読者になる

自分研究会

一日の振り返りと課題を探す

レイヤ3 ARP

レイヤ3 ARP


■4つのアドレス・おさらいのおさらい


送信元のアドレスを取得する方法について。

送信元、自分のMACアドレスNICをとりつけた段階で分かる。
送信元IPアドレスは、管理者に教えてもらうアドレスを直接入力する静的と
DHCPにより自動で割り振られる動的。の二つの方法がある。

残る問題は、データの転送を行いたい相手のアドレスをどのように知るかという一点にかかっている。

 

宛先のMACアドレスを知る方法はARPというプロトコルを使用する。

 

■アドレス解決プロトコル

アープと読む。

アドレス解決プロトコルと日本語では訳される。
「宛先のMACアドレスが分からない」という状態を解決してくれるプロトコルという意味。


ARPは宛先のIPアドレスが決定した時点で実行される。
例えば、このサイト「Roads to Node」を見たいと思ったとする。
そうすると、ブラウザに「Roads to Node」のURLを入力する。

そうすると、DNSという機能が働いて、サイトが置いてあるサーバのIPアドレスを教えてもらえる。

そこで、「このIPアドレスのホスト、あなたのMACアドレスを教えて」と聞く。
これがARPだ。


ARPテーブル

まず、データ転送を希望するホストは、宛先のIPアドレスを取得する。
DNS


宛先IPアドレスが決定した時点で、宛先MACアドレスを知るためにARPテーブルを参照する。

ARPテーブルとは、IPアドレスMACアドレスの対応表のこと。

 

f:id:sakamotosakamo:20161113171514p:plain

「192.168.0.1のMACアドレスは00-40-26-f4-1a-02」です。という表がある。


ARPエントリタイプは?>

static(静的)とdynamic(動的)の二つがある。
dynamicはARPによって取得したIPアドレスMACアドレスの対応という意味。
staticは手動で対応を入力したという意味になる。


ARPテーブルに宛先IPと宛先MACの対応があれば、その時点でMACアドレスがわかる。
ARPテーブルがあれば、いちいちMACアドレスを聞く必要がない。

問題は、ARPテーブルに宛先IPと宛先MACの対応がない場合だ。
そのため、「このIPアドレスのホスト、あなたのMACアドレスを教えて」と聞きその結果をARPテーブルに載せることをする。
この「教えて」というのがARP要求だ。

 


ARP要求&ARP応答

このARPはIPと同じくレイヤ3のプロトコルだ。
このARPにのっとって送信されるARP要求だが、IPを使わない。

つまり、IPの代わりにARPでデータ転送を行う。
なので、IPパケットの代わりにARPパケットというちょっと特殊なパケットを使う。


特徴はARPパケット自体がデータという点。
上のレイヤのプロトコルを使わない。

つまり以下のような形で送るということ。



f:id:sakamotosakamo:20161113171554p:plain

ARPパケットの中身は以下のようになっている。

f:id:sakamotosakamo:20161113171613p:plain

 

下の4つを見てわかる通り、4つのアドレスすべてが入っている。

????

でも宛先のMACアドレスは分からないのでは?
まず、文章でで説明するとこのようになる。


▼宛先にデータを転送しようとして、宛先IPアドレスが分かったあと。

 
1.ARPテーブルを参照し、宛先IPアドレスに対応するMACアドレスがあるかどうかを調べる。
2.なければ、ARP要求をブロードキャスト送信する。
3.ARP要求を受け取っとホストは、ARPパケットの中の宛先IPアドレスと自分のIPアドレスを比較する。
 └一致しなければ無視
 └一致した場合、ARP対応を送信

4.ARP対応を受け取った(ARP要求を送った)ホストは、ARPテーブルにそのMACアドレスを追加する。
4つのアドレスがそろい、宛先へのデータ送信が可能になる。

 

 

f:id:sakamotosakamo:20161113171652p:plain

 

 

f:id:sakamotosakamo:20161113171700p:plain

 

 

f:id:sakamotosakamo:20161113171710p:plain

 

f:id:sakamotosakamo:20161113171948p:plain

 

 

f:id:sakamotosakamo:20161113172018p:plain

 

 

 

 

 

DHCPと同じように、ブロードキャストを使う。
誰に送ったらいいか分からないときは、ブロードキャストをよく使う。


ARP要求を受け取ったら、その送信元を自分のARPテーブルに追加しておく。
そうすることによって、ARPを出す回数をなるべく減らすようにしている。
ARPが多発するのは望ましくない。

 

ARPテーブルのエントリの問題

ARPが多発するのはなぜよくないのか?

それはARPがブロードキャストだから。
ブロードキャストはなにしろ、全員宛なので、ネットワークの帯域幅を多く消費する。


<でも、イーサネットは結局全員に届くのでは?別にブロードキャストでなくて、一人宛だとしても全員と同じになってしまわないか?>


確かにイーサネットだと全員に届く。
しかし、スイッチやブリッジなどのデバイスを使えば事情はことなる。
※スイッチやブリッジはフィルタリングして宛先のみに届く。

だが、ブロードキャストはスイッチやブリッジではフィルタリングできない。
なのでブロードキャストの多発はトラフィックに影響を及ぼしやすい。


ブロードキャストが多発しすぎると、ネットワーク全体が通信不能になってしまうことがある。
このような状態をブロードキャスト・ストームという。

 

では、そのARPの回数を減らす方法は?


答えは、ARPテーブルを事前に作っておくこと。

ARPテーブルを静的にエントリを作っておくのがARPの回数を減らす早道だ。
静的なエントリはずっと保持される。
そうすればARPは行われなくなる。


だが、実際ほとんどのデバイスでは、ARPテーブルを静的に作成することはできない。
なぜなら、ARPテーブルが間違っている時点で、送信は絶対に不可能になるからだ。


ARPテーブルが間違って記憶されると、IPアドレスMACアドレスが一致しないことになる。
イーサネットの仕組みを思い出してもらいたい。
自分のMACアドレスと一致しないフレームは破棄される。


なので、MACアドレスが違った時点でフレームを受け取ってもらえないことになる。
だからARPテーブルの動的なエントリは一定時間ごとにクリアされるように作られている。
IPアドレスMACアドレスの対応が間違うことのないように。


。。。。。でもそうなると、結局ARPは減らないよね?

結論、そうなってしまう。

 

 

<今日のポイント>


・宛先MACアドレスを知るにはARPを使用する
・ホストはIPアドレスMACアドレスの対応表であるARPテーブルをもつ
ARPテーブルは一定時間でクリアされる
ARPテーブルに宛先のエントリがない場合、ARPが実行される
ARP要求をブロードキャストする
ARP要求の宛先IPアドレス以外のホストはARP要求を破棄する
ARP要求の宛先IPアドレスのホストは、ARP対応を返す
ARP対応を受け取ったARP要求の送信ホストはARPテーブルにエントリを追加する