Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
My question is that I have 16 linux computers that are connected to a linux server and they use DHCP to obtain their IPs. The problem is that now I want to use another server for this "cluster", and I want that the clients can also ask for their IPs to this new server, so I want to configure this DHCP service with several servers, to load balance.
The problem is that I am not really sure how can I configure the 16 clients of DHCP to select one of the both servers, so how can I configure them??
Here is a simple explanation of how DHCP works:
a client on the network will send DHCP Request broadcast packet and waits for a DHCP server to reply. If there is a DHCP server on the network, the server will reply back and says: Hey ..i'm here. then the client asks for IP configuration then the DHCP server send IP information back ... then the client writes the information to the adapter.
can you guess what happens if you had two DHCP servers on the same network subnet?.... the server that replies first gives out the infomration first ......which is a total mess. For that reason, you can't have two DHCP servers on the same network subnet. There is no option for a DHCP client to choose a DHCP server.
In your case, all you need to do is to configure your new DHCP server's scope with the right options then disconnect the old DHCP server.
Last edited by waelaltaqi; 05-21-2007 at 07:35 AM.
Absolutely you CAN have two DHCP servers on the same subnet handing out addresses in the same subnet.
The key is not allocating the entire IP scope you are handing out to a single server.
DHCP Server A: 192.168.1.50-149
DHCP Server B: 912.168.1.150-249
Make all the other options the two servers hand out identical.
Works like a charm, I have setup several networks in this manner and have never had a problem.
But according with farslayer's answer the two DHCP Servers cannot deliver the same IP's to the clients.
And one question more, the clients need some special configuration??
Quote:
Originally Posted by farslayer
Absolutely you CAN have two DHCP servers on the same subnet handing out addresses in the same subnet.
The key is not allocating the entire IP scope you are handing out to a single server.
DHCP Server A: 192.168.1.50-149
DHCP Server B: 912.168.1.150-249
Make all the other options the two servers hand out identical.
Works like a charm, I have setup several networks in this manner and have never had a problem.
farslayer is right. you can put two DHCP server's on the same network with different scope as a failover solution.for example, one server will hand out addresses from 192.168.0.1 to 190.168.0.150 and the other DHCP server will hand out from 192.168.0.151 to 192.168.0.254. In that example, two clients will never have the chance to get the same IP address because the server's scopes are different.
You still can't pick or choose what DHCP server you want. Who ever answers first gives out address. After the the client leases from the server, it will get stuck with until the lease expires.
We don't mean to confuse you here. but i still think that you will be better off shutting down the old server and turning on the new one.
The other thing is that you can leave both server's on with different scope options so if one DHCP server went down the network will still function.
thanks farslayer for the correction.
Last edited by waelaltaqi; 05-21-2007 at 10:37 AM.
I'm actually interested in looking closer at the solution posted by Centinul as that looks to be a true failover/load balancing DHCP configuration, unlike my ugly workaround hack.
Definitely different than what I've been doing, but currently my DHCP servers are stuck in the Windows AD world, and as far as I know, windows DHCP does NOT support any sort of failover/load balancing which is why I split the pool.
When a server starts that has not previously communicated with its failover peer, it must establish communications with its failover peer and synchronize with it before it can serve clients. This can happen either because you have just configured your DHCP servers to perform failover for the first time or because one of your failover servers has failed catastrophically and lost its database.
The initial recovery process is designed to ensure that when one failover peer loses its database and then resynchronizes, any leases that the failed server gave out before it failed will be honored. When the failed server starts up, it notices that it has no saved failover state, and attempts to contact its peer.
When it has established contact, it asks the peer for a complete copy its peer’s lease database. The peer then sends its complete database, and sends a message indicating that it is done. The failed server then waits until MCLT (the length of time for which a lease may be renewed by either failover peer without contacting the other) has passed, and once MCLT has passed both servers make the transition back into normal operation. This waiting period ensures that any leases the failed server may have given out while out of contact with its partner will have expired.
While the failed server is recovering, its partner remains in the partner-down state, which means that it is serving all clients. The failed server provides no service at all to DHCP clients until it has made the transition into normal operation.
In the case where both servers detect that they have never before communicated with their partner, they both come up in this recovery state and follow the procedure. In this case, no service will be provided to DHCP clients until MCLT has expired.
Following is the sample config that worked for me :
· Sample /etc/dhcpd.conf on LinuxServer1
…
failover peer "ltsp" {
primary;
address 192.168.1.1;
port 519;
peer address 192.168.1.2;
peer port 520;
mclt 3600;
max-response-delay 30;
max-unacked-updates 10;
load balance max seconds 3;
split 128;
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;
}
…
pool {
failover peer "robotics";
max-lease-time 7200;
deny dynamic bootp clients;
range 192.168.1.25 192.168.1.200;
}
…
· Sample /etc/dhcpd.conf on LinuxServer2
…
failover peer "ltsp" {
secondary;
address 192.168.1.2;
port 520;
peer address 192.168.1.1;
peer port 519;
max-response-delay 30;
max-unacked-updates 10;
load balance max seconds 3;
}
…
pool {
failover peer "ltsp";
max-lease-time 7200;
deny dynamic bootp clients;
range 192.168.1.25 192.168.1.200
}
…
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.