explicity_egress_direct prevents learning of local MACs and causes flooding of ingress packets, firewall_driver = openvswitch

[Bence Romsics]

I believe this issue was already reported earlier:

https://bugs.launchpad.net/neutron/+bug/1884708

That bug has a fix committed:

https://review.opendev.org/c/openstack/neutron/+/738551

However I believe the above change fixed only part of the issue (with firewall_driver=noop).
But the same problem is still not fixed with firewall_driver=openvswitch.

First, I re-opened bug #1884708, but then I realized that nobody will notice a several year old bug's status change, so I rather opened this new bug report instead.

Reproduction:

# config
ml2_conf.ini:
[securitygroup]
firewall_driver = openvswitch
[agent]
explicitly_egress_direct = True
[ovs]
bridge_mappings = physnet0:br-physnet0,...

# a random IP on net0 we can ping
sudo ip link set up dev br-physnet0
sudo ip link add link br-physnet0 name br-physnet0.100 type vlan id 100
sudo ip link set up dev br-physnet0.100
sudo ip address add dev br-physnet0.100 10.0.100.1/24

# code
devstack 6b0f055b
neutron $ git log --oneline -n2
27601f8eea (HEAD, origin/bug/2048785, origin/HEAD) Set trunk parent port as access port in ovs to avoid loop
3ef02cc2fb (origin/master) Consume code from neutron-lib
openvswitch 2.17.8-0ubuntu0.22.04.1
linux 5.15.0-91-generic

# clean up first
openstack server delete vm0 --wait
openstack port delete port0
openstack network delete net0

# build the environment
openstack network create net0 --provider-network-type vlan --provider-physical-network physnet0 --provider-segment 100
openstack subnet create --network net0 --subnet-range 10.0.100.0/24 subnet0
openstack port create --no-security-group --disable-port-security --network net0 --fixed-ip ip-address=10.0.100.10 port0
openstack server create --flavor cirros256 --image cirros-0.6.2-x86_64-disk --nic port-id=port0 --availability-zone :devstack0a --wait vm0

# mac addresses for reference
$ openstack port show port0 -f value -c mac_address
fa:16:3e:96:58:ab
$ ifdata -ph br-physnet0
82:E8:18:67:7E:40

# generate traffic that will keep fdb entries fresh
sudo virsh console "$( openstack server show vm0 -f value -c OS-EXT-SRV-ATTR:instance_name )"
ping 10.0.100.1

# clear all past junk
for br in br-physnet0 br-int ; do sudo ovs-appctl fdb/flush "$br" ; done

# br-int does not learn port0's mac despite the ongoing ping
for br in br-physnet0 br-int ; do echo ">>> $br <<<" ; sudo ovs-appctl fdb/show "$br" | egrep -i "$( openstack port show port0 -f value -c mac_address )|$( ifdata -ph br-physnet0 )" ; done
>>> br-physnet0 <<<
    1 100 fa:16:3e:96:58:ab 0
LOCAL 100 82:e8:18:67:7e:40 0
>>> br-int <<<
    1 4 82:e8:18:67:7e:40 0

# port and physnet bridge mac in all fdbs, egress == vnic -> physnet bridge
# in br-int we have a direct output action
$ sudo ovs-appctl ofproto/trace br-int in_port="$( sudo ovs-vsctl -- --columns=ofport find Interface name=$( echo "tap$( openstack port show port0 -f value -c id )" | cut -b1-14 ) | awk '{ print $3 }' )",dl_vlan=0,dl_dst=$( ifdata -ph br-physnet0 ),dl_src=$( openstack port show port0 -f value -c mac_address )
Flow: in_port=45,dl_vlan=0,dl_vlan_pcp=0,vlan_tci1=0x0000,dl_src=fa:16:3e:96:58:ab,dl_dst=82:e8:18:67:7e:40,dl_type=0x0000

bridge("br-int")
----------------
 0. priority 0, cookie 0x2b36d6b4a42fe7b5
    goto_table:58
58. priority 0, cookie 0x2b36d6b4a42fe7b5
    goto_table:60
