Floating IP traffic does not work on OVN-DVR setup when using VLAN tenant network type

[Brian Haley]

When we are trying to use the Floating IP address of an instance in a OVN-DVR setup while using VLAN tenant network type the traffic does not pass.
Because of limitations with VLAN tenant network type, we can't have distributed VLAN routing.
Vlan routing is centralized whether the deployment is DVR or not.

Steps to Reproduce:
1. Deploy OVN-DVR setup with VLAN tenant network type support
2. Create a VLAN network
3. Create an External network with a router
4. Boot instance & Assign Floating IP to the VM
5. open security group access

Ping to the Floating IP of the instance fails when it should succeed.

The problem is the external_mac should not be set in the NAT table for the Floating IP which belongs to the logical port of a VLAN tenant logical switch.
Otherwise, the compute node which is binding the logical port will send the GARP where as the routing for VLAN tenant networks is centralized.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/658923

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/658923
Committed: https://git.openstack.org/cgit/openstack/networking-ovn/commit/?id=c5aef51edc9843db605303ec8bd8610b6c55e9c2
Submitter: Zuul
Branch: master

commit c5aef51edc9843db605303ec8bd8610b6c55e9c2
Author: Brian Haley <email address hidden>
Date: Mon May 13 17:02:36 2019 -0400

    Floating IP does not work with VLAN tenant networks

    When trying to use the Floating IP address of an instance
    in a OVN-DVR setup while using VLAN tenant network type
    the traffic does not pass. This is because of limitations
    with VLAN tenant network types, which doesn't support
    distributed VLAN routing.

    The problem is the external_mac should not be set in the
    NAT table for the Floating IP which belongs to the logical
    port of a VLAN tenant logical switch. Otherwise, the compute
    node which is binding the logical port will send the GARP
    where as the routing for VLAN tenant networks is centralized.

    Change-Id: I406204fc751387c02517286c87fe45533d70b93d
    Closes-bug: #1828891

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/stein
Review: https://review.opendev.org/661778

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/661778
Committed: https://git.openstack.org/cgit/openstack/networking-ovn/commit/?id=2daf80449a8eddc6c9dc78a11f9b208cdb6ff608
Submitter: Zuul
Branch: stable/stein

commit 2daf80449a8eddc6c9dc78a11f9b208cdb6ff608
Author: Brian Haley <email address hidden>
Date: Mon May 13 17:02:36 2019 -0400

    Floating IP does not work with VLAN tenant networks

    When trying to use the Floating IP address of an instance
    in a OVN-DVR setup while using VLAN tenant network type
    the traffic does not pass. This is because of limitations
    with VLAN tenant network types, which doesn't support
    distributed VLAN routing.

    The problem is the external_mac should not be set in the
    NAT table for the Floating IP which belongs to the logical
    port of a VLAN tenant logical switch. Otherwise, the compute
    node which is binding the logical port will send the GARP
    where as the routing for VLAN tenant networks is centralized.

    Change-Id: I406204fc751387c02517286c87fe45533d70b93d
    Closes-bug: #1828891
    (cherry picked from commit c5aef51edc9843db605303ec8bd8610b6c55e9c2)

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/rocky
Review: https://review.opendev.org/666159

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/queens
Review: https://review.opendev.org/666160

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/666160
Committed: https://git.openstack.org/cgit/openstack/networking-ovn/commit/?id=dcd1ff9afdb88110d16609a5b317ee468d65bc26
Submitter: Zuul
Branch: stable/queens

commit dcd1ff9afdb88110d16609a5b317ee468d65bc26
Author: Brian Haley <email address hidden>
Date: Mon May 13 17:02:36 2019 -0400

    Floating IP does not work with VLAN tenant networks

    When trying to use the Floating IP address of an instance
    in a OVN-DVR setup while using VLAN tenant network type
    the traffic does not pass. This is because of limitations
    with VLAN tenant network types, which doesn't support
    distributed VLAN routing.

    The problem is the external_mac should not be set in the
    NAT table for the Floating IP which belongs to the logical
    port of a VLAN tenant logical switch. Otherwise, the compute
    node which is binding the logical port will send the GARP
    where as the routing for VLAN tenant networks is centralized.

    Conflicts:
        networking_ovn/tests/unit/l3/test_l3_ovn.py

    Change-Id: I406204fc751387c02517286c87fe45533d70b93d
    Closes-bug: #1828891
    (cherry picked from commit c5aef51edc9843db605303ec8bd8610b6c55e9c2)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/666159
Committed: https://git.openstack.org/cgit/openstack/networking-ovn/commit/?id=44e5191c47a697a1c0d11557381e828afedf7f31
Submitter: Zuul
Branch: stable/rocky

commit 44e5191c47a697a1c0d11557381e828afedf7f31
Author: Brian Haley <email address hidden>
Date: Mon May 13 17:02:36 2019 -0400

    Floating IP does not work with VLAN tenant networks

    When trying to use the Floating IP address of an instance
    in a OVN-DVR setup while using VLAN tenant network type
    the traffic does not pass. This is because of limitations
    with VLAN tenant network types, which doesn't support
    distributed VLAN routing.

    The problem is the external_mac should not be set in the
    NAT table for the Floating IP which belongs to the logical
    port of a VLAN tenant logical switch. Otherwise, the compute
    node which is binding the logical port will send the GARP
    where as the routing for VLAN tenant networks is centralized.

    Conflicts:
        networking_ovn/tests/unit/l3/test_l3_ovn.py

    Change-Id: I406204fc751387c02517286c87fe45533d70b93d
    Closes-bug: #1828891
    (cherry picked from commit c5aef51edc9843db605303ec8bd8610b6c55e9c2)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/networking-ovn 7.0.0.0b1 development milestone.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/networking-ovn 4.0.4 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/networking-ovn 6.0.1 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/networking-ovn 5.1.0 release.

[Brendan Shephard (bshephar)]

Looks like this was merged a while ago. I'm running:

python3-neutron-1:16.1.0-0.20200505061431.2a6ab2e.el8.noarch : Neutron Python libraries
Repo : delorean-component-network
Matched from:
Filename : /usr/lib/python3.6/site-packages/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py

I checked that file and the code from this patch is missing. I also tried adding the patch, but now I can't reach it from the same Layer2 network either.

I believe its the same problem, without this code, I can ssh to the VM from anywhere on the same Layer2 network via the FIP. If I try from another VLAN, I can't reach it. But I can directly attach the VM to the VLAN external network and it all works fine.

Do we know if this is a regression, or was there another solution implemented after this?

[Brendan Shephard (bshephar)]

For reference:

https://opendev.org/openstack/neutron/src/branch/master/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py#L762-L763

[Harry Kominos (hkominos)]

I am seeing something similar in latest Ussuri/TripleO.
FIP does not work at all expect when trying through another IP on the same subnet as the public.
Maybe related?

[Rahmat Agung Wibowo (riupie)]

I have similiar issue using FLAT. It just work when i disable distributed floating IP on ml2_conf.ini

[Wojciech (suzumushi)]

Same on latest as of date Ussuri/TripleO
cannot access instances with floating ip;s on VLAN tenant network type, in DVR outside that vlan

[Daniel Alvarez (dalvarezs)]

The plan is to fix it with this approach:

https://review.opendev.org/#/c/732174/

In the meantime, the right behavior should be to force centralized FIPs for non Geneve tenant networks. I thought this was solved but needs revisit