dhcp failover

[andreash]

Ich setzte RedHat 8.0 mit DHCP 3.0pl1 ein.
Beide DHCP-Server starten ohne Fehler und kommunizieren auch untereinander.
Aber leider bekommt kein Client eine IP-Adresse zugewiesen. Ich habe schon Linux-Clients und auch Windows-Clients getestet.
Es kommt immer die Fehlermeldung:
dhcpd: DHCPDISCOVER from 00:80:c7:23:ab:27 via eth0: not responding (recovering)

Server1 hat den Namen dns1 und die IP-Adresse 192.168.0.1 (Primary DHCP)
Server2 hat den Namen dns2 und die IP-Adresse 192.168.0.2 (Secondary DHCP)

***/var/log/messages
Feb 6 10:29:56 dns1 dhcpd: Internet Software Consortium DHCP Server V3.0pl1
Feb 6 10:29:56 dns1 dhcpd: Copyright 1995-2001 Internet Software Consortium.
Feb 6 10:29:56 dns1 dhcpd: All rights reserved.
Feb 6 10:29:56 dns1 dhcpd: For info, please visit http://www.isc.org/products/DHCP
Feb 6 10:29:56 dns1 dhcpd: Internet Software Consortium DHCP Server V3.0pl1
Feb 6 10:29:56 dns1 dhcpd: Copyright 1995-2001 Internet Software Consortium.
Feb 6 10:29:56 dns1 dhcpd: All rights reserved.
Feb 6 10:29:56 dns1 dhcpd: For info, please visit http://www.isc.org/products/DHCP
Feb 6 10:29:56 dns1 dhcpd: Wrote 0 leases to leases file.
Feb 6 10:29:56 dns1 dhcpd: Listening on LPF/eth0/00:03:47:e6:37:2e/192.168.0.0/24
Feb 6 10:29:56 dns1 dhcpd: Sending on LPF/eth0/00:03:47:e6:37:2e/192.168.0.0/24
Feb 6 10:29:56 dns1 dhcpd: Sending on Socket/fallback/fallback-net
Feb 6 10:29:56 dns1 dhcpd: Wrote 0 leases to leases file.
Feb 6 10:29:56 dns1 dhcpd: Listening on LPF/eth0/00:03:47:e6:37:2e/192.168.0.0/24
Feb 6 10:29:56 dns1 dhcpd: Sending on LPF/eth0/00:03:47:e6:37:2e/192.168.0.0/24
Feb 6 10:29:56 dns1 dhcpd: failover peer dhcp: I move from recover to startup
Feb 6 10:29:56 dns1 dhcpd: Sending on Socket/fallback/fallback-net
Feb 6 10:29:56 dns1 dhcpd: Failover CONNECT to 192.168.0.2 rejected: Connection rejected, time mismatch too great.
Feb 6 10:29:56 dns1 dhcpd: failover peer dhcp: I move from recover to startup
Feb 6 10:29:56 dns1 dhcpd: Starten von dhcpd succeeded
Feb 6 10:30:11 dns1 dhcpd: failover peer dhcp: I move from startup to recover
Feb 6 10:30:12 dns1 kernel: device eth0 entered promiscuous mode
Feb 6 10:30:53 dns1 dhcpd: DHCPDISCOVER from 00:80:c7:23:ab:27 via eth0: not responding (recovering)
Feb 6 10:31:05 dns1 last message repeated 2 times
Feb 6 10:31:06 dns1 login(pam_unix)[813]: session opened for user root by LOGIN(uid=0)
Feb 6 10:31:06 dns1 -- root[813]: ROOT LOGIN ON tty3
Feb 6 10:31:21 dns1 dhcpd: DHCPDISCOVER from 00:80:c7:23:ab:27 via eth0: not responding (recovering)
Feb 6 10:31:57 dns1 dhcpd: DHCPINFORM from 169.254.191.190 via eth0: unknown subnet 0.0.0.0
Feb 6 10:31:57 dns1 last message repeated 2 times
Feb 6 10:31:59 dns1 dhcpd: DHCPDISCOVER from 00:80:c7:23:ab:27 via eth0: not responding (recovering)
Feb 6 10:32:31 dns1 last message repeated 4 times
Feb 6 10:32:43 dns1 last message repeated 2 times
Feb 6 10:32:57 dns1 kernel: device eth0 left promiscuous mode
Feb 6 10:32:59 dns1 dhcpd: DHCPDISCOVER from 00:80:c7:23:ab:27 via eth0: not responding (recovering)

***tcpdump
10:30:53.880057 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x674e867a [|bootp]
10:30:57.883731 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x674e867a secs:24107 [|bootp]
10:31:05.886762 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x674e867a secs:24107 [|bootp]
10:31:21.893219 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x674e867a secs:24107 [|bootp]

