In a recent post I described the cutover procedure used to move from a Virtual Chassis (VC) configuration to a Multi-Chassis Link Aggregation Group (MC-LAG) configuration. One of the other requirements on this cutover was to utilize DHCP Relay. However I ran into a problem getting the DHCP Relay to work.
When reviewing the statistics on Bootp Helper I noticed that the dropped packet counter “Due to no interface in fud database” was increasing exponentially. Naturally, I enabled traceoptions under forwarding-options helpers with the following command:
forwarding-options { helpers { traceoptions { file fud.log; level all; flag all; } } }
In the debug log we could see the following:
vndcpwar029@USDCA-SWJ-P01> show log fud.log May 6 21:51:24 fud_ifdb_get_addr(): getting database entry for irb.1221, port 67 May 6 21:51:28 received packet from 0.0.0.0 port 68 interface irb.1221 l2 interface ae21 rt_inst default May 6 21:51:28 fud_ifdb_get_addr(): getting database entry for irb.1221, port 67 May 6 21:51:31 received packet from 0.0.0.0 port 68 interface irb.1224 l2 interface ae21 rt_inst default May 6 21:51:31 fud_ifdb_get_addr(): getting database entry for irb.1224, port 67 May 6 21:51:36 received packet from 0.0.0.0 port 68 interface irb.1221 l2 interface ae21 rt_inst default May 6 21:51:36 fud_ifdb_get_addr(): getting database entry for irb.1221, port 67
The unusual part about this is that the debug log did not indicate any unknown interface that was dropping the packet, and that the MX was receiving the packets. After a quick call to JTAC they recommended we enable the broadcast option on each bootp interface so that it looked like the following:
forwarding-options { helpers { traceoptions { file fud.log; level all; flag all; } bootp { interface { irb.1 { broadcast; server 1.2.3.4; } } } } }
This broadcast option enables the MX to forward DHCP relay packets if the interface is unknown. Once this was added and committed DHCP Relay started to work as expected.