![]() |
![]() |
@IT|@IT自分戦略研究所|@IT情報マネジメント |
|
@IT > Master of IP Network > イーサネット通信は正しく行われているか? |
![]() 連載:ネットワーク・コマンドでトラブル解決(4) イーサネット通信は正しく行われているか? 〜arpによるARPテーブルの確認と設定〜 加地眞也 2001/11/29
|
![]() |
図1 MACアドレスのフォーマット |
イーサネットにおける通信は非常に単純なものだ。IPネットワークと同様に、イーサネット・フレームは送信先MACアドレスと送信元MACアドレスを持ち、フレームの送信先MACアドレスが自身のものであれば受け取ることになる。
イーサネット・フレーム自体は、IPパケットのようにほかのネットワークへと転送されることはない。フレームは、ただ物理ネットワーク内全体に対し送出されて、相手に受け取られて終わりだ。ここでいう物理ネットワークとは、電気的に直接接線されて、フレームが直接届く範囲のネットワークを示している。イーサネットの通信範囲とは、この物理的な接続範囲に限られる。ネットワーク全体から見ると、非常に狭い範囲である。これが「コリジョン・ドメイン(衝突ドメイン)」だ。
![]() |
図2 イーサネット・フレームとコリジョン・ドメインの関係 |
イーサネット・フレームは、送出と同時にほかのホストから送出されたフレームと衝突が起こり、再送の必要が出る可能性がある。フレームの衝突が起こる可能性があるのは、物理的に同じネットワークに接続されたホスト同士の通信に限られる。言い換えれば、フレームが直接到達し得ない場所にあるホストやルータとは、フレームの衝突のしようがないはずだ。従って、コリジョン・ドメインとは、フレームが直接到達可能なネットワークの範囲でもあるのだ。
ところで、フレームの送信に必要なMACアドレスを、どのようにして送信元ホストは知るのだろうか? 考えてほしい。元々の送信先は、まずIPアドレスによって決定される。Webやメール送信などでは、多くの場合、サーバのDNS名(ホスト名)が与えられ、DNSの名前解決によって相手ホストのIPアドレスを得ていることだろう。そしてIPルーティングによって、このIPパケットを目的のホストまで転送するためのルータのIPアドレスも分かるはずだ。だが、転送先ホストのMACアドレスまでは分からないため、イーサネット上では転送のすべがない。これは、IPアドレスとMACアドレスに相関性がなく、IPアドレスが与えられただけではMACアドレスが分からないからだ。
このIPアドレスからMACアドレスへの変換を行うためのプロトコルが「ARP(Address Resolution Protocol)」だ。
![]() |
図3 ARPの実行例。ARP要求では、送信先MACアドレスにブロードキャスト・アドレス(「ff:ff:ff:ff:ff:ff」)を指定する。ホストBは、受け取ったARP要求の「要求先IPアドレス」が自身であったため、ARP応答によって自身のMACアドレスを返答する。その際に、ホストBは、ARP要求から判明したホストAのMACアドレスをARPテーブルへとキャッシュする(つまりARPは2往復する必要はない) |
ARPの根本は、ARPパケットと呼ばれる特殊なフォーマットのパケットだ。プロトコル・スタック(ネットワーク階層)でいえば、ほぼIPパケットと同じレイヤ(ネットワーク層)に位置し、イーサネット・フレームに含まれたパケットと思えばよい。
ARPでは、変換したいIPアドレスを指定して、物理ネットワーク内のすべてのホストに対してMACアドレスを問い合わせる。該当するIPアドレスのホストは自身のMACアドレスを返答し、両者は互いのMACアドレスを把握する。イーサネットによる通信が可能になるのである。
ARP要求は通常のイーサネット・フレームなどとは異なり、すべてのホストに受け取らせて判断させなければならない。そのため、ARP要求の送信先アドレスでは、イーサネット・フレームの送信先アドレスとして「ff:ff:ff:ff:ff:ff」という特殊なアドレスが指定される。これを「ブロードキャスト・アドレス」と呼び、このアドレスのフレームはすべてのホストが受信しなければならない。また、このような要求の方法を「ブロードキャスト」と呼ぶ。つまり、ネットワーク全体へ大声で呼びかけているようなものだ。またARP要求の段階では、要求先MACアドレス(つまり目的ホストのMACアドレス)はまだ分からないため、「00:00:00:00:00:00」という一種の空白値が入っている。
しかし、毎回このような問い合わせをしていては大変効率が悪い。そこで、多くのホストやルータでは、問い合わせで判明したIPアドレスとMACアドレスの対照表を一定期間メモリにキャッシュして、以前問い合わせたことのあるIPアドレスはそこから参照するという手法をとるのが一般的だ。これが「ARPテーブル」または「ARPキャッシュ」と呼ばれるものである。
|
||||||||||||
表1 一般的なARPテーブルのイメージ。OSなどにより保持するデータに違いはあるが、最低限以下のようなデータが必要となる |
イメージとしては、IPルーティングにおける「ルーティング・テーブル」やDNSにも似ているかも知れない。だが、ARPテーブルは比較的「揮発性」の高いキャッシュであり、常にこれまで通信したすべてのホストの情報が記載されているとは限らない。一度キャッシュされたエントリーであっても、再利用されない限りはOSが自動的にエントリーを削除してしまうのだ(Windows 2000の場合、最短10分)。また、必要とするホストがARPテーブル内に載っていなくとも、ARPによって再度MACアドレスを取得すればいいだけだ。サーバやルータなど、比較的利用頻度の高いエントリーだけがメモリに残り続け、同時にARPの手間もなくなるので非常に効率的な運用が可能になるのである。
ARPテーブルは単純なIPアドレスとMACアドレスの対照表でしかなく、エントリーの最大数はその物理ネットワーク内のホスト数に依存する(OSとしての制限もある)。しかし、ほとんどの場合、すべてのホストと通信し合っているわけではないので、比較的少ないエントリーしか保持されていないことだろう。
ただし、ARPテーブルはホストやルータが持つインターフェイスごとに保持される必要がある。複数のインターフェイスが存在する場合には、それだけARPテーブルは大きくならざるを得ない。
|
時として、「Proxy ARP」と呼ばれる仕組みが使用されることもある。これはおもにルータが実装する機能で、名前通り、特定のネットワーク機器が別のホストのためにARPを仲介する機能のことだ。仲介されるホストからすれば、実際にはルータの向こうの相手が同一のネットワークにいるように見えるだろう。つまり、元々は異なるコリジョン・ドメイン同士を無理やりくっつけてしまうのだ。
一般に、コリジョン・ドメインが大きくなることは、それだけ全体のネットワーク負荷も増大する。一体何に使うのかと思われるかも知れないが、現在では1つのサブネットを複数のサブネットへと分割する際の移行期などによく使用される。ホストの設定を一気に変更せずにとりあえずルータだけを設置して、実際の運用においてはルータのProxy ARP機能により、複数のコリジョン・ドメインを1つのサブネットとして仮想的に運用する。そしてその後、ホストの設定を順に変更していけば、ネットワークを極力止めず、かつ管理負担を減らしての移行が可能になるわけだ。
管理者にとっては重宝する機能なのだが、逆にいえば、ろくにサブネット化もせずにネットワークを構築できてしまう手段でもあり、多用し過ぎて機器のリプレース時などにトラブルを起こしてしまう、という話もよく聞く。無計画な使いすぎにはご注意。
関連ネットワーク・コマンド/ツール | |
arp 〜ARPテーブルの表示/設定を行う |
|
![]() |
「Master of IP Network総合インデックス」 |
本企画では、各種コマンド/ツール紹介やそれらを活用したTipsを順次追加、各種索引を用意して、読者の方々に手軽にご利用いただける、便利なリソース集としてアップデートしていく予定です。ぜひご期待ください。
![]() |
|
![]() |
7/16無料セミナー in丸の内 ◆プロジェクトの度重なる仕様 変更に柔軟に対応する方法
目指す第二新卒を期間限定募集 ------------------------- 【無料】あなたに合った 最新の仕事情報をメール配信
プロフェッショナル編 ◆UMLモデリングを 業界第一人者が伝授!
開発技術書プレゼント
真のリアルタイムOSに ◆もっと上をめざす 開発者のためのギルド ◆check!あなたのPC 本当はもっと速い! ◆ソフトウェア開発者へ贈る セキュアなコードへの第一歩 ◆顧客に提案ができる自立したエ ンジニアになるには? ◆持ち込みPCなどによる脅威と クライアント・セキュリティ ◆24時間365日無料サポート レンタルサーバの有力候補 ◆SPSS Data Mining Day 2004 詳細なイベントレポート公開 ◆手軽に使えるASP型VPN 「GMOどこでもLAN」登場! ◆オブジェクト指向と業務コン サルのその先にある技術とは? ◆組み込み開発の常識を変える 「intent」の衝撃!全容紹介
|
|
|||||||||
@IT [FYI] 注目記事 ![]() ![]() ![]()
|
Master of IP Networkフォーラムスポンサー |
Copyright(c) 2000-2004 atmarkIT 著作権はアットマーク・アイティまたはその記事の筆者に属します @ITに掲載されている記事や画像などの無断転載を禁止します 「アットマーク・アイティ」「@IT」「@IT自分戦略研究所」「@ITハイブックス」は、株式会社アットマーク・アイティの登録商標です 弊社へのご連絡は「アットマーク・アイティへのお問い合わせ」をご覧ください |