60. in_port=45, priority 100, cookie 0x2b36d6b4a42fe7b5
    set_field:0x2d->reg5
    set_field:0x4->reg6
    resubmit(,73)
73. reg5=0x2d, priority 80, cookie 0x2b36d6b4a42fe7b5
    resubmit(,94)
94. reg6=0x4,dl_src=fa:16:3e:96:58:ab,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00, priority 10, cookie 0x2b36d6b4a42fe7b5
    push_vlan:0x8100
    set_field:4100->vlan_vid
    output:1

bridge("br-physnet0")
---------------------
 0. in_port=1,dl_vlan=4, priority 4, cookie 0x85bc1a5077d54d3f
    set_field:4196->vlan_vid
    NORMAL
     -> forwarding to learned port

Final flow: reg5=0x2d,reg6=0x4,in_port=45,dl_vlan=4,dl_vlan_pcp=0,dl_vlan1=0,dl_vlan_pcp1=0,dl_src=fa:16:3e:96:58:ab,dl_dst=82:e8:18:67:7e:40,dl_type=0x0000
Megaflow: recirc_id=0,eth,in_port=45,dl_vlan=0,dl_vlan_pcp=0,dl_src=fa:16:3e:96:58:ab,dl_dst=82:e8:18:67:7e:40,dl_type=0x0000
Datapath actions: pop_vlan,push_vlan(vid=100,pcp=0),1

# port and physnet bridge mac in all fdbs, ingress == physnet bridge -> vnic
# in br-int we have the normal action flooding, despite the ongoing ping
$ sudo ovs-appctl ofproto/trace br-physnet0 in_port=LOCAL,dl_vlan=100,dl_src=$( ifdata -ph br-physnet0 ),dl_dst=$( openstack port show port0 -f value -c mac_address )
Flow: in_port=LOCAL,dl_vlan=100,dl_vlan_pcp=0,vlan_tci1=0x0000,dl_src=82:e8:18:67:7e:40,dl_dst=fa:16:3e:96:58:ab,dl_type=0x0000

bridge("br-physnet0")
---------------------
 0. priority 0, cookie 0x85bc1a5077d54d3f
    NORMAL
     -> forwarding to learned port

bridge("br-int")
----------------
 0. in_port=1,dl_vlan=100, priority 3, cookie 0x2b36d6b4a42fe7b5
    set_field:4100->vlan_vid
    goto_table:58
58. priority 0, cookie 0x2b36d6b4a42fe7b5
    goto_table:60
60. priority 3, cookie 0x2b36d6b4a42fe7b5
    NORMAL
     -> no learned MAC for destination, flooding

bridge("br-tun")
----------------
 0. in_port=1, priority 1, cookie 0xc8cfff9c6bbea88d
    goto_table:2
 2. dl_dst=00:00:00:00:00:00/01:00:00:00:00:00, priority 0, cookie 0xc8cfff9c6bbea88d
    goto_table:20
20. priority 0, cookie 0xc8cfff9c6bbea88d
    goto_table:22
22. priority 0, cookie 0xc8cfff9c6bbea88d
    drop

Final flow: unchanged
Megaflow: recirc_id=0,eth,in_port=LOCAL,dl_vlan=100,dl_vlan_pcp=0,dl_src=82:e8:18:67:7e:40,dl_dst=fa:16:3e:96:58:ab,dl_type=0x0000
Datapath actions: pop_vlan,push_vlan(vid=4,pcp=0),8,13,pop_vlan,9,11

This bug has a long history:

round #1 - some unnecessary flooding in the egress direction
https://bugs.launchpad.net/neutron/+bug/1732067
https://bugs.launchpad.net/neutron/+bug/1841622
fix introducing explicitly_egress_direct:
https://review.opendev.org/c/openstack/neutron/+/666991

round #2 - the fix above introduced some unnecessary ingress flooding
https://bugs.launchpad.net/neutron/+bug/1884708
fix for firewall_driver=noop
https://review.opendev.org/c/openstack/neutron/+/738551
also related:
https://bugs.launchpad.net/neutron/+bug/1732067/comments/50
https://bugs.launchpad.net/neutron/+bug/1732067/comments/79
may be related:
https://bugs.launchpad.net/neutron/+bug/1866445

