DHCP Failover questions

[Jason Frisvold]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/13/2009 06:04 PM, David W. Hankins wrote:
> You are running a 3.0.x release.  3.0.x matches based upon the far
> side's IP address, so you can get away with mis-naming the
> relationships.  However this doesn't allow you to have more than one
> relationship between two IPv4 addresses, so when we were trying to
> sync 3.1.x up to the latest failover draft, we adopted that part of
> the draft's direction; the match is now done based on the relationship
> name.

I'm still having problems getting load balancing to work (I believe) ..
 I've configured the lab environment with the suggestions I've received
thus far and restarted the servers.  One goal here is to try and keep
the existing leases, if only to prevent further problems with clients.
(Windows apparently behaves badly when confronted with conflicting IPs)

Even with the changes I'm still seeing duplicate offers with no load
balancing.  For instance, from my test machines :

dhcp0:

Nov 16 13:02:40 dhcp0 dhcpd: pool 9f92f60 192.168.2.64/26 total 61  free
32  backup 29  lts -1
Nov 16 13:02:40 dhcp0 dhcpd: DHCPDISCOVER from 00:1c:df:3f:e6:ca via
192.168.2.65
Nov 16 13:02:40 dhcp0 dhcpd: DHCPOFFER on 192.168.2.92 to
00:1c:df:3f:e6:ca via 192.168.2.65

dhcp1:

Nov 16 13:02:40 dhcp1 dhcpd: pool 2b53124d0c70 192.168.2.64/26 total 61
 free 32  backup 29  lts 1
Nov 16 13:02:40 dhcp1 dhcpd: DHCPDISCOVER from 00:1c:df:3f:e6:ca via
192.168.2.65
Nov 16 13:02:40 dhcp1 dhcpd: DHCPOFFER on 192.168.2.102 to
00:1c:df:3f:e6:ca via 192.168.2.65


The configuration is as follows :

dhcp0:

#
# DHCP Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd.conf.sample
#
min-lease-time 3600;
max-lease-time 86400;
default-lease-time 86400;

allow bootp;
allow booting;

option domain-name "example.com";
option domain-name-servers 192.168.0.53 , 192.168.1.53;

ddns-update-style ad-hoc;
ddns-updates off;

key OMAPI {
   algorithm hmac-md5;
   secret sooperseekritkey;
};

omapi-port 7911;

failover peer "dhcp" {
   primary;
   address 192.168.0.67;
   port 647;
   peer address 192.168.1.67;
   peer port 647;
   max-response-delay 60;
   max-unacked-updates 10;
   mclt 3600;
   split 128;
   load balance max seconds 3;
}

include "/etc/dhcpd/dhcpd-primary.cfg";

And dhcp1:

#
# DHCP Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd.conf.sample
#
min-lease-time 3600;
max-lease-time 86400;
default-lease-time 86400;

allow bootp;
allow booting;

option domain-name "example.com";
option domain-name-servers 192.168.0.53 , 192.168.1.53;

ddns-update-style ad-hoc;
ddns-updates off;

key OMAPI {
   algorithm hmac-md5;
   secret sooperseekritkey;
};

omapi-port 7911;

failover peer "dhcp" {
   secondary;
   address 192.168.1.67;
   port 647;
   peer address 192.168.0.67;
   peer port 647;
   max-response-delay 60;
   max-unacked-updates 10;
   load balance max seconds 3;
}

include "/etc/dhcpd/dhcpd-secondary.cfg";

Initially, the primary and secondary files varied in nameserver order.
Thinking this might be an issue, I copied the primary file to both
servers and I'm now using that.  I still get the same problem, though.

The primary file is as follows:

subnet 192.168.0.0 netmask 255.255.255.0 {
        option routers 192.168.0.1;
        option domain-name-servers 192.168.0.53 , 192.168.1.53;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
        option routers 192.168.1.1;
        option domain-name-servers 192.168.0.53 , 192.168.1.53;
}

subnet 192.168.2.64 netmask 255.255.255.192 {
        option routers 192.168.2.65;
        option domain-name-servers 192.168.0.53 , 192.168.1.53;
        pool {
                deny dynamic bootp clients;
                failover peer "dhcp";
                range 192.168.2.66 192.168.2.126;
        }
}

Both dhcp servers are in a normal failover state as can be seen via omshell:

partner-state = 00:00:00:02
local-state = 00:00:00:02

So what am I missing?  Any ideas?

> Even though 3.0.x allows you to get away with it, best to make the
> change now so you won't have to panic when you upgrade to
> 3.1/4.0/4.1/4.2...

So far we're staying with the RHEL releases, so 3.0.5 seems to be the
current standard.  However, I can be persuaded to look at later releases.

- -- 
- ---------------------------
Jason Frisvold
Network Engineer
frisvolj at lafayette.edu
- ---------------------------
"What I cannot create, I do not understand"
   - Richard Feynman
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAksBo6oACgkQO80o6DJ8UvnCPwCfVZAXlOFPF9aC2uBjBe1tmSaM
AwEAn0a9rlX33ZS9qScEYZCOGMmi3dx2
=M0nt
-----END PGP SIGNATURE-----