DHCP Conflits

First, DHCP has been rock solid for a long, long time, even in FortiOS v3.00. Second, what is your exact FortiOS version (see your other post for the command how to find that out). - does the FGT show DHCP leases given to clients? do these (of which the FGT knows that they are already used) conflict, or others from the range? - are you 100% sure you don' t have any other DHCP servers online: WLAN accesspoints, NAS, even desktop switches sometimes have this feature - it helps to determine if the FGT is the only DHCP server if you can see that all other information is handed out correctly, that is DNS server, gateway IP, netmask. A ' rogue' DHCP server which runs without you knowing it would probably not have the same configuration.

Hi, as Ede mentioned DHCP is rock-solid with any FortiOS or Fortigate out there! The only problem with DHCP and Fortigate might be from a design issue: - Fortigates keep there DHCP leases only in memory! (honestly I' ve not tried it with HD models...) - when you reboot the firewall or have power problems, then you lose the lease database!!! - then you might have real troubles with DHCP if you rely on it with a larger DHCP lease database.... Consider using realy short lease times and try avoid rebooting the Fortigate!! best regards, Roman

A cleared DHCP lease DB will IMHO not lead to duplicate assignment. This is what happens when a client requests an address (as far as I' ve understood the process): - client broadcasts for DHCP server Windows clients include the last used IP address, and their hostname - DHCP server replies with next free IP address, based on all current entries in lease DB - DHCP server will check if the proposed/requested IP address is already in use by pinging it! - if not in use, DHCP request is granted and IP address is entered into lease DB Even with an intact DHCP database the server has to check for duplicates before granting an IP. Otherwise it would risk that a static IP put in use before that request would be duplicated. So in short: even an empty DHCP database will not lead to duplicate addresses being assigned. OK, if you check the RFC 2131, you' ll find:

As a consistency check, the allocating server SHOULD probe the reused address before allocating the address, e.g., with an ICMP echo request, and the client SHOULD probe the newly received address, e.g., with ARP.

DHCP must: o Retain DHCP client configuration across DHCP client reboot. A DHCP client should, whenever possible, be assigned the same configuration parameters (e.g., network address) in response to each request, o Retain DHCP client configuration across server reboots, and, whenever possible, a DHCP client should be assigned the same configuration parameters despite restarts of the DHCP mechanism,

Ede, all what you write here is correct! But with DHCP clients like IP-Phones, which do not remember their last assigned address, you can always run into trouble with a dhcp server, that does not have a permanent storage!! The Fortigate only tests 3 addresses in the duplicates check and then does not hand out any ip address any more! It will mark the address in the database with a conflict! With many devices that do not remember the last address this scenario can easily happen!! best regards, Roman

Will if that is all true on what you state, then you have the following options; 1> static assign the phones 2> move the phones from the main users network and place then on a seperate vlan/interface and assigned a dhcp-scope for phones only 3> shorten the lease timeframe fwiw, I' ve never see conflicts with any version of fortios from what I can remember. Outside of having a rouge dhcp-server, dhcp is rock solid on the fortigates. and rogue dhcp server protection, can easily be mitigated iwth cisco and a few other switches vendor with ip dhcp snooping.

I lost power for a week so i' ll keep an eye on it now. I have version Fortigate-60 3.00,build0318,060630. i was going to upgrade it its worth the cost to do so. Right now i have trouble with it not listening to reserved ips. I set an ip and set mac on a few machines but it just ignores those settings. any thoughts? does the reserved list have to be bound to the server part some how? I excluded those lower numbers and it didn' t work. I tried to change the range of the server and that didn' t work. show system dhcp reserved-address config system dhcp reserved-address edit " MacMini" set ip 192.168.1.3 set mac 10:9a:dd:5b:7b:db next edit " XPServer" set ip 192.168.1.2 set mac 00:1f:e2:69:0e:82 next edit " IPCamTrend" set ip 192.168.1.10 set mac 00:14:d1:8a:79:db next end

the dhcp range is 192.168.1.2-200. The resereved addresss are 2-10. I' ve excluded 11-99. IT still does not listen to my requests. I added my laptop to 1.6 but it got an ip of 102. Any Thoughts?

Please post your reservations:

 conf sys dh res     show  end

here is the reservations and dhcp server: config system dhcp reserved-address edit " MacMini" set ip 192.168.1.3 set mac 10:9a:dd:5b:7b:db next edit " XPServer" set ip 192.168.1.2 set mac 00:1f:e2:69:0e:82 next edit " IPCamTrend" set ip 192.168.1.10 set mac 00:14:d1:8a:79:db next edit " Dell3100" set ip 192.168.1.7 set mac 08:00:37:32:17:ff next edit " Vonage" set ip 192.168.1.8 set mac 00:24:2b:e9:f4:7d next edit " GregLaptop" set ip 192.168.1.6 set mac 00:26:b0:e0:81:90 next end config system dhcp server edit " internal" set default-gateway 192.168.1.1 set dns-server1 68.105.28.16 set dns-server2 208.67.222.222 set dns-server3 8.8.8.8 set end-ip 192.168.1.200 config exclude-range edit 1 set end-ip 192.168.1.5 set start-ip 192.168.1.4 next edit 2 set end-ip 192.168.1.9 set start-ip 192.168.1.9 next edit 3 set end-ip 192.168.1.99 set start-ip 192.168.1.11 next end set interface " internal" set lease-time 21600 set netmask 255.255.255.0 set start-ip 192.168.1.2 next end

The mac addresses i see in the dhcp lease list are the same as those in the cli output. Thats why i' m confused. Also the dhcp is the same address as the router itself, 192.168.1.1.