障害対応に使う arp
/sbin/arp -e
Address HWtype HWaddress Flags Mask Iface
192.168.100.2 ether 00:18:8B:@@:@@:@@ C eth0
192.168.100.1 ether 00:A0:DE:@@:@@:@@ C eth0
192.168.100.3からコマンドを叩いた結果が上記になる。
ちなみに192.168.100.1はYAMAHAで192.168.100.2はDELLです。
障害発生時に、ここを見て注意する点はIPまたはホスト名対MACアドレスです。
ネットワークを管理する上でMACアドレスを見ただけで機器を判別できるように
記録しておくと良いみたいです。していなければ
「MACアドレス ベンダー 一覧」と検索し、ベンダーコード一覧から調べておく。
管理するネットワーク内で使われているベンダー数は限られている場合が多いので
該当のMACアドレスとベンダーは覚えちゃった方がいいですね。
見方は192.168.100.2なら00188B、192.168.100.1なら00A0DEと
最初の3bitのところです。
このarpを叩いた時にでる一覧はそのサーバが現在持っている通信機器の
IP/MACの紐付け表です。これは自動で行われており、定期的に更新されています。
もし、ここの情報に誤りを発見した場合、修正することができます。
定期的に更新されるテーブルですが、手動で編集した情報は残り続けます。
紐付けの誤りを削除
arp -d 192.168.100.2
紐付けの表を追加
arp -s 192.168.100.2 00:18:8B:**:**:**
この時点で、障害が復旧しても抜本的な解決にはなりません。
自動でこの情報を提供した原因を探します。
また、手動は永続的に残るため192.168.100.2の実機を取り換えたらまた問題が起こります。
Linuxでは、「temp」オプションを指定して、通常のキャッシュ・エントリーとして追加することもできる。ただし、これらの手動追加エントリーは、リブート時にはクリアされてしまう。
http://www.atmarkit.co.jp/fnetwork/netcom/arp/arp.html :ARPテーブルの表示／設定を行う
抜本的な解決が行われたら、忘れずに削除、追加を行い追加時にtempを入れると良い。
抜本的な解決策として、問題があった自身の/etc/ethersを確認と
同じネットワーク内に誤ったホスト、IPの設定をしている機器がないか探す事になる。
/etc/ethersについては以下を参照するとRARPだけの設定に使われていることがわかります。
そもそもこういう設定を行っている環境ならば、いわずもがなチェックするでしょうが
経験もなし、引き継ぎもなしとかなってくるとハマりやすい箇所な気がします。
http://search.luky.org/linux-users.6/msg09306.html :/etc/ethers File ?
ディスクレスで自分のIPを知らないクライアントがハード
ウェアアドレスをブロードキャストで流すと、RARPサーバが自分のRARPテーブル
を見てそのハードウェアアドレスに対応したIPアドレスを教えてやる、というの
がRARP
