Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
discoscott
New Contributor III

Secondary FG DHCP server - delay to DHCP DISCOVER requests from DHCP clients

I currently have 2 x fortigates configured in a VRRP group. There are 2 x VLANs on both Fortigates and both Fortigates are VRRP master for one VLAN and backup for the subsequent VLAN. e.g. FW1 is master for VLAN 100 and FW2 is master for VLAN 200. FW1 is backup for VLAN 200 and FW2 is backup for VLAN 100.

 

I have configured split DHCP scopes on both fortigates so that if one goes down or connectivity is interupted, the other will serve DHCP addresses to clients.

 

Is there any way to set a delay in DHCP response on the FG to the secondary (VRRP backup) DHCP server so it will only offer an address if the primary VRRP firewall doesnt beat the backup unit? If not - how would I go about having this added as a feature request?

 

I went for VRRP over HA for capacity and granular policy control on the backup VLAN in a fail-over scenario. Session sync is not at all important in the current environment.

 

The alernate solution is to move DHCP server to Windows servers.

 

 

6 REPLIES 6
Toshi_Esumi
SuperUser
SuperUser

It probably wouldn't work well if both FGs or any other DHCP server devices share the same range of IPs. Both don't know what the other leased to the clients. 

discoscott
New Contributor III

The scopes are split so that each FW doesnt need to know about what the other FW has served.

 

e.g.

 

FW1 - 192.168.0.1-192.168.0.176

FW2 - 192.168.0.177-192.168.0.253

 

Toshi_Esumi

If so it wouldn't matter which offer the client picks, wouldn't it?

discoscott

Whilst it shouldnt matter which one responds, like a MS Windows DHCP server I would prefer to set which one answers first so as not to exhaust the scope of the backup(secondary) DHCP server.

 

e.g. FW1 responds immediately for VLAN 100 and FW1 responds after 1500ms for VLAN 200

then vice versa for FW2 - responds immediately for VLAN 200 and responds after 1500ms for VLAN 100

 

e.g. In MS Windows you would set a delay under the Advanced tab

http://blogs.technet.com/b/teamdhcp/archive/2009/01/22/how-to-prevent-address-exhaustion-from-second...

 

Toshi_Esumi

I'm not trying to discredit your claim but I'm just curious from the technical aspect. If the one of them has exhausted IPs, wouldn't the client pick another offer from the other FG?

Mikelar

Did you ever find a solution to this? I'm interested in similar functionality.

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors