br-int bridge in one compute can't learn MAC addresses of VMs in other compute nodes

Top output after I launched many VMs in the same subnet.

Hi Yi,

Could this be a duplicate of https://bugs.launchpad.net/neutron/+bug/1732067?

If no, could you please give us details on how to reproduce the issue?

Bence, thank you so much for information,but we used linux bridge for security group, i.e firewall_driver = iptables_hybrid. I will tried the fix for bug #1732067 and check if it can fix my issue.

By the way, Rocky also has same issue, we tried to narrow issue domain, if we don't add subnet of VMs into a router, MAC can be learnt, but MAC can't be learnt if we add subnet of VMs to a router. We used DVR and distributed DHCP, every VM's tap interface is attached into a linux bridge which is attached into br-int by veth pair.

bug #1732067 is same issue as this one.

But fix for bug #1732067 is just a workaround, MAC learning issue isn't fixed, it will be better if somebody can fix MAC learning issue and make sure br-int can always VMs' MACs.

bug #1732067 is about the egress flooding in the intergration bridge (br-int), and its fix is aiming to that. So have you enable the L2pop for your deployment? Paste your config file may be usefull for the upstream team.

Remove the duplicated mark since flooding and mac learning are not same. And you could use "ovs-appctl ofproto/trace" to find out the flows hit by the packets. Typically, the packets hit the "NORMAL" flow will let the bridge learn the mac to the fdb.

@LIU Yulong, yes, we enabled l2pop and arpresponder, and use DVR, firewall_dirver is iptables_hybrid, to be clarified, your fix patch can't fix our issue because your fix patch is openvswitch firewall only.

From ovs-ofctl -Oopenflow13 dump-flows br-int, we can see VM-to-VM traffic hits NORMAL action, ovs-appctl dpif/dump-flows can see the traffic is output to many ofports, what is very weird is br-int can learn MAC once the subnet VMs host is removed from router.

The below is neutron openvswitch agent config in our compute node.

cat /etc/neutron/plugins/ml2/openvswitch_agent.ini
[DEFAULT]
[agent]
tunnel_types =vxlan
vxlan_udp_port = 4789
l2_population = True
arp_responder = True
enable_distributed_routing = True
drop_flows_on_start = False

[network_log]
[ovs]
integration_bridge = br-int
tunnel_bridge = br-tun
local_ip = xxx.xxx.xxx.xxx
bridge_mappings = physnet1:br-floating
[securitygroup]
firewall_driver = iptables_hybrid
enable_security_group = True

@LIU Yulong, BTW, after we switch to openvswitch firewall, your patch can work, fix our issue, but br-int can't learn local MACs and remote MACs, do you have such issue in your deployment? but when we use iptables_hybrid firewall driver, local MACs can be learnt, remote MACs can't be learn. My point is if br-int can learn remote MACs, it won't have flood issue, we also do have flood issue, that is root cause which results in super low pps performance.

Related fix proposed to branch: master
Review: https://review.opendev.org/712640

@LIU Yulong, I added a fix commit in https://review.opendev.org/#/c/712640/, it can make sure your fix patch can work for iptables_hybrid, please help review if it is ok to you.

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

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

In DVR mode, this bug not only caused Layer 2 flooding, but also caused Layer 3 flooding.
* For example L2 flooding, vm1(sub1, host1), vm2(sub1, host1), vm3(sub1, host2).
  Ping from vm1 to vm3, the vm2 can also grab packets.

* For example L3 flooding, vm1(sub1, host1), vm4(sub2, host1), vm5(sub2, host2).
  Ping from vm1 to vm5, the vm4 can also grab packets.

I add a fix commit in [1], it add a flow table 59 which process the packets with src_mac is gateway_mac.This table contains three types of flows:
 * table=59, n_packets=0, n_bytes=0, priority=20,dl_vlan=3,dl_src=fa:16:3e:6f:7b:39,dl_dst=fa:16:3e:1b:18:b9 actions=strip_vlan,output:"qvoe6d500f9-62". This flow process the l3 packet from remote ports to local port.
 * table=59, n_packets=8, n_bytes=672, priority=20,dl_src=fa:16:3e:6f:7b:39,dl_dst=fa:16:3e:1b:18:b9 actions=output:"qvoe6d500f9-62". This flow process the l3 packet from local router to local ports.
 * table=59, n_packets=3, n_bytes=294, priority=19,dl_src=fa:16:3e:6f:7b:39 actions=mod_vlan_vid:3,output:"patch-tun". This flow process the l3 packet from local router to remote ports.

