Hi Andrew,
I've done a bit more testing to answer some of your questions. No, it's not dhcp3-server-ldap specific. I've removed all remnants of dhcp3-* from both systems, removed all files and directories on disk that I could 'locate dhcp3', and only reinstalled the dhcp3-client, dhcp3-common and dhcp3-server. With IP addresses used under the failover peer stanza, the failover works fine as previously described. When I change to DNS names, it breaks again. This is definitely a problem in the core dhcp3-server, and the source tree it's built from. Secondly, I don't know if this wasn't a problem under previous debian versions of dhcpd3, as this was the first time I've ever implemented this sort of setup. This was a test installation to iron out the "gotchas" before I instituted a similar setup in production. I'm actually glad to be coming across this problem now and not later :-) Some further information with what happens: When the IP addresses are used in the failover peer stanza, only one DHCP server is authoritative and offers the client an IP address. Should the primarydhcp.example.com go down, secondarydhcp.example.com fills in for it nicely. However as soon as I change the configuration to use the resolvable DNS names, *both* servers start independently offering different IP addresses to the client. The below results are using dhcp3-server only (no dhcp3-server-ldap installed). FYI, 172.16.1.16 = primarydhcp.example.com and 172.16.1.20 = secondarydhcp.example.com. To demonstrate, when failover is working properly (IP addresses used in the failover peer stanza), exampledhcpclient (a windows box), has an IP address issued to it of 172.16.1.150 as shown with an "ipconfig /all": === snip === Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : example.com Description . . . . . . . . . . . : Realtek RTL8169/8110 Family Gigabit Ethernet NIC Physical Address. . . . . . . . . : 00-0A-EB-2F-1A-AB DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 172.16.1.150 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 172.16.1.1 DHCP Server . . . . . . . . . . . : 172.16.1.16 DNS Servers . . . . . . . . . . . : 172.16.1.16 Primary WINS Server . . . . . . . : 172.16.1.16 Lease Obtained. . . . . . . . . . : Monday, 20 July 2009 11:25:43 AM Lease Expires . . . . . . . . . . : Tuesday, 21 July 2009 11:25:43 AM === snip === Then once I've 'broken' the DHCP servers by changing the address and peer address values to DNS names (in the failover peer stanza) as well as subsequently restarted dhcpd on both primarydhcp and secondarydhcp, I run a "ipconfig /release" and a "ipconfig /renew" on exampledhcpclient: === snip === Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : example.com Description . . . . . . . . . . . : Realtek RTL8169/8110 Family Gigabit Ethernet NIC Physical Address. . . . . . . . . : 00-0A-EB-2F-1A-AB DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 172.16.1.50 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 172.16.1.1 DHCP Server . . . . . . . . . . . : 172.16.1.16 DNS Servers . . . . . . . . . . . : 172.16.1.16 Primary WINS Server . . . . . . . : 172.16.1.16 Lease Obtained. . . . . . . . . . : Monday, 20 July 2009 11:40:17 AM Lease Expires . . . . . . . . . . : Tuesday, 21 July 2009 11:40:17 AM === snip === Concurrently, in the logs on primarydhcp I see: === snip === Jul 20 11:40:06 primarydhcp dhcpd: DHCPDISCOVER from 00:0a:eb:2f:1a:ab (exampledhcpclient) via eth0 Jul 20 11:40:06 primarydhcp dhcpd: DHCPOFFER on 172.16.1.50 to 00:0a:eb:2f:1a:ab (exampledhcpclient) via eth0 Jul 20 11:40:06 primarydhcp dhcpd: DHCPREQUEST for 172.16.1.50 (172.16.1.16) from 00:0a:eb:2f:1a:ab (exampledhcpclient) via eth0 Jul 20 11:40:06 primarydhcp dhcpd: DHCPACK on 172.16.1.50 to 00:0a:eb:2f:1a:ab (exampledhcpclient) via eth0 === snip === And on secondarydhcp I see: === snip === Jul 20 11:40:06 secondarydhcp dhcpd: DHCPOFFER on 172.16.1.150 to 00:0a:eb:2f:1a:ab (exampledhcpclient) via eth0 Jul 20 11:40:06 secondarydhcp dhcpd: DHCPDISCOVER from 00:0a:eb:2f:1a:ab (exampledhcpclient) via eth0 Jul 20 11:40:06 secondarydhcp dhcpd: DHCPOFFER on 172.16.1.150 to 00:0a:eb:2f:1a:ab (exampledhcpclient) via eth0 Jul 20 11:40:06 secondarydhcp dhcpd: DHCPDISCOVER from 00:0a:eb:2f:1a:ab (exampledhcpclient) via eth0 Jul 20 11:40:06 secondarydhcp dhcpd: DHCPOFFER on 172.16.1.150 to 00:0a:eb:2f:1a:ab (exampledhcpclient) via eth0 === snip === So both primarydhcp and secondarydhcp are offering exampledhcpclient *different* IP addresses. Obviously, this is Very Bad(TM). We have two dhcp servers believing they are individually authoritative for a single DHCP pool, and both are handing out different IP addresses. IP conflicts will ensue. Furthermore, it seems to be random which server the client responds to. On some trial runs, I've seen exampledhcpclient receive an IP address from primarydhcp. Sometimes it receives it's address from secondarydhcp. When the two dhcp servers come back online I see this single remark in the log on primarydhcp when the leases sync between the two servers in the failover peer "dhcp": === snip === Jul 20 11:43:12 primarydhcp dhcpd: bind update on 172.16.1.150 got ack from dhcp: xid mismatch. === snip === DHCP client behaviour gets a little strange too when you 'fix' the DHCP server configs (revert the failover peer stanza to use IP addresses). Once you've changed the configs back on both servers, and have restarted dhcpd on both servers, the pool balances itself like you would expect. The I run "ipconfig /release" and "ipconfig /renew" on exampledhcpclient and get the following result: === snip === Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : example.com Description . . . . . . . . . . . : Realtek RTL8169/8110 Family Gigabit Ethernet NIC Physical Address. . . . . . . . . : 00-0A-EB-2F-1A-AB DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 172.16.1.50 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 172.16.1.1 DHCP Server . . . . . . . . . . . : 172.16.1.20 Lease Obtained. . . . . . . . . . : Monday, 20 July 2009 11:44:51 AM Lease Expires . . . . . . . . . . : Tuesday, 21 July 2009 11:44:51 AM === snip === It keeps the different IP address (172.16.1.50, instead of reaquiring 172.16.1.150) but suddenly, the DHCP server is not sending or the Windows DHCP client is not receiving, any information about DNS servers (as defined in dhcpd.conf's "option domain-name-servers <value1>, <value2>;". Also odd, is the fact that the DHCP server is listed as secondarydhcp, not primarydhcp as I would have expected. At this point, the Windows DHCP client on exampledhcpclient continually get's these results without fail, until I do a full reboot. I tried stopping and restarting dhcpd on both primarydhcp and secondarydhcp, and running "ipconfig /release" and "ipconfig /renew" on exampledhcpclient, but this does not return it's IP address to 172.16.1.150, nor does it show that DNS server information was provided by the DHCP server. Additionally, I tried stopping dhcpd on primarydhcp and secondarydhcp, and zeroing out the dhcpd.leases, dhcpd.leases~ and dhclient.leases in /var/lib/dhcp3 on both servers before restarting dhcpd. Again, once I ran "ipconfig /release" and "ipconfig /renew" on exampledhcpclient, no DNS server information was present in a "ipconfig /all" output. I even tried a "ipconfig /flushdns" on exampledhcpclient before the release and renew, but this did not resolve the problem either. When in this state, on exampledhcpclient if I run a nslookup I get the following: === snip === C:\Documents and Settings\Administrator>nslookup *** Default servers are not available Default Server: UnKnown Address: 127.0.0.1 > === snip === Only a full reboot of exampledhcpclient, after primarydhcp and secondarydhcp were reconfigured and restarted to use IP addresses in the failover peer stanza fixes this problem. Obviously, this is far from ideal. What's the best move to have this resolved from here? Kind Regards, Stewart _________________________________________________________________ View photos of singles in your area Click Here http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau%2Fsearch%2Fsearch%2Easpx%3Fexec%3Dgo%26tp%3Dq%26gc%3D2%26tr%3D1%26lage%3D18%26uage%3D55%26cl%3D14%26sl%3D0%26dist%3D50%26po%3D1%26do%3D2%26trackingid%3D1046138%26r2s%3D1&_t=773166090&_r=Hotmail_Endtext&_m=EXT
