Overlay technologies in data center

Everyone speaks about SDN an the benefits its brings when deploying cloud or enterprise infrastructures. But do we actually know or have any understanding what this all SDN is about? If you want be fluent in the language of virtual networking and network overlays in modern data centers you need to understand at least the following concepts:

• SDN controller (Northbound and Southbound API) (an example controller could be VMware NVP/NSX or OpenDaylighta; a list of vendor specific Northbound API)
• Openflow as Southbound API (example flow in Open vSwitch)
• Network Functions Virtualization
• Overlay and tunnels concept for cloud network inside data center (example protocols are VXLAN and STT)

In the remaining of the post we will concentrate solely on existing overlay technologies. These information was extracted from Cisco doc: Cisco Nexus 9000 Series Switches - Data Center Overlay Technologies).

Network-Based Overlay Networks

1. IEEE 802.1ad Provider Bridging or IEEE 802.1q Tunneling also known as IEEE 802.1QinQ or simply Q-in-Q
2. IEEE 802.1ah Provider Backbone Bridges (PBB) or Mac-in-Mac Tunnels
3. Cisco FabricPath allows multipath networking at Layer 2
4. TRILL - IETF Transparent Interconnection of Lots of Links is a Layer 2 multipathing technology
5. Shortest-Path Bridging (SPB) is defined in IEEE 802.1aq and is targeted as a replacement for Spanning Tree Protocol (example info based on Avaya documentation)
6. Cisco Overlay Transport Virtualization (OTV) is a Layer 2-over-Layer 3 encapsulation "MAC-in-IP" technology
7. The Cisco Location/Identifier Separation Protocol (LISP) is currently defined as a Layer 3 overlay scheme over a Layer 3 network
8. Multiprotocol Label Switching (MPLS)
9. Virtual Private LAN Service (VPLS) a Layer 2 tunneling protocols
10. Virtual Private Routed Network (VPRN) also known as BGP/MPLS or IP-VPN provides IP VPN services

Host-Based Overlay Networks

1. Virtual Extensible LAN (VXLAN) is a Layer 2 overlay scheme over a Layer 3 networ that uses IP/UDP encapsulation
2. Network Virtualization Using Generic Routing Encapsulation (NVGRE) allows creation of virtual Layer 2 topologies on top of a physical Layer 3 network
3. Stateless transport tunneling (STT) is an overlay encapsulation scheme over Layer 3 networks that use a TCP-like header

How to design a network for Openstack or cloud deployment

Designing a network is a topic within itself and there is no way we can cover all of it in this single post. Cisco has its own certification path path CCDE for these who want to know more.

Cisco design and implementation guide - old best practices

In a very simplistic view back in the old days a network used to be design similar to the picture below (although it is hard to say when the new era started ;)). Every big network had to have a core, distribution(sometimes called aggregation) and access layer. The network was engineered mainly to help with North to South traffic in the data center or in another words to help get the data out and into the data center.

New cloud friendly data center design best practice

With the advent and popularization of new networking devises that support layer 2 routing, commonly know as networks fabrics (more info about TRILL and fabric) the network design has shifted in data centers. The way we design the networks today is to maximize the East to West traffic instead of the North to South ( old design above). The purpose of the new network is to allow more efficiently exchange data between the servers within the rack or data center.

They say that a picture is worth more than a thousand words. To help us to visualize how a new data center network/cloud network is designed these demonstration pictures (taken from Cisco document: Cisco Massively Salable Data Center) will shed some more light on it. Please note that we no longer use the core, distribution or access keyword but instead: spine, leaf or superspine to describe the different network layers :).

Openstack Neutron architecture explained based on OVS and VMware NVP plugin comparison

