Troubleshooting Tip: Resolving DHCP lease conflict Issue on FortiGate

[sjoshi]

Description

This article describes the steps to resolve a DHCP lease conflict issue on FortiGate, where the device is unable to assign an IP address to a client due to a conflict with an existing IP address on the network.

Scope

FortiGate.

Solution

FortiGate is experiencing a DHCP conflict issue. The device is unable to assign IP addresses to clients due to conflicts, despite nobody running the DHCP lease clear command.

As a first step, review the existing dhcp leases by the DHCP server on this FortiGate to check for any issues using the below CLI command.

FortiGate# execute dhcp lease-list

Take DHCP debugs.

SSH1:

diagnose debug reset
diagnose debug application dhcps -1
diagnose debug enable

To stop the debug:

diagnose debug reset
diagnose debug disable

SSH2:

diagnose sniff packet any 'port 67 or 68' 6 0 l

Note down the MAC address of the PC facing the issue.

Note: If there is any VIP or IP pool configured, then please disable ARP reply.

Related article:

Troubleshooting Tip: FortiGate is not providing DHCP with error DHCP DECLINE 

Before leasing an IP address, a DHCP server may perform conflict detection using either ICMP (Ping) or ARP. It sends an ICMP Echo Request or ARP probe to the intended IP address. If a response is received, indicating the address is already in use, the server marks it as conflicted and avoids assigning it. If no response is received, the IP is considered available and is assigned to the client.

Let's review the logs below:

The PC D0:65:78:16:67:96 is facing the issue of getting the IP address.

Log 1: Here, the FortiGate assigns the IP 172.16.30.51 to the client and sends.

[note]DHCPDISCOVER from d0:65:78:16:67:96 via port9(ethernet)
[debug]found a new lease of ip 172.16.30.51
[debug]added ip 172.16.30.51 mac d0:65:78:16:67:96 in vd root

[debug]Sending ICMP echo-request to 172.16.30.51 -> FortiGate sends an ICMP Echo Request to verify whether the IP address is already in use on the network before assigning it.

[debug]Received ICMP echo-reply from 172.16.30.51 -> FortiGate got reply from some other device.
[warn]Abandoning IP address 172.16.30.51: pinged before offer -> FortiGate abandoned the IP because this IP is already in use by some other network.
[debug]deled ip 172.16.30.51 mac d0:65:78:16:67:96 in vd root

Log 2: Since the previously selected IP address was already in use, FortiGate attempted to assign a new IP address. However, a response was again received from a device on the downstream network, indicating that the newly selected IP address is also in use.

[note]DHCPDISCOVER from d0:65:78:16:67:96 via port9(ethernet)
[debug]found a new lease of ip 172.16.30.53
[debug]added ip 172.16.30.53 mac d0:65:78:16:67:96 in vd root

[debug]Sending ICMP echo-request to 172.16.30.53
[debug]Received ICMP echo-reply from 172.16.30.53
[warn]Abandoning IP address 172.16.30.53: pinged before offer
[debug]deled ip 172.16.30.53 mac d0:65:78:16:67:96 in vd root

Log 3:

[note]DHCPDISCOVER from d0:65:78:16:67:96 via port9(ethernet)
[debug]found a new lease of ip 172.16.30.54
[debug]added ip 172.16.30.54 mac d0:65:78:16:67:96 in vd root

[debug]Sending ICMP echo-request to 172.16.30.54
[debug]Received ICMP echo-reply from 172.16.30.54
[warn]Abandoning IP address 172.16.30.54: pinged before offer
[debug]deled ip 172.16.30.54 mac d0:65:78:16:67:96 in vd root

Log 4:

[note]DHCPDISCOVER from d0:65:78:16:67:96 via port9(ethernet)
[debug]found a new lease of ip 172.16.30.55
[debug]added ip 172.16.30.55 mac d0:65:78:16:67:96 in vd root

[debug]Sending ICMP echo-request to 172.16.30.55
[debug]Received ICMP echo-reply from 172.16.30.55
[warn]Abandoning IP address 172.16.30.55: pinged before offer
[debug]deled ip 172.16.30.55 mac d0:65:78:16:67:96 in vd root

Log 5:

[note]DHCPDISCOVER from d0:65:78:16:67:96 via port9(ethernet)
[debug]found a new lease of ip 172.16.30.56
[debug]added ip 172.16.30.56 mac d0:65:78:16:67:96 in vd root

[debug]Sending ICMP echo-request to 172.16.30.56
[debug]Received ICMP echo-reply from 172.16.30.56
[warn]Abandoning IP address 172.16.30.56: pinged before offer
[debug]deled ip 172.16.30.56 mac d0:65:78:16:67:96 in vd root

Log 6:

[note]DHCPDISCOVER from d0:65:78:16:67:96 via port9(ethernet)
[debug]found a new lease of ip 172.16.30.57
[debug]added ip 172.16.30.57 mac d0:65:78:16:67:96 in vd root

[debug]Sending ICMP echo-request to 172.16.30.57
[debug]Received ICMP echo-reply from 172.16.30.57
[warn]Abandoning IP address 172.16.30.57: pinged before offer
[debug]deled ip 172.16.30.57 mac d0:65:78:16:67:96 in vd root

Log 7:

[note]DHCPDISCOVER from d0:65:78:16:67:96 via port9(ethernet)
[debug]found a new lease of ip 172.16.30.58
[debug]added ip 172.16.30.58 mac d0:65:78:16:67:96 in vd root

[debug]Sending ICMP echo-request to 172.16.30.58
[debug]Received ICMP echo-reply from 172.16.30.58
[warn]Abandoning IP address 172.16.30.58: pinged before offer
[debug]deled ip 172.16.30.58 mac d0:65:78:16:67:96 in vd root

Log 8:

[note]DHCPDISCOVER from d0:65:78:16:67:96 via port9(ethernet)
[debug]found a new lease of ip 172.16.30.59
[debug]added ip 172.16.30.59 mac d0:65:78:16:67:96 in vd root

[debug]Sending ICMP echo-request to 172.16.30.59
[debug]Received ICMP echo-reply from 172.16.30.59
[warn]Abandoning IP address 172.16.30.59: pinged before offer
[debug]deled ip 172.16.30.59 mac d0:65:78:16:67:96 in vd root

Conclusion:

Based on the logs, FortiGate attempted to assign different IP addresses multiple times. Before assigning an IP, FortiGate sends an ICMP Echo Request to the Layer 2 network to verify whether the IP is already in use. In each case, an ICMP Echo Reply was received, indicating that the IP address is already active on the network. As a result, FortiGate marked the IP as conflicted and did not assign it.

This behavior indicates that FortiGate is functioning as expected. The repeated conflict suggests that the IPs are already in use by other devices on the network, despite not appearing in the DHCP lease list. This implies those systems may have obtained IP addresses from a different source or been manually assigned.

It is recommended to investigate the Layer 2 network and connected systems to determine why the conflicting IP address was already assigned. The presence of this address on the network is resulting in IP conflicts during DHCP allocation.