round #3 (today)
https://bugs.launchpad.net/neutron/+bug/2048785/comments/2
https://bugs.launchpad.net/neutron/+bug/1884708/comments/29

[LIU Yulong (dragon889)]

@Bence,

``explicity_egress_direct`` was mainly added for openvswitch firewall driver. Noop firewall driver is not the primary case of this option. There is a bug which is related to iptables_hybird drivers, so the fix is added to noop and iptables_hybird drivers as well.

But anyway, TBH, this option is not really cover the trunk port scenario. If trunk port is widely used, it's worthy to have a fix to cover it.

So this bug is mainly for trunk port scenario?

So, we are facing more cases as I said before:
https://bugs.launchpad.net/neutron/+bug/1732067/comments/79

[Bence Romsics (bence-romsics)]

Hi Liu,

Thanks for the quick response.

The ingress flooding on br-int can occur with or without trunk ports. I originally observed this in an environment using trunk ports (https://bugs.launchpad.net/neutron/+bug/2048785/comments/2). But later I was able to reproduce the flooding problem without trunk ports too. As reported here - the reproduction above does not use trunk ports. So I believe this applies to all environments with firewall_driver=openvswitch.

[LIU Yulong (dragon889)]

Is your test compute node running combined with dvr_snat?

[LIU Yulong (dragon889)]

OK, I see the upstream problem, your ports are created with ``--no-security-group --disable-port-security``. Seems the ingress packet never go into table 94. It is run "NORMAL" in table 60 instead. So, it is flooding.

[Bence Romsics (bence-romsics)]

Today we don't treat a port with disable-port-security the same as firewall_driver=noop:

https://opendev.org/openstack/neutron/src/commit/c6ac441a5160b79c48d04596ab464e0bac9f6592/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L2301-L2306
https://opendev.org/openstack/neutron/src/commit/c6ac441a5160b79c48d04596ab464e0bac9f6592/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L2344-L2350

But maybe we could do that? And install the same direct output flows for ports with disable-port-security?

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/907382

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/907382
Committed: https://opendev.org/openstack/neutron/commit/d6f56c5f96c42e1682f3d1723a65253429778c20
Submitter: "Zuul (22348)"
Branch: master

commit d6f56c5f96c42e1682f3d1723a65253429778c20
Author: LIU Yulong <email address hidden>
Date: Thu Jan 27 17:01:43 2022 +0800

    Add a default goto table=94 for openvswitch fw

    If enable explicitly_egress_direct=True and set port as
    no security group and port_security=False, the ingress
    flood will reappear. The pipleline is:
    Ingress
    table_0 -> table_60 -> NORMAL -> VM
    Egress
    table_0 -> ... -> table_94 -> output

    Because ingress final action is normal, the br-int will learn the
    source MAC, but egress final action is output. So VM's mac will
    never be learnt by the br-int. Then ingress flood comes again.

    This patch adds a default direct flow to table 94 during the
    openflow security group init and explicitly_egress_direct=True, then
    the pipleline will be:
    Ingress
    table_0 -> table_60 -> table_94 -> output VM
    Egress
    table_0 -> ... -> table_94 -> output

    And this patch adds the flows coming from patch port which will
    match local vlan then go to table 94 do the same direct actions.

    Above flood issue will be addressed by these flows.

    Closes-Bug: #2051351
    Change-Id: Ia61784174ee610b338f26660b2954330abc131a1

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/2024.1
Review: https://review.opendev.org/c/openstack/neutron/+/921940

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/2023.2
Review: https://review.opendev.org/c/openstack/neutron/+/921941

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/2023.1
Review: https://review.opendev.org/c/openstack/neutron/+/921942

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: unmaintained/zed
Review: https://review.opendev.org/c/openstack/neutron/+/921943

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: unmaintained/yoga
Review: https://review.opendev.org/c/openstack/neutron/+/921944

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: unmaintained/xena
Review: https://review.opendev.org/c/openstack/neutron/+/921945

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: unmaintained/wallaby
Review: https://review.opendev.org/c/openstack/neutron/+/921946

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: unmaintained/victoria
Review: https://review.opendev.org/c/openstack/neutron/+/921948

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/921941
Committed: https://opendev.org/openstack/neutron/commit/fc7fa9cf308766cdbf29b8cf4d3aaad867738dc0
Submitter: "Zuul (22348)"
Branch: stable/2023.2

commit fc7fa9cf308766cdbf29b8cf4d3aaad867738dc0
Author: LIU Yulong <email address hidden>
Date: Thu Jan 27 17:01:43 2022 +0800

    Add a default goto table=94 for openvswitch fw

    If enable explicitly_egress_direct=True and set port as
    no security group and port_security=False, the ingress
    flood will reappear. The pipleline is:
    Ingress
    table_0 -> table_60 -> NORMAL -> VM
    Egress
    table_0 -> ... -> table_94 -> output

    Because ingress final action is normal, the br-int will learn the
    source MAC, but egress final action is output. So VM's mac will
    never be learnt by the br-int. Then ingress flood comes again.

    This patch adds a default direct flow to table 94 during the
    openflow security group init and explicitly_egress_direct=True, then
    the pipleline will be:
    Ingress
    table_0 -> table_60 -> table_94 -> output VM
    Egress
    table_0 -> ... -> table_94 -> output

    And this patch adds the flows coming from patch port which will
    match local vlan then go to table 94 do the same direct actions.

    Above flood issue will be addressed by these flows.

    Closes-Bug: #2051351
    Change-Id: Ia61784174ee610b338f26660b2954330abc131a1
    (cherry picked from commit d6f56c5f96c42e1682f3d1723a65253429778c20)
    (cherry picked from commit f94f8b63842099904ff88906e8221a366a809f99)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/921940
Committed: https://opendev.org/openstack/neutron/commit/f94f8b63842099904ff88906e8221a366a809f99
Submitter: "Zuul (22348)"
Branch: stable/2024.1

commit f94f8b63842099904ff88906e8221a366a809f99
Author: LIU Yulong <email address hidden>
Date: Thu Jan 27 17:01:43 2022 +0800

    Add a default goto table=94 for openvswitch fw

    If enable explicitly_egress_direct=True and set port as
    no security group and port_security=False, the ingress
    flood will reappear. The pipleline is:
    Ingress
    table_0 -> table_60 -> NORMAL -> VM
    Egress
    table_0 -> ... -> table_94 -> output

    Because ingress final action is normal, the br-int will learn the
    source MAC, but egress final action is output. So VM's mac will
    never be learnt by the br-int. Then ingress flood comes again.

    This patch adds a default direct flow to table 94 during the
    openflow security group init and explicitly_egress_direct=True, then
    the pipleline will be:
    Ingress
    table_0 -> table_60 -> table_94 -> output VM
    Egress
    table_0 -> ... -> table_94 -> output

    And this patch adds the flows coming from patch port which will
    match local vlan then go to table 94 do the same direct actions.

    Above flood issue will be addressed by these flows.

    Closes-Bug: #2051351
    Change-Id: Ia61784174ee610b338f26660b2954330abc131a1
    (cherry picked from commit d6f56c5f96c42e1682f3d1723a65253429778c20)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/921942
Committed: https://opendev.org/openstack/neutron/commit/1045985c76dbea8851e6ced72d09a0f9bc58a59d
Submitter: "Zuul (22348)"
Branch: stable/2023.1

commit 1045985c76dbea8851e6ced72d09a0f9bc58a59d
Author: LIU Yulong <email address hidden>
Date: Thu Jan 27 17:01:43 2022 +0800

    Add a default goto table=94 for openvswitch fw

    If enable explicitly_egress_direct=True and set port as
    no security group and port_security=False, the ingress
    flood will reappear. The pipleline is:
    Ingress
    table_0 -> table_60 -> NORMAL -> VM
    Egress
    table_0 -> ... -> table_94 -> output

    Because ingress final action is normal, the br-int will learn the
    source MAC, but egress final action is output. So VM's mac will
    never be learnt by the br-int. Then ingress flood comes again.

    This patch adds a default direct flow to table 94 during the
    openflow security group init and explicitly_egress_direct=True, then
    the pipleline will be:
    Ingress
    table_0 -> table_60 -> table_94 -> output VM
    Egress
    table_0 -> ... -> table_94 -> output

    And this patch adds the flows coming from patch port which will
    match local vlan then go to table 94 do the same direct actions.

    Above flood issue will be addressed by these flows.

    Closes-Bug: #2051351
    Change-Id: Ia61784174ee610b338f26660b2954330abc131a1
    (cherry picked from commit d6f56c5f96c42e1682f3d1723a65253429778c20)
    (cherry picked from commit f94f8b63842099904ff88906e8221a366a809f99)
    (cherry picked from commit fc7fa9cf308766cdbf29b8cf4d3aaad867738dc0)
        Conflict with 02b12b09175 in neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/br_int.py

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/921943
Committed: https://opendev.org/openstack/neutron/commit/c32eb5669a542470bf659f79697517f5682ec19e
Submitter: "Zuul (22348)"
Branch: unmaintained/zed

commit c32eb5669a542470bf659f79697517f5682ec19e
Author: LIU Yulong <email address hidden>
Date: Thu Jan 27 17:01:43 2022 +0800

    Add a default goto table=94 for openvswitch fw

    If enable explicitly_egress_direct=True and set port as
    no security group and port_security=False, the ingress
    flood will reappear. The pipleline is:
    Ingress
    table_0 -> table_60 -> NORMAL -> VM
    Egress
    table_0 -> ... -> table_94 -> output

    Because ingress final action is normal, the br-int will learn the
    source MAC, but egress final action is output. So VM's mac will
    never be learnt by the br-int. Then ingress flood comes again.

    This patch adds a default direct flow to table 94 during the
    openflow security group init and explicitly_egress_direct=True, then
    the pipleline will be:
    Ingress
    table_0 -> table_60 -> table_94 -> output VM
    Egress
    table_0 -> ... -> table_94 -> output

    And this patch adds the flows coming from patch port which will
    match local vlan then go to table 94 do the same direct actions.

    Above flood issue will be addressed by these flows.

    Closes-Bug: #2051351
    Change-Id: Ia61784174ee610b338f26660b2954330abc131a1
    (cherry picked from commit d6f56c5f96c42e1682f3d1723a65253429778c20)
    (cherry picked from commit f94f8b63842099904ff88906e8221a366a809f99)
    (cherry picked from commit fc7fa9cf308766cdbf29b8cf4d3aaad867738dc0)
        Conflict with 02b12b09175 in neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/br_int.py
    (cherry picked from commit 1045985c76dbea8851e6ced72d09a0f9bc58a59d)
        Conflict with 5b64ac90133 in neutron/tests/unit/plugins/ml2/drivers/openvswitch/agent/openflow/native/test_br_int.py

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/921944
Committed: https://opendev.org/openstack/neutron/commit/7992ca9bec5c7194bc390c1bc4a4bb3793eb607a
Submitter: "Zuul (22348)"
Branch: unmaintained/yoga

commit 7992ca9bec5c7194bc390c1bc4a4bb3793eb607a
Author: LIU Yulong <email address hidden>
Date: Thu Jan 27 17:01:43 2022 +0800

    Add a default goto table=94 for openvswitch fw

    If enable explicitly_egress_direct=True and set port as
    no security group and port_security=False, the ingress
    flood will reappear. The pipleline is:
    Ingress
    table_0 -> table_60 -> NORMAL -> VM
    Egress
    table_0 -> ... -> table_94 -> output

    Because ingress final action is normal, the br-int will learn the
    source MAC, but egress final action is output. So VM's mac will
    never be learnt by the br-int. Then ingress flood comes again.

    This patch adds a default direct flow to table 94 during the
    openflow security group init and explicitly_egress_direct=True, then
    the pipleline will be:
    Ingress
    table_0 -> table_60 -> table_94 -> output VM
    Egress
    table_0 -> ... -> table_94 -> output

    And this patch adds the flows coming from patch port which will
    match local vlan then go to table 94 do the same direct actions.

    Above flood issue will be addressed by these flows.

    Closes-Bug: #2051351
    Change-Id: Ia61784174ee610b338f26660b2954330abc131a1
    (cherry picked from commit d6f56c5f96c42e1682f3d1723a65253429778c20)
    (cherry picked from commit f94f8b63842099904ff88906e8221a366a809f99)
    (cherry picked from commit fc7fa9cf308766cdbf29b8cf4d3aaad867738dc0)
        Conflict with 02b12b09175 in neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/br_int.py
    (cherry picked from commit 1045985c76dbea8851e6ced72d09a0f9bc58a59d)
        Conflict with 5b64ac90133 in neutron/tests/unit/plugins/ml2/drivers/openvswitch/agent/openflow/native/test_br_int.py
    (cherry picked from commit c32eb5669a542470bf659f79697517f5682ec19e)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/921945
Committed: https://opendev.org/openstack/neutron/commit/01e4a647eee7ccd7c4ea85fe5b1b8ec295e90c9e
Submitter: "Zuul (22348)"
Branch: unmaintained/xena

commit 01e4a647eee7ccd7c4ea85fe5b1b8ec295e90c9e
Author: LIU Yulong <email address hidden>
Date: Thu Jan 27 17:01:43 2022 +0800

    Add a default goto table=94 for openvswitch fw

    If enable explicitly_egress_direct=True and set port as
    no security group and port_security=False, the ingress
    flood will reappear. The pipleline is:
    Ingress
    table_0 -> table_60 -> NORMAL -> VM
    Egress
    table_0 -> ... -> table_94 -> output

    Because ingress final action is normal, the br-int will learn the
    source MAC, but egress final action is output. So VM's mac will
    never be learnt by the br-int. Then ingress flood comes again.

    This patch adds a default direct flow to table 94 during the
    openflow security group init and explicitly_egress_direct=True, then
    the pipleline will be:
    Ingress
    table_0 -> table_60 -> table_94 -> output VM
    Egress
    table_0 -> ... -> table_94 -> output

    And this patch adds the flows coming from patch port which will
    match local vlan then go to table 94 do the same direct actions.

    Above flood issue will be addressed by these flows.

    Closes-Bug: #2051351
    Change-Id: Ia61784174ee610b338f26660b2954330abc131a1
    (cherry picked from commit d6f56c5f96c42e1682f3d1723a65253429778c20)
    (cherry picked from commit f94f8b63842099904ff88906e8221a366a809f99)
    (cherry picked from commit fc7fa9cf308766cdbf29b8cf4d3aaad867738dc0)
        Conflict with 02b12b09175 in neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/br_int.py
    (cherry picked from commit 1045985c76dbea8851e6ced72d09a0f9bc58a59d)
        Conflict with 5b64ac90133 in neutron/tests/unit/plugins/ml2/drivers/openvswitch/agent/openflow/native/test_br_int.py
    (cherry picked from commit c32eb5669a542470bf659f79697517f5682ec19e)
    (cherry picked from commit 7992ca9bec5c7194bc390c1bc4a4bb3793eb607a)
        Conflict with 053a9d24eca in neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/br_int.py

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/921946
Committed: https://opendev.org/openstack/neutron/commit/3e2e1819ddeaa87b82c4c686f4f3bf9f83e8697f
Submitter: "Zuul (22348)"
Branch: unmaintained/wallaby

commit 3e2e1819ddeaa87b82c4c686f4f3bf9f83e8697f
Author: LIU Yulong <email address hidden>
Date: Thu Jan 27 17:01:43 2022 +0800

    Add a default goto table=94 for openvswitch fw

    If enable explicitly_egress_direct=True and set port as
    no security group and port_security=False, the ingress
    flood will reappear. The pipleline is:
    Ingress
    table_0 -> table_60 -> NORMAL -> VM
    Egress
    table_0 -> ... -> table_94 -> output

    Because ingress final action is normal, the br-int will learn the
    source MAC, but egress final action is output. So VM's mac will
    never be learnt by the br-int. Then ingress flood comes again.

    This patch adds a default direct flow to table 94 during the
    openflow security group init and explicitly_egress_direct=True, then
    the pipleline will be:
    Ingress
    table_0 -> table_60 -> table_94 -> output VM
    Egress
    table_0 -> ... -> table_94 -> output

    And this patch adds the flows coming from patch port which will
    match local vlan then go to table 94 do the same direct actions.

    Above flood issue will be addressed by these flows.

    Closes-Bug: #2051351
    Change-Id: Ia61784174ee610b338f26660b2954330abc131a1
    (cherry picked from commit d6f56c5f96c42e1682f3d1723a65253429778c20)
    (cherry picked from commit f94f8b63842099904ff88906e8221a366a809f99)
    (cherry picked from commit fc7fa9cf308766cdbf29b8cf4d3aaad867738dc0)
        Conflict with 02b12b09175 in neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/br_int.py
    (cherry picked from commit 1045985c76dbea8851e6ced72d09a0f9bc58a59d)
        Conflict with 5b64ac90133 in neutron/tests/unit/plugins/ml2/drivers/openvswitch/agent/openflow/native/test_br_int.py
    (cherry picked from commit c32eb5669a542470bf659f79697517f5682ec19e)
    (cherry picked from commit 7992ca9bec5c7194bc390c1bc4a4bb3793eb607a)
        Conflict with 053a9d24eca in neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/br_int.py
    (cherry picked from commit 01e4a647eee7ccd7c4ea85fe5b1b8ec295e90c9e)
        Conflict with 56e8498a4da in neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/br_int.py

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/921948
Committed: https://opendev.org/openstack/neutron/commit/982eab5576b8deaded3a403c407f22500dbb6457
Submitter: "Zuul (22348)"
Branch: unmaintained/victoria

commit 982eab5576b8deaded3a403c407f22500dbb6457
Author: LIU Yulong <email address hidden>
Date: Thu Jan 27 17:01:43 2022 +0800

    Add a default goto table=94 for openvswitch fw

    If enable explicitly_egress_direct=True and set port as
    no security group and port_security=False, the ingress
    flood will reappear. The pipleline is:
    Ingress
    table_0 -> table_60 -> NORMAL -> VM
    Egress
    table_0 -> ... -> table_94 -> output

    Because ingress final action is normal, the br-int will learn the
    source MAC, but egress final action is output. So VM's mac will
    never be learnt by the br-int. Then ingress flood comes again.

    This patch adds a default direct flow to table 94 during the
    openflow security group init and explicitly_egress_direct=True, then
    the pipleline will be:
    Ingress
    table_0 -> table_60 -> table_94 -> output VM
    Egress
    table_0 -> ... -> table_94 -> output

    And this patch adds the flows coming from patch port which will
    match local vlan then go to table 94 do the same direct actions.

    Above flood issue will be addressed by these flows.

    Closes-Bug: #2051351
    Change-Id: Ia61784174ee610b338f26660b2954330abc131a1
    (cherry picked from commit d6f56c5f96c42e1682f3d1723a65253429778c20)
    (cherry picked from commit f94f8b63842099904ff88906e8221a366a809f99)
    (cherry picked from commit fc7fa9cf308766cdbf29b8cf4d3aaad867738dc0)
        Conflict with 02b12b09175 in neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/br_int.py
    (cherry picked from commit 1045985c76dbea8851e6ced72d09a0f9bc58a59d)
        Conflict with 5b64ac90133 in neutron/tests/unit/plugins/ml2/drivers/openvswitch/agent/openflow/native/test_br_int.py
    (cherry picked from commit c32eb5669a542470bf659f79697517f5682ec19e)
    (cherry picked from commit 7992ca9bec5c7194bc390c1bc4a4bb3793eb607a)
        Conflict with 053a9d24eca in neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/br_int.py
    (cherry picked from commit 01e4a647eee7ccd7c4ea85fe5b1b8ec295e90c9e)
        Conflict with 56e8498a4da in neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/br_int.py
    (cherry picked from commit 3e2e1819ddeaa87b82c4c686f4f3bf9f83e8697f)
        Conflict with 4f249b8579a in doc/source/contributor/internals/openvswitch_firewall.rst avoided by cherry-picking 4f249b8579a first

[OpenStack Infra (hudson-openstack)]

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