***dhcpd.conf (Primary)
ddns-update-style none;
failover peer "dhcp" {
primary;
address 192.168.0.1;
port 519;
peer address 192.168.0.2;
peer port 520;
max-response-delay 60;
max-unacked-updates 10;
mclt 3600;
split 128;
load balance max seconds 3;
}
subnet 192.168.0.0 netmask 255.255.255.0 {
option broadcast-address 192.168.0.255;
default-lease-time 864000;
max-lease-time 864000;
option subnet-mask 255.255.255.0;
pool {
range 192.168.0.50 192.168.0.100;
deny dynamic bootp clients;
failover peer "dhcp";
}
}

***dhcpd.conf (Secondary)
ddns-update-style none;
failover peer "dhcp" {
secondary;
address 192.168.0.2;
port 520;
peer address 192.168.0.1;
peer port 519;
max-response-delay 60;
max-unacked-updates 10;
}
subnet 192.168.0.0 netmask 255.255.255.0 {
option broadcast-address 192.168.0.255;
default-lease-time 864000;
max-lease-time 864000;
option subnet-mask 255.255.255.0;
pool {
range 192.168.0.50 192.168.0.100;
deny dynamic bootp clients;
failover peer "dhcp";
}
}

[brainyartist]

Hi,

vielleicht das mal ändern:

deny dynamic bootp clients;

zu allow

gruß

[andreash]

failover unterstützt keine Bootp-Clients.
wenn ich die Einstellung ändere startet dhcpd mit einer Fehlermeldung

[andreash]

ich habe jetzt ziemlich viel getestet, verschiedene dhcpd.conf und auch eine andere Distribution (Suse 8.1) in der auch die Ports (647, 847) in der etc/services eingetragen sind.
In der etc/hosts habe ich die Namensauflösung für beide Server eingetragen.
Leider immer mit dem selben Fehler.
Was macht eigentlich der Eintrag failover peer "dhcp"?
Brauch ich dafür vielleicht auch eine Namensauflösung?
Ich kann mir nur noch vorstellen, das irgendetwas an der Linux-Konfiguration noch nicht stimmt.
Vielleicht mir jetzt jemand weiterhelfen.

[Manfred.S]

dhcp 3.0 p2

haste gelesen was alles zu beachten ist ?


DHCP FAILOVER
This version of the ISC DHCP server supports the DHCP failover protocol as documented in draft-ietf-dhc-failover-07.txt. This is not a final protocol
document, and we have not done interoperability testing with other vendors' implementations of this protocol, so you must not assume that this implementa-
tion conforms to the standard. If you wish to use the failover protocol, make sure that both failover peers are running the same version of the ISC DHCP
server.

The failover protocol allows two DHCP servers (and no more than two) to share a common address pool. Each server will have about half of the available IP
addresses in the pool at any given time for allocation. If one server fails, the other server will continue to renew leases out of the pool, and will
allocate new addresses out of the roughly half of available addresses that it had when communications with the other server were lost.

It is possible during a prolonged failure to tell the remaining server that the other server is down, in which case the remaining server will (over time)
reclaim all the addresses the other server had available for allocation, and begin to reuse them. This is called putting the server into the PARTNER-DOWN
state.

You can put the server into the PARTNER-DOWN state either by using the omshell (1) command or by stopping the server, editing the last peer state declara-
tion in the lease file, and restarting the server. If you use this last method, be sure to leave the date and time of the start of the state blank:

failover peer name state {
my state partner-down;
peer state state at date;
}

When the other server comes back online, it should automatically detect that it has been offline and request a complete update from the server that was
running in the PARTNER-DOWN state, and then both servers will resume processing together.

It is possible to get into a dangerous situation: if you put one server into the PARTNER-DOWN state, and then *that* server goes down, and the other server
comes back up, the other server will not know that the first server was in the PARTNER-DOWN state, and may issue addresses previously issued by the other
server to different clients, resulting in IP address conflicts. Before putting a server into PARTNER-DOWN state, therefore, make sure that the other
server will not restart automatically.

The failover protocol defines a primary server role and a secondary server role. There are some differences in how primaries and secondaries act, but
most of the differences simply have to do with providing a way for each peer to behave in the opposite way from the other. So one server must be config-
ured as primary, and the other must be configured as secondary, and it doesn't matter too much which one is which.


CONFIGURING FAILOVER
In order to configure failover, you need to write a peer declaration that configures the failover protocol, and you need to write peer references in each
pool declaration for which you want to do failover. You do not have to do failover for all pools on a given network segment. You must not tell one
server it's doing failover on a particular address pool and tell the other it is not. You must not have any common address pools on which you are not
doing failover. A pool declaration that utilizes failover would look like this:

