Weird behavior with multiple pool inside shared networks

[Roberto De Oliveira]

I have a weird behavior on my dhcp-server, I am using a load balance configuration and using multiple pool inside that shared-network, I have this configuration:

shared-network "my-shared-network" {
    subnet 186.88.128.0 netmask 255.255.224.0 {
        option subnet-mask 255.255.224.0;
        option routers 186.88.128.1;
        pool {
            range 186.88.128.2 186.88.159.254;
            failover peer "my-failover";
        }
    }
    subnet 186.90.0.0 netmask 255.255.224.0 {
        option subnet-mask 255.255.224.0;
        option routers 186.90.0.1;
        pool {
            range 186.90.0.2 186.90.31.254;
            failover peer "my-failover";
        }
    }
}

Works fine for subnet 186.88.128.0, but when I receive packages from subnet 186.90.0.0 my servers offers IP from subnet 186.88.128.0, what I see on logs:

Oct 26 18:22:09 my-server dhcpd: DHCPDISCOVER from 60:e7:01:4d:f9:3f via 186.90.0.1
Oct 26 18:22:09 my-server dhcpd: DHCPOFFER on 186.88.139.127 to 60:e7:01:4d:f9:3f via 186.90.0.1
Oct 26 18:22:09 my-server dhcpd: DHCPRELEASE of 186.88.139.127 from 60:e7:01:4d:f9:3f via 186.90.0.1 (found)

What is wrong with my configuration?

P.D: All DHCPDISCOVER comes from the same IP, for example: 172.16.25.40

Thanks in advance

--

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Steven Carr]

On 27 October 2015 at 04:18, Roberto De Oliveira <[hidden email]> wrote:
> What is wrong with my configuration?

Nothing, it's working as intended. A shared network means that those
two networks inside of there are in the same broadcast domain,
therefore it doesn't matter which pool of addresses the clients are
assigned an IP address from it should still work. DHCPD won't move on
to the second pool until it's exhausted the first pool.

Steve
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Steven Carr <[hidden email]> wrote:

> On 27 October 2015 at 04:18, Roberto De Oliveira <[hidden email]> wrote:
>> What is wrong with my configuration?
>
> Nothing, it's working as intended. A shared network means that those
> two networks inside of there are in the same broadcast domain,
> therefore it doesn't matter which pool of addresses the clients are
> assigned an IP address from it should still work. DHCPD won't move on
> to the second pool until it's exhausted the first pool.

To expand on that a bit ...
The shared-network statement tells the server that the two (or more) subnets are on the same network (broadcast domain). That explicitly means all IP addresses are to be considered equal.
There is no way to determine in advance which subnet any client will get an address from - which is the same for the case of a larger subnet and two pools within the one subnet.

A key thing to remember is that there is no such thing as "I receive packages from subnet 186.90.0.0" for broadcast packets. When a client is configuring itself, it has no IP address, so the concept of belonging to a specific subnet does not exist - the only "location" for the client is the broadcast domain which in the case of a shared-network hosts multiple subnets. When the server receives a packet from IP address 0.0.0.0, there just isn't any way to say it belongs to one subnet or another.

As an aside, this is also the reason you can't run a DHCP service on a sub-interface (eg eth0.1) - when broadcast packets come in, there's no way to route that packet to the main interface (eth0) or the subinterface (eth0.1).

Only when a client has been allocated an address, and configured it's interface, does it "belong" to a specific subnet.


For a "fresh" install, the address allocation order is determined by the way the code works - which is not specified and liable to change without notice. At present this is a "top down" ordering where the highest numerical address is issued first.
Once there are no "never used before" addresses left, then addresses are re-used on a least recently used basis - at which point allocation takes on a pseudo-random appearance.
If a client requests a specific address, and that address is available, then that address will be given. So if there are clients which already had addresses on the network, then depending on how "clingy" they are, you will see "out of order" allocation of never used before addresses.

If you need specific clients to get addresses in specific pools, then you need to tell the server about your requirements. This may be as simple as defining host statements for certain clients and using allow/deny known-clients in the pools. Or it may be more complicated, using classes and possibly subclasses.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Niall O'Reilly]

On Tue, 27 Oct 2015 09:17:59 +0000,
Simon Hobson wrote:
>
> A key thing to remember is that there is no such thing as "I receive
> packages from subnet 186.90.0.0" for broadcast packets.

  Absolutely.

  It's also worth bearing in mind that the address shown in the "via"
  phrase of the log message for DHCPDISCOVER is just arbitrarily
  selected by the gateway/relay from the addresses configured on the
  interface connected to the shared network.  It may be the "primary"
  address, or the one first in sort order, according to the
  implementation.  In particular, the example "via 186.90.0.1" doesn't
  indicate anything which should prevent a DHCPOFFER from carrying an
  address from the other subnet.

  ATB
  Niall
 
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Roberto De Oliveira]

