Neutron is the networking project within the OpenStack cloud platform. The purpose of OpenStack Neutron is to provide physical and virtual network resources to the instances (or virtual machines). Before you continue to read this article I would recommend that you read about OpenStack networking concepts. To appreciate the architecture and the functionality of Neutron, it is important to understand the components that are part of Neutron.

Have you come across a situation when you want to continue reading an interesting online article but do not have enough time? Have you felt the need to add a “reminder to read it later” and block out specific time on your calendar? If the answer to these questions is a Yes, then I will show a simple way to do this using Google Calendar. Before I give a step by step guide to adding a URL to Google Calendar, here are some details about the solution:

In the next installment of “What I learnt today” or WILT, I briefly touch upon Network Namespace. I came across Namespace as part of my ongoing study of OpenStack networking. Namespaces are powerful constructs in Linux that allows you to create a copy of the TCP/IP network stack -all the way from the Ethernet interfaces (L2), routing tables etc.

This is the first blog in a new series that I have wanted to start for a while. The series will be called WILT which stands for What I Learnt Today. In our day to day life, especially at work, we all learn something or at least aspire to learn something. In this series of short blogs, I will share some interesting topics that I come across in my workplace.

The goal of this blog is to share some details about how I have setup a cost-effective OpenStack Lab at home. For most enthusiasts, DevStack is the preferred way to experiment with OpenStack. But I wanted something more realistic for my experiments. OpenStack is intended for multi-tenant, distributed and highly scalable cloud. To appreciate its architecture I needed to move beyond DevStack. With a more realistic setup, you can understand how the distributed OpenStack components interact with each other.

Here is my mid-year (I know I am off by couple of months) review of my blogging and learning goals for 2014. I will start off with my assessment of the first half of 2014 and then wrap with goals for the remaining four months of this year.

In data center and cloud environment, servers used for hosting the virtual machines usually have more than one wired networking interfaces. In fact there are multiple Ethernet interfaces on each server. It is common practice to use one of the interface for ‘managing’ the host itself. This interface is usually accessible from corporate networks and administrators will use this interface for doing SSH into the server. The other interfaces are usually used for virtual machine traffic or storage traffic.

Most of us have “cloud storage” accounts to keep our important files backed up in a central location and yet be accessible across devices. But these accounts have limits unless you are willing to shell out more money. Also the network traffic for big files will eat up into your monthly broadband quota (especially in India). Therefore it is still common to have a “backup” store at home. Most people are probably using USB hard disk drives for this.

I continue the series on virtual networking with an overview of OpenStack networking concepts. OpenStack is an open source project with an aim to create a scalable cloud operating platform. The primary goal of this software platform is to help build public and private clouds. Specifically it allows users to build and operate infrastructure as a service or IaaS clouds.

This is a guest post by Suryanarayana M N V. Having led teams working on Networking protocols, Surya has in-depth knowledge of networking. He has keen interest in the areas of Network Virtualization and NFV.

The most common NFV product that I had come across is in security domain viz., firewalls. To get an idea on how good they are, I checked the Juniper, PaloAlto & Fortinet Virtual Firewall products.