DCHP OFFER response going to relay address not to orginating address

[Simon]

Dees <motosingh at yahoo.co.uk> wrote:

> With difficulty in routing internal site DHCP subnet across (it will prevent usual DHCP renewal through unicast assuming a client will eventually do DHCP broadcast), will the following subnet declaration for tunnel IP then give out a shared-network pool subnet 
> 
> shared-network Combined-pools {
> subnet 192.168.1.0 netmask 255.255.255.0 {
>   range 192.168.1.100 192.168.1.254;
>   option subnet-mask 255.255.255.0;
>   option routers 192.168.1.1;
> 
> option domain-name-servers 8.8.8.8, 8.8.4.4;
>                                           }
> 
> subnet 192.168.3.0 netmask 255.255.255.0  {  # subnet on interface 
>                                                                        }
>                  
> subnet 10.0.8.0 netmask 255.255.255.0  {
>                                                                   }
>                                 }
> 
> Where 10.0.8.0 is the subnet for the tunnel interface.

Is 192.168.3.0/24 the interface on the DHCP server ? If so, then it should NOT be in the shared-network.
Otherwise, yes that should do it provided your relay agent allows you to set the CI-Addr (Client Interface Address) field to 10.0.8.n rather than 192.168.1.1.
The normal function of the shared-network declaration is to handle the case where you run two (or more) IP subnets on the one wire, and where (in principle) all IPs in the subnets are functionally equivalent. Here, we are sort of cheating the system to work around broken routing.

The way things work is :

When a client broadcasts for a DHCP server, the relay agent will pick up the packet. It then fills in the CI-Addr field to inform the server where the client is located. The packet is then unicast to the server(s) it’s configured to - the source address doesn’t actually matter here.

When the server picks up the packet, it sees the CI-Addr field and looks for a subnet declaration that contains it. If there’s a shared-network declaration, then that will be taken into account - all addresses within subnets within a shared-network are considered equal.
In this case, your CI-Addr will be in one subnet of the shared-network, and as there are only ranges in the other subnet, then those will be used.

The response packet will then be unicast to the CI-Addr regardless of the IP being offered or the source address of the request packet.

And finally the gateway will broadcast the packet on the client’s network so the client can pick it up.


As I say, ideally you should simply add the requisite route to the subnet.
Without that, you will have clients attempting to renew leases and failing to do so. If the packets reach the server then that will increase the load on the server as it will be responding to each of the renewal requests.
Different clients may behave differently, and it’s possible that some “poorly designed” ones may time out. Most should resort to broadcasts a short time before their lease times out and so should still be able to renew without timing out.


Simon