Please,view http://www.gluster.org/author/boris-derzhavets/ . Stuff in blog is based on original Kashyap's posts. My earliest http://lxer.com/module/newswire/view/197613/index.html appears to be correct. Two Real Node Neutron GRE+OVS+Gluster Havana F20 Cluster works stable enough for about 2 months.

Just to note, I have a two node OpenStack RDO Havana set-up configured manually on two Fedora 20 VMs (running Nested KVM on Intel), and it's running pretty solid:

• Controller node: Nova, Keystone, Cinder, Glance, Neutron (using Open vSwitch plugin and GRE tunneling).
• Compute node: Nova (nova-compute), Neutron (openvswitch-agent)

Networking details:

• Controller & Compute nodes are using a single NIC, non-default libvirt network (created manually -- http://kashyapc.fedorapeople.org/virt/create-a-new-libvirt-bridge.txt )
• In case if it helps, here are myNeutron configurations, iptables rules on both Controller and Compute nodes: http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-two-node.txt

Somebody recently wrote an article about this issue. Might be worthy checking it out: http://fosskb.wordpress.com/2014/06/1...

You can read this artical first. It will help you understand Quantum/Neutron networking. http://openstack.redhat.com/Networking_in_too_much_detail

Then go to this artical. http://openstack.redhat.com/Using_GRE_Tenant_Networks

We currently are setup with bonded nics. I layered vlans ontop of bond0 and used the vlans as the interfaces for the bridges. Following the examples in the article, a config that looks something like this should work:

RedHat and derivites should work with something like this:

DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
#######################
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
#######################
DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
#######################
DEVICE=bond0.100
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
VLAN=yes
NM_CONTROLLED=no
BRIDGE=br-eth0
#######################
# Please change bridge name to somethine else
#######################
DEVICE=br-eth0
TYPE=Bridge
IPADDR=10.240.0.10
NETMASK=255.255.255.0
ONBOOT=yes
BOOTPROTO=none
NM_CONTROLLED=no
DELAY=0

I just named the bridge br-eth0 because that is what the guide says, change it to something more meaningful.

This would be for Debian (should work for Ubuntu)

auto eth0
iface eth0 inet manual
  bond-master bond0

auto eth1
iface eth1 inet manual
  bond-master bond0

# Remember this isn't the only way to bond these nics.
# Make sure to use the appropriate bond-mode
auto bond0
iface bond0 inet manual
  bond-mode 802.3ad
  bond-miimon 100
  bond-lacp-rate 1
  bond-slaves eth0 eth1
  up ip link set bond0 promisc on

# This is vlan 100. This requires additional configuration
# on the switch itself. Also install the `vlan` package if you
# haven't done so already.
auto bond0.100
iface bond0.100 inet manual
  up ip addr add 0.0.0.0 dev bond0.100
  up ip link set br-eth0 up
  vlan-raw-device bond0

# I have kept the name as br-eth0 because that is what the
# interface is named in the article. I suggest creating it as
# something less confusing like br-data.
auto br-eth0
iface br-eth0 inet static
  address 10.240.0.10
  netmask 255.255.255.0
  gateway 10.240.0.1
  nameserver 8.8.8.8
  bridge_ports bond0.100