Description of problem: The customer is attempting to start a Cisco IOS-XE CSR1000V router in a VM on OSP13. This router sends a DHCPREQUEST on an interface at boot. The Neutron subnet is configured for DHCP. tcpdump at the VM's tap interface on the compute shows a DHCPDISCOVER broadcast exit the VM. "Flags [Broadcast]" is set. OVN generates a DHCPOFFER, however the destination IP is unicast, back to Neutron's chosen IP address for the VM. It seems that this version of the router software cannot handle this case, and is unable to process the DHCPRESPONSE. Version-Release number of selected component (if applicable): RHOSP13, z9, OVN 2.9; update to z10 is planned in the immediate future. How reproducible: Repeatedly. For VMs with more capable IP stacks this has not caused a problem. Expected results: 1) Specify the IP broadcast address as the destination in all DHCPOFFER cases, or, 2) Adhere to the broadcast bit setting and use broadcast only if the bit is set. Additional info: I am not sure an update to z10 will resolve this - I have checked the upstream OVN code and verified that current master branch is still generating OVN logical flows that send unicast responses [1]. [1] https://github.com/ovn-org/ovn/blob/94ed4f6b433c26439d958965ee20497c2b32e4f9/northd/ovn-northd.c#L4256
It's clear what's happening here: native DHCP responder doesn't honor the flag. Fix posted here: https://patchwork.ozlabs.org/patch/1248736/
The actual fix belongs to core OVN code. I've created two bugs for each relevant OVN major release: 2.11: https://bugzilla.redhat.com/show_bug.cgi?id=1811119 2.12: https://bugzilla.redhat.com/show_bug.cgi?id=1811117 This original bug is marked as TestOnly and should be validated in conjunction with the bugs listed above.
According to our records, this should be resolved by ovn2.11-2.11.1-57.el7fdp. This build is available now.
Closing this since QA will not test it in OSP scope and because the bug fix actually belonged to OVN, not OVN driver, and was already delivered.