DHCP Relay Issue

[Polina]

Hello,

Could you please help me with a DHCP Relay issue? We have a bond interface and several VLAN interfaces added to it. DHCP Relay is configured for each VLANs.
When traffic passes through one cluster node, DHCP Relay works correctly, but when another node becomes active, clients in one VLAN stop receiving addresses from the DHCP server. This issue only affects one VLAN; in all other networks, DHCP Relay works correctly on both cluster nodes.

We've already tried several SK methods to resolve the issue, but nothing works.
The strange thing is that both cluster members are configured identically.

Has anyone seen similar issues? Or are there any solutions for fixing this?

[WiliRGasparetto]

Hi Polina, have you already checked the DHCP traffic?

Check DHCP traffic arriving on the VLAN (client → gateway):

tcpdump -eni bondX.<VLAN> -vv udp port 67 or 68

Check DHCP relay traffic leaving towards the server (gateway → server):

tcpdump -eni <iface-to-dhcp-server> -vv udp port 67 or 68

If on member B you do not see the DHCPDISCOVER broadcast reaching the VLAN sub-interface, then it points to an L2/tagging/trunk issue.

If you can, please share the relevant tcpdump output/logs so we can review them and help you more effectively.

[WiliRGasparetto]

To tell you the “most likely root cause” without guessing, please send me these 4 pieces of evidence:

1. Version: R80.40 / R81.10 / R81.20 / R82 + JHF/take

2. Screenshot/output of the DHCP Relay configuration for the affected VLAN only (including Primary Address, if configured)

3. Output of fw ctl get int fwx_dhcp_relay_nat on both cluster members

4. Two 20–30 second tcpdumps during failover (good member vs bad member): one on the VLAN sub-interface and one on the interface towards the DHCP server

[the_rock]

This is the abbreviation often used when it comes to dhcp:

Detailed Breakdown of the DORA Process:

• Discover (DHCPDISCOVER): The client sends a broadcast message on the network to locate available DHCP servers.
• Offer (DHCPOFFER): The server receives the request and sends a unicast or broadcast offer containing an IP address, subnet mask, default gateway, and DNS information.
• Request (DHCPREQUEST): The client accepts the offer and broadcasts a request, notifying the server (and others) that it will use that specific IP address.
• Acknowledge (DHCPACK): The server sends a final confirmation (unicast) to the client, authorizing the lease and completing the process. 

Now, here is what I would do...can you run tcpdump/fw monitor and see where this exactly fails? That will 100% tell you why its not working. Also, I would make sure config matches the working firewall. Sometimes, people may forget, specially if they worked long time with another vendor (ie Fortinet for example), that in such case, there is no VIP, everything is replicated automatically from master to backup fw, unlike Check Point, where you would need to ensure it is the same.