Mixing
Which DHCPOFFER the client accept when there are two dhcp servers on the same physical network?
Clash Royale CLAN TAG#URR8PPP
up vote
10
down vote
favorite
I am not completely oblivious when it comes to networks but here is something I can't wrap my head around.
Imagine we have a network like in the picture. 6 hosts on one layer 2 network, no VLANs. The network is supposed to be segmented into 2 subnets, with one DHCP server each. The DHCP servers have fixed IP addresses, so they know in which subnet they belong, obviously.
Then new clients get plugged in. They know nothing about which subnet they're supposed to be in and send their DHCPDISCOVER to the ethernet broadcast 255.255.255.255, so it goes to both DHCP servers. Both servers reply with an offer. Now here's my question: How does the client know, which DHCPOFFER it is supposed to accept?
networking dhcp
edited 16 mins ago
Braiam
3,99631850
asked 14 hours ago
Michael Niemand
1607
add a comment |Â
up vote
10
down vote
favorite
I am not completely oblivious when it comes to networks but here is something I can't wrap my head around.
Imagine we have a network like in the picture. 6 hosts on one layer 2 network, no VLANs. The network is supposed to be segmented into 2 subnets, with one DHCP server each. The DHCP servers have fixed IP addresses, so they know in which subnet they belong, obviously.
Then new clients get plugged in. They know nothing about which subnet they're supposed to be in and send their DHCPDISCOVER to the ethernet broadcast 255.255.255.255, so it goes to both DHCP servers. Both servers reply with an offer. Now here's my question: How does the client know, which DHCPOFFER it is supposed to accept?
networking dhcp
edited 16 mins ago
Braiam
3,99631850
asked 14 hours ago
Michael Niemand
1607
Compare this question and answers there.
– Kamil Maciorowski
11 hours ago
Here is another related question.
– kasperd
8 hours ago
"the ethernet broadcast 255.255.255.255" -- That's the IP broadcast address for the local network, not an Ethernet address. The initial DHCP DISCOVER messages also are very likely to use the Ethernet broadcast address ff:ff:ff:ff:ff:ff, but those really aren't the same thing.
– ilkkachu
29 mins ago
add a comment |Â
up vote
10
down vote
favorite
up vote
10
down vote
favorite
I am not completely oblivious when it comes to networks but here is something I can't wrap my head around.
Imagine we have a network like in the picture. 6 hosts on one layer 2 network, no VLANs. The network is supposed to be segmented into 2 subnets, with one DHCP server each. The DHCP servers have fixed IP addresses, so they know in which subnet they belong, obviously.
Then new clients get plugged in. They know nothing about which subnet they're supposed to be in and send their DHCPDISCOVER to the ethernet broadcast 255.255.255.255, so it goes to both DHCP servers. Both servers reply with an offer. Now here's my question: How does the client know, which DHCPOFFER it is supposed to accept?
networking dhcp
edited 16 mins ago
Braiam
3,99631850
asked 14 hours ago
Michael Niemand
1607
I am not completely oblivious when it comes to networks but here is something I can't wrap my head around.
Imagine we have a network like in the picture. 6 hosts on one layer 2 network, no VLANs. The network is supposed to be segmented into 2 subnets, with one DHCP server each. The DHCP servers have fixed IP addresses, so they know in which subnet they belong, obviously.
Then new clients get plugged in. They know nothing about which subnet they're supposed to be in and send their DHCPDISCOVER to the ethernet broadcast 255.255.255.255, so it goes to both DHCP servers. Both servers reply with an offer. Now here's my question: How does the client know, which DHCPOFFER it is supposed to accept?
networking dhcp
networking dhcp
edited 16 mins ago
Braiam
3,99631850
asked 14 hours ago
Michael Niemand
1607
edited 16 mins ago
Braiam
3,99631850
asked 14 hours ago
Michael Niemand
1607
edited 16 mins ago
Braiam
3,99631850
edited 16 mins ago
Braiam
3,99631850
edited 16 mins ago
Braiam
3,99631850
3,99631850
asked 14 hours ago
Michael Niemand
1607
asked 14 hours ago
Michael Niemand
1607
asked 14 hours ago
Michael Niemand
1607
1607
Compare this question and answers there.
– Kamil Maciorowski
11 hours ago
Here is another related question.
– kasperd
8 hours ago
"the ethernet broadcast 255.255.255.255" -- That's the IP broadcast address for the local network, not an Ethernet address. The initial DHCP DISCOVER messages also are very likely to use the Ethernet broadcast address ff:ff:ff:ff:ff:ff, but those really aren't the same thing.
– ilkkachu
29 mins ago
add a comment |Â
Compare this question and answers there.
– Kamil Maciorowski
11 hours ago
Here is another related question.
– kasperd
8 hours ago
"the ethernet broadcast 255.255.255.255" -- That's the IP broadcast address for the local network, not an Ethernet address. The initial DHCP DISCOVER messages also are very likely to use the Ethernet broadcast address ff:ff:ff:ff:ff:ff, but those really aren't the same thing.
– ilkkachu
29 mins ago
Compare this question and answers there.
– Kamil Maciorowski
11 hours ago
Compare this question and answers there.
– Kamil Maciorowski
11 hours ago
Here is another related question.
– kasperd
8 hours ago
Here is another related question.
– kasperd
8 hours ago
"the ethernet broadcast 255.255.255.255" -- That's the IP broadcast address for the local network, not an Ethernet address. The initial DHCP DISCOVER messages also are very likely to use the Ethernet broadcast address ff:ff:ff:ff:ff:ff, but those really aren't the same thing.
– ilkkachu
29 mins ago
"the ethernet broadcast 255.255.255.255" -- That's the IP broadcast address for the local network, not an Ethernet address. The initial DHCP DISCOVER messages also are very likely to use the Ethernet broadcast address ff:ff:ff:ff:ff:ff, but those really aren't the same thing.
– ilkkachu
29 mins ago
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
17
down vote
accepted
Simplest answer - first come first served.
If you had multiple VLANs and 10.10.10.0/24 was on a different VLAN to 10.10.20.0/24 - the broadcast wouldn't cross VLANs.
If the DHCP Server was on a separate VLAN to the clients, an iphelper on the routing interface between vlans would direct the broadcast onto the correct location.
In your scenario where you have 2 separate networks within the same VLAN (or lack thereof) serving up different subnets - its a race.
DHCP Serves up using the following transactions:
- DHCP Discovery (DHCPDISCOVER) - Client Broadcast - "Is there a DHCP
Server out there?" - DHCP Offer (DHCPOFFER) - Server to Client - "Yeah, I'm here and available!"
- DHCP Request (DHCPREQUEST) - Client to Server "Awesome, Can I have an address please?"
- DHCP Acknowledgement (DHCPACK) - Server to client "Sure, here's an IP, a mask, a gateway, some DNS/WINS Servers, a Time Server, and all the other stuff configured for your scope"
All of this happens on UDP Ports 67 for the server and 68 for the client.
As soon as Step 2 is reached - the client will stop "listening" to other DHCP Servers responses - its happy dealing with the first Server to give it some attention.
As a side note - there is actually a well known series of DoS (Denial of Service) attacks which abuse this right. An attacker plugs in a device which responds and sends out DHCPOFFER packets and then doesn't send DHCPACK out when asked... over and over and over again. There is also another DoS attack where "fake" DHCP Servers offer out addresses that can't be routed or that conflict with other IPs it's sniffed to mess with networks.
answered 13 hours ago
Fazer87
10k12439
13
And therefore the short answer to "But then how do I run multiple subnets on a single Layer-2 segment?" is "You don't." (Yes, there are ways, but it's not something you should generally do. One layer-2 domain = one subnet.)
– grawity
13 hours ago
Thank you guys, that really clicked with me. I always wondered how this would be possible, but it simply isn't. So the take away is: Have a router / layer 3 switch between subnets or segment with VLANs, am I right?
– Michael Niemand
13 hours ago
3
In general, yes, you need either VLANs or physical segmentation. Sharing a L2 domain would be doable only if both of your DHCP servers were restricted to handling "known" clients (e.g. by list of 'static leases' with allowed MAC addresses).
– grawity
12 hours ago
2
I think you could give each DHCP server a whitelist of MAC addresses and control which client gets an address from which server that way.
– Darren
10 hours ago
@grawity, you can easily run multiple IP subnets on the same layer-2 segment, if the subnets are equal, and you don't care which client gets an address from which subnet. You just have one DHCP server that gives addresses from both blocks, and one router that acts as a gateway for both blocks (with an address in each). Done. Saying just "you don't" is plain wrong.
– ilkkachu
27 mins ago
 |Â
show 1 more comment
up vote
4
down vote
The existing answer from @Fazer87 is broadly correct in practice and I recommend upvoting and accepting it. This answer explores a minor detail a little more precisely.
Both DHCP servers may respond with a DHCPOffer message.
A DHCP client may accept them on a "first come, first serve" basis. However, it is not required to take that approach.
RFC2131 specifies:
The client receives one or more DHCPOFFER messages from one or more
servers. The client may choose to wait for multiple responses.
The client chooses one server from which to request configuration
parameters, based on the configuration parameters offered in the
DHCPOFFER messages.
So, if second DHCP server offered a longer IP address reservation, or offered a time-server where the other didn't, or maybe had a custom field that the client had been programmed to prefer, it may accept the second offer.
Typically, a "first come, first served" approach is going to get you the offer that hasn't been through several hops across devices (BOOTP rebroadcasts) so it is a good protocol to follow if you have no reason to care.
I was on one project where a custom device would prefer a DHCPOffer that included a TFTP server where updated firmware could be found.
answered 4 hours ago
Oddthinking
544217
...or if one server offered an address that the client had already used before and wanted to keep
– ilkkachu
25 mins ago
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
17
down vote
accepted
Simplest answer - first come first served.
If you had multiple VLANs and 10.10.10.0/24 was on a different VLAN to 10.10.20.0/24 - the broadcast wouldn't cross VLANs.
If the DHCP Server was on a separate VLAN to the clients, an iphelper on the routing interface between vlans would direct the broadcast onto the correct location.
In your scenario where you have 2 separate networks within the same VLAN (or lack thereof) serving up different subnets - its a race.
DHCP Serves up using the following transactions:
- DHCP Discovery (DHCPDISCOVER) - Client Broadcast - "Is there a DHCP
Server out there?" - DHCP Offer (DHCPOFFER) - Server to Client - "Yeah, I'm here and available!"
- DHCP Request (DHCPREQUEST) - Client to Server "Awesome, Can I have an address please?"
- DHCP Acknowledgement (DHCPACK) - Server to client "Sure, here's an IP, a mask, a gateway, some DNS/WINS Servers, a Time Server, and all the other stuff configured for your scope"
All of this happens on UDP Ports 67 for the server and 68 for the client.
As soon as Step 2 is reached - the client will stop "listening" to other DHCP Servers responses - its happy dealing with the first Server to give it some attention.
As a side note - there is actually a well known series of DoS (Denial of Service) attacks which abuse this right. An attacker plugs in a device which responds and sends out DHCPOFFER packets and then doesn't send DHCPACK out when asked... over and over and over again. There is also another DoS attack where "fake" DHCP Servers offer out addresses that can't be routed or that conflict with other IPs it's sniffed to mess with networks.
answered 13 hours ago
Fazer87
10k12439
13
And therefore the short answer to "But then how do I run multiple subnets on a single Layer-2 segment?" is "You don't." (Yes, there are ways, but it's not something you should generally do. One layer-2 domain = one subnet.)
– grawity
13 hours ago
Thank you guys, that really clicked with me. I always wondered how this would be possible, but it simply isn't. So the take away is: Have a router / layer 3 switch between subnets or segment with VLANs, am I right?
– Michael Niemand
13 hours ago
3
In general, yes, you need either VLANs or physical segmentation. Sharing a L2 domain would be doable only if both of your DHCP servers were restricted to handling "known" clients (e.g. by list of 'static leases' with allowed MAC addresses).
– grawity
12 hours ago
2
I think you could give each DHCP server a whitelist of MAC addresses and control which client gets an address from which server that way.
– Darren
10 hours ago
@grawity, you can easily run multiple IP subnets on the same layer-2 segment, if the subnets are equal, and you don't care which client gets an address from which subnet. You just have one DHCP server that gives addresses from both blocks, and one router that acts as a gateway for both blocks (with an address in each). Done. Saying just "you don't" is plain wrong.
– ilkkachu
27 mins ago
 |Â
show 1 more comment
up vote
17
down vote
accepted
Simplest answer - first come first served.
If you had multiple VLANs and 10.10.10.0/24 was on a different VLAN to 10.10.20.0/24 - the broadcast wouldn't cross VLANs.
If the DHCP Server was on a separate VLAN to the clients, an iphelper on the routing interface between vlans would direct the broadcast onto the correct location.
In your scenario where you have 2 separate networks within the same VLAN (or lack thereof) serving up different subnets - its a race.
DHCP Serves up using the following transactions:
- DHCP Discovery (DHCPDISCOVER) - Client Broadcast - "Is there a DHCP
Server out there?" - DHCP Offer (DHCPOFFER) - Server to Client - "Yeah, I'm here and available!"
- DHCP Request (DHCPREQUEST) - Client to Server "Awesome, Can I have an address please?"
- DHCP Acknowledgement (DHCPACK) - Server to client "Sure, here's an IP, a mask, a gateway, some DNS/WINS Servers, a Time Server, and all the other stuff configured for your scope"
All of this happens on UDP Ports 67 for the server and 68 for the client.
As soon as Step 2 is reached - the client will stop "listening" to other DHCP Servers responses - its happy dealing with the first Server to give it some attention.
As a side note - there is actually a well known series of DoS (Denial of Service) attacks which abuse this right. An attacker plugs in a device which responds and sends out DHCPOFFER packets and then doesn't send DHCPACK out when asked... over and over and over again. There is also another DoS attack where "fake" DHCP Servers offer out addresses that can't be routed or that conflict with other IPs it's sniffed to mess with networks.
answered 13 hours ago
Fazer87
10k12439
13
And therefore the short answer to "But then how do I run multiple subnets on a single Layer-2 segment?" is "You don't." (Yes, there are ways, but it's not something you should generally do. One layer-2 domain = one subnet.)
– grawity
13 hours ago
Thank you guys, that really clicked with me. I always wondered how this would be possible, but it simply isn't. So the take away is: Have a router / layer 3 switch between subnets or segment with VLANs, am I right?
– Michael Niemand
13 hours ago
3
In general, yes, you need either VLANs or physical segmentation. Sharing a L2 domain would be doable only if both of your DHCP servers were restricted to handling "known" clients (e.g. by list of 'static leases' with allowed MAC addresses).
– grawity
12 hours ago
2
I think you could give each DHCP server a whitelist of MAC addresses and control which client gets an address from which server that way.
– Darren
10 hours ago
@grawity, you can easily run multiple IP subnets on the same layer-2 segment, if the subnets are equal, and you don't care which client gets an address from which subnet. You just have one DHCP server that gives addresses from both blocks, and one router that acts as a gateway for both blocks (with an address in each). Done. Saying just "you don't" is plain wrong.
– ilkkachu
27 mins ago
 |Â
show 1 more comment
up vote
17
down vote
accepted
up vote
17
down vote
accepted
Simplest answer - first come first served.
If you had multiple VLANs and 10.10.10.0/24 was on a different VLAN to 10.10.20.0/24 - the broadcast wouldn't cross VLANs.
If the DHCP Server was on a separate VLAN to the clients, an iphelper on the routing interface between vlans would direct the broadcast onto the correct location.
In your scenario where you have 2 separate networks within the same VLAN (or lack thereof) serving up different subnets - its a race.
DHCP Serves up using the following transactions:
- DHCP Discovery (DHCPDISCOVER) - Client Broadcast - "Is there a DHCP
Server out there?" - DHCP Offer (DHCPOFFER) - Server to Client - "Yeah, I'm here and available!"
- DHCP Request (DHCPREQUEST) - Client to Server "Awesome, Can I have an address please?"
- DHCP Acknowledgement (DHCPACK) - Server to client "Sure, here's an IP, a mask, a gateway, some DNS/WINS Servers, a Time Server, and all the other stuff configured for your scope"
All of this happens on UDP Ports 67 for the server and 68 for the client.
As soon as Step 2 is reached - the client will stop "listening" to other DHCP Servers responses - its happy dealing with the first Server to give it some attention.
As a side note - there is actually a well known series of DoS (Denial of Service) attacks which abuse this right. An attacker plugs in a device which responds and sends out DHCPOFFER packets and then doesn't send DHCPACK out when asked... over and over and over again. There is also another DoS attack where "fake" DHCP Servers offer out addresses that can't be routed or that conflict with other IPs it's sniffed to mess with networks.
answered 13 hours ago
Fazer87
10k12439
Simplest answer - first come first served.
If you had multiple VLANs and 10.10.10.0/24 was on a different VLAN to 10.10.20.0/24 - the broadcast wouldn't cross VLANs.
If the DHCP Server was on a separate VLAN to the clients, an iphelper on the routing interface between vlans would direct the broadcast onto the correct location.
In your scenario where you have 2 separate networks within the same VLAN (or lack thereof) serving up different subnets - its a race.
DHCP Serves up using the following transactions:
- DHCP Discovery (DHCPDISCOVER) - Client Broadcast - "Is there a DHCP
Server out there?" - DHCP Offer (DHCPOFFER) - Server to Client - "Yeah, I'm here and available!"
- DHCP Request (DHCPREQUEST) - Client to Server "Awesome, Can I have an address please?"
- DHCP Acknowledgement (DHCPACK) - Server to client "Sure, here's an IP, a mask, a gateway, some DNS/WINS Servers, a Time Server, and all the other stuff configured for your scope"
All of this happens on UDP Ports 67 for the server and 68 for the client.
As soon as Step 2 is reached - the client will stop "listening" to other DHCP Servers responses - its happy dealing with the first Server to give it some attention.
As a side note - there is actually a well known series of DoS (Denial of Service) attacks which abuse this right. An attacker plugs in a device which responds and sends out DHCPOFFER packets and then doesn't send DHCPACK out when asked... over and over and over again. There is also another DoS attack where "fake" DHCP Servers offer out addresses that can't be routed or that conflict with other IPs it's sniffed to mess with networks.
answered 13 hours ago
Fazer87
10k12439
answered 13 hours ago
Fazer87
10k12439
answered 13 hours ago
Fazer87
10k12439
answered 13 hours ago
Fazer87
10k12439
10k12439
13
And therefore the short answer to "But then how do I run multiple subnets on a single Layer-2 segment?" is "You don't." (Yes, there are ways, but it's not something you should generally do. One layer-2 domain = one subnet.)
– grawity
13 hours ago
Thank you guys, that really clicked with me. I always wondered how this would be possible, but it simply isn't. So the take away is: Have a router / layer 3 switch between subnets or segment with VLANs, am I right?
– Michael Niemand
13 hours ago
3
In general, yes, you need either VLANs or physical segmentation. Sharing a L2 domain would be doable only if both of your DHCP servers were restricted to handling "known" clients (e.g. by list of 'static leases' with allowed MAC addresses).
– grawity
12 hours ago
2
I think you could give each DHCP server a whitelist of MAC addresses and control which client gets an address from which server that way.
– Darren
10 hours ago
@grawity, you can easily run multiple IP subnets on the same layer-2 segment, if the subnets are equal, and you don't care which client gets an address from which subnet. You just have one DHCP server that gives addresses from both blocks, and one router that acts as a gateway for both blocks (with an address in each). Done. Saying just "you don't" is plain wrong.
– ilkkachu
27 mins ago
 |Â
show 1 more comment
13
And therefore the short answer to "But then how do I run multiple subnets on a single Layer-2 segment?" is "You don't." (Yes, there are ways, but it's not something you should generally do. One layer-2 domain = one subnet.)
– grawity
13 hours ago
Thank you guys, that really clicked with me. I always wondered how this would be possible, but it simply isn't. So the take away is: Have a router / layer 3 switch between subnets or segment with VLANs, am I right?
– Michael Niemand
13 hours ago
3
In general, yes, you need either VLANs or physical segmentation. Sharing a L2 domain would be doable only if both of your DHCP servers were restricted to handling "known" clients (e.g. by list of 'static leases' with allowed MAC addresses).
– grawity
12 hours ago
2
I think you could give each DHCP server a whitelist of MAC addresses and control which client gets an address from which server that way.
– Darren
10 hours ago
@grawity, you can easily run multiple IP subnets on the same layer-2 segment, if the subnets are equal, and you don't care which client gets an address from which subnet. You just have one DHCP server that gives addresses from both blocks, and one router that acts as a gateway for both blocks (with an address in each). Done. Saying just "you don't" is plain wrong.
– ilkkachu
27 mins ago
13
13
And therefore the short answer to "But then how do I run multiple subnets on a single Layer-2 segment?" is "You don't." (Yes, there are ways, but it's not something you should generally do. One layer-2 domain = one subnet.)
– grawity
13 hours ago
And therefore the short answer to "But then how do I run multiple subnets on a single Layer-2 segment?" is "You don't." (Yes, there are ways, but it's not something you should generally do. One layer-2 domain = one subnet.)
– grawity
13 hours ago
Thank you guys, that really clicked with me. I always wondered how this would be possible, but it simply isn't. So the take away is: Have a router / layer 3 switch between subnets or segment with VLANs, am I right?
– Michael Niemand
13 hours ago
Thank you guys, that really clicked with me. I always wondered how this would be possible, but it simply isn't. So the take away is: Have a router / layer 3 switch between subnets or segment with VLANs, am I right?
– Michael Niemand
13 hours ago
3
3
In general, yes, you need either VLANs or physical segmentation. Sharing a L2 domain would be doable only if both of your DHCP servers were restricted to handling "known" clients (e.g. by list of 'static leases' with allowed MAC addresses).
– grawity
12 hours ago
In general, yes, you need either VLANs or physical segmentation. Sharing a L2 domain would be doable only if both of your DHCP servers were restricted to handling "known" clients (e.g. by list of 'static leases' with allowed MAC addresses).
– grawity
12 hours ago
2
2
I think you could give each DHCP server a whitelist of MAC addresses and control which client gets an address from which server that way.
– Darren
10 hours ago
I think you could give each DHCP server a whitelist of MAC addresses and control which client gets an address from which server that way.
– Darren
10 hours ago
@grawity, you can easily run multiple IP subnets on the same layer-2 segment, if the subnets are equal, and you don't care which client gets an address from which subnet. You just have one DHCP server that gives addresses from both blocks, and one router that acts as a gateway for both blocks (with an address in each). Done. Saying just "you don't" is plain wrong.
– ilkkachu
27 mins ago
@grawity, you can easily run multiple IP subnets on the same layer-2 segment, if the subnets are equal, and you don't care which client gets an address from which subnet. You just have one DHCP server that gives addresses from both blocks, and one router that acts as a gateway for both blocks (with an address in each). Done. Saying just "you don't" is plain wrong.
– ilkkachu
27 mins ago
 |Â
show 1 more comment
up vote
4
down vote
The existing answer from @Fazer87 is broadly correct in practice and I recommend upvoting and accepting it. This answer explores a minor detail a little more precisely.
Both DHCP servers may respond with a DHCPOffer message.
A DHCP client may accept them on a "first come, first serve" basis. However, it is not required to take that approach.
RFC2131 specifies:
The client receives one or more DHCPOFFER messages from one or more
servers. The client may choose to wait for multiple responses.
The client chooses one server from which to request configuration
parameters, based on the configuration parameters offered in the
DHCPOFFER messages.
So, if second DHCP server offered a longer IP address reservation, or offered a time-server where the other didn't, or maybe had a custom field that the client had been programmed to prefer, it may accept the second offer.
Typically, a "first come, first served" approach is going to get you the offer that hasn't been through several hops across devices (BOOTP rebroadcasts) so it is a good protocol to follow if you have no reason to care.
I was on one project where a custom device would prefer a DHCPOffer that included a TFTP server where updated firmware could be found.
answered 4 hours ago
Oddthinking
544217
...or if one server offered an address that the client had already used before and wanted to keep
– ilkkachu
25 mins ago
add a comment |Â
up vote
4
down vote
The existing answer from @Fazer87 is broadly correct in practice and I recommend upvoting and accepting it. This answer explores a minor detail a little more precisely.
Both DHCP servers may respond with a DHCPOffer message.
A DHCP client may accept them on a "first come, first serve" basis. However, it is not required to take that approach.
RFC2131 specifies:
The client receives one or more DHCPOFFER messages from one or more
servers. The client may choose to wait for multiple responses.
The client chooses one server from which to request configuration
parameters, based on the configuration parameters offered in the
DHCPOFFER messages.
So, if second DHCP server offered a longer IP address reservation, or offered a time-server where the other didn't, or maybe had a custom field that the client had been programmed to prefer, it may accept the second offer.
Typically, a "first come, first served" approach is going to get you the offer that hasn't been through several hops across devices (BOOTP rebroadcasts) so it is a good protocol to follow if you have no reason to care.
I was on one project where a custom device would prefer a DHCPOffer that included a TFTP server where updated firmware could be found.
answered 4 hours ago
Oddthinking
544217
...or if one server offered an address that the client had already used before and wanted to keep
– ilkkachu
25 mins ago
add a comment |Â
up vote
4
down vote
up vote
4
down vote
The existing answer from @Fazer87 is broadly correct in practice and I recommend upvoting and accepting it. This answer explores a minor detail a little more precisely.
Both DHCP servers may respond with a DHCPOffer message.
A DHCP client may accept them on a "first come, first serve" basis. However, it is not required to take that approach.
RFC2131 specifies:
The client receives one or more DHCPOFFER messages from one or more
servers. The client may choose to wait for multiple responses.
The client chooses one server from which to request configuration
parameters, based on the configuration parameters offered in the
DHCPOFFER messages.
So, if second DHCP server offered a longer IP address reservation, or offered a time-server where the other didn't, or maybe had a custom field that the client had been programmed to prefer, it may accept the second offer.
Typically, a "first come, first served" approach is going to get you the offer that hasn't been through several hops across devices (BOOTP rebroadcasts) so it is a good protocol to follow if you have no reason to care.
I was on one project where a custom device would prefer a DHCPOffer that included a TFTP server where updated firmware could be found.
answered 4 hours ago
Oddthinking
544217
The existing answer from @Fazer87 is broadly correct in practice and I recommend upvoting and accepting it. This answer explores a minor detail a little more precisely.
Both DHCP servers may respond with a DHCPOffer message.
A DHCP client may accept them on a "first come, first serve" basis. However, it is not required to take that approach.
RFC2131 specifies:
The client receives one or more DHCPOFFER messages from one or more
servers. The client may choose to wait for multiple responses.
The client chooses one server from which to request configuration
parameters, based on the configuration parameters offered in the
DHCPOFFER messages.
So, if second DHCP server offered a longer IP address reservation, or offered a time-server where the other didn't, or maybe had a custom field that the client had been programmed to prefer, it may accept the second offer.
Typically, a "first come, first served" approach is going to get you the offer that hasn't been through several hops across devices (BOOTP rebroadcasts) so it is a good protocol to follow if you have no reason to care.
I was on one project where a custom device would prefer a DHCPOffer that included a TFTP server where updated firmware could be found.
answered 4 hours ago
Oddthinking
544217
answered 4 hours ago
Oddthinking
544217
answered 4 hours ago
Oddthinking
544217
answered 4 hours ago
Oddthinking
544217
544217
...or if one server offered an address that the client had already used before and wanted to keep
– ilkkachu
25 mins ago
add a comment |Â
...or if one server offered an address that the client had already used before and wanted to keep
– ilkkachu
25 mins ago
...or if one server offered an address that the client had already used before and wanted to keep
– ilkkachu
25 mins ago
...or if one server offered an address that the client had already used before and wanted to keep
– ilkkachu
25 mins ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1370188%2fwhich-dhcpoffer-the-client-accept-when-there-are-two-dhcp-servers-on-the-same-ph%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Compare this question and answers there.
– Kamil Maciorowski
11 hours ago
Here is another related question.
– kasperd
8 hours ago
"the ethernet broadcast 255.255.255.255" -- That's the IP broadcast address for the local network, not an Ethernet address. The initial DHCP DISCOVER messages also are very likely to use the Ethernet broadcast address ff:ff:ff:ff:ff:ff, but those really aren't the same thing.
– ilkkachu
29 mins ago