[1] https://review.opendev.org/#/c/715419/

I'm confused by several proposed patches. Per my understanding, they are duplicate.

@Li Yajie, please check if L3 flood you're saying is still there after applied Darragh O'Reilly (darragh-oreilly) https://review.opendev.org/714726.Per my understanding, both of them are L2 flood because ovs bridge acts as a switch but not router. You can use "ovs-appctl dpif/dump-flows br-int" to double confirm what you're saying "other VM can grab packets".

Per my check, Liu Yulong's fix patch plus my fix patch for iptables_hybrid won't have L2 flood and L3 flood you're saying. So now we have at least 3 proposed ways to fix it, which one is better? Welcome comments.

Change abandoned by Darragh O'Reilly (<email address hidden>) on branch: master
Review: https://review.opendev.org/714726
Reason: https://review.opendev.org/#/c/715419 is a more comprehensive approach.

Hi, sorry for the late reply.
The fix of bug #1732067 has a config option ``explicitly_egress_direct`` [1] which is for non-OVS firewall.
Please have a try to add the following config option to your compute nodes to see if the flooding still happen:
[agent]
...
explicitly_egress_direct = True

The fix has a flow which direct the unicast from br-int to tunnel/physical bridge, something like this:
able=61, n_packets=0, n_bytes=0, priority=10,in_port="qr-7fae49a8-f9",dl_src=fa:16:3e:c6:ca:b2,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:2,output:"patch-tun"
table=61, n_packets=0, n_bytes=0, priority=10,in_port="tapfc769b36-d8",dl_src=fa:16:3e:d6:c4:37,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:3,output:"patch-tun"
table=61, n_packets=0, n_bytes=0, priority=10,in_port="tap6d0aedf5-65",dl_src=fa:16:3e:21:40:16,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:1,output:"patch-tun"
table=61, n_packets=0, n_bytes=0, priority=10,in_port="qr-0ae0e877-1f",dl_src=fa:16:3e:5b:8e:90,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:3,output:"patch-tun"
table=61, n_packets=0, n_bytes=0, priority=10,in_port="qr-0d184ea8-f9",dl_src=fa:16:3e:52:39:08,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:2,output:"patch-tun"
table=61, n_packets=0, n_bytes=0, priority=10,in_port="qr-04bfb1fd-d3",dl_src=fa:16:3e:11:d1:47,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:3,output:"patch-tun"

so these test cases should not happen:

* For example L2 flooding, vm1(sub1, host1), vm2(sub1, host1), vm3(sub1, host2).
  Ping from vm1 to vm3, the vm2 can also grab packets.

* For example L3 flooding, vm1(sub1, host1), vm4(sub2, host1), vm5(sub2, host2).
  Ping from vm1 to vm5, the vm4 can also grab packets.

[1] https://review.opendev.org/#/c/710183/4/releasenotes/notes/accepted_egress_direct-cc23873e213c6919.yaml@18

@LIU Yulong, your fix can't work for firewall_driver=iptables_hybrid, please take a look at https://review.opendev.org/#/c/712640/.

Can you help review Yajie's solution? What do you think about it?

Is there any idea what caused this breakage, and for how long? We are NOT seeing it on Pike, but we are seeing it in Rocky.

We thought it was this commit, https://review.opendev.org/#/c/472691/, but that is not the case as our Pike branch has that.

This is affecting us in large setups.

Correction - we see this in Pike as well.

@abaindur - yes I believe https://review.opendev.org/#/c/472691/ is the cause.

Hi, folks, I think https://review.opendev.org/#/c/666991/ + https://review.opendev.org/#/c/712640/ is current best solution to this issue although MAC learning doesn't work. Actually, MAC learning can't fix L3 flood (for that case, learnt MAC is qrouter MAC, not VM MAC because DVR changed source VM MAC to gateway MAC)

@Darragh O'Reilly (darragh-oreilly), for the case you mentioned (a subnet which isn't added a router), it also doesn't have flood, https://review.opendev.org/#/c/666991/ + https://review.opendev.org/#/c/712640/ installed egress direct flows for all the ports including qrouter, local VMs and remote VMs no matter if their subnets are added to a router or not.

