
連載:ネットワーク・コマンドでトラブル解決(4)
イーサネット通信は正しく行われているか?
〜arpによるARPテーブルの確認と設定〜
加地眞也
2001/11/29
|
■イーサネット通信の仕組み
IPパケットのルーティングは、データリンク層のプロトコルであるイーサネットの仕組みにより、ホストからルータ、ルータから別のルータへと中継(リレー)が行われることで実現されている。イーサネットから見れば、中継されるIPパケットはイーサネット・フレーム(「フレーム」はデータリンク層におけるパケットの呼び名)に含まれるデータとして扱われ、さまざまなネットワーク機器間を転送される。
このように、イーサネットはIPネットワークの下層プロトコルとして、最小のネットワーク通信をつかさどる。普段はIPネットワークよりも表面に見えることはないが、実際には通信の根底を支える重要な要素なのである。
IPルーティングでは、送信先ホストが同一のサブネット内のホストであった場合にはそのホストへ直接、ほかのサブネットであった場合には経路として指定されているルータへとIPパケットを転送することになるが、これらに共通することは、IPパケットの転送先が自身と同じサブネット(通常は「セグメント」と呼ばれる、同一の物理ネットワーク)内のネットワーク機器という点である。つまり、イーサネットは、このような最小の物理ネットワーク内の通信だけに特化したプロトコルなのだ。
IPネットワークがIPアドレスを各ホストに割り当てて“目印”としているように、イーサネットにおいてもホストやルータを見分ける目印が必要になる。これが「MACアドレス(イーサネット・アドレス)」だ。「物理アドレス」「データリンク・アドレス」などと呼ばれることもある。それぞれ、微妙に意味する範囲や定義も異なるが、イーサネット+IPネットワーク環境においては、ほぼ同じ意味だと思っていい。
![]() |
| 図1 MACアドレスのフォーマット |
イーサネットにおける通信は非常に単純なものだ。IPネットワークと同様に、イーサネット・フレームは送信先MACアドレスと送信元MACアドレスを持ち、フレームの送信先MACアドレスが自身のものであれば受け取ることになる。
イーサネット・フレーム自体は、IPパケットのようにほかのネットワークへと転送されることはない。フレームは、ただ物理ネットワーク内全体に対し送出されて、相手に受け取られて終わりだ。ここでいう物理ネットワークとは、電気的に直接接線されて、フレームが直接届く範囲のネットワークを示している。イーサネットの通信範囲とは、この物理的な接続範囲に限られる。ネットワーク全体から見ると、非常に狭い範囲である。これが「コリジョン・ドメイン(衝突ドメイン)」だ。
![]() |
| 図2 イーサネット・フレームとコリジョン・ドメインの関係 |
イーサネット・フレームは、送出と同時にほかのホストから送出されたフレームと衝突が起こり、再送の必要が出る可能性がある。フレームの衝突が起こる可能性があるのは、物理的に同じネットワークに接続されたホスト同士の通信に限られる。言い換えれば、フレームが直接到達し得ない場所にあるホストやルータとは、フレームの衝突のしようがないはずだ。従って、コリジョン・ドメインとは、フレームが直接到達可能なネットワークの範囲でもあるのだ。
■IPアドレスとMACアドレスの対応をいかに見つけるか?
ところで、フレームの送信に必要な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」とは?
時として、「Proxy ARP」と呼ばれる仕組みが使用されることもある。これはおもにルータが実装する機能で、名前通り、特定のネットワーク機器が別のホストのためにARPを仲介する機能のことだ。仲介されるホストからすれば、実際にはルータの向こうの相手が同一のネットワークにいるように見えるだろう。つまり、元々は異なるコリジョン・ドメイン同士を無理やりくっつけてしまうのだ。
一般に、コリジョン・ドメインが大きくなることは、それだけ全体のネットワーク負荷も増大する。一体何に使うのかと思われるかも知れないが、現在では1つのサブネットを複数のサブネットへと分割する際の移行期などによく使用される。ホストの設定を一気に変更せずにとりあえずルータだけを設置して、実際の運用においてはルータのProxy ARP機能により、複数のコリジョン・ドメインを1つのサブネットとして仮想的に運用する。そしてその後、ホストの設定を順に変更していけば、ネットワークを極力止めず、かつ管理負担を減らしての移行が可能になるわけだ。
管理者にとっては重宝する機能なのだが、逆にいえば、ろくにサブネット化もせずにネットワークを構築できてしまう手段でもあり、多用し過ぎて機器のリプレース時などにトラブルを起こしてしまう、という話もよく聞く。無計画な使いすぎにはご注意。
| 関連ネットワーク・コマンド/ツール | |
| arp 〜ARPテーブルの表示/設定を行う |
|
|
ネットワークトラブル解決法
|
|
ネットワークコマンド使い方
|
ネットワーク・コマンドでトラブル解決
トラブルシューティングに便利な各種コマンド/ツール事典。各ツールの活用法をまとめたTipsも順次アップデート!
- 第1回 つながらないネットワークの原因を特定する!
- 第2回 ネットワークトラブル、まずはホストの設定を見直そう!
- 第3回 ルーティングのトラブル、まずはその仕組みから理解!
- 第4回 イーサネットの通信は正しく行えているか?
- 第5回 TCP/UDPの接続ステータスを確認しよう!
- 第6回 DHCPの自動設定機能をうまく使いこなすコツは?
- 第7回 DNSの設定と動作は正しいか?
コマンドを使ってトラブルシューティング
社内のPCが突然、メールを受信できなくなり、Webも見られない環境になってしまった。そんなとき、どのように対処するべきか
- 第1回 LANから外に出られない!?
- 第2回 どうして課長だけプリントできない?
- 第3回 ネットワークに同じIPアドレスが2つある?
- 第4回 同じメールしか受信できない!?
- 第5回 ファイルがアップロードできない?
- 第6回 私だけネットワークにつながらない!?
- 第7回 特定のサイトにだけアクセスできない
- 第8回 無線LANでメールがたまに受信できない?
- 第9回 外部を勝手に攻撃しているのは誰?
- 第10回 夜になるとネットワークが遅くなる?
- 最終回 怪しいサイトに飛ばされるんだけど
ツールを使ってネットワーク管理
名前しか知らない後輩君がやってきた。彼によると、コマンドはすでに古くツールがクールだという。ならば教えてもらおうではないか
- 第1回 後輩のツール君曰く、コマンドはもう古い!?
- 第2回 勝手にネットにつないでるマシンを探せ!
- 第3回 私用メールする子にお仕置きを
- 第4回 OSやアプリケーションの箱がなくなっても大丈夫?
- 第5回 俺の「パスワード:*****」って何でしたっけ?
- 第6回 ユーザー名と同じ安易なパスワードを撲滅せよ!
- 第7回 いきなりナウでヤングなWebサイトを管理しろって……
- 第8回 「POPFile」でスパムと無駄な時間は除去じゃ!
- 第9回 それはスパムか否か、POPFileの振り分けを鍛える
- 第10回 情報漏洩防止のためにPC監視!?「WatchYourPC」
- 第11回 とにかく社内でWinnyの起動をやめさせたい
- 第12回 USBでコピーデータを家に持ち帰らせたくない
- 第13回 パスワード、記憶に頼っていて大丈夫?
- 第14回 サーバ異常をメールで知らせる統合監視ツール
- 第15回 メールサーバがいっぱいですよ、と警告されたら
- 第16回 出張中のメール送信にご用心!
- 第17回 安いホスティングに引っ越しって簡単にいうけど
- 第18回 WebサーバにFTPできないんですけど……
- 第19回 PC環境の移行。あなたならどうする?
- 第20回 サーバのリモートバックアップをさせたい
| 「Master of IP Network総合インデックス」 |
TechTargetジャパン
- 実機では測定できない性能を測定? (2012/2/7)
システムの完成前に、達成し得る性能値や必要なサーバリソースを知るには? その解となる「性能シミュレーション技法」を解説 - 性能チューニング個所の検討 (2012/1/30)
アプリのチューニングや環境増強で、どの程度改善が見込める? 今回からは「実際に活用できる性能対策」を解説します - 遅いところを直すだけでいいのですか? (2012/1/24)
負荷が集中したときの性能ボトルネックを改善するのに、アプリケーションサーバとDB、どちらを優先すべきでしょう? - cloudfoundry.comを使ってみよう (2012/1/19)
VMwareが提供するPaaSプラットフォーム「CloudFoundry」。注目を集めるこの基盤を活用してPaaSを構築!
|
|
キャリアアップ
スポンサーからのお知らせ
- - PR -
イベントカレンダー
- - PR -




