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 :
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 !
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
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.