Fix OpenStack / RDO / Havanna network

After installing openstack on CentOS with RDO package (installation I recommand as it is really easy) I had some issue with network : the bridges were not connected to the physical network and well configured so I was not able to communicate with any VM created.

Here is how I solved this issue …

First of all, to understand how network is working on openstack, installed on a single node (control + compute), you have 2 bridges. Bridges are level 2  virtual Ethernet concentrator (I would say switch).On one of these two (br-int) you connect all your VM. On the second one, you connect different (br-in) when make sense together + a link to the external world. It look like this :

openstack basic network topology
openstack basic network topology

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Br-int is connectect to the VM the L3 network is 192.168.0.0/24 ; Br-ex is connected to eth0 the L3 network is 111.22.100.0/24. A virtual router is deployed between both bridges to link them together and allow traffic routing.

In my initial configuration, the br-ex was disconnected from eth0 and it was not possible to communicate with the VMs.

To make this connection i’ve got this interesting URL (thank you for the guy on IRC who helped me !!) take a look here.

Basically the /etc/sysconfig/network-scripts/ifcfg-eth0 have to be like :

DEVICE="eth0"
HWADDR="xx:xx:xx:xx:xx:xx"
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=br-ex
ONBOOT="yes"

This indicates that eth0 is a physical port connected to an OpenVSwitch bridge named br-ex.

The /etc/sysconfig/network-scripts/ifcfg-br-ex file looks like :

DEVICE=br-ex
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
IPADDR=10.0.0.20
NETMASK=255.255.255.0
GATEWAY=10.0.0.254
DNS1=10.0.0.254
ONBOOT=yes

It contains the network configuration I would had given to the eth0 card basically. With specific type

Then neutron is configured by adding these two lines in  [OVS] session of file /etc/neutron/plugin.ini

[OVS]
tenant_network_type=vlan
network_vlan_ranges = physnet1:2000:3999
bridge_mappings = physnet1:br-ex
integration_bridge=br-int

Network is restarted & I also recommend to reboot because it seems that some previously defined iptables rules can block traffic.

After doing this, the br-ex interface is visible from outside. The configuration of openvswitch lok like this :

# ovs-vsctl show
ed54db06-7cb7-415a-97ea-2bc2ef85e085
    Bridge br-int
        Port br-int
            Interface br-int
                type: internal
        Port int-br-ex
            Interface int-br-ex
        Port "qvoc6ce8a66-17"
            tag: 1
            Interface "qvoc6ce8a66-17"

    Bridge br-ex
        Port "eth0"
            Interface "eth0"
        Port phy-br-ex
            Interface phy-br-ex
        Port br-ex
            Interface br-ex
                type: internal
    ovs_version: "1.11.0"
  • Port eth0 is the connection of the physical card to the bridge
  • Port “qvo4f65df07-8e” is the port of my virtual machine.
  • Port int-br-ex is ???
  • Port phy-br-ex is ??

At this point the communication between the two bridge is still not working. It is missing a virtual cable between them …

This can be done like this:

ovs-vsctl add-port br-int patch_cable_12 -- set Interface \
      patch_cable_12 type=patch options:peer=patch_cable_21
ovs-vsctl add-port br-ex patch_cable_21 -- set Interface \
      patch_cable_21 type=patch options:peer=patch_cable_12

This is creating two port connected together like a patch cable. and gives this result :

# ovs-vsctl show
ed54db06-7cb7-415a-97ea-2bc2ef85e085
    Bridge br-int
        Port br-int
            Interface br-int
                type: internal
        Port int-br-ex
            Interface int-br-ex
        Port "qvoc6ce8a66-17"
            tag: 1
            Interface "qvoc6ce8a66-17"
        Port "patch_cable_12"
            Interface "patch_cable_12"
                type: patch
                options: {peer="patch_cable_21"}
    Bridge br-ex
        Port "eth0"
            Interface "eth0"
        Port "patch_cable_21"
            Interface "patch_cable_21"
                type: patch
                options: {peer="patch_cable_12"}
        Port phy-br-ex
            Interface phy-br-ex
        Port br-ex
            Interface br-ex
                type: internal
    ovs_version: "1.11.0"

At this step, I still not able to join the VM but a big change appeared ! I’m now able to see on the br-int bridge the network traffic from the eth0 card !

# tcpdump -n -i br-int
tcpdump: WARNING: br-int: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-int, link-type EN10MB (Ethernet), capture size 65535 bytes
22:24:50.389479 IP 10.0.0.254.filenet-pa > 255.255.255.255.7423: UDP, length 173
22:24:50.412359 IP 10.0.0.30.42237 > 239.255.255.250.ssdp: UDP, length 314
22:24:50.418932 IP 10.0.0.14.ssdp > 239.255.255.250.ssdp: UDP, length 1024

At this point I’m assuming the problem is related to the iptable rules …

If anyne have idea or can tell me what’s wrong in my config, i’ll be happy to hear it !

 

 

 

This entry was posted in Virtualization and tagged , , . Bookmark the permalink.

2 Responses to Fix OpenStack / RDO / Havanna network

  1. Daniele says:

    Hi,

    first at all thanks to share your work 😉

    Could you please tell me what would you include on this offer? Shield, Antenna, SMA conenctor…
    Can you estimate the shipping price to Switzerland?
    Would it be possible to have the shield that keep the pin accessible to directly connect another expansion board (for example enocean pi).
    A solution similar to this one http://www.pridopia.co.uk/pi-usb-7-hub-i2c-lite.html where you could already conenct a next expantion board.

    Thanks
    Daniele

    • Paul says:

      Hello Daniele, no idea for price to switzerland, but I assume it can be included in the 60€ price.
      The shield comes with antenna and SMA connector. RF433 receiver + transmitter + 3 led. As I sold it manually, I could just left connector un-sold so you could sold the one you want, but it means I won’t be able to test it before send it, which is a risk. What I can do is to sold it to be later removed as easy as possible with no warranty. I do not have any connector like you show me available to built it ; if you can wait 1 month, I think I’ll have to order some new components and I could try to find a such one. For the led, tell me what color you want, if I have it, I’ll sold it.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.