+++ This bug was initially created as a clone of Bug #1816616 +++ Description of problem: In a distributed routing scenario, if a VM (VM1) is connected to the aggregation switch (public) and tries to connect to another VM (VM2) connected to a switch through a floating IP (dnat_and_snat with external_mac and logical_port set), if VM2 resides on a different chassis then ARP requests don't reach the chassis of VM2. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. On a two chassis (hv1 and hv2) physical topology configure the following logical topology: ovn-nbctl ls-add sw-agg ovn-nbctl lsp-add sw-agg sw-agg-ext \ -- lsp-set-addresses sw-agg-ext 00:00:00:00:00:01 ovn-nbctl lsp-add sw-agg sw-rtr1 \ -- lsp-set-type sw-rtr1 router \ -- lsp-set-addresses sw-rtr1 00:00:00:00:01:00 \ -- lsp-set-options sw-rtr1 router-port=rtr1-sw ovn-nbctl lsp-add sw-agg sw-agg-ln ovn-nbctl lsp-set-addresses sw-agg-ln unknown ovn-nbctl lsp-set-type sw-agg-ln localnet ovn-nbctl lsp-set-options sw-agg-ln network_name=phys ovn-nbctl lr-add rtr1 ovn-nbctl lrp-add rtr1 rtr1-sw 00:00:00:00:01:00 10.0.0.1/24 10::1/64 ovn-nbctl lrp-add rtr1 rtr1-sw1 00:00:01:00:00:00 20.0.0.1/24 20::1/64 ovn-nbctl lrp-set-gateway-chassis rtr1-sw hv1 20 ovn-nbctl lr-nat-add rtr1 dnat_and_snat 10.0.0.122 20.0.0.12 sw1-p2 00:00:00:02:00:00 2. Configure the underlying physical network on both hv1 and hv2: ovs-vsctl set open . external-ids:ovn-bridge-mappings=phys:br-phys 3. Bind sw-agg-ext to an OVS port on hv1. 4. Bind sw1-p2 to an OVS port on hv2. 5. Send ARP request from sw-agg-ext for 10.0.0.122. Actual results: ARP requests don't reach hv2 and are not replied to. Expected results: ARP requests reach hv2 and get replied to. The neighbor entry is populated on sw-agg-ext. Additional info: Originally reported upstream: https://mail.openvswitch.org/pipermail/ovs-discuss/2020-March/049856.html
Closing as NEXTRELEASE. Fix will be available in ovn2.13.