Version 4 of OpenStack Beginner’s Guide is out. This guide is based on OpenStack Icehouse version. You can download the book by clicking the link below.
The following method was tested with FreeBSD 10.0 image bundled into Icehouse version of OpenStack running on Ubuntu 14.04
Create an image needed for Hard-drive emulation
qemu-img create -f qcow2 freebsd.img 5G
The neutron l3 agent is responsible for providing service for routing, natting, security-group rules and floatingip allocation. This purpose of this post is to document its working principles and also to enable users to effectively debug their Openstack cloud(most problems occur due to user mis configuration). The l3 agent offers these services from the network node and relies on neutron-openvswitch-agent to provide l2 connectivity to the instances running on compute nodes. This post assumes that the readers are aware of how l2 connectivity is achieved using ‘openvswitch’ mechanism driver. Continue reading “L3 connectivity using neutron-l3-agent”
The following procedure can be used to install OpenStack Glance Juno Version on FreeBSD 10.0.
Keystone is a prerequisite for installing Glance. Follow this link for installing Keystone on FreeBSD.
Continue reading “Installing OpenStack-Glance (Juno) on FreeBSD 10.0”
Install FreeBSD 10.0 on a machine with partitioning as per your requirements.
Continue reading “Installing OpenStack-Keystone (Juno) on FreeBSD 10.0”
Install OpenStack setup using the link https://fosskb.in/2014/04/12/openstack-icehouse-on-ubuntu-12-04-lts-single-machine-setup/
Setting Up GCE local access
Add ssh of your local machine to GCE Metadata
1. On Your local machine generate ssh key
$ sudo apt-get install ssh $ ssh-keygen -t rsa -P "" $ cat $HOME/.ssh/id_rsa.pub
2. copy the contents and replace yourusername@yourhostname with hadoop@yourhostname
Continue reading “Hadoop Multi-Node Setup in Google Compute Engine”
In this post we shall be discussing about various network components and their corresponding Linux virtual counterparts.
Switches basically provide the following functionality
- Mac learning: As switch receive packets on their interface they map the interface id/port number to the source mac address of the all packets received on that interface. This is used later while forwarding.
- Forwarding: Switches do not see a packet past the l2 headers. The have to perform a simple logic before sending out a packet received on one interface, to other interfaces.
- If the destination is broadcast/multi-cast, forward on all ports except the ingress port.
- If the destination of a packet is mapped to any interface send the packet out that interface alone.
- If the destination is non of the above, forward on all ports belonging to the packet’s VLAN, except the ingress port.
- VLAN Isolation: Packets are assorted according to their VLAN. A switch’s port can be either configured as trunk port(Belongs to all VLANs) or as an access port for a particular VLAN. The rules therefore are simple.
- Packets appearing on trunk ports should be tagged unless they belong to vlan 1(native vlan). The tag identifies the packet’s vlan in this case.
- Packets appearing on access ports should not be tagged unless they want to be dropped. The port configuration(access ports always belong to a VLAN) identifies the packet in this case
The assorted packets then pass through the forwarding phase, which determine to which port they would be sent to. Packets going out trunk ports will be tagged and those going out access ports will not be tagged. The forwarding logic guarantees that a packet belonging to a VLAN shall never trespass another VLAN.