dhclientがT1 / T2タイマーではなく、約15秒ごとにユニキャストDHCPREQUESTを発行するのはなぜですか？
CentOS 6.2サーバーをゲートウェイとファイアウォールとして実行していますが、内部サービスも提供しています。これは、さまざまなハードウェアとディストリビューション（redhatベース）を使用して何年もの間行ってきた設定です。最近、インターネット接続の問題に遭遇しましたが、これはISP（Roadrunner、アップステートニューヨーク）の欠陥か、dhclientの設定（デフォルト）の欠陥が原因であると考えています。
このサーバーではNetworkManagerを使用していません。ネットワーク構成が静的で、サーバーがゲートウェイとして24時間年中無休で稼働しているためです。私のsysconfigネットワークスクリプトインターフェース設定は以下のとおりです：
起動時にインターフェースを構成し、dhclientユーティリティを介してDHCPを使用します。ルーティング/ NAT機能を提供するために何年にもわたって継続的に取り組んでいる有効なiptablesファイアウォールスクリプトがありますが、それは私の問題とは無関係です。
過去1〜2週間（少なくとも、しばらくの間これらのログエントリのオンとオフを確認しました）ISPから提供されたDHCPリースが中間点に到達して更新をトリガーすると、dhclientがループに入り、 15秒間、/ var/lib/dhclient/dhclient-eth1.leasesファイルで指定されたDHCPサーバーエントリにユニキャストDHCPREQUESTを発行します（以下を参照）。これは、ネットワーク接続が切断されるか、最終的にブロードキャストを検出して新しいリースを適切に受信するまで、数時間続きます。
Dhclient要求ループは常にユニキャストであり、更新しようとしているリースで指定されたDHCPサーバーアドレスを常に使用し、これらの各要求に対して常に同じxid値を使用します。更新のためにユニキャストのREQUESTパケットの代わりにdhclientが常にブロードキャストDHCPDISCOVERを発行するように強制する方法はあるのでしょうか。構成に問題があるのでしょうか、それともTime Warnerの不安定なDHCPサービスだけですか？私は過去5年間、ISPとしてTWCを使用しており、Linuxをゲートウェイとして使用したときにこの問題が発生することはありませんでした。
これが私のインターフェース設定スクリプトです：
/etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
NAME=Internet
HWADDR=00:D0:B7:**:**:**
MTU=1500
BOOTPROTO=dhcp
PEERDNS=no
IPV6INIT=no
ONBOOT=yes
Dhclient-eth1.leasesファイルの例を示します（現在ですが、ループは6〜8時間で開始されます）
lease {
interface "eth1";
fixed-address 74.***.***.***;
option subnet-mask 255.255.240.0;
option routers 74.***.***.***;
option dhcp-lease-time 43200;
option dhcp-message-type 5;
option domain-name-servers 209.18.47.61,209.18.47.62;
option dhcp-server-identifier 10.111.64.1;
option interface-mtu 576;
option broadcast-address 255.255.255.255;
option domain-name "rochester.rr.com";
renew 3 2012/01/18 21:51:02;
rebind 4 2012/01/19 02:57:58;
expire 4 2012/01/19 04:27:58;
}
この問題に関する/ var/log/messagesからの抜粋（午前12時30分頃に始まり、午前11時30分まで続く：
... DHCPREQUESTの長いリストは以下とほぼ同じ
Jan 17 16:50:59 server dhclient[1384]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x54a5b374)
Jan 17 16:51:13 server dhclient[1384]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x54a5b374)
Jan 17 16:51:21 server dhclient[1384]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x54a5b374)
Jan 17 16:51:31 server dhclient[1384]: DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0x54a5b374)
Jan 17 16:51:31 server dhclient[1384]: DHCPACK from 10.111.64.1 (xid=0x54a5b374)
Jan 17 16:51:31 server dhclient[1384]: bound to 74.69.54.153 -- renewal in 17309 seconds.
最終的に、試行の長いリストの後にDHCPACKを取得したようです。
昨日の午後7時30分頃、16：51の上記のログエントリをはるかに超えて、他の理由でサーバーを完全に再起動したため、以下のREQUEST行が表示されます。
Jan 17 20:11:51 server dhclient[3872]: DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0x4a4507ce)
Jan 17 20:11:51 server dhclient[3872]: DHCPACK from 10.111.64.1 (xid=0x4a4507ce)
Jan 17 20:11:51 server dhclient[3872]: bound to 74.69.54.153 -- renewal in 17073 seconds.
Jan 18 00:56:24 server dhclient[3917]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x4a4507ce)
Jan 18 00:56:32 server dhclient[3917]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x4a4507ce)
Jan 18 00:56:46 server dhclient[3917]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x4a4507ce)
Jan 18 00:57:04 server dhclient[3917]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x4a4507ce)
Jan 18 00:57:24 server dhclient[3917]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x4a4507ce)
....上記の数時間および多くの行の省略、〜15秒ごとここで、手動でインターフェイスを上下に移動しました。
Jan 18 11:27:29 server dhclient[3917]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x4a4507ce)
Jan 18 11:27:45 server dhclient[3917]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x4a4507ce)
Jan 18 11:27:52 server dhclient[3917]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x4a4507ce)
Jan 18 11:27:58 server dhclient[16174]: DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0x63741216)
Jan 18 11:27:58 server dhclient[16174]: DHCPACK from 10.111.64.1 (xid=0x63741216)
Jan 18 11:27:58 server dhclient[16174]: bound to 74.69.54.153 -- renewal in 19384 seconds.
私はファイアウォールの断片化に関して常にいくつかのMTUの問題を抱えていましたが、それはここでは根本的な原因ではないようで、もしあれば別の質問になります。
同じISP（RoadRunner）で同じ問題が発生しました。 RRが無効または到達不可能なdhcp-server-identifierホストIPを提供しているようです。 ISPが問題を修正したとしたらいいのですが、/etc/dhcp/dhclient.confに次のものを追加できます（ディストリビューションによって場所が異なる場合があります）。
interface "ethX" {
supersede dhcp-server-identifier 255.255.255.255;
}
これにより、クライアントは応答で提供されたDHCPサーバーのIPアドレスを無視し、DHCPREQUESTにブロードキャストを送信します。これはハックです。それはおそらく管理RFCに違反しますが、私にとってはうまくいきます。
ケーブルプロバイダーにこの問題があります。ユニキャストDHCPREQUESTパケットには応答しません。私が使う：
iptables -t nat -A OUTPUT -d 10.0.0.0/255.0.0.0 -o eth1 -p udp -m udp --dport 67 -j DNAT --to-destination 255.255.255.255
これらを放送に変えると、問題はなくなります。
私もこれを持っていました。問題は、dhclientがユニキャスト（サーバーIP）要求をISPに送信していて、ISPがユニキャストのみのマルチキャスト（255.255.255.255）を受け入れないことです。ユニキャストが失敗しても、dhclientはマルチキャストにフォールバックするはずですが、失敗しません。再バインドまたは期限切れになるまで（どちらかわからない）、それは数日後になる可能性があります。
私の解決策は、/ etc/crontabからrootでこのスクリプトを毎日実行することでした
#!/bin/bash
/usr/bin/killall -vw dhclient
/sbin/dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0 -cf /etc/dhcp/dhcpd.conf eth0
最初の行は、ユニキャスト要求を送信している既存のdhclientを削除します。 2行目は、マルチキャストを使用する新しいインスタンスを開始します。
スクリプトを実行可能にします
chmod 755 /root/renew.sh
/ etc/crontabに次のような行を追加します
10 1 * * * root /root/renew.sh
ファイアウォールルールが奇妙であるか、ダイレクトDHCP要求を許可しないことに関するサービスプロバイダー側の奇妙な設定が原因であると考えられます。 DHCPクライアントはおそらく正常に動作しています。
クライアントがRENEW時間に達すると、ユニキャストDHCPREQUESTSを送り返して、最小限の更新を試みます。
EXPIRE時間に達すると、ブロードキャストが再開されます。貼り付けたログからそれがわかります。
Dhclientの強制終了、リースファイルのスクラブ、dhclientの再起動など、不器用なことを行うと、正常に動作する場合があります。しかし、実際には必要ありません。
ネットワーク接続が実際に切断されたときのログはありますか？