This article explains, how DHCP behaves when DHCP packets have extra padding.
The issue is observed when extra padding is present in the DHCP packets and we observed below logs on the traceoptions, where in the non-working scenario L2 and L3 IFL ID remains to be same while in the working scenario these IFL Value to be differnent.
Non-working:
Oct 22 01:10:41.305777 [MSTR][INFO] [irb.90] jdhcpd_io_get_ifs: The L3 interface is 332 and L2 interface is 332, using the L3 interface
Working:
Oct 22 01:11:19.818083 [MSTR][INFO] [irb.90] jdhcpd_io_get_ifs: The L3 interface is 332 and L2 interface is 512, using the L3 interface
Oct 22 01:10:41.306393 [MSTR][NOTE] [default:default][RLY][INET][SID=0] jdhcpd_packet_handle: Failed to find L2 subunit stack or ifbd for Client on L2 ifindex 332, L3 ifindex 332 - Deleting client
Due to extra padding, the right L2 IFL information is not carried to control plane from PFE. This results in DHCP discover PDUs getting dropped at jdhcpd in control plane.
In our customer case, the problematic DHCP clients have padding in their DHCP PDUs leading to the issue. Without padding however the issue would not be seen, that's why we have some DHCP clients working as they don't have any padding in their DHCP PDUs.
On Trio chipset based platforms, when Dynamic Host Configuration Protocol (DHCP) packets have extra padding, DHCP discover packets get discarded resulting in DHCP OFFER not being received at the client.
JDHCPD is discarding the DHCP discover packets with error indicating that L2 IIF is incorrect. However, the issue is only seen in case packets have padding.
Oct 10 02:58:46.517728 [MSTR][WARN] [LOGSYS:default][RLY][INET][irb.20] jdhcpd_process_offer_advertise_delay: offer/advertise-delay: Not applicable
Oct 10 02:58:46.517750 [MSTR][NOTE] [LOGSYS:default][RLY][INET][SID=0] jdhcpd_packet_handle: Failed to find L2 subunit stack or ifbd for Client on L2 ifindex 362, L3 ifindex 362 - Deleting client
The issue was fixed in this PR.
https://prsearch.juniper.net/problemreport/PR1675316
Resolved In :
junos:21.4R3-S3 junos:21.4R3-S4 junos:22.2R3 junos:22.2R3-S3 junos:22.3R2 junos:22.3R3 junos:22.4R2 junos:22.4R3 junos:22.4R3-S2 junos:23.1R1 junos:23.2R1
Workaround :
Avoid padded DHCP packets.