Bug 1816617 - [OVN] ARP requests not forwarded to chassis owning the logical port behind FIP in DVR scenarios.
Summary: [OVN] ARP requests not forwarded to chassis owning the logical port behind FI...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Enterprise Linux Fast Datapath
Classification: Red Hat
Component: ovn2.12
Version: FDP 20.A
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: Dumitru Ceara
QA Contact: Jianlin Shi
URL:
Whiteboard:
Depends On: 1816616 1816620
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-24 11:43 UTC by Dumitru Ceara
Modified: 2021-05-31 01:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1816616
Environment:
Last Closed: 2020-04-15 14:09:33 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Dumitru Ceara 2020-03-24 11:43:08 UTC
+++ 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

Comment 2 Dumitru Ceara 2020-04-15 14:09:33 UTC
Closing as NEXTRELEASE. Fix will be available in ovn2.13.


Note You need to log in before you can comment on or make changes to this bug.