So so far, I propose you folks use https://review.opendev.org/#/c/666991/ + https://review.opendev.org/#/c/712640/, I have verified it works well in our environment.

Yi, what about https://review.opendev.org/#/c/715419 ? Darragh's comment states "I think the solution in https://review.opendev.org/#/c/715419 is better than the "accepted egress direct flow" way."

We're on Rocky, and do not already have Yulong's fix (666991) as you pointed out. So in that case we'd have to backport in two patches. Do you recommend abandoning 714519 and instead backporting the two fixes you mentioned?

Also, you said on review: "Another is found by Darragh O'Reilly, if subnet has no router
connected, it will case the a new "ingress" flooding. This will be
addressed in another bug or patch."

I was under the impression the original issue is only hit in DVR cases, and when subnet is attached to a router. What about for provider networks? Does this patch introduce a new flooding issue for that? Because provider networks can never be attached to a DVR router.

Is this truly fixed? The patch doesn't seem to fix the underlying issue at hand - ingress MACs (coming from br-vlan or br-tun) are NOT learned by br-int.

Also what are the implications of turning on this setting? The commit states:

"A new config option ``explicitly_egress_direct``, with default value False,
    was added for the aim of distinguishing clouds which are running the
    network node mixed with compute services, upstream neutron CI should be
    an example. In such situation, this ``explicitly_egress_direct`` should be
    set to False, because there are numerous cases from HA routers which can
    not be covered, particularly when you have centralized floating IPs running
    in such mixed hosts.
    Otherwise, set ``explicitly_egress_direct`` to True to avoid the flooding.
    One more note is if your network nodes are for networing services only, we
    recommand you disable all the security_group to get a higher performance."

I take that to say on a network node mixed with compute services it should be set to False. But isn't that the case for every node in DVR? The compute node hosts qrouter, fip router, and can also host dhcp services.

Or does it mean we not supposed to enable this setting on hosts with dvr_snat mode for l3-agent? The message states something about centralized fips - which are hosting on the snat router/node.

This fix seems to break certain other scenarios by causing flooding in opposite direction: https://bugs.launchpad.net/neutron/+bug/1884708

We are seeing ingress flooding occur due to enabling this fix on other networks. We have a VLAN based network, both attached and unattached to a DVR router. In both cases, on ingress the NORMAL action at table=60 is hit.

This is because for a provider network, there are no dvr MAC rules with an explicit output: action to a local port. In DVR subnet, these rules are added with the EXTERNAL vlan/segmentation ID. Not with the local vlan. However, there is a table=0, priority=3 rule which converts from the external VLAN to host local VLAN.

NORMAL action at table=60 for ingress, requires the local VM MACs to be learned. But these are never learned, because the fix resubmits egress packets to table 61, which has a direct output: action northbound.

So now we have flooding in opposite direction. But we still need this fix because in other scenarios, we see the egress flooding.

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

Related fix proposed to branch: master
Review: https://review.opendev.org/738397

Change abandoned by Slawek Kaplonski (<email address hidden>) on branch: master
Review: https://review.opendev.org/738397
Reason: This review is > 4 weeks without comment, and failed Zuul jobs the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Change abandoned by Slawek Kaplonski (<email address hidden>) on branch: master
Review: https://review.opendev.org/712640
Reason: This review is > 4 weeks without comment, and failed Zuul jobs the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

This bug has had a related patch abandoned and has been automatically un-assigned due to inactivity. Please re-assign yourself if you are continuing work or adjust the state as appropriate if it is no longer valid.

Change abandoned by Slawek Kaplonski (<email address hidden>) on branch: master
Review: https://review.opendev.org/715419
Reason: This review is > 4 weeks without comment, and failed Zuul jobs the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Reviewed: https://review.opendev.org/738551
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=959d8b6d73e2a6ab1a45c9a7b0b05ae163e650fc
Submitter: Zuul
Branch: master

