I have the following setup:

• Openstack release - Kilo
• Controller node (node 1) - Horizon, Keystone, Glance, Database, Rabbitmq, neutron-server etc.
• Compute/Network node (node 2) - nova-compute, all networking services (OVS, L3, DHCP, neutron plugin)

On node 2, I have four provider networks with four interfaces - em0 (untagged), eth1 (vlan 100), eth2 (vlan 200), eth3 (vlan 300). They connect to a ToR switch that is configured to allow the VLANs. em0 has external access via br-ex. eth1, eth2 and eth3 are part of br-vlan. There are four project networks corresponding to the above provider networks.
net-0 (flat) => em0 (no DHCP)
net-1 (vlan 100) => eth1
net-2 (vlan 200) = > eth2
net-3 (vlan 300) => eth3
And a neutron router connected to net-0 and net-1.

The OVS bridges are as follows:
br-ex: with ports em0 and phy-br-ex
br-vlan: with ports eth1, eth2, eth3 and phy-br-vlan
br-int: with ports int-br-ex, int-br-vlan, qr-xxxx, qg-xxxx and three tapxxx interfaces to DHCP namespaces (for net-1, net-2 and net-3).
After launching a VM (Ubuntu guest OS), I can see qvoxxxx ports (towards linux bridges) created on br-int. And the flow table in OVS look identical to the one http://techbackground.blogspot.com/2013/07/the-open-vswitch-plugin-with-vlans.html (here).
(http://techbackground.blogspot.com/2013/07/the-open-vswitch-plugin-with-vlans.html (http://techbackground.blogspot.com/20...))

Now, when an external ARP request comes on either eth*, it creates an ARP flood within the network. To stop this, I have to bring down the eth* interfaces. I ran tcpdump on all eth* and noticed ARP requests tagged with 100, 200 and 300 on all three of them. It looks like the NORMAL action in OVS flows creates the broadcast storm, which should die out as the MACs are learned. But I don't see it happening. Am I missing any OVS flows?