isc-dcp-server behavior when receiving duplicate requests
 

Hi everyone,

I hope you can help me understanding how to handle the following problem.

MY OBJECTIVE
I have a network with several segments and one DHCP server. Each segment has a network element that I want to get a static IP.
I identify the segments where the network elements are by using DHCP option 82 (remote-id + circuit-id) and I provide a static IP address.

IMPLEMENTATION for test
SERVER A is running isc-dhcp-server on a Debian OS.
SWITCH A is configured with server A as DHCP relay server. Option 82 is added with circuit-id and remote-id.
CLIENT - A DHCP client

FLOW DESCRIPTION
Once I power on the client (connected to SWITCH A) following message flow is visible:
In other words:
1 - Client sends broadcast DHCP discover.
2 - Switch forwards the DHCP DISCOVER broadcast and,
3 - Sends a DHCP DISCOVER unicast to server A with option 82 remote-id and circuit-id
4 - Server A ignores the broadcast from point 2 (no lease for that request since there is no match)
5 - Server A responds to the unicast DHCP DISCOVER from point 3 with a DHCP OFFER.
6 - Switch A forwards the DHCP Offer to the client
7 - Client sends a broadcast DHCP REQUEST
8 - Switch A forwards the broadcast to server A and,
9 - Switch sends a DHCP requets unicast to Server A.
10 - The server will answer with NACK to the broadcast DHCP Request (since there is no circuit-id in the DHCP request that matches the lease)
11 - Server will answer with an ACK to the unicast

I attached a wireshark capture where:
DHCP server: 10.1.52.1 and 192.168.255.112 (relay server)
Switch : 10.1.52.80

Now, the behavior at the client will vary depending on the DHCP client implementation:
a) Windows client - a new DHCP discover is sent right after receiving the NACK. The ACK response is discarded. A DHCP Discover, request, NACK, ACK loop happens and the client never uses the received IP address.
b) OpenWRT Access Point - same as previous
c) Debian OS client with dhclient : The DHCP DISCOVER is sent at a higher timing than fro Windows or the openwrt. Hence, the ACK response is accepted and the client uses the received IP address.
d) HP Access Point - same as c)


QUESTIONS
1 - Is there a way to configure isc-dhcp-server to validate the DHCP Request using the MAC address instead of the circuit-id? I would avoid the NACK response.
2 - Is there a way to configure isc-dhcp-server to avoid sending NACK (Not-authoritative doesn't work here because the lease is from this server).
3 - Is there a way to configure isc-dhcp-server to answer only unicasts and no broadcasts?


I tried, as a workaround at server A, to DROP brodcast answers for ports 67 and 68 but since isc-dhcp-server uses raw sockets the iptables are bypassed. I solved my problem by removing isc-dhcp-server and usnig dnsmasq since this one can be blocked by iptables but I would prefer to use isc-dhcp-server rather than dnsmasq.

Your help is appreciated!

Best regards

Why not just run a separate DHCP instance for each network segment?

Edit: I guess not easy to do without multiple NICs. Maybe have a tap interface and a VPN to the switch for each segment, assuming its smart enough to forward broadcasts to the right VPN.

Thanks for your response @smallpond.
The issue is more complicated. I tried in my post to simplify it at most and I might have passed the wrong idea.

My DHCP server has only one interface connected to a ring network of several switches. I have to identify where the network elements are and I do that by using option 82.
That is why I try to find a solution at isc-dhcp-server.