|
|
|
|
Hello. I'm currently setting up a test network with a DHCP relay agent that it's not communicating back to the client with the corresponding DHCP server offers. So the client keeps sending discovery messages, the relay agent forwards those messages to the servers, receives the responses and does not pass them along to the client. Setup:
CLIENT <---> [eth0] (relay agent) ROUTER-1 [eth1] <---> ROUTER-2 <---> DHCP Server
The relay agent runs ONLY on the interface that faces the client, which is eth0: "dhcrelay -4 -i eth0 10.0.1.10"
tpcpdump and Wireshark both show that the discovery message from the client are being forwarded to the server. The server replies with an offer, with the correct dst ip address (interface of R1 facing the client, eth0 on R1), reaches interface eth1 on R1 and but does not gets to the client. The transaction ID mataches on all messages and the option "Relay agent IP address" is set with the correct ip (eth0 on R1).
Can anybody tell me if I'm doing something wrong? Is this a known bug?
ISC DHCP version 4.2.8.
Thanks all,
Gerónimo.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Gero Palacio < [hidden email]> wrote:
> CLIENT <---> [eth0] (relay agent) ROUTER-1 [eth1] <---> ROUTER-2 <---> DHCP Server
>
> The relay agent runs ONLY on the interface that faces the client, which is eth0: "dhcrelay -4 -i eth0 10.0.1.10"
...
> Can anybody tell me if I'm doing something wrong? Is this a known bug?
It's a known feature. You must also listen on eth1 in order to get the replies from the server - it's just the way the relay agent works.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Hi Simon,
Thanks for the reply, I did not know if it was a bug or the correct behavior.
If I may, let me ask you a follow up question. Does DHCP relay works well with a pair of DHCP servers in failover mode?
I've configured the relay agent described in my previous email to forward the messages to the pair of DHCP servers. Now everytime the relay agent forwards a discovery message from the host, I receive 2 dhcp offers, one from each server. As I've configured split to 128, only 1 server should reply with an offer.
If I test the same configuration with hosts in the same subnet as the DHCP servers, the behavior is as expected. The DHCP servers responds or ignores the discovery messages according to the result of the hash based on the MAC address of the hosts.
Any idea what might be the problem? Is it even a good idea to run a relay agent and a pair of DHCP servers in failover?
Thanks!
Gerónimo. _______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
You'll want more experienced answers, I'm sure, but we are running a fair-sized network for our DHCP - I believe around 45000 devices and roughly 70 subnets. All of those devices
find the DHCP servers via relay agents and we are using failover.
We do generally see two DHCP offers - one from each server - when a device requests an address. I expected that behavior and saw no reason to be concerned with it. I still don't - I am under the impression that this is how the system is designed to work.
It has worked fine for us in this fashion for years. We deployed this particular solution in 2007, but I believe it was used for other devices prior to that, so we have used this through several iterations of ISC-DHCP.
Patrick
Hi Simon,
Thanks for the reply, I did not know if it was a bug or the correct behavior.
If I may, let me ask you a follow up question. Does DHCP relay works well with a pair of DHCP servers in failover mode?
I've configured the relay agent described in my previous email to forward the messages to the pair of DHCP servers. Now everytime the relay agent forwards a discovery message from the host, I receive 2 dhcp offers, one from each server. As I've configured split
to 128, only 1 server should reply with an offer.
If I test the same configuration with hosts in the same subnet as the DHCP servers, the behavior is as expected. The DHCP servers
responds or ignores the discovery messages according to the result of the hash based on the MAC address of the hosts.
Any idea what might be the problem? Is it even a good idea to run a relay agent and a pair of DHCP servers in failover?
Thanks!
Gerónimo.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Yes, this is the expected and normal behavior. Each server will reply with an address from its half of the pool. The machine that is receiving the offers will
take the first offer to arrive and ignore the other.
We have deployed remote DHCP served by relay for 20 years, and this is how it functions.
The only annoyance with remote relay DHCP is that the NAK message is a local broadcast.
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Patrick Trapp
Sent: Tuesday, June 16, 2015 6:17 AM
To: Users of ISC DHCP
Subject: RE: DHCP Relay agent not forwarding messages to the client
You'll want more experienced answers, I'm sure, but we are running a fair-sized network for our DHCP - I believe around 45000 devices
and roughly 70 subnets. All of those devices find the DHCP servers via relay agents and we are using failover.
We do generally see two DHCP offers - one from each server - when a device requests an address. I expected that behavior and saw no reason to be concerned with it. I still don't - I am under the impression that this is how the system is designed to work.
It has worked fine for us in this fashion for years. We deployed this particular solution in 2007, but I believe it was used for other devices prior to that, so we have used this through several iterations of ISC-DHCP.
Patrick
Hi Simon,
Thanks for the reply, I did not know if it was a bug or the correct behavior.
If I may, let me ask you a follow up question. Does DHCP relay works well with a pair of DHCP servers in failover mode?
I've configured the relay agent described in my previous email to forward the messages to the pair of DHCP servers. Now everytime the relay agent forwards a discovery message from the host, I receive 2 dhcp offers, one from each server. As I've configured split
to 128, only 1 server should reply with an offer.
If I test the same configuration with hosts in the same subnet as the DHCP servers, the behavior is as expected. The DHCP servers
responds or ignores the discovery messages according to the result of the hash based on the MAC address of the hosts.
Any idea what might be the problem? Is it even a good idea to run a relay agent and a pair of DHCP servers in failover?
Thanks!
Gerónimo.
On Mon, Jun 15, 2015 at 6:18 PM, Simon Hobson <[hidden email]> wrote:
Gero Palacio <[hidden email]> wrote:
> CLIENT <---> [eth0] (relay agent) ROUTER-1 [eth1] <---> ROUTER-2 <---> DHCP Server
>
> The relay agent runs ONLY on the interface that faces the client, which is eth0: "dhcrelay -4 -i eth0 10.0.1.10"
...
> Can anybody tell me if I'm doing something wrong? Is this a known bug?
It's a known feature. You must also listen on eth1 in order to get the replies from the server - it's just the way the relay agent works.
_______________________________________________
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
|
|
|
Hi There.
I have tested this behavior with 2 computers connected on the same subnet as the DHCP servers (so no relay agent involved) and it works as described. Both servers receives the offer but only one of them responds with an offer. This is also back up by RFC 3074 DHC Load Balancing Algorithm:
Section 4: The proposal maps the STID into a hash value using the function in section 6. The resulting hash value can then be used to decide who
should respond to the request, or who the forwarding target should be.
So I don't why it's behaving the way it does when there's a relay agent involved.
Thanks all for your help! - Gerónimo. El mar., 16 de jun. de 2015 a la(s) 10:28 a. m., Friesen, Don MTIC:EX < [hidden email]> escribió:
Yes, this is the expected and normal behavior. Each server will reply with an address from its half of the pool. The machine that is receiving the offers will
take the first offer to arrive and ignore the other.
We have deployed remote DHCP served by relay for 20 years, and this is how it functions.
The only annoyance with remote relay DHCP is that the NAK message is a local broadcast.
Subject: RE: DHCP Relay agent not forwarding messages to the client
You'll want more experienced answers, I'm sure, but we are running a fair-sized network for our DHCP - I believe around 45000 devices
and roughly 70 subnets. All of those devices find the DHCP servers via relay agents and we are using failover.
We do generally see two DHCP offers - one from each server - when a device requests an address. I expected that behavior and saw no reason to be concerned with it. I still don't - I am under the impression that this is how the system is designed to work.
It has worked fine for us in this fashion for years. We deployed this particular solution in 2007, but I believe it was used for other devices prior to that, so we have used this through several iterations of ISC-DHCP.
Patrick
Hi Simon,
Thanks for the reply, I did not know if it was a bug or the correct behavior.
If I may, let me ask you a follow up question. Does DHCP relay works well with a pair of DHCP servers in failover mode?
I've configured the relay agent described in my previous email to forward the messages to the pair of DHCP servers. Now everytime the relay agent forwards a discovery message from the host, I receive 2 dhcp offers, one from each server. As I've configured split
to 128, only 1 server should reply with an offer.
If I test the same configuration with hosts in the same subnet as the DHCP servers, the behavior is as expected. The DHCP servers
responds or ignores the discovery messages according to the result of the hash based on the MAC address of the hosts.
Any idea what might be the problem? Is it even a good idea to run a relay agent and a pair of DHCP servers in failover?
Thanks!
Gerónimo.
On Mon, Jun 15, 2015 at 6:18 PM, Simon Hobson <[hidden email]> wrote:
Gero Palacio <[hidden email]> wrote:
> CLIENT <---> [eth0] (relay agent) ROUTER-1 [eth1] <---> ROUTER-2 <---> DHCP Server
>
> The relay agent runs ONLY on the interface that faces the client, which is eth0: "dhcrelay -4 -i eth0 10.0.1.10"
...
> Can anybody tell me if I'm doing something wrong? Is this a known bug?
It's a known feature. You must also listen on eth1 in order to get the replies from the server - it's just the way the relay agent works.
_______________________________________________
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
|
|
|
I have zero experience with dhcp failover, but I agree with Gero.
They should not both make offers.
If they are both making offers, what is the point of configuring
them in failover? You might as well set them up independent of each
other and have them serve different pools.
What am I missing?
On 06/16/2015 08:18 AM, Gero Palacio
wrote:
Hi There.
I have tested this behavior with 2 computers connected on
the same subnet as the DHCP servers (so no relay agent
involved) and it works as described. Both servers receives the
offer but only one of them responds with an offer. This is
also back up by RFC 3074 DHC
Load Balancing Algorithm:
Section
4:
The proposal maps the STID into a hash value using the
function in section 6. The resulting hash value can then be
used to decide who
should respond to the request, or who the forwarding target
should be.
So I don't why it's behaving the way it does when there's a
relay agent involved.
Thanks all for your help!
- Gerónimo.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Referencing the RFCs that were posted earlier... what we are seeing here is how it's supposed to
work. When the dhcp relay system doesn't opt to choose which server to relay requests to.
Absent some form of dhcp monitoring built into the router, the dhcp relay doesn't know which of
the various relay systems will have available IPs or even which of them will be not too busy to
handle the dhcpdiscover message it is relaying. As a result, it sends it to all dhcp relay
hosts. The dhcp relay hosts, seeing a dhcpdiscover send an answer back, as they are supposed to.
The client, accepts the first response it gets and completes the dhcp handshake and continues to
talk to that dhcp server for future lease renewals.
The hash is to split the IP Pool space between the two servers, not to determine who the dhcp
servers are allowed to talk to.
What I find odd is that the failover pair actually seeming to discuss between them who will
respond to a local broadcast request in the direct connection mode. That actually seems odd to
me. Normally all dhcp servers on the wire will answer unless one server is defined as
authoritative.
Caused me no end of grief when someone would host a rogue dhcp server in a campus environment I
ran back in the day.
Dave
On 6/16/15 14:16, Sean McMurray wrote:
> I have zero experience with dhcp failover, but I agree with Gero. They should not both make offers.
>
> If they are both making offers, what is the point of configuring them in failover? You might as
> well set them up independent of each other and have them serve different pools.
>
> What am I missing?
>
> On 06/16/2015 08:18 AM, Gero Palacio wrote:
>> Hi There.
>>
>> What I find odd is that according to section 5.3 of this document IETF Internet Draft - DHCP
>> Failover Protocol < https://tools.ietf.org/pdf/draft-ietf-dhc-failover-12.pdf> *only one* of
>> the servers should respond to the DHCP offer. The other should discard it.
>>
>> I have tested this behavior with 2 computers connected on the same subnet as the DHCP servers
>> (so no relay agent involved) and it works as described. Both servers receives the offer but
>> only one of them responds with an offer. This is also back up by RFC 3074 DHC Load Balancing
>> Algorithm < https://tools.ietf.org/html/rfc3074>:
>>
>> _Section 4: _
>> The proposal maps the STID into a hash value using the function in section 6. The
>> resulting hash value can then be used to decide who
>> should respond to the request, or who the forwarding target should be.
>>
>>
>> So I don't why it's behaving the way it does when there's a relay agent involved.
>>
>> Thanks all for your help!
>> - Gerónimo.
>
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users>
--
Dave Calafrancesco
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On 6/16/15 12:42 PM, dave c wrote:
> Referencing the RFCs that were posted earlier... what we are seeing here
> is how it's supposed to work. When the dhcp relay system doesn't opt to
> choose which server to relay requests to.
I think there is some confusion in this thread. If you're running
failover it's correct that the IP helpers on the network gear need to
send all of the DHCP packets to both servers.
Both servers will see the majority of the traffic, but what should be
true is that only *one* server will actually send the DHCPACK. You
should be able to see that in the logs, and verify it in the leases file
on both servers.
If you are seeing a situation where both servers are handing out ACKs
then it's almost certain that they are not operating in "normal" state.
hope this helps,
Doug
--
I am conducting an experiment in the efficacy of PGP/MIME signatures.
This message should be signed. If it is not, or the signature does not
validate, please let me know how you received this message (direct, or
to a list) and the mail software you use. Thanks!
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
I'd thought that the hash was used to determine which MAC addresses each of the DHCP servers would reply to in normal mode, with the 'other' server picking up the full load of the peer became unavailable.
-----Original Message-----
From: [hidden email] [mailto: [hidden email]] On Behalf Of dave c
Sent: Tuesday, June 16, 2015 3:42 PM
To: Users of ISC DHCP
Subject: Re: DHCP Relay agent not forwarding messages to the client
Referencing the RFCs that were posted earlier... what we are seeing here is how it's supposed to work. When the dhcp relay system doesn't opt to choose which server to relay requests to.
Absent some form of dhcp monitoring built into the router, the dhcp relay doesn't know which of the various relay systems will have available IPs or even which of them will be not too busy to handle the dhcpdiscover message it is relaying. As a result, it sends it to all dhcp relay hosts. The dhcp relay hosts, seeing a dhcpdiscover send an answer back, as they are supposed to.
The client, accepts the first response it gets and completes the dhcp handshake and continues to talk to that dhcp server for future lease renewals.
The hash is to split the IP Pool space between the two servers, not to determine who the dhcp servers are allowed to talk to.
What I find odd is that the failover pair actually seeming to discuss between them who will respond to a local broadcast request in the direct connection mode. That actually seems odd to me. Normally all dhcp servers on the wire will answer unless one server is defined as authoritative.
Caused me no end of grief when someone would host a rogue dhcp server in a campus environment I ran back in the day.
Dave
On 6/16/15 14:16, Sean McMurray wrote:
> I have zero experience with dhcp failover, but I agree with Gero. They should not both make offers.
>
> If they are both making offers, what is the point of configuring them
> in failover? You might as well set them up independent of each other and have them serve different pools.
>
> What am I missing?
>
> On 06/16/2015 08:18 AM, Gero Palacio wrote:
>> Hi There.
>>
>> What I find odd is that according to section 5.3 of this document
>> IETF Internet Draft - DHCP Failover Protocol
>> < https://tools.ietf.org/pdf/draft-ietf-dhc-failover-12.pdf> *only one* of the servers should respond to the DHCP offer. The other should discard it.
>>
>> I have tested this behavior with 2 computers connected on the same
>> subnet as the DHCP servers (so no relay agent involved) and it works
>> as described. Both servers receives the offer but only one of them
>> responds with an offer. This is also back up by RFC 3074 DHC Load Balancing Algorithm < https://tools.ietf.org/html/rfc3074>:
>>
>> _Section 4: _
>> The proposal maps the STID into a hash value using the function in section 6. The
>> resulting hash value can then be used to decide who
>> should respond to the request, or who the forwarding target should be.
>>
>>
>> So I don't why it's behaving the way it does when there's a relay agent involved.
>>
>> Thanks all for your help!
>> - Gerónimo.
>
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users>
--
Dave Calafrancesco
_______________________________________________
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
|
|
|
In reply to this post by Friesen, Don MTIC:EX
Hi Folks,
On 16/06/2015 14:28, Friesen, Don MTIC:EX wrote:
> Yes, this is the expected and normal behavior. Each server will reply
> with an address from its half of the pool. The machine that is receiving
> the offers will take the first offer to arrive and ignore the other.
We have 'split 128' & 'load balance max seconds 5' parameters set, and so clients that discover with a low 'secs' field are only answered by one of the pair:
==
Jun 16 09:19:05 is-dhcp0 dhcpd: DHCPDISCOVER from aa:bb:cc:dd:ee:ff (Kates-iPhone) via 10.32.176.8: load balance to peer schlep-failover
[and no OFFER]
Jun 16 09:19:05 fa-dhcp0 dhcpd: DHCPDISCOVER from aa:bb:cc:dd:ee:ff (Kates-iPhone) via 10.32.176.8
Jun 16 09:19:06 fa-dhcp0 dhcpd: DHCPOFFER on 10.32.186.98 to aa:bb:cc:dd:ee:ff (Kates-iPhone) via 10.32.176.8
==
Some clients don't implement the secs field correctly (or appear to get their most/least significant bits muddled), so we do see some clients that receive two offers. Perhaps there are some relay agents that are the same (although I'd be surprised if the ISC relay was broken in this regard).
The idea here is that, on average, the load for unicast renews is split evenly between the pair of dhcp servers.
On 16/06/2015 20:16, Sean McMurray wrote:
> If they are both making offers, what is the point of configuring them in
> failover? You might as well set them up independent of each other and
> have them serve different pools.
Even if all clients receive two offers, the benefit is that when one of the dhcp pair fails, clients don't suddenly renumber themselves into the remaining server's pool - they can continue to renew their current address (and that you don't need to run with two pools, each large enough to cover all clients).
We're very happy with relay agents and failover - 1,150 networks, 17,300 static 'host' addresses & 260,339 dynamic addresses.
Graham
PS: Any movements on failover for DHCPv6? At least I don't feel bad for using twice the address space within a /64.. :)
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On Tue, 2015-06-16 at 12:16 -0700, Sean McMurray wrote:
> I have zero experience with dhcp failover, but I agree with Gero. They
> should not both make offers.
>
> If they are both making offers, what is the point of configuring them
> in failover? You might as well set them up independent of each other
> and have them serve different pools.
>
> What am I missing?
The point in failover is at least a) that the still online server can
ACK renew requests from clients that got their lease from the other
server and b) that the two servers make sure the pool of free leases are
balanced between them as long as they can communicate so that the
remaining server can serve at least "pool-free-leases / 2" new clients
from when the other crashed.
This means that with just one server online you can survive for a longer
period than if you had started with two separate servers with half the
pool each.
The failover communication also means that you can lose one server
completely and still recover gracefully. Even with the local lease file
gone a new server would just download a copy from the partner. This is
probably less important as most people have ample redundancy in their
disk subsystems but worth mentioning.
Regarding your observation: It is possible that the "secs" parameter
from the client is larger than the configured "load balance max seconds"
value. If it is then load balancing is supposed to be disabled and both
servers should answer.
Taking a quick look at a capture on both our servers I see many clients
that send "secs" larger than the 3 that we have configured. The ones I
watched that had seconds less than 3 (typically 0) were only answered by
one of the servers.
The "secs" parameters should not be mangled by relay agents so you
should not see a difference between relayed and locally broadcast
discover messages.
If both servers answer queries that have "secs" less than your
configured "load balance max seconds" then that does sound like a bug of
some kind. I haven't thoroughly checked if our servers do that since it
doesn't really bother me. :-)
--
Peter
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
In reply to this post by Cuttler, Brian (HEALTH)
As I understand it, Brian is correct and dave is ... inaccurate.
As per the man page:
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, 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 255, of which the most reasonable is 128.
On 06/16/2015 12:49 PM, Cuttler, Brian (HEALTH) wrote:
> I'd thought that the hash was used to determine which MAC addresses each of the DHCP servers would reply to in normal mode, with the 'other' server picking up the full load of the peer became unavailable.
>
>
> -----Original Message-----
> From: [hidden email] [mailto: [hidden email]] On Behalf Of dave c
> Sent: Tuesday, June 16, 2015 3:42 PM
> To: Users of ISC DHCP
> Subject: Re: DHCP Relay agent not forwarding messages to the client
>
> Referencing the RFCs that were posted earlier... what we are seeing here is how it's supposed to work. When the dhcp relay system doesn't opt to choose which server to relay requests to.
>
> Absent some form of dhcp monitoring built into the router, the dhcp relay doesn't know which of the various relay systems will have available IPs or even which of them will be not too busy to handle the dhcpdiscover message it is relaying. As a result, it sends it to all dhcp relay hosts. The dhcp relay hosts, seeing a dhcpdiscover send an answer back, as they are supposed to.
> The client, accepts the first response it gets and completes the dhcp handshake and continues to talk to that dhcp server for future lease renewals.
>
> The hash is to split the IP Pool space between the two servers, not to determine who the dhcp servers are allowed to talk to.
>
> What I find odd is that the failover pair actually seeming to discuss between them who will respond to a local broadcast request in the direct connection mode. That actually seems odd to me. Normally all dhcp servers on the wire will answer unless one server is defined as authoritative.
>
> Caused me no end of grief when someone would host a rogue dhcp server in a campus environment I ran back in the day.
>
> Dave
>
> On 6/16/15 14:16, Sean McMurray wrote:
>> I have zero experience with dhcp failover, but I agree with Gero. They should not both make offers.
>>
>> If they are both making offers, what is the point of configuring them
>> in failover? You might as well set them up independent of each other and have them serve different pools.
>>
>> What am I missing?
>>
>> On 06/16/2015 08:18 AM, Gero Palacio wrote:
>>> Hi There.
>>>
>>> What I find odd is that according to section 5.3 of this document
>>> IETF Internet Draft - DHCP Failover Protocol
>>> < https://tools.ietf.org/pdf/draft-ietf-dhc-failover-12.pdf> *only one* of the servers should respond to the DHCP offer. The other should discard it.
>>>
>>> I have tested this behavior with 2 computers connected on the same
>>> subnet as the DHCP servers (so no relay agent involved) and it works
>>> as described. Both servers receives the offer but only one of them
>>> responds with an offer. This is also back up by RFC 3074 DHC Load Balancing Algorithm < https://tools.ietf.org/html/rfc3074>:
>>>
>>> _Section 4: _
>>> The proposal maps the STID into a hash value using the function in section 6. The
>>> resulting hash value can then be used to decide who
>>> should respond to the request, or who the forwarding target should be.
>>>
>>>
>>> So I don't why it's behaving the way it does when there's a relay agent involved.
>>>
>>> Thanks all for your help!
>>> - Gerónimo.
>>
>> _______________________________________________
>> dhcp-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users>>
> --
> Dave Calafrancesco
> _______________________________________________
> 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
|
|
|
In reply to this post by Cuttler, Brian (HEALTH)
Both servers are in normal mode. I checked using the OMSHELL and also the status of the servers that's logged in the "dhcpd.leases" file.
To make it clear, what's going on is this: - Host sends DHCPDISCOVERY.
- Relay agent forwards this request to both DHCP servers (this is the way it's suppose to work).
- BOTH servers replies with a DHCPOFFER message to the client.
- Clients picks one, sends DHCPREQUEST.
- The selected server replies back to the client with an DHCPACK.
Step 3 is the one that doesn't make sense to me.
I've done a test with 1 host is in the same subnet as the DHCP servers, and both of them receives the DHCPDISCOVERY message but actually one of them responds back to the client with a DHCPOFFER, and I understand it's the way it should work.
Maybe it's me that's understanding this section incorrectly, but that's actually the way it works when host and servers are in the same subnet as described above:
In order to implement load balancing between a primary and secondary server pair, each server must respond to DHCPDISCOVER requests from some clients and not from other clients. In order to do this suc- cessfully, each server must be able to determine immediately upon receipt of a DHCP client request whether it is to service this request or to ignore it in order to allow the other server to service
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Hi Graham,
I’m very interested how you have setup your machines for the DHCP Failover.
We have a big MAN in Switzerland with almost 600 subnets and 20’000 computers. Now we have 1’400 static entries in our dhcpd.conf.
Can you send me your config files ?
And how many CPU/RAM/Disk you have for the machines ?
Physical or Virtual machines ?
Thank you so much for all
Best regards
Stefano
> On 16 Jun 2015, at 21:58, Graham Clinch < [hidden email]> wrote:
>
> Hi Folks,
>
> On 16/06/2015 14:28, Friesen, Don MTIC:EX wrote:
>> Yes, this is the expected and normal behavior. Each server will reply
>> with an address from its half of the pool. The machine that is receiving
>> the offers will take the first offer to arrive and ignore the other.
>
> We have 'split 128' & 'load balance max seconds 5' parameters set, and so clients that discover with a low 'secs' field are only answered by one of the pair:
>
> ==
> Jun 16 09:19:05 is-dhcp0 dhcpd: DHCPDISCOVER from aa:bb:cc:dd:ee:ff (Kates-iPhone) via 10.32.176.8: load balance to peer schlep-failover
> [and no OFFER]
>
> Jun 16 09:19:05 fa-dhcp0 dhcpd: DHCPDISCOVER from aa:bb:cc:dd:ee:ff (Kates-iPhone) via 10.32.176.8
> Jun 16 09:19:06 fa-dhcp0 dhcpd: DHCPOFFER on 10.32.186.98 to aa:bb:cc:dd:ee:ff (Kates-iPhone) via 10.32.176.8
> ==
>
>
> Some clients don't implement the secs field correctly (or appear to get their most/least significant bits muddled), so we do see some clients that receive two offers. Perhaps there are some relay agents that are the same (although I'd be surprised if the ISC relay was broken in this regard).
>
> The idea here is that, on average, the load for unicast renews is split evenly between the pair of dhcp servers.
>
>
> On 16/06/2015 20:16, Sean McMurray wrote:
>> If they are both making offers, what is the point of configuring them in
>> failover? You might as well set them up independent of each other and
>> have them serve different pools.
>
> Even if all clients receive two offers, the benefit is that when one of the dhcp pair fails, clients don't suddenly renumber themselves into the remaining server's pool - they can continue to renew their current address (and that you don't need to run with two pools, each large enough to cover all clients).
>
> We're very happy with relay agents and failover - 1,150 networks, 17,300 static 'host' addresses & 260,339 dynamic addresses.
>
> Graham
>
> PS: Any movements on failover for DHCPv6? At least I don't feel bad for using twice the address space within a /64.. :)
> _______________________________________________
> 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
|
|
|
Hello.
I'm just done testing and can confirm that the problem was due to the "secs" field (client) being greater than the "load balance max seconds" (server) and they way I was conducting the tests.
The dhclient and dhcpd servers were started from moment 0, relay agent would start 30 seconds later. When both servers reach the normal state, I'd start the relay agent. That caused the client to increase his "secs" field because it was not getting any answers as his messages were not being forwarded from moment 0 (relay agent down).
So thanks Graham and Peter for pointing that out and everyone else who was involved in this! I've should read the definition for "load balance max seconds" more carefully -_-
Cheers! _______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
Locked
signature.asc (484 bytes)