There are 3 recorded meetup videos that were organized by the onlinemeetup Openstack group (http://www.meetup.com/OpenStack-Online-Meetup/). These are an excellent source of information into network virtualization, nova-network, Neutron OVS and NVP plugins.

The recorded sessions can be found on YouTube here:

OpenStack Networking - Theory Session, Part 1
OpenStack Networking - Theory Session, Part 2
OpenStack Networking - Hands-On Lab, Part 3

Network virtualization basic

Nova Networking

The first version of network implemented in Openstack is called nova-networking and can be still used. Some of the advantages and limitations can be seen below.

The most complex deployment architecture used VLANs to implemented tenant and isolation. This scenario has a lot ideas that are then later shared in Neutron plugins.

OVS plugin

As you can see the architecture looks very similar. There are some subtle differences although like: instead of VLAN we use GRE tunnels, instead of Linux bridge we use the OpenVswitch (OVS). The important thing to note is that we don't use OpenFlow protocol to control the OVS switches. The switch will be pre-programmed by the agent running on the hypervisor.

NVP plugin

To describe and explain how NVP works it is good to compare its architecture to OVS plugin above. The first slide shows what component are not being used.

The network communication model with NVP provides new component.

The main differences are:

• OVS switches will be programmed by the NVP cluster using OpenFlow protocol
• Instead of GRE we use STT tunneling
• Security groups will be natively implemented in OVS (no need for iptables)
• The virtual router is highly available and is implemented on external nodes 

Debugging networking issues in Neutron

Overview of cloud networking and Neutron in Openstack

We saw what challenges a successful Neutron deployment in Openstack would have to overcome in this post: Status and maturity of the Neutron in Openstack Havana release. But the journey into cloud network is worth the trouble and you can find many discussions that show the potential business and technological advantage you gain (an example What your Dev, Engineering and sales teams can achieve by using Openstack cloud and Quantum network).

But as the Neutron continues to bring new and advance networking features with every consecutive  Openstack release ( Havana Neutron features) there is always a fear that it may become very complex and difficult to troubleshoot. To help to fill the gap the video from Dave Neary (slides are here Networking in OpenStack for non-networking people) is taking us on the journey what cloud networking and Neutron is as well as showing the basic troubleshooting every one should be aware of.

Neutron troubleshooting

These couple of slides from the video summarized very well what troubleshooting actions you can do when dealing with network connectivity problems from and to your VM. For more info watch the video yourself.

References

http://openstack.redhat.com/Main_Page
http://openstack.redhat.com/Networking
http://openstack.redhat.com/Networking_in_too_much_detail

Status and maturity of the Neutron in Openstack Havana release

Randy Bias from Cloudscaling organized a meetup and brought together 4 engineers who work on cloud network and Openstack Neutron:

• Juniper, Rudra Rugee
• Midokura, Ryu Ishimoto
• VMware, Aaron Rosen
• PLUMgrid, Edgar Magana

More info about the meetup can be found here:
http://www.meetup.com/openstack/events/152128692/
http://cloudscaling.com/blog/cloud-computing/neutron-in-production-work-in-progress-or-ready-for-prime-time/
http://www.slideshare.net/randybias/sfbay-openstack-meetup-neutron-and-sdn-in-production-20131203

Below are some of my notes I took when watching the video.

 Key SDN components

• Network programmability (API)
• Network vitalization (responsible for creating overlay network, multi-tenancy, managing flows, gateways, virtual routers ...)

What cloud network is and what Openstack Neutron is trying to solve

Neutron is an abstraction layer. It separates your physical network from the direct "tenant network"/virtual network topology. It allows you pragmatically (through a reach API and cli) create virtual routers, lb, firewall. That way it allows you to emulate/virtualize physical devices in cloud.

The main idea is to keep the physical layer as simple and minimal as possible but reach enough so you can create more complex configuration on top of it. That way you can think about Neutron in term of configuration management, orchestration or network vitalization management.

Neutron

• It defines a clear public API how to interact with Openstack to create network objects.
• Provide Network as a Service (NaaS) to tenants to enable more advance deployments and configuration options. 
• Initially the goal was to remove the Nova Network from Openstack and create its won project to allow more flexibility and expand functionality (Nova network does support only a limited number of topologies: flat, flat DHCP and VLANs). 
• Platform for new future network development in Openstack.
• Neutron is promising a scalable and highly available infrastructure for tenants.
• There are some single point of failures (SPOF) in the current vanilla Havana release. This is one of the differences between the open source vanilla Neutron and vendor specific plugins.
• It provides a choice of technology and no vendor lock-in for network in Openstack. One way of looking at it is that the customer have a choice of what technology/vendor  he would like to use to build up the network infrastructure. The there benefit is access to an public  open API that is independent of the actual backed technology. But it is important to understand that various backed drivers may provide different and more reach functionality than the Openstack one. In this case you can always get access to this through API extension that Neutron exposes as well. In this sense you can gain additional way of interacting and using your new technology and still remain open and interoperable with feature versions.  
• It allows for vendor specific extension for more advance networking features that may not be present in current Neutron API.
• It is the platform to integrate all network functionality in cloud. Although its main focus is on the most common cases and what users demand.
• Openstack wants to be the the reference model for the next generation cloud data center and Neutron aims to provide support for the networking part.  By providing a common and widely acceptable platform it opens and allows multi network vendors integration. 
• Every vendor can have its own differentiate factors. In the current state of networking industry it is impossible to have a single API in Openstack to address every use case needs. It looks like there will be always space for vendor extension in Neutron for these infrastructure providers or customer who demand more specific and unique features that are not present yet. 
• Exposes network abstraction to developers, operation and devops teams who don't need to worry about the implemented details.

Would you run vanilla Openstack Neutron in production

This question was asked at about 41.50. There were different answers.

• If you want to run the vanilla Neutron configuration it is not recommend to run it in production without good knowledge of how all Openstack components work and interact together. 
• You can run Neutron with vendor plugin in production. By choosing a vendor plugin instead of the vanilla open source solution you get additional level of confidence and support.
• Maybe for private cloud depending on feature requirements and scalability but no for public cloud and enterprise network deployments.

The choice between Neutron Openstack vanilla vs vendor plugin needs to be always analyzed individual per customer.

• What level of (technical) support is required before and after implementation.
• How much expertise do you have in your company.
• What scalability do we talk about.
• What application do you want to run.
• What features do you require.

Other issues

There aren't many good troubleshooting tools.
It is difficult to see and track a specific VM to VM traffic.

Top 10 data center network vendor list

In previous post was saw how handful the Gartner magic quadrants can be when learning and researching particular technology or industry trend:

• New 2012 Gartner Magic Quadrant for Cloud Infrastructure as a Service (Iaas)
• Rackspace and Brocade pushing ADX platform

Below is an another comparison chart, this time targeting vendor network equipment in data centers.

By the way I was investigating this because of the networks vendor selection on this cloud hardware deployment calculator (How to estimate hardware requirements for your private Openstack deployment ) : Dell, Cisco, HP, Arista, Juniper, Brocade.

How does the VXLAN protocol work

The VXLAN is one of the overlay network tunneling protocols that is used to built network infrastructure for cloud environment. Below are some details about the operation and specification.

• Frame headers definition

• The traffic between VMs is encapsulated in IP/UDP packets
• Logical isolation is implemented in a form of logical overlay where the traffic is exchanged between encryption tunnels endpoints
• VXLAN ID is used to identify the specify isolated L2 cloud network that belongs to a tenant
• The tunnel endpoints represent the edge of the cloud network infrastructure
• The tunnel endpoints perform encapsulation and decapsulation
• It is there where all the logic is implemented to find out where to sent next a packet or to witch VM the packet should be delivered after decapsulation

• A comprehensive summary and operational features can be found under the links in reference section, below are few of the main characteristics and benefits:
• It operates over IP and used UDP to carry payload 
• Multicast support is the only other requirement for switches and routers to support VXLAN 
• Multicast is used to handle L2 broadcast traffic (like ARP requests)
• Logical networks can be extended among virtual machines placed in different Layer 2 domains

References

1. http://www.definethecloud.net/vxlan-deep-dive
2. http://www.definethecloud.net/vxlan-deep-divepart-2
3. http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/white_paper_c11-685115.html
4. http://www.emulex.com/artifacts/d658610a-d3b6-457c-bf2d-bf8d476c6a98/elx_wp_all_VXLAN.pdf
5. http://blogs.cisco.com/datacenter/more-vxlan-qa/
6. http://blog.scottlowe.org/2011/12/07/revisiting-vxlan-and-layer-3-connectivity/
7. http://blog.scottlowe.org/2011/12/22/otv-and-vxlan-layer-3-connectivity-compared/

Network virtualization jargon

I've read recently this blog post Virtual Network Domain and Network Abstractions. In the post PlumGrid  CTO describes challenges and opportunities that currently exists in cloud network. In my opinion what makes it unique and interesting in comparison to other blogs concentrating on network virtualization is the language he uses.

Below are some of the examples:

• Distributed Virtual Switch (DVS)
• Physical Network Infrastructure (PNI)
• Virtual Broadcast Domains (aka Distributed VLANs) 
• Virtual Network Infrastructure (VNI)
• Virtual Network Domains (VND)

Do you believe that these concepts are more understandable when we speak about networking in the cloud. Typically described today as network virtualization, virtual network, cloud network, hybrid network or private network.

References

1. http://umairhoodbhoy.net/2013/02/12/what-is-plumgrid-up-to/
2. http://en.wikipedia.org/wiki/Network_virtualization

Architecture frameworks

Did you see big systems implementations?
Did you participated in a system implementation or deployment?
What is your current role?
What is your carrier goal?

Every company is organised in a different way. Every company is build in a different way. But it all starts from a vision that is going to be mapped into an architecture. Once the concept or the first sketches of the architecture are established the implementation process is going to follow.

It is an example how it can look like. If you are interested in other options it is worth to take a look at some of the established (enterprise) architecture frameworks. Generally speaking, it is rather a quite difficult document to read as it tries to address the issue of an enterprise company. But even though its complexities it still gives a good overview how complex some processes, implementations or deployments can be. Below is a table from FEAF framework that list key roles and teams for an organisation.

This one below shows the concept of an architecture from a high level point of view.

The more detailed description of the architecture domains can be found here. Personally, I'm specializing in the area of technical infrastructure architecture. With the specialization in virtual networking and cloud network in IaaS cloud.

Technical architecture or infrastructure architecture: The structure and behaviour of the technology infrastructure. Covers the client and server nodes of the hardware configuration, the infrastructure applications that run on them, the infrastructure services they offer to applications, the protocols and networks that connect applications and nodes.

References

1. http://en.wikipedia.org/wiki/Solution_architecture
2. http://en.wikipedia.org/wiki/Architecture_domain
3. http://en.wikipedia.org/wiki/TOGAF
4. http://pubs.opengroup.org/architecture/togaf8-doc/arch/
5. http://en.wikipedia.org/wiki/Multitier_architecture
6. http://en.wikipedia.org/wiki/Peer-to-peer

Performance analysis of network tunnels in SDN cloud network

Additional network overlay is the foundation and building block for most modern cloud network architectures today. In practice it means that before we can even think how to architect and build network for the cloud we need to build a solid and reliable multi-tiered IP network topology to interconnect our hypervisors servers. Of course this is a big simplification and there are many vendors that provide hardware support for cloud network (SDN enabled network). Examples are Brocade VCS/MLX or Cisco Nexus platform/Random thoughts about Cisco nexus product line.

But what is important is that in essence what we are going to built will be a typical multi-tier network with access, distribution and core layers like this example below:

Once the network is built there is now time for the cloud network element to be added. This is again very simplistic view to avoid all the technical details.

The industry is still working to established a common ground and consensus how a cloud network should look like and what services it should provide but in practice (base on a few companies like Nicira or Midokura) it is tightly associated with  Software defined networking (SDN) concept and architecture. And the common practice today is to implement SDN network as an additional network overlay on top of IP fabric infrastructure.

Like every network, cloud network needs to provide IP connectivity for cloud resources (cloud servers for example). Often to achieve this al hypervisors are inter-connected using tunneling protocols. This model allow us to decouple the cloud network from the physical one and allow more flexibility. That way all VMs traffic is going to be routed within the tunnels. To solve the cloud network problem is to find a solution how to route between the hypervisors using the tunnels.

Data flows, connections and tunnels are manged by cloud controller (a distributed server cluster) that need to be deployed in our existing physical network. An example of Nicira NVP controller can be found here: Network Virtualization: a next generation modular platform for the data center virtual network.

As we agreed VMs data will be routed within tunnels. These are the most popular ones: NVGRE, STT and VXLAN (Introduction into tunneling protocols when deploying cloud network for your cloud infrastructure).

As tunnels require additional resources there is an open question what overhead, resource consumption and performance implication will they represent. This post: The Overhead of Software Tunneling (*), do a comparison and tries to shed some more light on the topic.

	Throughput	Recv side cpu	Send side cpu
Linux Bridge:	9.3 Gbps	85%	75%
OVS Bridge:	9.4 Gbps	82%	70%
OVS-STT:	9.5 Gbps	70%	70%
OVS-GRE:	2.3 Gbps	75%	97%

This next table shows the aggregate throughput of two hypervisors with 4 VMs each.

	Throughput	CPU
OVS Bridge:	18.4 Gbps	150%
OVS-STT:	18.5 Gbps	120%
OVS-GRE:	2.3 Gbps	150%

We can see that not all tunnels are completely transparent when it comes to performance. The GRE tunnel shows a significant degradation in throughput. The TCP based STT tunnel works fine although  For a complete analysis, explanation and further discussion I recommend to read the blog above (*).

References

1. http://rtomaszewski.blogspot.co.uk/2012/12/what-do-you-need-to-implement-virtual.html
2. http://rtomaszewski.blogspot.co.uk/2012/11/what-network-topologies-can-i-build.html
3. http://rtomaszewski.blogspot.co.uk/2012/11/after-server-virtualization-there-is.html
4. http://rtomaszewski.blogspot.co.uk/2013/05/sdn-system-software-architecture.html
5. http://bradhedlund.com/2012/10/06/mind-blowing-l2-l4-network-virtualization-by-midokura-midonet/
6. http://blog.ioshints.info/2012/08/midokuras-midonet-layer-2-4-virtual.html

SDN system software architecture

By reading about various companies like (Nicira, Midokura) that provide SDN solutions you hear various technology acronyms like Openflow, Openvswitch and others. After a while once you allow this knowledge to sink your appetite grows and you begin to ask more questions like:

• How did they create this
• What tread off and compromises exist in the architecture
• What could be the limitations
• How complex is the architecture and deployment
• What software, languages etc.. did they use
• How much operational intensive it is to support this 

It is hard and even impossible to answer all of them fully but I hope the little info below will help to fill some of the gaps.

Vendor advertised information 

There is no much info about internal architecture or deployment options on the vendor's home site. We can find only very generic descriptions like the ones below.

Nicira [1]

What is Nicira's architecture?
Nicira's Distributed Virtual Network Infrastructure (DVNI) is an architecture that builds on a distributed software system that decouples virtual services from the network hardware and works with any server hypervisor. 

How does the platform work?
The NVP Controller Cluster dynamically updates the state of tunnel connections between OVS switches through the physical network. These tunnels allow virtual networks to span across the data center, even between data centers. Data communications between workloads connected to virtual networks is encapsulated and traverses the physical network, enabling VM mobility across subnet boundaries, while maintaining L2 adjacency. The operational state of the network is computed algorithmically in the NVP Controller Cluster,

Midokura [2]

Fully Distributed Architecture with no single points of failure

Midokura has built MidoNet to be completely distributed and scalable. These advantages are key in building your infrastructure.

Furthermore, MidoNet is a completely distributed scale-out system, offering no single point of failure.

Architecture differences

But there is one thing that can be read between the lines. Although both vendors claim to offer SDN solution that is based on a distributed architecture is seems they interpret this in a different way.

It looks like that for Nicira the distributed attribute is mainly a property of its NVP cluster. NVP is a central place that holds all network (like flows, port, tenants, network ...) related information that is relevant to implement a control plane.

For Midokura the distributed attribute is a way they designed the whole solution they have. There is no single central component (in a form of a single or multi-server distributed cluster) that holds and manages all network information. It looks like that every Midonet node has limited knowledge but in the same time has enough information to perform tasks done normally by the control plane.

Comparison of the architecture types

Depending on the architecture type both companies facing different challenges that they need to solved. An interesting summary of types and problems that you may encounter can be found in this wiki article SDN deployment models. The article list following types that matching quite well above descriptions that should give us enough info to realize how different are both approaches:

• Symmetric vs asymmetric
• Floodless vs flood-based
• Host-based vs Network-centric

References

1. http://nicira.com/en/frequently-asked-questions
2. http://www.midokura.com/midonet/openstack/
http://www.midokura.com/for-enterprise-and-government/for-service-providers/
http://www.midokura.com/for-enterprise-and-government/

Challenge 11 script

The full summary of all posts for API Rackspace challenge can be found here:
Rackspace api-challenge summary

Challenge 11 script

Below is the output and results from script #11 from the api-challenge.

The script can be repeatedly run with the option -d otherwise it stops if any of the cloud objects it wants to create already exist.

    Challenge 11: Write an application that will: Create an SSL terminated load balancer 
    (Create self-signed certificate).
    Create a DNS record that should be pointed to the load balancer. Create Three servers 
    as nodes behind the LB.

    Each server should have a CBS volume attached to it. (Size and type are irrelevant.)
    All three servers should have a private Cloud Network shared between them.
    Login information to all three servers returned in a readable format as the result 
    of the script, including connection information. Worth 6 points


Depending on the obligatory -n options it will create cloud objects with predictable names.
Below is an example what objects it creates and what the naming conversion is.

# # python challenge11.py

    usage: challenge11.py [-h] [-v] [-d] [ -k key-key  ] [ -c cert ] [ -i image-id ][ -f flavor-id ] -n FQDN-name

    image-id -f flavor-id
        -h - usage help
        -v - verbose / debug output
        -d - delete objects if they existed in cloud before creating new one
        -k - certificate pritate key (see -c below)
        -c - public certificate ( see -k above)
        -n - FQDN name like www.myexample.com
        -i - specify image-id or use the default for Ubuntu 10.04
        -f - specify flavor-id or use the default for the smallest cloud server


# python challenge11.py -d -n www.challenge11.myrado.net

[01:04:17] Checked your cert/key pair www.challenge11.myrado.net.crt/www.challenge11.myrado.net.key, ok
[01:04:18] Deleting existing domain challenge11.myrado.net
[01:04:20] Checked your FQDN www.challenge11.myrado.net, ok
[01:04:20] Checked your DNS domains challenge11.myrado.net, there is none, ok
[01:04:26] Deleted existing cloud server www.challenge11.myrado.net-0
[01:04:29] Deleted existing cloud server www.challenge11.myrado.net-1
[01:04:33] Deleted existing cloud server www.challenge11.myrado.net-2
[01:04:33] Checked your existing cloud server www.challenge11.myrado.net-*, ok
[01:04:34] Checked your block images www.challenge11.myrado.net, there is none, ok
[01:04:36] Checked your lb www.challenge11.myrado.net, there is none, ok
[01:04:37] Checked your image id d4c7b93d-9f18-45dc-aa7c-3e3b126e3792, ok
[01:04:37] Checked your flavor id 2, ok
[01:04:38] Deleted existing network obj www.challenge11.myrado.net
[01:04:38] Checked your existing network objects www.challenge11.myrado.net, ok
[01:04:38] Checked your cert/key pair www.challenge11.myrado.net.crt/www.challenge11.myrado.net.key, ok
[01:04:39] Checked your FQDN www.challenge11.myrado.net, ok
[01:04:39] Checked your DNS domains challenge11.myrado.net, there is none, ok
[01:04:45] Deleted existing cloud server www.challenge11.myrado.net-1
[01:04:50] Deleted existing cloud server www.challenge11.myrado.net-2
[01:04:50] Checked your existing cloud server www.challenge11.myrado.net-*, ok
[01:04:50] Deleted existing block storage image  www.challenge11.myrado.net-0
[01:04:51] Deleted existing block storage image  www.challenge11.myrado.net-1
[01:04:51] Deleted existing block storage image  www.challenge11.myrado.net-2
[01:04:51] Checked your block images www.challenge11.myrado.net, there is none, ok
[01:05:04] Checked your image id d4c7b93d-9f18-45dc-aa7c-3e3b126e3792, ok
[01:05:04] Checked your flavor id 2, ok
[01:05:05] Checked your existing network objects www.challenge11.myrado.net, ok
[01:05:05] Building 3 cloud servers
.
.
.
.
[01:08:20] Building and configuring lb ...
.
.
.
.
.
.
.
[01:09:09] Building and configuring dns domain ...
[01:09:13] ----------------------------------------------------------------------
[01:09:13] vip name www.challenge11.myrado.net and ip 162.13.24.49
[01:09:13] cloud server www.challenge11.myrado.net-0 added to pool as 10.179.65.126
[01:09:13] cloud server www.challenge11.myrado.net-1 added to pool as 10.179.70.78
[01:09:13] cloud server www.challenge11.myrado.net-2 added to pool as 10.179.73.93
[01:09:13] ----------------------------------------------------------------------
Server # 0: ID 3227a512-3a1c-4f68-a82a-89d15ec74341 name www.challenge11.myrado.net-0 pub IP 95.138.173.80 priv IP 192.168.100.2 password SecretP@ss1
Server # 1: ID 662606f2-66a8-4281-8025-5161bf31754c name www.challenge11.myrado.net-1 pub IP 95.138.171.48 priv IP 192.168.100.1 password SecretP@ss1
Server # 2: ID f37d3551-60f5-40f3-92eb-4cbb1f7dbcfe name www.challenge11.myrado.net-2 pub IP 95.138.175.130 priv IP 192.168.100.3 password SecretP@ss1

References

1. https://github.com/rtomaszewski/api-challenge/tree/challenge11
2. http://docs.rackspace.com/loadbalancers/api/v1.0/clb-devguide/content/SSLTermination-d1e2479.html

Cisco Nexus NX-OS operating systems has a build in Python shell

The world is changing and Cisco doesn't want to stay behind. In its new NX-OS os that is targeting data centre and service provider customer they build in a python shell: Python API

More info about the Cisco Nexus can be found here:
http://www.cisco.com/en/US/products/ps9494/Products_Sub_Category_Home.html

Example:

 
switch# show clock                                           
23:54:55.872 UTC Wed May 16 2012

switch# python                          !-- Enter Python interpreter
switch# >>> cli("conf term ; interface loopback 1")          
switch(config-if)# >>> cli("ip address 1.1.1.1/24")          
switch(config-if)# >>> cli("exit")      !-- Exit the CLI interface mode
switch(config)# >>> cli("exit")                              
switch# >>> i=0                                              
switch# >>> while i<8:                                       
switch# ...   i=i+1                     !-- Composite command; prompt indicates more input
switch# ...   cmd = "show module %i" % i                     
switch# ...   r=clid(cmd)                                    
switch# ...   if "TABLE_modinfo/model" in r.keys():          
switch# ...     if r["TABLE_modinfo/model"] == "Nurburgring":
switch# ...       print "got a racer in slot %d" % i         
switch# ...                             !-- Empty input indicates end of loop
got a racer in slot 3                                        
switch# >>> exit                        ! -- Exit Python interpreter          
switch#

Openstack deployment options

Openstack wants to be as flexible as possible. It means that each service that is developed under the umbrella of Openstack has to be written in a modular way to accept different backend system depending on user preferences. From a high level point of view it means that a service need to have a well defined internal and external API, and the more specific technical implementation details are left for backend systems.

The Openstack specific public (external) API is one milestone for every project. If the API is not reach, flexible and useful enough it will not empower uses when consuming the service. On the other side, if the internal service level API is badly design it may cause issues for example when integrating with other components, exchanging messages, causing bottlenecks or hinder vertical scalability to expand system capacity.

Below is a list of deployment options for Folsom and Grizzly Openstack release.

• External API
•  XML
•  JSON

• Possible hypervisors for OpenStack Compute
• KVM
• Xen
• Citrix XenServer
• Microsoft HyperV
• VMware ESX
• LXC

• Possible OpenStack Block Storage drivers 
• Coraid
• EMC
• GlusterFS
• Huawei
• LVM
• NetApp
• Nexenta
• NFS
• Ceph RBD
• SAN/HP
• SAN/Solaris
• Scality
• Sheepdog
• SolidFire
• Storwize
• Windows
• Xenapi
• XIV
• Zadara

• Possible OpenStack Network backends 
• Big Switch
• Brocade
• Cisco
• Hyper-V
• Linux Bridge
• MidoNet
• NEC
• Nicira
• Open vSwitch
• PLUMgrid
• Ryu

• OpenStack Identity drivers
• LDAP
• SQL
• PAM
• KVS

What do you need to implement virtual network and build hybrid cloud

To build an infrastructure that can be used to host a hybrid cloud environments or to benefit from the flexibility that a virtual networking provides we need software and hardware components. Below are couple of links I found when researching on this topic.

VMware ESXi/vSphere

• vSphere Distributed Switch
• Overview of vNetwork Distributed Switch concepts

Citrix XenServer

• Overview of XenServer Distributed Virtual Switch/Controller and Troubleshooting Network Issues

Opensource Linux alternatives

• Open vSwitch (IBM introduction and good overview of the product Virtual networking in Linux )
• Virtual Square / vde switch - Example how to use it with Rackspace Private Cloud Installing Rackspace Private Cloud - KVM or with  Virtualbox
• Linux bridge

Microsoft Hyper-V

• Hyper-V Virtual Switch Overview in Windows 2012

Vendors

• bigswitch networks
• nicira 
• 10 Next-Gen Networking Startups Ripe For The Plucking

Introduction into tunneling protocols when deploying cloud network for your cloud infrastructure

Cloud network is a hot topic for cloud providers and hosting companies. In basic the concept should enable and allow tenants to create, manage and destroy network typologies on demand for the cloud servers by using cloud open API. That said, we want to allow a tenant to create an isolated virtual layer 2 network with its own IP subnet.

Before going into further details we have to realize that the problem isn't trivial to solve. The difficulty comes from a fact that the existing network that interconnects hypervizors hosts is not very flexible and adaptable for changes. That physical network architecture was build and tune to  allow to handle all traffic from all cloud VM across you cloud deployment. This represent its strength and limitation as it is not flexible enough when it comes to configure and create many isolated virtual layer 2 or layer 3 networks per single tenant. This is exactly the problem that the cloud network promises to resolve.

At the moment there isn't a single standard how to implement a cloud network. Instead, we have 3 different protocols that were proposed: VXLAN, NVGRE, STT [1].

All these protocols relay on the fact that the hypervisor hosts are interconnected  The implementation of the additional features is done by using tunneling mechanisms. All of them implement a L2 in L3 tunnels by using TCP, UDP or IP datagrams.

A short introduction and more explanation how this works can on the screenshots below that were taken from this video:  Video: Cloud Tunnels @ Cloud Mafia ( slies can be found here http://ifup.org/slides/cloud-tunnels/ )

References

1. VXLAN
2. NVGRE
3. STT