| Description | This article describes how to troubleshoot the DHCP relay if the DHCP client cannot be assigned an IP address. |
| Scope | FortiGate. |
| Solution |
Topology:
Host(DHCP client)----(port2 10.57.1.147)FGT(port1 10.56.241.147)---------(10.56.241.172)DHCP Server
get router info routing-table details <DHCP Server IP> execute ping <DHCP Server IP>
Take packet capture on the Ingress interface of the client on FortiGate via the packet capture function, filtering ports 67, 68
If a specific client MAC Address is required to be checked, run the following Sniffer and provide it to TAC to convert it to PCAP :
diagnose sniffer packet <interface> "ether host aa:bb:cc:dd:ee:ff" 6 0 l
Note: A specific interface is required to filter the sniffer using MAC Address. Interface 'any' cannot be used.
To verify the client's DHCP Discover request is sent out, filter the outgoing interface packet capture using the filter : dhcp.hw.mac_addr == AA:BB:CC:DD:EE:FF, whereby AA:BB:CC:DD:EE:FF is the client's MAC address.
If it is seen, it means FortiGate has sent out the client's DHCP Discover, and further check would need to be done on the DHCP Server.
Note: It would be FortiGate's internal IP address 10.57.1.147 (the interface that faces the DHCP client) and NOT the external IP address 10.56.241.147 that sends DHCP Discover to the DHCP relay server. It would cause no reply if the DHCP server did not have the route to the 10.57.1.0/24 subnet.
In this example, a static route is added to the DHCP server:
route add 10.57.1.0/24 MASK 255.255.255.0 10.56.241.147.
After that, FortiGate will receive a DHCP offer and ACK.
FortiGate then forwards ACK with the new IP address 10.57.1.2 to the Host.
Also, run dhcprelay debugs as mentioned below:
diagnose debug application dhcprelay -1
Collect the reproduction logs, then disable debug:
diagnose debug reset |
