I Installed OVS plugin with VXLAN and GRE. Both work similar even switching beetween GRE and VXLAN is only done in /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini. Important is part [agent], because it missing in openstack documentation.

[ovs] 

tunnel_type = vxlan // or gre
tenant_network_type = vxlan // or gre

tunnel_id_ranges = 1:1000
enable_tunneling = True


integration_bridge = br-int
tunnel_bridge = br-tun
local_ip = 10.0.13.18

[agent]
tunnel_types = gre //or vxlan

[securitygroup]

firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

today we succesfully run the ML2 plugin with VXLAN on Ubuntu. There is no additional package for installation, because it is integrated inside of neutron-server. We have 1CTL, 1NTW, 2 CP nodes and for ML2 plugin must be configured only CTL node, where is neutron-server installed.

1) Edit /etc/default/neutron-server

# defaults for neutron-server
# path to config file corresponding to the core_plugin specified in
# neutron.conf
#NEUTRON_PLUGIN_CONFIG="/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini"
NEUTRON_PLUGIN_CONFIG="/etc/neutron/plugins/ml2/ml2_conf.ini"

2) Setup service_plugins inside of /etc/neutron/neutron.conf

# Advanced service modules
# service_plugins =
service_plugins = neutron.services.l3_router.l3_router_plugin.L3RouterPlugin,neutron.services.firewall.fwaas_plugin.FirewallPlugin

3) Create file /etc/neutron/plugins/ml2/ml2_conf.ini

[ml2]
# (ListOpt) List of network type driver entrypoints to be loaded from
# the neutron.ml2.type_drivers namespace.
#
# type_drivers = local,flat,vlan,gre,vxlan
# Example: type_drivers = flat,vlan,gre,vxlan

type_drivers = vxlan,local

# (ListOpt) Ordered list of network_types to allocate as tenant
# networks. The default value 'local' is useful for single-box testing
# but provides no connectivity between hosts.
#
# tenant_network_types = local
# Example: tenant_network_types = vlan,gre,vxlan
tenant_network_types = vxlan

# (ListOpt) Ordered list of networking mechanism driver entrypoints
# to be loaded from the neutron.ml2.mechanism_drivers namespace.
# mechanism_drivers =
# Example: mechanism_drivers = arista
# Example: mechanism_drivers = cisco,logger
mechanism_drivers = openvswitch

[ml2_type_flat]
# (ListOpt) List of physical_network names with which flat networks
# can be created. Use * to allow flat networks with arbitrary
# physical_network names.
#
# flat_networks =
# Example:flat_networks = physnet1,physnet2
# Example:flat_networks = *

[ml2_type_vlan]
# (ListOpt) List of <physical_network>[:<vlan_min>:<vlan_max>] tuples
# specifying physical_network names usable for VLAN provider and
# tenant networks, as well as ranges of VLAN tags on each
# physical_network available for allocation as tenant networks.
#
# network_vlan_ranges =
# Example: network_vlan_ranges = physnet1:1000:2999,physnet2

[ml2_type_gre]
# (ListOpt) Comma-separated list of <tun_min>:<tun_max> tuples enumerating ranges of GRE tunnel IDs that are available for tenant network allocation
# tunnel_id_ranges =
#tunnel_id_ranges = 1:1000

[ml2_type_vxlan]
# (ListOpt) Comma-separated list of <vni_min>:<vni_max> tuples enumerating
# ranges of VXLAN VNI IDs that are available for tenant network allocation.
#
# vni_ranges =
#vni_ranges=400:500

vni_ranges=1:1000

# (StrOpt) Multicast group for the VXLAN interface. When configured, will
# enable sending all broadcast traffic to this multicast group. When left
# unconfigured, will disable multicast VXLAN mode.
#
# vxlan_group =
# Example: vxlan_group = 239.1.1.1

After this settings everything should work!

We had almost exactly the same issue,it turned out that networks created through the gui defaulted to "local" type and not gre. In your case I expect they were gre and not vxlan. A quick look in the DB will show you.

I tried similar devstack configuration using ml2, ovs and vxlan on ubuntu 13.10. I had some problems with ovs not creating the tunnels properly. After some troubleshooting without success I finally updated openvswitch to a more recent version. The key package to update was openvswitch-datapath-dkms which seemed to be faulty on my ubuntu distribution. Now using version ovs 1.10.2 and everything works smoothly.

I think with Havana and OVS (ML2 or OVS plugin), VXLAN works the same way as GRE. VXLAN is just being used as a different framing protocol - IP/UDP vs IP/GRE.

It can't be anything todo with MTU as DHCP packets are very small. Also OVS 1.10.0+ is now doing IP fragmentation, and that problem was only for some Internet sites that ignored the ICMP errors.

I guess it's something todo with the flows on controller's br-tun. Can you append the output of sudo ovs-ofctl dump-flows br-tun to the question:

Also try running that command, get the instance to do more DHCP requests (from VNC console), re-run the command and compare the statistics to see which flows are being hit.

Also can you include sudo ovs-vsctl show from the controller.

Update: The second flow in table 0 (matches port 2, the vxlan port) is not being hit. Linux does not seem to be sending the incoming VxLAN packets to it. VxLAN uses UDP port 4789 by default, so this should give something: netstat -an | grep 4789

Ubuntu 13.10 was probably not used by Neutron developers during the Havana cycle. What kernel is it? You might try some different kernel versions or upgrade OVS. I think 13.10 uses the 3.11 kernel, and the OVS FAQ says its requires OVS 2.1.x