1

I have configured a Linux dhcpd server with multiple scopes on the same interface(eth0). The devices which needs these IP address(DHCP clients) are on two different remote networks. The networking team has completed all the configuration including DHCP relays in between so the requests are reaching my DHCP server in the following format:

DHCPDISCOVER from macaddress via 10.238.16.10 (remote_network_1)

DHCPDISCOVER from macaddress via 10.238.25.20 (remote_network_2)

(I think the IPs mentioned above belongs to the remote routers which are forwarding DHCP requests to my server.)

Right now the DHCP server is successfully assigning IPs from the first configured scope(10.238.16.x) to clients requesting from both remote_network_1 and remote_network_2.

How can I configure it so that when a request comes in from 10.238.16.10, it assigns an 10.238.16.X IP and when it comes from 10.238.25.20, it assigns an 10.238.25.X IP.

I know there are other ways to tackle this issue - like configuring dhcpd to listen on two different interfaces etc, but that won't work for me.

I tried "option broadcast-address" but that didn't work.

My dhcpd.conf:

ddns-update-style none;

default-lease-time 6000;
max-lease-time 72000;

authoritative;

log-facility local7;


subnet 10.238.24.0 netmask 255.255.255.248 {
}

shared-network DA {
    subnet 10.238.16.0 netmask 255.255.255.0{
        range 10.238.16.52 10.238.16.254;
        option routers 10.238.24.9;     
        option broadcast-address 10.238.16.255;
    }

    subnet 10.238.25.0 netmask 255.255.255.0{
        range 10.238.25.52 10.238.25.254;
        option routers 10.238.24.9;
        option broadcast-address 10.238.25.255;
    }

}

From syslog:

Feb  3 13:32:18 linux-server dhcpd: DHCPDISCOVER from b8:5e:7b:1e:c2:89 via 10.238.25.20
Feb  3 13:32:19 linux-server dhcpd: DHCPOFFER on 10.238.16.53 to b8:5e:7b:1e:c2:89 (android-ba98679bfc07f0cb) via 10.238.25.20
Feb  3 13:32:19 linux-server dhcpd: DHCPREQUEST for 10.238.16.53 (10.238.24.20) from b8:5e:7b:1e:c2:89 (android-ba98679bfc07f0cb) via 10.238.25.20
Feb  3 13:32:19 linux-server dhcpd: DHCPACK on 10.238.16.53 to b8:5e:7b:1e:c2:89 (android-ba98679bfc07f0cb) via 10.238.25.20
Feb  3 13:35:40 linux-server dhcpd: DHCPDISCOVER from 40:f3:08:89:3f:13 via 10.238.16.10
Feb  3 13:35:41 linux-server dhcpd: DHCPOFFER on 10.238.16.54 to 40:f3:08:89:3f:13 (android-47aa390064e91817) via 10.238.16.10
Feb  3 13:35:41 linux-server dhcpd: DHCPREQUEST for 10.238.16.54 (10.238.24.20) from 40:f3:08:89:3f:13 (android-47aa390064e91817) via 10.238.16.10
Feb  3 13:35:41 linux-server dhcpd: DHCPACK on 10.238.16.54 to 40:f3:08:89:3f:13 (android-47aa390064e91817) via 10.238.16.10
2
  • 2
    This should just work, assuming you have properly configured your scopes. Perhaps show us your config file, and tell us what the netmasks are for these networks? Past that look at DHCP dump.
    – Zoredache
    Feb 3 '14 at 22:34
  • Unfortunately it did not. I have updated the question with more information..
    – Debianuser
    Feb 20 '14 at 17:46
1

Removed the shared-network portion. This is not a shared network. You just need the two scopes. From man dhcpd.conf:

The shared-network statement is used to inform the DHCP server that some IP subnets actually share the same physical network. Any subnets in a shared network should be declared within a shared-network statement. Parameters specified in the shared-network statement will be used when booting clients on those subnets unless parameters provided at the subnet or host level override them. If any subnet in a shared network has addresses available for dynamic allocation, those addresses are collected into a common pool for that shared network and assigned to clients as needed. There is no way to distinguish on which subnet of a shared network a client should boot.

You should also fix the option routers line in each subnet. This line should list the default gateway for each network.

1

In the end we figured out the best way to do this is to configured DHCPD to assign static IP based on device mac address.

We control the devices that connect to these networks and there are only a limited number of them so this solution works for us. It is a bit of extra work but adds some security as well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.