commit 959d8b6d73e2a6ab1a45c9a7b0b05ae163e650fc
Author: LIU Yulong <email address hidden>
Date: Fri Jul 10 17:25:15 2020 +0800

    Local mac direct flow for non-openflow firewall

    When there is no openflow firewall, aka the ovs agent security group
    is disabled or Noop/HybridIptable, this patch will introduce a different
    ingress pipeline for bridge ports which will avoid ingress flood:
    (1) table=0, in_port=patch_bridge,dl_vlan=physical_vlan action=mod_vlan:local_vlan,goto:60 (original)
    (2) table=60, in_port=patch_bridge action=goto:61 (new)
    (3) table=61, dl_dst=local_port_mac,dl_vlan=local_vlan, action=strip_vlan,output:<ofport> (changes)

    And changes the local ports pipeline:
    (1) table=0, in_port=local_ofport action=goto:25 (original)
    (2) table=25, in_port=local_ofport,dl_src=local_port_mac action=goto:60 (original)
    (3) table=60, in_port=local_ofport,dl_src=local_port_mac action=local_vlan->reg6,goto:61 (changes)
    (4) table=61, dl_dst=local_port_mac,reg6=local_vlan, action=output:<ofport> (changes)

    Closes-Bug: #1884708
    Closes-Bug: #1881070
    Related-Bug: #1732067
    Related-Bug: #1866445
    Related-Bug: #1883321

    Change-Id: Iecf9cffaf02616342f1727ad7db85545d8adbec2

Change abandoned by Yi Yang (<email address hidden>) on branch: master
Review: https://review.opendev.org/712640
Reason: https://review.opendev.org/#/c/738551/ has covered this, so abandon it.

Related fix proposed to branch: stable/victoria
Review: https://review.opendev.org/759363

Related fix proposed to branch: stable/ussuri
Review: https://review.opendev.org/759364

Related fix proposed to branch: stable/train
Review: https://review.opendev.org/759365

Related fix proposed to branch: stable/stein
Review: https://review.opendev.org/759366

Related fix proposed to branch: stable/rocky
Review: https://review.opendev.org/759367

Related fix proposed to branch: stable/queens
Review: https://review.opendev.org/759369

Reviewed: https://review.opendev.org/759364
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=ef14d258eea91ef563c63334b2da1623d93418f3
Submitter: Zuul
Branch: stable/ussuri

commit ef14d258eea91ef563c63334b2da1623d93418f3
Author: LIU Yulong <email address hidden>
Date: Fri Jul 10 17:25:15 2020 +0800

    Local mac direct flow for non-openflow firewall

    When there is no openflow firewall, aka the ovs agent security group
    is disabled or Noop/HybridIptable, this patch will introduce a different
    ingress pipeline for bridge ports which will avoid ingress flood:
    (1) table=0, in_port=patch_bridge,dl_vlan=physical_vlan action=mod_vlan:local_vlan,goto:60 (original)
    (2) table=60, in_port=patch_bridge action=goto:61 (new)
    (3) table=61, dl_dst=local_port_mac,dl_vlan=local_vlan, action=strip_vlan,output:<ofport> (changes)

    And changes the local ports pipeline:
    (1) table=0, in_port=local_ofport action=goto:25 (original)
    (2) table=25, in_port=local_ofport,dl_src=local_port_mac action=goto:60 (original)
    (3) table=60, in_port=local_ofport,dl_src=local_port_mac action=local_vlan->reg6,goto:61 (changes)
    (4) table=61, dl_dst=local_port_mac,reg6=local_vlan, action=output:<ofport> (changes)

    Closes-Bug: #1884708
    Closes-Bug: #1881070
    Related-Bug: #1732067
    Related-Bug: #1866445
    Related-Bug: #1883321

    Change-Id: Iecf9cffaf02616342f1727ad7db85545d8adbec2
    (cherry picked from commit 959d8b6d73e2a6ab1a45c9a7b0b05ae163e650fc)

Reviewed: https://review.opendev.org/759365
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=c06895e8e78de06c25d36cb347313240432953cf
Submitter: Zuul
Branch: stable/train

