为什么dhclient每隔15秒发送一个单播DHCP REQUEST而不是在T1 / T2定时器?

我运行一个CentOS 6.2服务器作为我的网关和防火墙,同时也提供一些内部服务。 这是我多年来使用各种硬件和发行版(基于Redhat)的设置。 最近我遇到了一个互联网连接问题,我认为这是由于我的ISP(Roadrunner,纽约州北部)或我的configuration(默认)dhclient的缺陷。

我没有在这台服务器上使用NetworkManager,因为networkingconfiguration是静态的,服务器24/7作为网关运行。 我有我的sysconfignetworking脚本接口configuration如下:

它已经通过dhclient工具configuration了启动界面和使用DHCP。 我有一个有效的iptables防火墙脚本,我一直在不断努力提供路由/ NATfunction,但这与我的问题无关。

在过去的一两周里(至less我已经看到这些日志条目已经有一段时间了),我看到一旦我的ISP提供的DHCP租约达到了中间点,触发了一个更新,dhclient进入一个循环, 15秒,它向/var/lib/dh​​client/dhclient-eth1.leases文件中指定的DHCP服务器条目(见下文)发出单播DHCPREQUEST。 这会持续几个小时,直到networking连接断开或最终尝试广播发现并正确接收新的租约。

dhclient请求循环始终是单播的,始终使用在其尝试续订的租约中指定的DHCP服务器地址,并且对每个请求始终使用相同的xid值。 我想知道,有没有办法强制dhclient总是发布广播DHCPDISCOVER而不是单播REQUEST数据包进行更新? 是否有可能的configuration问题,或者这只是时代华纳的片状DHCP服务? 在过去的5年中,我使用TWC作为我的ISP,在使用Linux作为网关时从来没有遇到过这个问题。

这是我的界面configuration脚本:

/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点半左右,在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的问题,但这似乎并不是这里的根本原因,如果有的话,将是一个单独的问题。

我的电缆供应商有这个问题。 它们不响应单播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 – 到目的地255.255.255.255

把这些变成广播,问题就消失了。

我有同样的问题与同一个ISP(RoadRunner)。 它看起来像RR提供了一个无效的或不可达的DHCP服务器标识符主机IP。 虽然如果ISP解决了这个问题会很好,但可以在/etc/dhcp/dhclient.conf添加以下内容(您的发行版中的位置可能不同):

 interface "ethX" { supersede dhcp-server-identifier 255.255.255.255; } 

这将导致客户端忽略响应中提供的DHCP服务器的IP地址,并为DHCPREQUEST发送一个广播。 这是一个黑客。 它可能违反了RFC的控制,但它适用于我。

这很可能是由于奇怪的防火墙规则或服务提供商端的不允许定向DHCP请求的奇怪configuration。 您的DHCP客户端很可能正常运行。

当客户端到达RENEW时间时,它将发送单播DHCPREQUESTS尝试和更新至less。

当它到达EXPIRE时间时,它会再次开始播放。 这就是我们从粘贴的日志中看到的。

做一些事情如杀死dhclient,擦洗租约文件,重新启动dhclient可能会使事情工作。 但真的不应该要求。

当networking连接中断时,你有没有logging?

我也有这个,问题是dhclient向ISP发送单播(服务器IP)请求,我的ISP不接受单播多播(255.255.255.255),当单播失败时,dhclient应该回退到多播,但是它不似乎这样做,直到重新绑定或到期(不知道哪个),那可能是几天后。

我的解决scheme是每天使用/ 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。 第二行开始使用多播的新实例。

使脚本可执行

 chmod 755 /root/renew.sh 

像这样添加一行到/ etc / crontab

 10 1 * * * root /root/renew.sh