Separates VLANs with the same IP-Range

Hello,

is it possible to configure a DHCP Server with multiple Relay-Servers identified via option 82(remote-id) for separates VLANs like the following example. If yes, how to set up?

DHCP-Server(10.0.3.24/24)
Relay1(10.0.3.55/24 and 192.168.0.1/24) -> offer IP-Range 192.168.0.100 - 150
Relay2(10.0.3.70/24 and 192.168.0.1/24) -> offer IP-Range 192.168.0.100 - 150

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

[perl-list]

I'm not sure how option 82 remote-id relates to the below, but you could cause both relays to allocate from the same ip range by setting up a shared network like this:

shared-network SomeNetwork {
     subnet 192.168.0.0 netmask 255.255.255.0 {
          range 192.168.0.100 192.16.0.150;
     }
     subnet 10.0.3.0 netmask 255.255.255.0 {
          # This will link the 10.0.3.0/24 subnet to the 192.168.0.0/24 subnet for address allocation purposes.
          # any relayed DHCP traffic from source 10.0.3.55 or 10.0.3.70 will cause the DHCP server to allocate
          # an address from 192.168.0.0/24
     }
}

----- Original Message -----
> From: [hidden email]
> To: "Users of ISC DHCP" <[hidden email]>
> Sent: Thursday, April 25, 2019 5:19:03 PM
> Subject: Separates VLANs with the same IP-Range

> Hello,

> is it possible to configure a DHCP Server with multiple Relay-Servers identified
> via option 82(remote-id) for separates VLANs like the following example. If
> yes, how to set up?

> DHCP-Server(10.0.3.24/24)
> Relay1(10.0.3.55/24 and 192.168.0.1/24) -> offer IP-Range 192.168.0.100 - 150
> Relay2(10.0.3.70/24 and 192.168.0.1/24) -> offer IP-Range 192.168.0.100 - 150

> Thanks in advance
> _______________________________________________
> 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-2]

perl-list <[hidden email]> wrote:

>> is it possible to configure a DHCP Server with multiple Relay-Servers identified
>> via option 82(remote-id) for separates VLANs like the following example. If
>> yes, how to set up?
>
>> DHCP-Server(10.0.3.24/24)
>> Relay1(10.0.3.55/24 and 192.168.0.1/24) -> offer IP-Range 192.168.0.100 - 150
>> Relay2(10.0.3.70/24 and 192.168.0.1/24) -> offer IP-Range 192.168.0.100 - 150

> I'm not sure how option 82 remote-id relates to the below, but you could cause both relays to allocate from the same ip range by setting up a shared network like this:
>
> shared-network SomeNetwork {
>     subnet 192.168.0.0 netmask 255.255.255.0 {
>          range 192.168.0.100 192.16.0.150;
>     }
>     subnet 10.0.3.0 netmask 255.255.255.0 {
>          # This will link the 10.0.3.0/24 subnet to the 192.168.0.0/24 subnet for address allocation purposes.
>          # any relayed DHCP traffic from source 10.0.3.55 or 10.0.3.70 will cause the DHCP server to allocate
>          # an address from 192.168.0.0/24
>     }
> }

That will not work - or rather, DHCP will not work in the network described.
The OP wants to run the same IP subnet on two separate networks. That is not supported as there is no way to make it work.
In theory it could be possible to handle relayed traffic via some sort of fudge, but not all DHCP traffic is relayed. When a client contacts the server directly by unicast (eg to renew an active lease) then the server has a problem - if does not know which network the packet came from, and there is no way to send the return packet back.

Fundamental rule of IP - addresses must be globally unique. NAT breaks this, but in the context of the query, IP addresses must be unique within the realm serviced by the DHCP server. This is not a DHCP limitation, it is a basic IP limitation - if addresses are not unique, then you can't build routing tables for them.

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

Hello together,

thanks for your support.
So i remove the nat konstrukt and add a subnet for the second relay.

Greetings

-------- Originalnachricht --------
Betreff: Re: Separates VLANs with the same IP-Range
Von: Simon Hobson
An: Users of ISC DHCP
Cc:

perl-list wrote:

>> is it possible to configure a DHCP Server with multiple Relay-Servers identified
>> via option 82(remote-id) for separates VLANs like the following example. If
>> yes, how to set up?
>
>> DHCP-Server(10.0.3.24/24)
>> Relay1(10.0.3.55/24 and 192.168.0.1/24) -> offer IP-Range 192.168.0.100 - 150
>> Relay2(10.0.3.70/24 and 192.168.0.1/24) -> offer IP-Range 192.168.0.100 - 150


> I'm not sure how option 82 remote-id relates to the below, but you could cause both relays to allocate from the same ip range by setting up a shared network like this:
>
> shared-network SomeNetwork {
> subnet 192.168.0.0 netmask 255.255.255.0 {
> range 192.168.0.100 192.16.0.150;
> }
> subnet 10.0.3.0 netmask 255.255.255.0 {
> # This will link the 10.0.3.0/24 subnet to the 192.168.0.0/24 subnet for address allocation purposes.
> # any relayed DHCP traffic from source 10.0.3.55 or 10.0.3.70 will cause the DHCP server to allocate
> # an address from 192.168.0.0/24
> }
> }

