Devices are sending DHCP requests but not receiving any responses

• Hosts were sending DHCP requests but not receiving any responses.
• No DHCP requests exiting out of  the switch port of the ION.
• ION was dropping DHCP requests meant for the DHCP server on the switchport.

• Prisma SD-WAN
• DHCP Server

Sequence of Events Causing DHCP Relay Failure :

1.  Route Diversion: When interface goes down, the route to the DHCP server is lost. Consequently, traffic is redirected over the preferred default route, which is the Fabric VPN to the back up Hub site. 
2. UDP Flow Persistence :Despite Fabric VPN being an allowed path, the DHCP traffic does not switch back to interface once it's restored. This is due to two key conditions:
   Stateless UDP: UDP is a stateless protocol, requiring a timeout before new packet detection for the same flow can be initiated.
   Continuous Requests: We observe a continuous stream of DHCP requests from interfaces being forwarded to the dhcp server which prevents the existing UDP flow from timing out.
3.  Persistent Forwarding: As UDP traffic is not switched while it remains allowed and forwarded, and existing flows haven't timed out, DHCP packets continue to be sent to the server via the Fabric VPN to the HUB site, even after interface comes back online.

The core problem arises when an interface flaps; the ION is not performing a Flow Controller (FC) lookup to check for the preferred available primary path. Required Flow Timeout:To ensure the ION correctly identifies the primary path, the DHCP flow must be timed out. It has been concluded that the DHCP flow should be timed out within 1800 to 2000 milliseconds to prevent an outage when an interface flaps. Solution: This desired timeout behavior can be achieved by creating a custom DHCP Application and setting its session timeout to 1800–2000 MS. This timeout will force the flow to expire, prompting the necessary FC lookup to steer traffic back to the available primary path.