Do not block connection between br-int and br-phys on startup

Block traffic between br-int and br-physical is over kill
and will at least

1. interrupt vlan flow during startup, and is particularly
so if dvr enabled
2. if let's rabbitmq is not stable, it is possible data plane
will be affected and vlan will never work.

Using openstack on k8s particularly amplifies the problem
because pod could be killed pretty easily by liveness
probes.

Change-Id: I51050c600ba7090fea71213687d94340bac0674a
Closes-Bug: #1869808

neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py

@@ -1551,20 +1551,29 @@ class OVSNeutronAgent(l2population_rpc.L2populationRpcCallBackTunnelMixin,
             self.int_ofports[physical_network] = int_ofport
             self.phys_ofports[physical_network] = phys_ofport
 
-            # These two drop flows are the root cause for the bug #1803919.
-            # And now we add a rpc check during agent start procedure. If
-            # ovs agent can not reach any neutron server, or all neutron
-            # servers are down, these flows will not be installed anymore.
-            # Bug #1803919 was fixed in that way.
-            # And as a reminder, we can not do much work on this. Because
-            # the bridge mappings can be varied. Provider (external) network
-            # can be implicitly set on any physical bridge due to the basic
-            # NORMAL flow. Different vlan range networks can also have many
-            # bridge map settings, these tenant network traffic can also be
-            # blocked by the following drop flows.
-            # block all untranslated traffic between bridges
-            self.int_br.drop_port(in_port=int_ofport)
-            br.drop_port(in_port=phys_ofport)
+            # following drop operations are not necessary for
+            # dvr agent setup_dvr_flows. So skip it if dvr enabled
+            # the reason is for br_int it is duplicate
+            # for br_physical drop_port is dangerous because when dvr
+            # enabled the highest flow on table=0 is 2 which means
+            # basically everything will be dropped until setup_dvr_flows
+            # got executed.
+            if not self.enable_distributed_routing:
+                # These two drop flows are the root cause for the bug #1803919.
+                # And now we add a rpc check during agent start procedure. If
+                # ovs agent can not reach any neutron server, or all neutron
+                # servers are down, these flows will not be installed anymore.
+                # Bug #1803919 was fixed in that way.
+                # And as a reminder, we can not do much work on this. Because
+                # the bridge mappings can be varied. Provider (external)
+                # network can be implicitly set on any physical bridge
+                # due to the basic NORMAL flow.
+                # Different vlan range networks can also have many
+                # bridge map settings, these tenant network traffic can also be
+                # blocked by the following drop flows.
+                # block all untranslated traffic between bridges
+                self.int_br.drop_port(in_port=int_ofport)
+                br.drop_port(in_port=phys_ofport)
 
             if self.use_veth_interconnection:
                 # enable veth to pass traffic