OVS-FIREWALL - can't create Loadbalancer when firewall_driver = openvswitch

[Yossi Boaron]

steps to reproduce:
=====================

A. Download the following local.conf file :https://github.com/openstack/octavia/blob/master/devstack/samples/singlenode/local.conf

B. Add the following at end of above file (set ML2 firewall_driver to OVS)

[[post-config|/$Q_PLUGIN_CONF_FILE]]
[securitygroup]
firewall_driver = openvswitch

C. Deploy devstack

D. Create LoadBalancer:

  openstack loadbalancer create --vip-subnet-id private-subnet --name tst_lb

Observations :
==============

A. Loadbalancer is stuck in ‘Provisioning_status’ = 'PENDING_UPDATE'.

B. Disable port security of Amaphora's 'lb-mgmt-net' port - solved the problem

C. Based on Octavia's experts feedback [1] , seems like the bug is solely in ovs-firewall .

“The issue is that one port is placed directly at the hypervisor while ovs firewall works with VM ports only”

[1] - https://storyboard.openstack.org/#!/story/2001426

[Jakub Libosvar (libosvar)]

The culprit is that port is on hypervisor and hence when packet arrives br-int, it already carries a conntrack information and then it's considered "weird" and packet is dropped.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/550421

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/550421
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=3327db80be22650144342d1cc7e2c1b3e04a57ca
Submitter: Zuul
Branch: master

commit 3327db80be22650144342d1cc7e2c1b3e04a57ca
Author: Jakub Libosvar <email address hidden>
Date: Fri Mar 9 14:25:23 2018 +0000

    ovs-fw: Clear conntrack information before egress pipeline

    In case where Neutron logical port is placed directly to hypervisor,
    hypervisor does a conntrack lookup before packets reach OVS integration
    bridge. This patch introduces a rule with high priority that is placed
    at the beginning of the egress pipeline. This rule removes conntrack
    information from all packets if conntrack information is present. Then
    packets continue in the egress pipeline.

    That means all packets in egress pipeline are not tracked and ovs
    firewall can do a lookup in correct zone. As for ingress pipeline, it
    distinguishes between tracked - which are packets coming from egress
    pipeline, and not tracked, which are inbound packets coming not from a
    local port.

    Change-Id: Ia4f524adce2b5ee6d98d3921cfb03d56ad6d0813
    Closes-bug: #1747082

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/queens
Review: https://review.openstack.org/554155

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/554155
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=d6bfd091b9394bec068a185bdae1086b09fcbf13
Submitter: Zuul
Branch: stable/queens

commit d6bfd091b9394bec068a185bdae1086b09fcbf13
Author: Jakub Libosvar <email address hidden>
Date: Fri Mar 9 14:25:23 2018 +0000

    ovs-fw: Clear conntrack information before egress pipeline

    In case where Neutron logical port is placed directly to hypervisor,
    hypervisor does a conntrack lookup before packets reach OVS integration
    bridge. This patch introduces a rule with high priority that is placed
    at the beginning of the egress pipeline. This rule removes conntrack
    information from all packets if conntrack information is present. Then
    packets continue in the egress pipeline.

    That means all packets in egress pipeline are not tracked and ovs
    firewall can do a lookup in correct zone. As for ingress pipeline, it
    distinguishes between tracked - which are packets coming from egress
    pipeline, and not tracked, which are inbound packets coming not from a
    local port.

    Change-Id: Ia4f524adce2b5ee6d98d3921cfb03d56ad6d0813
    Closes-bug: #1747082
    (cherry picked from commit 3327db80be22650144342d1cc7e2c1b3e04a57ca)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 13.0.0.0b1 development milestone.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 12.0.2 release.