CentOsを再起動するとARPテーブルのゲートウェイが「incomplete」になる

Question

実現したいこと

1.再起動してもARPテーブルのゲートウェイが「incomplete」にならないようにしたい
2.「1」が出来ない場合、どのような処理をしてARPテーブルを更新すればいいか

前提

VirtualBox上に仮想空間を作成し、ネットワークの勉強をしています。OSはCentOsです。
色々設定を記入したため、設定を保存するためにrebootコマンドで再起動した後pingを打つとネットに繋がらなかった。
色々調べてみると、ARPテーブルのゲートウェイが「incomplete」になっていることが分かった。

発生している問題・エラーメッセージ

再起動すると「incomplete」になる

試したこと

・ゲートウェイ[192.168.2.107]にpingを飛ばすと通信が確立するとあったので試してみたが「目的のホストに到達できません」となり、「incomplete」のままだった
・「nmcli c modify eth0 connection.autoconnect yes」でOS起動時にネットワークに自動で接続できるようにしてみたが、「incomplete」のままだった
・「systemctl restart NetworkManager」でシステムを再起動してみたが、「incomplete」のままだった
・ARPテーブルは再起動する度に削除されるようですが、IPアドレスとMACアドレスを紐づけていれば自動でゲートウェイのARPテーブルが更新される？ようなので
「/etc/sysconfig/netwrok-scripts」のifcfg-eth0ファイルに設定を書き込んでみたが、再起動すると「incomplete」になってしまう

補足情報

おそらく再起動時にゲートウェイが自動起動する設定にしていないためARPテーブルが更新(取得？)できていないと思いますが、サーバー関連について詳しくないため、そのような設定が出来ているのかどうかが分かりません。

仮に再起動すると必ずARPテーブルがリセットされる場合、どのようにしてARPテーブルを更新すればいいでしょうか？
今は再起動する度に「arp -s 192.168.2.107 08:0027:AC:8a:D9 -i eth0」を打ちネットに繋げていますが、このコマンドを入力するときはゲートウェイに対してではなくIPアドレスに対して使うものだと思いますので、対処の仕方を間違っているような気がします。

若輩者にどうかご教授のほど、よろしくお願いいたします

Answer 1

arpテーブルは、arpリクエストに対する応答結果のキャッシュなので、起動直後は空で正常です。

ping 192.168.2.107の結果がどうなるか書かれていませんが、応答が無いのなら、
192.168.2.106 から 192.168.2.107 に対してのarpリクエストの応答が返っていないと言うことでしょう。
応答が返ればその結果がarpテーブルに一定時間残ります。
ゲートウェイのルーターに異常が無いか確認しましょう。再起動もありです。
念のため設定値も確認しましょう。

Comments

[SH-221B]

回答ありがとうございます。
「ping 192.168.2.107」をすると「目的のホストに到達できません」となり、incompleteのままになります。
もう一度ルーターや設定を見直してみます。
ARPテーブルは再起動直後は空なのは正常なのですね。ということは「1.」は実現できないということですね。

追加の質問で申し訳ないのですが、再起動した後は毎度pingを打ったり「arp -s ~」コマンドでARPテーブルを更新しなければならないのでしょうか？
また、「arp -s 192.168.2.107 08:0027:AC:8a:D9 -i eth0」は「192.168.2.106」を対象に実行しなくてもよろしいのでしょうか？

[otn]

> 再起動した後は毎度pingを打ったり「arp -s ~」コマンドでARPテーブルを更新しなければならないのでしょうか？
いいえ。
arpテーブルはキャッシュだと書いた通りで、普通は意図的に更新する物では無いです。

> また、「arp -s 192.168.2.107 08:0027:AC:8a:D9 -i eth0」は「192.168.2.106」を対象に実行しなくてもよろしいのでしょうか？

106は自ホストでは？
そもそも、「ARPとは何か」「arpテーブルとは何か」を理解していないと言うことのようですね。
全ての機器が正しく設定されていて故障も無い場合は意識する必要は無いです。

簡単に書くと、
リンク層の通信はMACアドレスを使って行うので、通信相手のMACアドレスが必要です。上位層からは通信先をIPアドレスで指示されるので、そのIPアドレスを持つ機器のMACアドレスを知る必要があります。そのために使うのがARPプロトコル（ARPリクエストとARP応答）です。
「このIPアドレスの人、あなたのMACアドレスを教えてください」というのがARPリクエストですが、相手のMACアドレスが不明なので相手を指定してのリクエスト送信は出来ず、サブネット全体にブロードキャスト送信します。そのIPアドレスの機器から「私にはそのIPが付いていて、MACアドレスはこれこれです」というARP応答が返されます。通信のたびにこのやりとりをするのは何なので、リクエストと応答の結果は一定時間キャッシュされます。このキャッシュする領域のことをarpテーブルと言います。
なので、通信頻度の低い機器の情報はそのうちarpテーブルから消えます。

余談ですが、ARP応答はこのように自己申告制で、それを信じることで成り立っているので、悪意者がネットワークに潜り込むと、他人宛のARPリクエストに対して「それは私です」と素早く応答することで、通信を横取りできます。ARPスプーフィング攻撃。この攻撃を防ぐために全ての機器を arp -s で登録しておくという運用もあるのかも知れませんが、そうすると今度はMACアドレス詐称が気になります。
arp -s で登録した物はデフォルトでは時間無制限でテーブルに残るようです（再起動や、arp -dでの削除まで）。