commit c06895e8e78de06c25d36cb347313240432953cf
Author: LIU Yulong <email address hidden>
Date: Fri Jul 10 17:25:15 2020 +0800

    Local mac direct flow for non-openflow firewall

    When there is no openflow firewall, aka the ovs agent security group
    is disabled or Noop/HybridIptable, this patch will introduce a different
    ingress pipeline for bridge ports which will avoid ingress flood:
    (1) table=0, in_port=patch_bridge,dl_vlan=physical_vlan action=mod_vlan:local_vlan,goto:60 (original)
    (2) table=60, in_port=patch_bridge action=goto:61 (new)
    (3) table=61, dl_dst=local_port_mac,dl_vlan=local_vlan, action=strip_vlan,output:<ofport> (changes)

    And changes the local ports pipeline:
    (1) table=0, in_port=local_ofport action=goto:25 (original)
    (2) table=25, in_port=local_ofport,dl_src=local_port_mac action=goto:60 (original)
    (3) table=60, in_port=local_ofport,dl_src=local_port_mac action=local_vlan->reg6,goto:61 (changes)
    (4) table=61, dl_dst=local_port_mac,reg6=local_vlan, action=output:<ofport> (changes)

    Closes-Bug: #1884708
    Closes-Bug: #1881070
    Related-Bug: #1732067
    Related-Bug: #1866445
    Related-Bug: #1883321

    Change-Id: Iecf9cffaf02616342f1727ad7db85545d8adbec2
    (cherry picked from commit 959d8b6d73e2a6ab1a45c9a7b0b05ae163e650fc)

Reviewed: https://review.opendev.org/759366
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=7c757ad3372b5fe015ae4c5e3949c804e8515d20
Submitter: Zuul
Branch: stable/stein

commit 7c757ad3372b5fe015ae4c5e3949c804e8515d20
Author: LIU Yulong <email address hidden>
Date: Fri Jul 10 17:25:15 2020 +0800

    Local mac direct flow for non-openflow firewall

    When there is no openflow firewall, aka the ovs agent security group
    is disabled or Noop/HybridIptable, this patch will introduce a different
    ingress pipeline for bridge ports which will avoid ingress flood:
    (1) table=0, in_port=patch_bridge,dl_vlan=physical_vlan action=mod_vlan:local_vlan,goto:60 (original)
    (2) table=60, in_port=patch_bridge action=goto:61 (new)
    (3) table=61, dl_dst=local_port_mac,dl_vlan=local_vlan, action=strip_vlan,output:<ofport> (changes)

    And changes the local ports pipeline:
    (1) table=0, in_port=local_ofport action=goto:25 (original)
    (2) table=25, in_port=local_ofport,dl_src=local_port_mac action=goto:60 (original)
    (3) table=60, in_port=local_ofport,dl_src=local_port_mac action=local_vlan->reg6,goto:61 (changes)
    (4) table=61, dl_dst=local_port_mac,reg6=local_vlan, action=output:<ofport> (changes)

    Closes-Bug: #1884708
    Closes-Bug: #1881070
    Related-Bug: #1732067
    Related-Bug: #1866445
    Related-Bug: #1883321

    Change-Id: Iecf9cffaf02616342f1727ad7db85545d8adbec2
    (cherry picked from commit 959d8b6d73e2a6ab1a45c9a7b0b05ae163e650fc)

Reviewed: https://review.opendev.org/759363
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=88bbb58c80b9c888371e25267715b155851d9278
Submitter: Zuul
Branch: stable/victoria

commit 88bbb58c80b9c888371e25267715b155851d9278
Author: LIU Yulong <email address hidden>
Date: Fri Jul 10 17:25:15 2020 +0800

    Local mac direct flow for non-openflow firewall

    When there is no openflow firewall, aka the ovs agent security group
    is disabled or Noop/HybridIptable, this patch will introduce a different
    ingress pipeline for bridge ports which will avoid ingress flood:
    (1) table=0, in_port=patch_bridge,dl_vlan=physical_vlan action=mod_vlan:local_vlan,goto:60 (original)
    (2) table=60, in_port=patch_bridge action=goto:61 (new)
    (3) table=61, dl_dst=local_port_mac,dl_vlan=local_vlan, action=strip_vlan,output:<ofport> (changes)

    And changes the local ports pipeline:
    (1) table=0, in_port=local_ofport action=goto:25 (original)
    (2) table=25, in_port=local_ofport,dl_src=local_port_mac action=goto:60 (original)
    (3) table=60, in_port=local_ofport,dl_src=local_port_mac action=local_vlan->reg6,goto:61 (changes)
    (4) table=61, dl_dst=local_port_mac,reg6=local_vlan, action=output:<ofport> (changes)

    Closes-Bug: #1884708
    Closes-Bug: #1881070
    Related-Bug: #1732067
    Related-Bug: #1866445
    Related-Bug: #1883321

    Change-Id: Iecf9cffaf02616342f1727ad7db85545d8adbec2
    (cherry picked from commit 959d8b6d73e2a6ab1a45c9a7b0b05ae163e650fc)

