|
|
12
|
|
Dear people,
I´ve implemented a failover scheme with ISC-DHCP-SERVER in two
different servers, with the same version of the package and OS.
Everything seems to be OK, but when a execute "service isc-dhcp-server
stop" in the primary server, in the secondary server I can see:
Aug 15 11:52:01 dhcp2 dhcpd[5839]: peer dhcp-failover: disconnected
Aug 15 11:52:01 dhcp2 dhcpd[5839]: failover peer dhcp-failover: I move
from normal to communications-interrupted
what is correct, but after that the secondary server doesnt' receive
any DHCPREQUEST packet from clients.
So, my faoilover scheme doesn't work, because if primary server goes
down, the secondary server doesn't receive any IP request from
clients. When I start the isc-dhcp-server on primary server, at this
moment I can see the DHCPREQUEST from clients to primary server.
What can be the problem with the secondary server please ???
Thanks a lot!!!
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
The problem isn't with the secondary server. The DHCP packets must always go to both servers. If the packets are relayed from a relay agent, then the relay agent must be configured to send to both of the DHCP servers (On a Cisco router, that would involve having ip helper-address listed twice, for example).
If no relay, then the DHCP servers must both be on the same LAN with the clients.
When both of the primary and secondary servers are running, you should see logs of the DHCP packets in both servers logs.
----- Original Message -----
> From: "Roberto Carna" < [hidden email]>
> To: "Users of ISC DHCP" < [hidden email]>
> Sent: Wednesday, August 15, 2018 11:06:08 AM
> Subject: DHCP failover doesn't receive DHCP requests in secondary server
> Dear people,
> I´ve implemented a failover scheme with ISC-DHCP-SERVER in two
> different servers, with the same version of the package and OS.
> Everything seems to be OK, but when a execute "service isc-dhcp-server
> stop" in the primary server, in the secondary server I can see:
> Aug 15 11:52:01 dhcp2 dhcpd[5839]: peer dhcp-failover: disconnected
> Aug 15 11:52:01 dhcp2 dhcpd[5839]: failover peer dhcp-failover: I move
> from normal to communications-interrupted
> what is correct, but after that the secondary server doesnt' receive
> any DHCPREQUEST packet from clients.
> So, my faoilover scheme doesn't work, because if primary server goes
> down, the secondary server doesn't receive any IP request from
> clients. When I start the isc-dhcp-server on primary server, at this
> moment I can see the DHCPREQUEST from clients to primary server.
> What can be the problem with the secondary server please ???
> Thanks a lot!!!
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
(Robert) you didn't provide a lot of detail so the answers are probably going to be general. A couple of additional ideas come to mind but, without specifics, it's hard to troubleshoot. Is a firewall somewhere in the path blocking requests? Has the server been configured to listen on a specific (possibly wrong) interface rather than all interfaces?
Join us
at the 2018 Momentum User Conference!
Register
here
Leroy Tennison
Network Information/Cyber Security Specialist
E: [hidden email]
2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.com
TThis message has been sent on behalf
of a company that is part of the Harris Operating Group of
Constellation Software Inc. These companies are listed
here
.
If you prefer not to be contacted by Harris
Operating Group
please notify us
.
This message is intended exclusively for the
individual or entity to which it is addressed. This communication
may contain information that is proprietary, privileged or
confidential or otherwise legally exempt from disclosure. If you are
not the named addressee, you are not authorized to read, print,
retain, copy or disseminate this message or any part of it. If you
have received this message in error, please notify the sender
immediately by e-mail and delete all copies of the
message.
________________________________________
From: dhcp-users < [hidden email]> on behalf of perl-list < [hidden email]>
Sent: Wednesday, August 15, 2018 10:38 AM
To: Users of ISC DHCP
Subject: [EXTERNAL] Re: DHCP failover doesn't receive DHCP requests in secondary server
The problem isn't with the secondary server. The DHCP packets must always go to both servers. If the packets are relayed from a relay agent, then the relay agent must be configured to send to both of the DHCP servers (On a Cisco router, that would involve having ip helper-address listed twice, for example).
If no relay, then the DHCP servers must both be on the same LAN with the clients.
When both of the primary and secondary servers are running, you should see logs of the DHCP packets in both servers logs.
----- Original Message -----
> From: "Roberto Carna" < [hidden email]>
> To: "Users of ISC DHCP" < [hidden email]>
> Sent: Wednesday, August 15, 2018 11:06:08 AM
> Subject: DHCP failover doesn't receive DHCP requests in secondary server
> Dear people,
> I´ve implemented a failover scheme with ISC-DHCP-SERVER in two
> different servers, with the same version of the package and OS.
> Everything seems to be OK, but when a execute "service isc-dhcp-server
> stop" in the primary server, in the secondary server I can see:
> Aug 15 11:52:01 dhcp2 dhcpd[5839]: peer dhcp-failover: disconnected
> Aug 15 11:52:01 dhcp2 dhcpd[5839]: failover peer dhcp-failover: I move
> from normal to communications-interrupted
> what is correct, but after that the secondary server doesnt' receive
> any DHCPREQUEST packet from clients.
> So, my faoilover scheme doesn't work, because if primary server goes
> down, the secondary server doesn't receive any IP request from
> clients. When I start the isc-dhcp-server on primary server, at this
> moment I can see the DHCPREQUEST from clients to primary server.
> What can be the problem with the secondary server please ???
> Thanks a lot!!!
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Dear, thanks for your response...So I will review the DHCP agent as you said.
But now I have a question:
If both DHCP servers always receive DHCPREQUEST packets, does it mean
that in normal condition (primary and secondary server are running UP)
both DHCP servers responds these requests ??? Or only the primary
server responds the requests in despite of the secondary server is UP
too ???
Thanks a lot again, regards !!!
2018-08-15 12:38 GMT-03:00 perl-list < [hidden email]>:
> The problem isn't with the secondary server. The DHCP packets must always go to both servers. If the packets are relayed from a relay agent, then the relay agent must be configured to send to both of the DHCP servers (On a Cisco router, that would involve having ip helper-address listed twice, for example).
>
> If no relay, then the DHCP servers must both be on the same LAN with the clients.
>
> When both of the primary and secondary servers are running, you should see logs of the DHCP packets in both servers logs.
>
> ----- Original Message -----
>> From: "Roberto Carna" < [hidden email]>
>> To: "Users of ISC DHCP" < [hidden email]>
>> Sent: Wednesday, August 15, 2018 11:06:08 AM
>> Subject: DHCP failover doesn't receive DHCP requests in secondary server
>
>> Dear people,
>
>> I´ve implemented a failover scheme with ISC-DHCP-SERVER in two
>> different servers, with the same version of the package and OS.
>
>> Everything seems to be OK, but when a execute "service isc-dhcp-server
>> stop" in the primary server, in the secondary server I can see:
>
>> Aug 15 11:52:01 dhcp2 dhcpd[5839]: peer dhcp-failover: disconnected
>> Aug 15 11:52:01 dhcp2 dhcpd[5839]: failover peer dhcp-failover: I move
>> from normal to communications-interrupted
>
>> what is correct, but after that the secondary server doesnt' receive
>> any DHCPREQUEST packet from clients.
>
>> So, my faoilover scheme doesn't work, because if primary server goes
>> down, the secondary server doesn't receive any IP request from
>> clients. When I start the isc-dhcp-server on primary server, at this
>> moment I can see the DHCPREQUEST from clients to primary server.
>
>> What can be the problem with the secondary server please ???
>
>> Thanks a lot!!!
>> _______________________________________________
>> dhcp-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Both are active. Roughly 50% of clients will be answered by each, under normal circumstances.
Chris Buxton
> On Aug 15, 2018, at 8:58 AM, Roberto Carna < [hidden email]> wrote:
>
> Dear, thanks for your response...So I will review the DHCP agent as you said.
>
> But now I have a question:
>
> If both DHCP servers always receive DHCPREQUEST packets, does it mean
> that in normal condition (primary and secondary server are running UP)
> both DHCP servers responds these requests ??? Or only the primary
> server responds the requests in despite of the secondary server is UP
> too ???
>
> Thanks a lot again, regards !!!
>
> 2018-08-15 12:38 GMT-03:00 perl-list < [hidden email]>:
>> The problem isn't with the secondary server. The DHCP packets must always go to both servers. If the packets are relayed from a relay agent, then the relay agent must be configured to send to both of the DHCP servers (On a Cisco router, that would involve having ip helper-address listed twice, for example).
>>
>> If no relay, then the DHCP servers must both be on the same LAN with the clients.
>>
>> When both of the primary and secondary servers are running, you should see logs of the DHCP packets in both servers logs.
>>
>> ----- Original Message -----
>>> From: "Roberto Carna" < [hidden email]>
>>> To: "Users of ISC DHCP" < [hidden email]>
>>> Sent: Wednesday, August 15, 2018 11:06:08 AM
>>> Subject: DHCP failover doesn't receive DHCP requests in secondary server
>>
>>> Dear people,
>>
>>> I´ve implemented a failover scheme with ISC-DHCP-SERVER in two
>>> different servers, with the same version of the package and OS.
>>
>>> Everything seems to be OK, but when a execute "service isc-dhcp-server
>>> stop" in the primary server, in the secondary server I can see:
>>
>>> Aug 15 11:52:01 dhcp2 dhcpd[5839]: peer dhcp-failover: disconnected
>>> Aug 15 11:52:01 dhcp2 dhcpd[5839]: failover peer dhcp-failover: I move
>>> from normal to communications-interrupted
>>
>>> what is correct, but after that the secondary server doesnt' receive
>>> any DHCPREQUEST packet from clients.
>>
>>> So, my faoilover scheme doesn't work, because if primary server goes
>>> down, the secondary server doesn't receive any IP request from
>>> clients. When I start the isc-dhcp-server on primary server, at this
>>> moment I can see the DHCPREQUEST from clients to primary server.
>>
>>> What can be the problem with the secondary server please ???
>>
>>> Thanks a lot!!!
>>> _______________________________________________
>>> dhcp-users mailing list
>>> [hidden email]
>>> https://lists.isc.org/mailman/listinfo/dhcp-users>> _______________________________________________
>> dhcp-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Please note that it depends on the type of DHCPREQUEST packets. DHCPREQUESTs for clients in the RENEWING state will be unicast to the server that issued the lease, i.e. the primary DHCP server. DHCPREQUESTs for clients in the REBINDING state will be broadcast, and therefore should be received by both primary and failover DHCP servers. This is true for clients on the same LAN or separated by a DHCP relay. In the case of a DHCP relay, it will see the broadcast packet and (should be configured to) forward to both primary and failover. Unicast packets, of course, will not be relayed, but simply routed to the destination IP. DHCPDISCOVER packets are always broadcast.
Regards,
Greg Rabil
-----Original Message-----
From: dhcp-users [mailto: [hidden email]] On Behalf Of Chris Buxton
Sent: Wednesday, August 15, 2018 12:00 PM
To: Users of ISC DHCP < [hidden email]>
Subject: Re: DHCP failover doesn't receive DHCP requests in secondary server
Both are active. Roughly 50% of clients will be answered by each, under normal circumstances.
Chris Buxton
> On Aug 15, 2018, at 8:58 AM, Roberto Carna < [hidden email]> wrote:
>
> Dear, thanks for your response...So I will review the DHCP agent as you said.
>
> But now I have a question:
>
> If both DHCP servers always receive DHCPREQUEST packets, does it mean
> that in normal condition (primary and secondary server are running UP)
> both DHCP servers responds these requests ??? Or only the primary
> server responds the requests in despite of the secondary server is UP
> too ???
>
> Thanks a lot again, regards !!!
>
> 2018-08-15 12:38 GMT-03:00 perl-list < [hidden email]>:
>> The problem isn't with the secondary server. The DHCP packets must always go to both servers. If the packets are relayed from a relay agent, then the relay agent must be configured to send to both of the DHCP servers (On a Cisco router, that would involve having ip helper-address listed twice, for example).
>>
>> If no relay, then the DHCP servers must both be on the same LAN with the clients.
>>
>> When both of the primary and secondary servers are running, you should see logs of the DHCP packets in both servers logs.
>>
>> ----- Original Message -----
>>> From: "Roberto Carna" < [hidden email]>
>>> To: "Users of ISC DHCP" < [hidden email]>
>>> Sent: Wednesday, August 15, 2018 11:06:08 AM
>>> Subject: DHCP failover doesn't receive DHCP requests in secondary
>>> server
>>
>>> Dear people,
>>
>>> I´ve implemented a failover scheme with ISC-DHCP-SERVER in two
>>> different servers, with the same version of the package and OS.
>>
>>> Everything seems to be OK, but when a execute "service
>>> isc-dhcp-server stop" in the primary server, in the secondary server I can see:
>>
>>> Aug 15 11:52:01 dhcp2 dhcpd[5839]: peer dhcp-failover: disconnected
>>> Aug 15 11:52:01 dhcp2 dhcpd[5839]: failover peer dhcp-failover: I
>>> move from normal to communications-interrupted
>>
>>> what is correct, but after that the secondary server doesnt' receive
>>> any DHCPREQUEST packet from clients.
>>
>>> So, my faoilover scheme doesn't work, because if primary server goes
>>> down, the secondary server doesn't receive any IP request from
>>> clients. When I start the isc-dhcp-server on primary server, at this
>>> moment I can see the DHCPREQUEST from clients to primary server.
>>
>>> What can be the problem with the secondary server please ???
>>
>>> Thanks a lot!!!
>>> _______________________________________________
>>> dhcp-users mailing list
>>> [hidden email]
>>> https://lists.isc.org/mailman/listinfo/dhcp-users>> _______________________________________________
>> dhcp-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Re: DHCP failover doesn't receive DHCP requests in secondary server
Top posting:
I think the term "fail over" causes some confusion.
DHCPd in "fail-over" isn't what I'd typically think of, when I think "fail over."
When I think fail-over, I think of a server that essentially does no active "work" while the primary is up and functioning - other than *getting ready* to handle the load of the primary when it goes down.
Yet DHCPd fail-over is really *load-balancing* [at least in "normal" setups] with a bunch of communication between the two to handle the failure/unavailability of *either* server.
Thus, in regular practice, both servers are seeing requests and answering them, and [again in "normal" setups] will have approximately half of the leases distributed to each server.
HTH
-Greg
RC> Dear, thanks for your response...So I will review the DHCP agent as you said.
RC> But now I have a question:
RC> If both DHCP servers always receive DHCPREQUEST packets, does it mean
RC> that in normal condition (primary and secondary server are running UP)
RC> both DHCP servers responds these requests ??? Or only the primary
RC> server responds the requests in despite of the secondary server is UP
RC> too ???
RC> Thanks a lot again, regards !!!
RC> 2018-08-15 12:38 GMT-03:00 perl-list <[hidden email]>:
>> The problem isn't with the secondary server. The DHCP packets must always go to both servers. If the packets are relayed from a relay agent, then the relay agent must be configured to send to both of the DHCP servers (On a Cisco router, that would involve having ip helper-address listed twice, for example).
>> If no relay, then the DHCP servers must both be on the same LAN with the clients.
>> When both of the primary and secondary servers are running, you should see logs of the DHCP packets in both servers logs.
>> ----- Original Message -----
>>> From: "Roberto Carna" <[hidden email]>
>>> To: "Users of ISC DHCP" <[hidden email]>
>>> Sent: Wednesday, August 15, 2018 11:06:08 AM
>>> Subject: DHCP failover doesn't receive DHCP requests in secondary server
>>> Dear people,
>>> I´ve implemented a failover scheme with ISC-DHCP-SERVER in two
>>> different servers, with the same version of the package and OS.
>>> Everything seems to be OK, but when a execute "service isc-dhcp-server
>>> stop" in the primary server, in the secondary server I can see:
>>> Aug 15 11:52:01 dhcp2 dhcpd[5839]: peer dhcp-failover: disconnected
>>> Aug 15 11:52:01 dhcp2 dhcpd[5839]: failover peer dhcp-failover: I move
>>> from normal to communications-interrupted
>>> what is correct, but after that the secondary server doesnt' receive
>>> any DHCPREQUEST packet from clients.
>>> So, my faoilover scheme doesn't work, because if primary server goes
>>> down, the secondary server doesn't receive any IP request from
>>> clients. When I start the isc-dhcp-server on primary server, at this
>>> moment I can see the DHCPREQUEST from clients to primary server.
>>> What can be the problem with the secondary server please ???
>>> Thanks a lot!!!
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
iirc with the latest patch, only the primary server replies to clients when the split value is set to 255
Top posting:
I think the term "fail over" causes some confusion.
DHCPd in "fail-over" isn't what I'd typically think of, when I think "fail over."
When I think fail-over, I think of a server that essentially does no active "work" while the primary is up and functioning - other than *getting ready* to handle the load of the primary when it goes down.
Yet DHCPd fail-over is really *load-balancing* [at least in "normal" setups] with a bunch of communication between the two to handle the failure/unavailability of *either* server.
Thus, in regular practice, both servers are seeing requests and answering them, and [again in "normal" setups] will have approximately half of the leases distributed to each server.
HTH
-Greg
RC> Dear, thanks for your response...So I will review the DHCP agent as you said.
RC> But now I have a question:
RC> If both DHCP servers always receive DHCPREQUEST packets, does it mean
RC> that in normal condition (primary and secondary server are running UP)
RC> both DHCP servers responds these requests ??? Or only the primary
RC> server responds the requests in despite of the secondary server is UP
RC> too ???
RC> Thanks a lot again, regards !!!
RC> 2018-08-15 12:38 GMT-03:00 perl-list <[hidden email]>:
>> The problem isn't with the secondary server. The DHCP packets must always go to both servers. If the packets are relayed from a relay agent, then the relay agent must be configured to send to both of the DHCP servers (On a Cisco router, that would involve having ip helper-address listed twice, for example).
>> If no relay, then the DHCP servers must both be on the same LAN with the clients.
>> When both of the primary and secondary servers are running, you should see logs of the DHCP packets in both servers logs.
>> ----- Original Message -----
>>> From: "Roberto Carna" <
>>> To: "Users of ISC DHCP" <
>>> Sent: Wednesday, August 15, 2018 11:06:08 AM
>>> Subject: DHCP failover doesn't receive DHCP requests in secondary server
>>> Dear people,
>>> I´ve implemented a failover scheme with ISC-DHCP-SERVER in two
>>> different servers, with the same version of the package and OS.
>>> Everything seems to be OK, but when a execute "service isc-dhcp-server
>>> stop" in the primary server, in the secondary server I can see:
>>> Aug 15 11:52:01 dhcp2 dhcpd[5839]: peer dhcp-failover: disconnected
>>> Aug 15 11:52:01 dhcp2 dhcpd[5839]: failover peer dhcp-failover: I move
>>> from normal to communications-interrupted
>>> what is correct, but after that the secondary server doesnt' receive
>>> any DHCPREQUEST packet from clients.
>>> So, my faoilover scheme doesn't work, because if primary server goes
>>> down, the secondary server doesn't receive any IP request from
>>> clients. When I start the isc-dhcp-server on primary server, at this
>>> moment I can see the DHCPREQUEST from clients to primary server.
>>> What can be the problem with the secondary server please ???
>>> Thanks a lot!!!
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Thanks a lot for your help.
Regards!!!
2018-08-15 13:19 GMT-03:00 Philippe Maechler < [hidden email]>:
> iirc with the latest patch, only the primary server replies to clients when
> the split value is set to 255
>
> Gregory Sloop < [hidden email]> schrieb am Mi., 15. Aug. 2018, 18:16:
>>
>> Top posting:
>>
>> I think the term "fail over" causes some confusion.
>> DHCPd in "fail-over" isn't what I'd typically think of, when I think "fail
>> over."
>>
>> When I think fail-over, I think of a server that essentially does no
>> active "work" while the primary is up and functioning - other than *getting
>> ready* to handle the load of the primary when it goes down.
>>
>> Yet DHCPd fail-over is really *load-balancing* [at least in "normal"
>> setups] with a bunch of communication between the two to handle the
>> failure/unavailability of *either* server.
>>
>> Thus, in regular practice, both servers are seeing requests and answering
>> them, and [again in "normal" setups] will have approximately half of the
>> leases distributed to each server.
>>
>> HTH
>> -Greg
>>
>> RC> Dear, thanks for your response...So I will review the DHCP agent as
>> you said.
>>
>> RC> But now I have a question:
>>
>> RC> If both DHCP servers always receive DHCPREQUEST packets, does it mean
>> RC> that in normal condition (primary and secondary server are running UP)
>> RC> both DHCP servers responds these requests ??? Or only the primary
>> RC> server responds the requests in despite of the secondary server is UP
>> RC> too ???
>>
>> RC> Thanks a lot again, regards !!!
>>
>> RC> 2018-08-15 12:38 GMT-03:00 perl-list < [hidden email]>:
>>
>> >> The problem isn't with the secondary server. The DHCP packets must
>> >> always go to both servers. If the packets are relayed from a relay agent,
>> >> then the relay agent must be configured to send to both of the DHCP servers
>> >> (On a Cisco router, that would involve having ip helper-address listed
>> >> twice, for example).
>>
>> >> If no relay, then the DHCP servers must both be on the same LAN with
>> >> the clients.
>>
>> >> When both of the primary and secondary servers are running, you should
>> >> see logs of the DHCP packets in both servers logs.
>>
>> >> ----- Original Message -----
>> >>> From: "Roberto Carna" <
>> [hidden email]>
>>
>> >>> To: "Users of ISC DHCP" <
>> [hidden email]>
>>
>> >>> Sent: Wednesday, August 15, 2018 11:06:08 AM
>> >>> Subject: DHCP failover doesn't receive DHCP requests in secondary
>> >>> server
>>
>> >>> Dear people,
>>
>> >>> I´ve implemented a failover scheme with ISC-DHCP-SERVER in two
>> >>> different servers, with the same version of the package and OS.
>>
>> >>> Everything seems to be OK, but when a execute "service isc-dhcp-server
>> >>> stop" in the primary server, in the secondary server I can see:
>>
>> >>> Aug 15 11:52:01 dhcp2 dhcpd[5839]: peer dhcp-failover: disconnected
>> >>> Aug 15 11:52:01 dhcp2 dhcpd[5839]: failover peer dhcp-failover: I move
>> >>> from normal to communications-interrupted
>>
>> >>> what is correct, but after that the secondary server doesnt' receive
>> >>> any DHCPREQUEST packet from clients.
>>
>> >>> So, my faoilover scheme doesn't work, because if primary server goes
>> >>> down, the secondary server doesn't receive any IP request from
>> >>> clients. When I start the isc-dhcp-server on primary server, at this
>> >>> moment I can see the DHCPREQUEST from clients to primary server.
>>
>> >>> What can be the problem with the secondary server please ???
>>
>> >>> Thanks a lot!!!
>> _______________________________________________
>> dhcp-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users>
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users>
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
perl-list < [hidden email]> wrote:
> The problem isn't with the secondary server. The DHCP packets must always go to both servers. If the packets are relayed from a relay agent, then the relay agent must be configured to send to both of the DHCP servers (On a Cisco router, that would involve having ip helper-address listed twice, for example).
>
> If no relay, then the DHCP servers must both be on the same LAN with the clients.
Just to clarify as the above might give the wrong impression, the only requirement is that broadcast reach both servers and unicast packets reach the IP they are addressed to. It doesn't mean that both must be relayed, or both must be on the same LAN. It's perfectly OK for the servers to be on different networks, even geographically dispersed, provided that all the routing and relay agents are in place.
For example, it would be OK to have one central server, and failover peers in each satellite office of a multi-site business. The central server would take over if the on-site server failed, and the on-site server could continue working if comms to the main site went down. In this setup, clients at the satellite office would access the local server by directly (either broadcast or unicast), and the central server by relay agent (broadcast packets) or normal routing (unicast).
But back to the OPs problem. A bit of history might help, and config files, and information about network topology (clients on same network as servers, or relay agents involved).
If there was originally one server and it's been made into half of a pair, then it's possible that clients already have leases from the original server and so aren't having to broadcast looking for other servers - which means the second server won't see many (if any) requests until some clients are unable to renew by unicast with the original server for some reason.
It will also vary between different sorts of clients - devices that are never shut down might never* need to broadcast a request, while road warrior laptops might need to every time they join the network.
* For some approximation of "never" meaning "between significant server outages".
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On 8/15/18 6:19 PM, Philippe Maechler wrote:
> iirc with the latest patch, only the primary server replies to clients
> when the split value is set to 255
When was this added?
/Anders
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
> On 8/15/18 6:19 PM, Philippe Maechler wrote:
> > iirc with the latest patch, only the primary server replies to clients
> > when the split value is set to 255
> When was this added?
> /Anders
This has been there for a long time. Its just the same-ole split value. Affects how the load balancing algorithm is applied. From man page:
The split statement
split bits;
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, resulting in value from 0 to 255. This is
used as an index into a 256 bit field. If the bit at that index is set, the primary is responsible. If the bit at that index is not set, the secondary is responsible. The split value determines how many of the leading bits are set to one. So, in
practice, higher split values will cause the primary to serve more clients than the secondary. Lower split values, the converse. Legal values are between 0 and 256 inclusive, of which the most reasonable is 128. Note that a value of 0 makes the sec-
ondary responsible for all clients and a value of 256 makes the primary responsible for all clients.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
I saw it recently in the release notes.
split bits;
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, resulting in value from 0 to 255. This is used as an index into a 256 bit field. If the bit at that index is set, the primary is responsible. If the bit at that index is not set, the secondary is responsible. The split value determines how many of the leading bits are set to one. So, in practice, higher split values will cause the primary to serve more clients than the secondary. Lower split values, the converse. Legal values are between 0 and 256 inclusive, of which the most reasonable is 128. Note that a value of 0 makes the secondary responsible for all clients and a value of 256 makes the primary responsible for all
On 8/15/18 6:19 PM, Philippe Maechler wrote:
> iirc with the latest patch, only the primary server replies to clients
> when the split value is set to 255
When was this added?
/Anders
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Re: DHCP failover doesn't receive DHCP requests in secondary server
But I believe it's always [at least for a long time] been available. IIRC it wasn't recommended to use any split other than even, but it was possible.
The way it seemed to me was, that there was almost no conceivable situation where it made sense to run it other than an even split.
...because the only reason I can see to have it run with more leases to one peer vs the other would be if one of the peers couldn't handle all the load, while running even. But then how in the world would one expect the machine that can't even handle half the load to survive when in a peer-down situation where it has to handle ALL the load, and likely more heavy than "normal," since all the non owned leases would get renewed at the MCLT time instead of the full regular lease time.
So I'm probably not thinking of some corner case, but I honestly can't think of a case where a non-even split makes the slightest sense. Thus the option, while nice - doesn't seem to have any real-world practical use.
Sorry to the OP for the digression... :)
|
I saw it recently in the release notes.
split bits;
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, resulting in value from 0 to 255. This is used as an index into a 256 bit field. If the bit at that index is set, the primary is responsible. If the bit at that index is not set, the secondary is responsible. The split value determines how many of the leading bits are set to one. So, in practice, higher split values will cause the primary to serve more clients than the secondary. Lower split values, the converse. Legal values are between 0 and 256 inclusive, of which the most reasonable is 128. Note that a value of 0 makes the secondary responsible for all clients and a value of 256 makes the primary responsible for all
Source: https://www.isc.org/wp-content/uploads/2018/02/dhcp44.html
On Thu, 16 Aug 2018 at 16:23, Anders Löwinger <[hidden email]> wrote:
On 8/15/18 6:19 PM, Philippe Maechler wrote:
> iirc with the latest patch, only the primary server replies to clients
> when the split value is set to 255
When was this added?
/Anders
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users |
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Gregory Sloop < [hidden email]> wrote:
> ...because the only reason I can see to have it run with more leases to one peer vs the other would be if one of the peers couldn't handle all the load, while running even. But then how in the world would one expect the machine that can't even handle half the load to survive when in a peer-down situation where it has to handle ALL the load, and likely more heavy than "normal," since all the non owned leases would get renewed at the MCLT time instead of the full regular lease time.
>
> So I'm probably not thinking of some corner case, but I honestly can't think of a case where a non-even split makes the slightest sense. Thus the option, while nice - doesn't seem to have any real-world practical use.
I can think of one possible case - but it still comes under "but how would the remaining server cope".
In the past, one creative use of failover was to put a DHCP server in each pop, and configure all their pools in failover with a single central server. In practice, the distributed servers would take up the client load due to the extra round trip time for packets from the clients going back to the central server and back - but setting the split value would (I guess) force the issue anyway.
The main reason for doing this was to use the failover protocol to create a real-time backup of the leases in a central place (where it's easy to arrange stable power etc) and not have to worry about (eg) power cuts at the pop messing up the server there - the server would not even need to have persistent storage, it could save on ramdisk (good performance) and sync the leases from the central server any time it gets rebooted (eg if there's a power cut).
But even then, you have to consider the effect of a widespread power failure and what happens when all your pops (and their connected customers) come back on line together.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Its been available since the very first time I personally used failover (~2001) as this directive:
split 128;
has been in my config since that time. Not sure why people are saying its a new option.
----- Original Message -----
> From: "Greg Sloop" < [hidden email]>
> To: "Philippe Maechler" < [hidden email]>, "Users of ISC DHCP" < [hidden email]>
> Sent: Thursday, August 16, 2018 1:05:20 PM
> Subject: Re: DHCP failover doesn't receive DHCP requests in secondary server
> Re: DHCP failover doesn't receive DHCP requests in secondary server But I
> believe it's always [at least for a long time] been available. IIRC it wasn't
> recommended to use any split other than even, but it was possible.
> The way it seemed to me was, that there was almost no conceivable situation
> where it made sense to run it other than an even split.
> ...because the only reason I can see to have it run with more leases to one peer
> vs the other would be if one of the peers couldn't handle all the load, while
> running even. But then how in the world would one expect the machine that can't
> even handle half the load to survive when in a peer-down situation where it has
> to handle ALL the load, and likely more heavy than "normal," since all the non
> owned leases would get renewed at the MCLT time instead of the full regular
> lease time.
> So I'm probably not thinking of some corner case, but I honestly can't think of
> a case where a non-even split makes the slightest sense. Thus the option, while
> nice - doesn't seem to have any real-world practical use.
> Sorry to the OP for the digression... :)
> I saw it recently in the release notes.
> split bits;
> 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, resulting in value from 0
> to 255. This is used as an index into a 256 bit field. If the bit at that index
> is set, the primary is responsible. If the bit at that index is not set, the
> secondary is responsible. The split value determines how many of the leading
> bits are set to one. So, in practice, higher split values will cause the
> primary to serve more clients than the secondary. Lower split values, the
> converse. Legal values are between 0 and 256 inclusive, of which the most
> reasonable is 128. Note that a value of 0 makes the secondary responsible for
> all clients and a value of 256 makes the primary responsible for all
> Source: [ https://www.isc.org/wp-content/uploads/2018/02/dhcp44.html |
> https://www.isc.org/wp-content/uploads/2018/02/dhcp44.html ]
> On Thu, 16 Aug 2018 at 16:23, Anders Löwinger < [ mailto: [hidden email] |
> [hidden email] ] > wrote:
> On 8/15/18 6:19 PM, Philippe Maechler wrote:
> > iirc with the latest patch, only the primary server replies to clients
> > when the split value is set to 255
> When was this added?
> /Anders
> _______________________________________________
> dhcp-users mailing list
> [ mailto: [hidden email] | [hidden email] ]
> [ https://lists.isc.org/mailman/listinfo/dhcp-users |
> https://lists.isc.org/mailman/listinfo/dhcp-users ]
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On 8/16/18 4:33 PM, perl-list wrote:
> This has been there for a long time. Its just the same-ole split value. Affects how the load balancing algorithm is applied. From man page:
Ok, I thougth something was changed.
We have tried running with "split 255;" for a couple of hours (lease
time 30 min) but saw no real difference on the load between the two dhcp
servers....
/Anders
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On Thu, Aug 16, 2018 at 3:08 PM Anders Löwinger < [hidden email]> wrote: On 8/16/18 4:33 PM, perl-list wrote:
> This has been there for a long time. Its just the same-ole split value. Affects how the load balancing algorithm is applied. From man page:
Ok, I thougth something was changed.
We have tried running with "split 255;" for a couple of hours (lease
time 30 min) but saw no real difference on the load between the two dhcp
servers....
/Anders
"split" only affects which server responds *first* to *new* clients. It has no effect when a client renews - they just unicast directly to the server that gave them their lease. You would have to have a large turnover of clients, or have one server down for a while, to see the effect.
-- Bob Harold _______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Anders Löwinger < [hidden email]> wrote:
> We have tried running with "split 255;" for a couple of hours (lease time 30 min) but saw no real difference on the load between the two dhcp servers....
Was that with existing leases ? If so then I think that's what you should see. Clients renewing an existing lease will initially send (by unicast) a request to the server that issued their lease - which will look in the leases database and find that the lease belongs to itself, and I would guess that this will bypass the split evaluation.
If you get clients to release their leases and then renew, I'd guess that you'll see the split value take effect.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
12
|
Locked
