Note to QE: this bug should probably be verified in coordination with the original bug reported against OSP: https://bugzilla.redhat.com/show_bug.cgi?id=1801006 (the original bug is TestOnly).
I can reproduce this bug on version: # rpm -qa|grep ovn ovn2.11-central-2.11.1-33.el8fdp.x86_64 ovn2.11-2.11.1-33.el8fdp.x86_64 ovn2.11-host-2.11.1-33.el8fdp.x86_64 and verified on version ovn2.11-central-2.11.1-37.el8fdp.x86_64 ovn2.11-2.11.1-37.el8fdp.x86_64 ovn2.11-host-2.11.1-37.el8fdp.x86_64 server: local dhcp_102=$(ovn-nbctl create DHCP_Options cidr=42.42.42.0/24 \ options="\"server_id\"=\"42.42.42.254\" \"server_mac\"=\"00:de:ad:ff:01:02\" \ \"lease_time\"=\"3600\" \"router\"=\"42.42.42.254\"") echo $dhcp_102 ovn-nbctl ls-add ls ovn-nbctl lsp-add ls vm1 ovn-nbctl lsp-set-addresses vm1 "00:00:00:00:00:01 42.42.42.2" rlRun "ovn-nbctl lsp-set-dhcpv4-options vm1 $dhcp_102" rlRun "ovn-nbctl lsp-get-dhcpv4-options vm1" ovn-nbctl lsp-add ls vm2 ovn-nbctl lsp-set-addresses vm2 "00:00:00:00:00:02 42.42.42.3" rlRun "ovn-nbctl lsp-set-dhcpv4-options vm2 $dhcp_102" rlRun "ovn-nbctl lsp-get-dhcpv4-options vm2" ip netns add vm1 ovs-vsctl add-port br-int vm1 -- set interface vm1 type=internal ip link set vm1 netns vm1 ip netns exec vm1 ip link set vm1 address 00:00:00:00:00:01 ip netns exec vm1 ip link set vm1 up ip netns exec vm1 ip link set lo up ovs-vsctl set Interface vm1 external_ids:iface-id=vm1 client: ip netns add vm2 ovs-vsctl add-port br-int vm2 -- set interface vm2 type=internal ip link set vm2 netns vm2 ip netns exec vm2 ip link set vm2 address 00:00:00:00:00:02 ip netns exec vm2 ip link set vm2 up ip netns exec vm2 ip link set lo up ovs-vsctl set Interface vm2 external_ids:iface-id=vm2 rlRun "ip netns exec vm2 tcpdump -U -i vm2 -w a.pacp&" sleep 5 then send packet asbelow: conf.checkIPaddr = False fam,hw =get_if_raw_hwaddr(conf.iface) sendp(Ether(src="00:00:00:00:00:02", dst="ff:ff:ff:ff:ff:ff")/IP(src="0.0.0.0", dst="255.255.255.255")/UDP(sport=68,dport=67)/BOOTP(flags=32768,chaddr=hw)/DHCP(options=[("message-type","discover"),"end"]),iface="vm2") pkill -9 tcpdump tcpdump -r a.pacp -nn -v |grep 42.42.42.254.67.*255.255.255.255.*BOOTP/DHCP.*Reply' reading from file a.pacp, link-type EN10MB (Ethernet) 42.42.42.254.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 276, Flags [Broadcast] on the old version, the reply packet is a unicast packet. # tcpdump -r b.pacp -nn -v reading from file b.pacp, link-type EN10MB (Ethernet) 04:34:56.679758 IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto UDP (17), length 272) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:00:00:00:02, length 244, Flags [Broadcast] Client-Ethernet-Address 00:00:00:00:00:02 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover 04:34:56.681402 IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto UDP (17), length 304) 42.42.42.254.67 > 42.42.42.3.68: BOOTP/DHCP, Reply, length 276, Flags [Broadcast] Your-IP 42.42.42.3 Client-Ethernet-Address 00:00:00:00:00:02 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Lease-Time Option 51, length 4: 3600 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 42.42.42.254 Server-ID Option 54, length 4: 42.42.42.254
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:1458