Comment 3 for bug 1358718

With the current architecture of DVR, when we excite traffic from DHCP Namespaces (on one dvr subnet) to VMs (on other subnet in same dvr), will result in Duplicate responses generated for the requests.

The same situation will happen vice-versa also wherein if we excite traffic from a VM(on one dvr-routed subnet) to a DHCP Server IP (on another dvr -routed subnet)

When a PING request is initiated by the DHCP Server towards the VM on another subnet, the DHCP Server will first transmit the packet to default gateway port available on DVR. Since the default gateway port for the DVR is replicated on all the other Compute Nodes, the PING request will reach the DVR interfaces on all the compute nodes including the target compute node where the VM resides, as here l2-pop will replicate the PING request packet to all the compute nodes via Table 22.

Now all the existing compute nodes (which does not have the target VM), will route the Ping Packet and re-transmit the packet to the data network to the right destination compute node. So the target VM will receive X PING Requests (if there are X compute nodes) and hence it will respond to all such PING requests, thereby generating X PING replies.

So if we have x compute nodes. Then the PING request will yield X PING replies. In the scenario tried by Sarada , there were two compute nodes (excluding the NN that ran the DHCP Servr), so there were two PING replies. One PING reply to the original PING request that landed in the right compute node first itself. And the second PING reply is for the shadow PING request that was routed to the correct compute node, by the other compute node.

Since DHCP Server is not accessible by the tenants, tenants explicitly generating traffic to DHCP Servers on another subnet (and vice-versa) is not a frequent phenomenon.

As a result, I request this to be triaged as a LOW bug.