replyを返したとする。tableを学習する。tableを学習する。Advertisement)のやり取りが必要となる。RequestはOSの実装にもよるが、大抵はunicastになる。RFC826の一番下方に一応記載があるが、非常に分かりづらい。IPの情報はどこにあるんだよ?というとそれらの情報はARPのヘッダに記載されている。百聞は一見にしかずだと思うので、パケットキャプチャの画面キャプチャを貼っておくこれも、だからどーした、と思われる話かもしれないが、QoSなどでARPをACLでひっかけるときに注意が必要になる。要はIPパケットではないので、255.255.255.255といった形でIPベースでの表現では引っかけられないのだ。ARP"みたいにARPとして引っかけるかしかない。Requestを投げたとしよう。Ethernetアドレスはff:ff:ff:ff:ff:ffでブロードキャスト。これを受信した同一セグメントの全マシンはEthernetアドレスを見ただけでは「もしかしたら自分かも」と考え、ARPパケットの中身を見て、ようやく自分は関係ない、ということで破棄をする。ARPの中身を見て判断、という時点でNICレベルでの処理は難しく、CPUまで判断を仰ぐ形になる。address)を使うので、賢いNICだったら、NICレベルで破棄できるのだ。(昔検証したがトラウマになりその後二度と検証できていない)トラフィック切替時のARP学習に注意しよう例えば、Active/Standbyの冗長構成のL3スイッチをメンテナンスでトラフィックを切り替えることを想定しよう。tableを持っていない宛先に対して急いでARP学習をしないといけない。Replyを受信しきれず、上手くARP解決されないことがある。Requestの再送は行われなかったりする要は運が悪いと何故か20秒程度切り替えに時間がかかる、ということが発生し得るのだ。この手の障害があった際にはARPを疑ってみよう。upするやいなやその部分にトラフィックが流れ、通信が始まるような場合、まずARP解決をしなくてはいけない。RequestがL3スイッチBでdropされてしまうことがあり得る。RequestでARP解決されるはずだが、L3スイッチA側からのみ通信が始まるような通信の場合、運が悪いと通信が始まるまでに20秒程度時間がかかることがあったりする。この手のトラブルはなかなか気づかず、ついつい気のせい木の精、などと言ったりすることが多いが、そんなことはない。expireされるある一定時間前にARP更新のRequetstが(Unicast)で行われる。Requestを送信するものがあったりする。RequestのReplyを処理できない、というなんともお粗末な事象が起きたりする以上、ARPトラブルあるあるでした。upLoginユーザーは見つかりませんでした。