Thanks Simon,

Excellent explanation, I think that I have to rethink somethings on my network.

Thanks to Steven and Niall also.

2015-10-27 4:47 GMT-04:30 Simon Hobson <[hidden email]>:

Steven Carr <[hidden email]> wrote:

> On 27 October 2015 at 04:18, Roberto De Oliveira <[hidden email]> wrote:
>> What is wrong with my configuration?
>
> Nothing, it's working as intended. A shared network means that those
> two networks inside of there are in the same broadcast domain,
> therefore it doesn't matter which pool of addresses the clients are
> assigned an IP address from it should still work. DHCPD won't move on
> to the second pool until it's exhausted the first pool.

To expand on that a bit ...
The shared-network statement tells the server that the two (or more) subnets are on the same network (broadcast domain). That explicitly means all IP addresses are to be considered equal.
There is no way to determine in advance which subnet any client will get an address from - which is the same for the case of a larger subnet and two pools within the one subnet.

A key thing to remember is that there is no such thing as "I receive packages from subnet 186.90.0.0" for broadcast packets. When a client is configuring itself, it has no IP address, so the concept of belonging to a specific subnet does not exist - the only "location" for the client is the broadcast domain which in the case of a shared-network hosts multiple subnets. When the server receives a packet from IP address 0.0.0.0, there just isn't any way to say it belongs to one subnet or another.

As an aside, this is also the reason you can't run a DHCP service on a sub-interface (eg eth0.1) - when broadcast packets come in, there's no way to route that packet to the main interface (eth0) or the subinterface (eth0.1).

Only when a client has been allocated an address, and configured it's interface, does it "belong" to a specific subnet.


For a "fresh" install, the address allocation order is determined by the way the code works - which is not specified and liable to change without notice. At present this is a "top down" ordering where the highest numerical address is issued first.
Once there are no "never used before" addresses left, then addresses are re-used on a least recently used basis - at which point allocation takes on a pseudo-random appearance.
If a client requests a specific address, and that address is available, then that address will be given. So if there are clients which already had addresses on the network, then depending on how "clingy" they are, you will see "out of order" allocation of never used before addresses.

If you need specific clients to get addresses in specific pools, then you need to tell the server about your requirements. This may be as simple as defining host statements for certain clients and using allow/deny known-clients in the pools. Or it may be more complicated, using classes and possibly subclasses.

_______________________________________________
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

[Patrick Trapp]

I meant to reply earlier. I have nothing to add to the excellent responses you already have in hand, but we are doing what you are trying to do, I think, by using option-82 information to determine the source network of the request and assigning to the desired pool accordingly.

I'm sure there are other ways, but I thought I would share that one since I know it works for our equipment and our network.

---

From: [hidden email] [[hidden email]] on behalf of Roberto De Oliveira [[hidden email]]
Sent: Wednesday, October 28, 2015 9:29 AM
To: Users of ISC DHCP
Subject: Re: Weird behavior with multiple pool inside shared networks

Thanks Simon,

Excellent explanation, I think that I have to rethink somethings on my network.

Thanks to Steven and Niall also.

2015-10-27 4:47 GMT-04:30 Simon Hobson <[hidden email]>:

Steven Carr <[hidden email]> wrote:

> On 27 October 2015 at 04:18, Roberto De Oliveira <[hidden email]> wrote:
>> What is wrong with my configuration?
>
> Nothing, it's working as intended. A shared network means that those
> two networks inside of there are in the same broadcast domain,
> therefore it doesn't matter which pool of addresses the clients are
> assigned an IP address from it should still work. DHCPD won't move on
> to the second pool until it's exhausted the first pool.

To expand on that a bit ...
The shared-network statement tells the server that the two (or more) subnets are on the same network (broadcast domain). That explicitly means all IP addresses are to be considered equal.
There is no way to determine in advance which subnet any client will get an address from - which is the same for the case of a larger subnet and two pools within the one subnet.

A key thing to remember is that there is no such thing as "I receive packages from subnet 186.90.0.0" for broadcast packets. When a client is configuring itself, it has no IP address, so the concept of belonging to a specific subnet does not exist - the only "location" for the client is the broadcast domain which in the case of a shared-network hosts multiple subnets. When the server receives a packet from IP address 0.0.0.0, there just isn't any way to say it belongs to one subnet or another.

As an aside, this is also the reason you can't run a DHCP service on a sub-interface (eg eth0.1) - when broadcast packets come in, there's no way to route that packet to the main interface (eth0) or the subinterface (eth0.1).

Only when a client has been allocated an address, and configured it's interface, does it "belong" to a specific subnet.


For a "fresh" install, the address allocation order is determined by the way the code works - which is not specified and liable to change without notice. At present this is a "top down" ordering where the highest numerical address is issued first.
Once there are no "never used before" addresses left, then addresses are re-used on a least recently used basis - at which point allocation takes on a pseudo-random appearance.
If a client requests a specific address, and that address is available, then that address will be given. So if there are clients which already had addresses on the network, then depending on how "clingy" they are, you will see "out of order" allocation of never used before addresses.