pool {
failover peer "foo";
pool specific parameters
};


The server currently does very little sanity checking, so if you configure it wrong, it will just fail in odd ways. I would recommend therefore
that you either do failover or don't do failover, but don't do any mixed pools. Also, use the same master configuration file for both servers, and
have a seperate file that contains the peer declaration and includes the master file. This will help you to avoid configuration mismatches. As our
implementation evolves, this will become less of a problem. A basic sample dhcpd.conf file for a primary server might look like this:

failover peer "foo" {
primary;
address anthrax.rc.vix.com;
port 519;
peer address trantor.rc.vix.com;
peer port 520;
max-response-delay 60;
max-unacked-updates 10;
mclt 3600;
split 128;
load balance max seconds 3;
}

include "/etc/dhcpd.master";

The statements in the peer declaration are as follows:

The primary and secondary statements

[ primary | secondary ];

This determines whether the server is primary or secondary, as described earlier under DHCP FAILOVER.

The address statement

address address;

The address statement declares the IP address or DNS name on which the server should listen for connections from its failover peer, and also the value
to use for the DHCP Failover Protocol server identifier. Because this value is used as an identifier, it may not be omitted.

The peer address statement

peer address address;

The peer address statement declares the IP address or DNS name to which the server should connect to reach its failover peer for failover messages.

The port statement

port port-number;

The port statement declares the TCP port on which the server should listen for connections from its failover peer. This statement may not currently be
omitted, because the failover protocol does not yet have a reserved TCP port number.

The peer port statement

peer port port-number;

The peer port statement declares the TCP port to which the server should connect to reach its failover peer for failover messages. This statement may
not be omitted because the failover protocol does not yet have a reserved TCP port number. The port number declared in the peer port statement may be
the same as the port number declared in the port statement.

The max-response-delay statement
max-response-delay seconds;

The max-response-delay statement tells the DHCP server how many seconds may pass without receiving a message from its failover peer before it assumes
that connection has failed. This number should be small enough that a transient network failure that breaks the connection will not result in the
servers being out of communication for a long time, but large enough that the server isn't constantly making and breaking connections. This parameter
must be specified.

The max-unacked-updates statement

max-unacked-updates count;

The max-unacked-updates statement tells the DHCP server how many BNDUPD messages it can send before it receives a BNDACK from the failover peer. We
don't have enough operational experience to say what a good value for this is, but 10 seems to work. This parameter must be specified.

The mclt statement

mclt seconds;

The mclt statement defines the Maximum Client Lead Time. It must be specified on the primary, and may not be specified on the secondary. This is the
length of time for which a lease may be renewed by either failover peer without contacting the other. The longer you set this, the longer it will take
for the running server to recover IP addresses after moving into PARTNER-DOWN state. The shorter you set it, the more load your servers will experi-
ence when they are not communicating. A value of something like 3600 is probably reasonable, but again bear in mind that we have no real operational
experience with this.

The split statement

split index;

The split statement specifies the split between the primary and secondary for the purposes of load balancing. Whenever a client makes a DHCP request,
the DHCP server runs a hash on the client identification. If the hash comes out to less than the split value, the primary answers. If it comes out
to equal to or more than the split, the secondary answers. The only meaningful value is 128, and can only be configured on the primary.

The hba statement

hba colon-seperated-hex-list;

The hba statement specifies the split between the primary and secondary as a bitmap rather than a cutoff, which theoretically allows for finer-grained
control. In practice, there is probably no need for such fine-grained control, however. An example hba statement:

hba ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00;

This is equivalent to a split 128; statement. You must only have split or hba defined, never both. For most cases, the fine-grained control that hba
offers isn't necessary, and split should be used. As such, the use of hba is deprecated.

The load balance max seconds statement

load balance max seconds seconds;

This statement allows you to configure a cutoff after which load balancing is disabled. The cutoff is based on the number of seconds since the client
sent its first DHCPDISCOVER or DHCPREQUEST message, and only works with clients that correctly implement the secs field - fortunately most clients do.
We recommend setting this to something like 3 or 5. The effect of this is that if one of the failover peers gets into a state where it is responding to
failover messages but not responding to some client requests, the other failover peer will take over its client load automatically as the clients retry.

[andreash]

Habe Problem gefunden.
Fehler lag an der unterschiedlichen Systemzeit (Differenz von 30 Sekunden).

[Manfred.S]

ah ok gut zu wissen

[Scandan]

Ich hab eine Frage bezüglich der Config-Files.

Und zwar wird die dhcpd.master unbedingt benötigt oder kann ich auch die Ranges einfach in die dhcpd.conf einbinden???