APM-DHCP Access Policy Example and Detailed Instructions
Prepared with Mark Quevedo, F5 Principal Software Engineer May, 2020
Sectional Navigation links Important Version Notes || Installation Guide || What Is Going On Here? || Parameters You ...
Updated Sep 08, 2023
Version 9.0
Chase_Abbott
Employee
EmployeeChase_AbbottEmployee
Employee
Gopichand_YaraganiEmployee
Employee
M_Quevedo
Nimbostratus
Nimbostratus
, thank you very much. Based on your packet trace I have found the bug in APM-DHCP which explains why your DHCP server sends sends NAK when Option 61 client-id is not being used.
In each DHCP message there is a fixed-width field of 16 octets to hold the client-hardware-address value. The true length of the client-hardware-address is put into a "length" field of 1 octet. A classic (Ethernet-like) MAC address is 6 octets long, and the remaining 10 octets in the client-hardware-address field are filled with zeroes.
The APM-DHCP bug is to set the "length" field correctly in the DHCPDISCOVER message but set it (incorrectly) to 16 always in the DHCPREQUEST message. Many DHCP servers ignore that "length" field, but not yours!
I have fixed this bug in the forthcoming version v4b of the DHCP iApp.