If you need specific clients to get addresses in specific pools, then you need to tell the server about your requirements. This may be as simple as defining host statements for certain clients and using allow/deny known-clients in the pools. Or it may be more complicated, using classes and possibly subclasses.

_______________________________________________
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

[Muhammad Faisal]

Few cents of mine:

Recently encountered the situation where different clients are required to be segregated for different cities and assigned different subnets from centralized server. For this we have defined required subnets and used "option router" to classify different hosts for respective subnet. Using shared network to achieve the above did not work as explained below.

 

---

From: Patrick Trapp <[hidden email]>
To: Users of ISC DHCP <[hidden email]>
Sent: Wednesday, October 28, 2015 7:49 PM
Subject: RE: Weird behavior with multiple pool inside shared networks

I meant to reply earlier. I have nothing to add to the excellent responses you already have in hand, but we are doing what you are trying to do, I think, by using option-82 information to determine the source network of the request and assigning to the desired pool accordingly.

I'm sure there are other ways, but I thought I would share that one since I know it works for our equipment and our network.

---

From: [hidden email] [[hidden email]] on behalf of Roberto De Oliveira [[hidden email]]
Sent: Wednesday, October 28, 2015 9:29 AM
To: Users of ISC DHCP
Subject: Re: Weird behavior with multiple pool inside shared networks

Thanks Simon,

Excellent explanation, I think that I have to rethink somethings on my network.

Thanks to Steven and Niall also.

2015-10-27 4:47 GMT-04:30 Simon Hobson <[hidden email]>:

Steven Carr <[hidden email]> wrote:

> On 27 October 2015 at 04:18, Roberto De Oliveira <[hidden email]> wrote:
>> What is wrong with my configuration?
>
> Nothing, it's working as intended. A shared network means that those
> two networks inside of there are in the same broadcast domain,
> therefore it doesn't matter which pool of addresses the clients are
> assigned an IP address from it should still work. DHCPD won't move on
> to the second pool until it's exhausted the first pool.

To expand on that a bit ...
The shared-network statement tells the server that the two (or more) subnets are on the same network (broadcast domain). That explicitly means all IP addresses are to be considered equal.
There is no way to determine in advance which subnet any client will get an address from - which is the same for the case of a larger subnet and two pools within the one subnet.

A key thing to remember is that there is no such thing as "I receive packages from subnet 186.90.0.0" for broadcast packets. When a client is configuring itself, it has no IP address, so the concept of belonging to a specific subnet does not exist - the only "location" for the client is the broadcast domain which in the case of a shared-network hosts multiple subnets. When the server receives a packet from IP address 0.0.0.0, there just isn't any way to say it belongs to one subnet or another.

As an aside, this is also the reason you can't run a DHCP service on a sub-interface (eg eth0.1) - when broadcast packets come in, there's no way to route that packet to the main interface (eth0) or the subinterface (eth0.1).

Only when a client has been allocated an address, and configured it's interface, does it "belong" to a specific subnet.


For a "fresh" install, the address allocation order is determined by the way the code works - which is not specified and liable to change without notice. At present this is a "top down" ordering where the highest numerical address is issued first.
Once there are no "never used before" addresses left, then addresses are re-used on a least recently used basis - at which point allocation takes on a pseudo-random appearance.
If a client requests a specific address, and that address is available, then that address will be given. So if there are clients which already had addresses on the network, then depending on how "clingy" they are, you will see "out of order" allocation of never used before addresses.

If you need specific clients to get addresses in specific pools, then you need to tell the server about your requirements. This may be as simple as defining host statements for certain clients and using allow/deny known-clients in the pools. Or it may be more complicated, using classes and possibly subclasses.

_______________________________________________
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

[Simon Hobson]

Muhammad Faisal <[hidden email]> wrote:

> Recently encountered the situation where different clients are required to be segregated for different cities and assigned different subnets from centralized server. For this we have defined required subnets and used "option router" to classify different hosts for respective subnet. Using shared network to achieve the above did not work as explained below.

I assume these different cities were using different subnets, with traffic routed between them ? If so then that is *NOT* a shared network, and you are correct that defining a shared-network would not work. For multiple routed networks, selecting an appropriate address for the client happens automagically based on the GI-Addr (Gateway Interface Address) value inserted into the relayed packet by the BOOTP relay agent serving the remote network.

BTW - for an easy to read and in depth explanation of how it all works, lookup The DHCP Handbook by Ralph Droms and Ted Lemon (two of the key people responsible for the ISC DHCP server, and who really know their stuff). I recommend this book - it covers the "why" (including an explanation of earlier methods), and the "how". The 2nd edition also covers failover.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users