Reviewed: https://review.opendev.org/759367
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=7ce65c94786d2d144a49cb991575534d0771bb20
Submitter: Zuul
Branch: stable/rocky

commit 7ce65c94786d2d144a49cb991575534d0771bb20
Author: LIU Yulong <email address hidden>
Date: Fri Jul 10 17:25:15 2020 +0800

    Local mac direct flow for non-openflow firewall

    When there is no openflow firewall, aka the ovs agent security group
    is disabled or Noop/HybridIptable, this patch will introduce a different
    ingress pipeline for bridge ports which will avoid ingress flood:
    (1) table=0, in_port=patch_bridge,dl_vlan=physical_vlan action=mod_vlan:local_vlan,goto:60 (original)
    (2) table=60, in_port=patch_bridge action=goto:61 (new)
    (3) table=61, dl_dst=local_port_mac,dl_vlan=local_vlan, action=strip_vlan,output:<ofport> (changes)

    And changes the local ports pipeline:
    (1) table=0, in_port=local_ofport action=goto:25 (original)
    (2) table=25, in_port=local_ofport,dl_src=local_port_mac action=goto:60 (original)
    (3) table=60, in_port=local_ofport,dl_src=local_port_mac action=local_vlan->reg6,goto:61 (changes)
    (4) table=61, dl_dst=local_port_mac,reg6=local_vlan, action=output:<ofport> (changes)

    Closes-Bug: #1884708
    Closes-Bug: #1881070
    Related-Bug: #1732067
    Related-Bug: #1866445
    Related-Bug: #1883321

    Conflicts:
        neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
        neutron/tests/unit/plugins/ml2/drivers/openvswitch/agent/openflow/native/test_br_int.py

    Change-Id: Iecf9cffaf02616342f1727ad7db85545d8adbec2
    (cherry picked from commit 959d8b6d73e2a6ab1a45c9a7b0b05ae163e650fc)

Reviewed: https://review.opendev.org/759369
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=7fe3e3d1e04d206245480d28534d9ee11949a9fa
Submitter: Zuul
Branch: stable/queens

commit 7fe3e3d1e04d206245480d28534d9ee11949a9fa
Author: LIU Yulong <email address hidden>
Date: Fri Jul 10 17:25:15 2020 +0800

    Local mac direct flow for non-openflow firewall

    When there is no openflow firewall, aka the ovs agent security group
    is disabled or Noop/HybridIptable, this patch will introduce a different
    ingress pipeline for bridge ports which will avoid ingress flood:
    (1) table=0, in_port=patch_bridge,dl_vlan=physical_vlan action=mod_vlan:local_vlan,goto:60 (original)
    (2) table=60, in_port=patch_bridge action=goto:61 (new)
    (3) table=61, dl_dst=local_port_mac,dl_vlan=local_vlan, action=strip_vlan,output:<ofport> (changes)

    And changes the local ports pipeline:
    (1) table=0, in_port=local_ofport action=goto:25 (original)
    (2) table=25, in_port=local_ofport,dl_src=local_port_mac action=goto:60 (original)
    (3) table=60, in_port=local_ofport,dl_src=local_port_mac action=local_vlan->reg6,goto:61 (changes)
    (4) table=61, dl_dst=local_port_mac,reg6=local_vlan, action=output:<ofport> (changes)

    Closes-Bug: #1884708
    Closes-Bug: #1881070
    Related-Bug: #1732067
    Related-Bug: #1866445
    Related-Bug: #1883321

    Conflicts:
        neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
        neutron/tests/unit/plugins/ml2/drivers/openvswitch/agent/openflow/native/test_br_int.py

    Change-Id: Iecf9cffaf02616342f1727ad7db85545d8adbec2
    (cherry picked from commit 959d8b6d73e2a6ab1a45c9a7b0b05ae163e650fc)