That will not work - or rather, DHCP will not work in the network described.
The OP wants to run the same IP subnet on two separate networks. That is not supported as there is no way to make it work.
In theory it could be possible to handle relayed traffic via some sort of fudge, but not all DHCP traffic is relayed. When a client contacts the server directly by unicast (eg to renew an active lease) then the server has a problem - if does not know which network the packet came from, and there is no way to send the return packet back.

Fundamental rule of IP - addresses must be globally unique. NAT breaks this, but in the context of the query, IP addresses must be unique within the realm serviced by the DHCP server. This is not a DHCP limitation, it is a basic IP limitation - if addresses are not unique, then you can't build routing tables for them.

_______________________________________________
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]

[hidden email] wrote:

> So i remove the nat konstrukt and add a subnet for the second relay.

It's not entirely clear what your network topology is here. Are you saying that there is NAT between the DHCP server and the clients ?


There must be no NAT between clients and server - the server needs to be able to send unicast packets to the client and this cannot be done if there is NAT in the path.
Also, you cannot have any overlap in IP addressing between networks - normal packet routing doesn't handle this, and the ISC DHCP server certainly doesn't.

Remember two two fundamental rules of IP are "addresses must be globally unique"(1) and "any node should be able to address a packet to any other node"(2). NAT breaks both of these.

1 - In the context here, in the collection of networks your DHCP server is to handle, all addresses must be unique.

2 - Obviously these days subject to administrative restrictions (ie firewall filters). But again for your context, the DHCP server and any client it is to support must be able to address unicast packets to each other and have them delivered.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[glenn.satchell]

Remember the DHCP relay only handles relaying broadcast traffic from the
client. This is the DHCPDISCOVER and initial response packets. Once the
client gets an IP address it talks directly to the DHCP server for
checking, renewing and acknowledging, the relay is no longer involved.

regards,
-glenn

On 2019-04-28 02:02, Simon Hobson wrote:

> [hidden email] wrote:
>
>> So i remove the nat konstrukt and add a subnet for the second relay.
>
> It's not entirely clear what your network topology is here. Are you
> saying that there is NAT between the DHCP server and the clients ?
>
>
> There must be no NAT between clients and server - the server needs to
> be able to send unicast packets to the client and this cannot be done
> if there is NAT in the path.
> Also, you cannot have any overlap in IP addressing between networks -
> normal packet routing doesn't handle this, and the ISC DHCP server
> certainly doesn't.
>
> Remember two two fundamental rules of IP are "addresses must be
> globally unique"(1) and "any node should be able to address a packet
> to any other node"(2). NAT breaks both of these.
>
> 1 - In the context here, in the collection of networks your DHCP
> server is to handle, all addresses must be unique.
>
> 2 - Obviously these days subject to administrative restrictions (ie
> firewall filters). But again for your context, the DHCP server and any
> client it is to support must be able to address unicast packets to
> each other and have them delivered.
> _______________________________________________
> 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]

That is not always 100% the case.  I've seen relay agents in ISP environments that never tell the client the location of the actual DHCP server.  They masquerade as the DHCP server swapping their own address for the GIADDR in the response packet.  Probably not proper RFC wise, but I have seen it.

----- Original Message -----
> From: "glenn satchell" <[hidden email]>
> To: "Users of ISC DHCP" <[hidden email]>
> Sent: Monday, April 29, 2019 2:14:02 AM
> Subject: Re: Separates VLANs with the same IP-Range

> Remember the DHCP relay only handles relaying broadcast traffic from the
> client. This is the DHCPDISCOVER and initial response packets. Once the
> client gets an IP address it talks directly to the DHCP server for
> checking, renewing and acknowledging, the relay is no longer involved.

> regards,
> -glenn

> On 2019-04-28 02:02, Simon Hobson wrote:
> > [hidden email] wrote:

> >> So i remove the nat konstrukt and add a subnet for the second relay.

> > It's not entirely clear what your network topology is here. Are you
> > saying that there is NAT between the DHCP server and the clients ?


> > There must be no NAT between clients and server - the server needs to
> > be able to send unicast packets to the client and this cannot be done
> > if there is NAT in the path.
> > Also, you cannot have any overlap in IP addressing between networks -
> > normal packet routing doesn't handle this, and the ISC DHCP server
> > certainly doesn't.

> > Remember two two fundamental rules of IP are "addresses must be
> > globally unique"(1) and "any node should be able to address a packet
> > to any other node"(2). NAT breaks both of these.

> > 1 - In the context here, in the collection of networks your DHCP
> > server is to handle, all addresses must be unique.

> > 2 - Obviously these days subject to administrative restrictions (ie
> > firewall filters). But again for your context, the DHCP server and any
> > client it is to support must be able to address unicast packets to
> > each other and have them delivered.
> > _______________________________________________
> > 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