Category Archives: cisco

Hybrid cloud recent solutions from Microsoft and VMWare – 2 different ends of the hybrid cloud spectrum

Public clouds have grown tremendously over the last few years and there are very few companies who do not use public cloud at this point. Even traditional enterprises with in-house data centers have some presence in the public cloud. I was looking at Amazon’s re:Invent conference details and I was amazed by the number of new services and enhancements that were announced this year.  It is very difficult for private clouds to keep up in pace with the new features of public cloud. There is no doubt that public clouds will overtake private clouds in the long term. Private clouds still have a wide deployment and there will be enough use cases for quite some time to deploy private cloud. The use cases includes regulated industries, compute needed in remote locations not having access to public cloud and some specialized requirements that public clouds cannot meet. For some enterprises, private cloud would make more sense from a costing perspective. Having hybrid cloud option is a safe bet for most companies as it provides the best of both worlds. I saw 2 recent announcements in hybrid cloud that captured my attention. One is Azure stack that allows running Azure stack in private cloud. Another is VMWare cloud on AWS that allows running entire VMware stack in AWS public cloud. I see these two services as 2 ends of the hybrid cloud spectrum. In 1 case, public cloud infrastructure software is made to run on private cloud(Azure stack) and in another case, private cloud infrastructure software is made to run on public cloud(Vmware cloud on AWS). In this blog, I have tried to capture more details on these 2 services.

Hybrid cloud

There are predominantly 2 options currently to run Private cloud. 1 option is to use vendor based cloud management software along with hardware from same vendor. Cisco UCS is an example in this category where customers get to use UCS servers integrated with networking and storage along with management software from Cisco. This provides a tightly integrated solution. Another option is to use Openstack as a cloud orchestration system and use server, networking and storage hardware from any vendor. Both these kinds of solutions works well in private cloud. For enterprises having private cloud, there always are use-cases where few services makes more sense in public cloud. A classic example is a development team using public cloud for 1 of their development projects for agility reasons. Once the development is complete, operations team has a choice to deploy the application in either private or public cloud. There is also the use case where current applications deployed in private cloud needs to be scaled by using public cloud for elasticity reasons. In either of the cases, we need a solution that allows easier migration of applications along with their policies between the private and public cloud.

Following are some important requirements of hybrid cloud:

  • Having a common management software to manage public and private clouds.
  • Ability to move applications seamlessly between the clouds.
  • Secure connectivity between the clouds.

Microsoft Azure stack

Azure stack is a hybrid cloud platform product from Microsoft that allows managing the private cloud with the same Azure public cloud software stack.

Following picture from Azure stack link shows the components of Azure stack:


Following are some details on the solution:

  • Azure stack takes some of the components of Microsoft Azure public cloud to manage private cloud. To start with, Azure stack will support limited services in private cloud when compared to Azure public cloud.
  • Cloud infrastructure layer is hardware and basic system software for running compute, storage and networking. In the initial release, Azure stack will be provided as turnkey integrated solution with hardware integrated from Dell, HP and Lenovo. It looks like more vendors will be added in future. The reason to support limited vendors is to achieve tight integration and simplify the deployment solution.
  • Azure infrastruture layer sits on top of cloud infrastructure and the Azure services layer interacts with Azure infrastructure layer.
  • The first technical preview release was done in early 2016 and the second technical preview release was done in late 2016. GA release is planned middle of 2017.
  • The entire Azure stack runs currently on a single node. The plan is to make this distributed in future.

Following are some of my general thoughts on Azure stack:

  • Public cloud providers typically did not focus on private clouds since that would eat into their pie. This is a good move by Microsoft to facilitate hybrid cloud and the gradual move to public cloud.
  • The pricing and licensing model of Azure stack is not clear. Since the plan is to have a turnkey integrated solution with few vendors, there has to be some form of licensing agreement with multiple parties.
  • It is not clear how the OEM vendors providing cloud infrastructure can differentiate their solutions.
  • Having a restricted cloud infrastructure vendor list will make this solution not useful for private clouds using legacy hardware. It will be good if the cloud stack can provide common API that can allow any hardware vendor that supports the API to be managed by the Azure stack cloud software. To some extent, Openstack is following this model. It will be good if Azure stack can do the same so that there is no restriction on the vendor list.
  • AWS and Google cloud have not introduced private cloud management solutions till now. As mentioned earlier, there are use cases where access to public cloud is not possible and private cloud would be a better fit. AWS greengrass IoT solution is the closest private cloud like solution from AWS that I have seen where local IoT resources are used for compute when needed.

VMWare cloud on AWS

This solution allows the entire VMWare virtualization stack(including compute, storage and networking) to run in AWS public cloud. The solution is provided by VMWare and is a joint collaboration between VMWare and Amazon AWS. For enterprises using VMWare stack to manage their private cloud infrastructure, they can use the same software stack when moving some of their services to AWS public cloud.

Following picture from VMWare link shows the components of this solution:


Following are some details on the solution:

  • All the core components of VMWare stack including Vsphere, Virtual SAN, NSX, ESX and Vcenter runs in AWS infrastructure.
  • AWS typically uses Xen hypervisor for virtualization and VMWare uses ESX for virtualization. To do this integrated solution, ESX runs in AWS baremetal. There is no Xen hypervisor in this integrated solution.
  • Vcenter is used for management across on-premise as well as in AWS. In 1 of the joint demos, VMWare shows seamless VM migration between on-premise cloud and AWS cloud.
  • VMs deployed in AWS public cloud can use all the AWS services like storage, database, analytics etc. This makes this solution very attractive.
  • This service will be operated and managed by VMWare. Both AWS and VMWare have made changes to their stack for this integrated solution.
  • The solution is currently in Technical preview phase and general availability is expected middle of 2017.

Following are some of my general thoughts on this VMware cloud on AWS solution:

  • VMWare has tried different strategies to get a foothold into public and hybrid cloud. vCloud hybrid service was 1 of their unsuccessful attempts earlier on this. This solution will benefit both VMWare and AWS, the bigger benefit lies for AWS.
  • AWS has not sold baremetal servers till now. There are companies like Packet that provides baremetal servers. There are use cases for baremetal like non-virtualized scenarios or pure container based solutions where baremetal servers would help. It will be interesting to see if AWS would sell these baremetal servers in future. It is not clear why AWS has not provided bare metal servers till now, 1 possible reason could be that it would take away some of its differentiators.
  • Microsoft has a private cloud enterprise solution with hyperv and public cloud solution with Azure public stack. Microsoft can provide a similar integrated solution that allows Microsoft’s private cloud stack to run on its Azure public cloud. It is not sure if Microsoft will venture into this.


Both solutions described above are good hybrid cloud solutions that eases movement to public cloud. Both these hybrid cloud solutions are favorable more for public cloud rather than private cloud. Even though these solutions helps private clouds temporarily, long term benefits lies with public cloud. It will be good to have cloud management software that is cloud agnostic so that multiple cloud vendors can be used and there is no vendor lock-in. Terraform and Cliqr are some solutions catered to this space.


Contiv Networking policy Hands-on

Contiv is an Open source project driven primarily by Cisco for policy based networking, storage and cluster management for containerized applications. In this blog, I will cover some of the hands-on stuff that I tried with Contiv Networking. I used the sample examples provided in Contiv documentation as starting point. For Contiv networking basics, you can refer to my previous blog here.

Contiv environment

I followed the “Contiv getting started” guide to setup a two node Contiv cluster with Vagrant. I started the cluster in Packet baremetal cloud. Contiv netmaster runs in one of the nodes, Contiv netplugin is installed in both the nodes.

git clone
cd netplugin; make demo

Following command shows the 2 node Vagrant cluster:

root@contiv:~/netplugin# vagrant status
Current machine states:

netplugin-node1           running (virtualbox)
netplugin-node2           running (virtualbox)

Following are the business details of the sample application that I have used in this blog:

Continue reading Contiv Networking policy Hands-on

Contiv – Policy based networking for Containers

Contiv is an Open source project driven primarily by Cisco for policy based networking, storage and cluster management for containerized applications. In this blog, I will focus on how Contiv does policy based Container networking. In the next blog, I will cover some hands-on stuff that I tried with Contiv.

Container Policy

Policies have become critical to control the business logic in a Cloud environment. There are 2 ways to describe policy. In imperative model, policy is defined in terms of how the end goal is achieved. For example, we specify the filters and actions with Openflow protocol that achieves end goal of packet handling and this is an example of imperative model. In declarative model, policy is defined in terms of the end goal and it gives flexibility to the end-system to implement the policy in different ways. Congress and Opflex are examples of declarative policy model. With declarative model, it is possible to specify the policy in terms of business logic without specifying implementation detail. For example, the business logic can say that web container should not talk to database container. The implementation of this business logic can be achieved by having an iptables rule or by having a hardware tcam rule to block specific ports. In a cloud computing world, policies can be defined for compute, storage and networking. Both Containers and VM needs policies to implement business logic. Following are examples of some policies that can be applied to applications deployed in Cloud using either VMs or Containers:

  • Authorization policy – Specifies tenants and their privileges.
  • Resource usage policy – Specifies resource constraints for tenants, containers and VMs.
  • Application access policy – Specifies containers that can communicate to each other and containers that are exposed to outside world.

Contiv Networking

Contiv Networking project provides policy based networking for Docker Containers. Following are some details on Contiv Networking:

Continue reading Contiv – Policy based networking for Containers

Microservices Infrastructure using Mantl

Mantl is an Open source project from Cisco and it provides an integrated solution to deploy distributed Microservices. Any company deploying Microservices has to integrate different components before the solution becomes production ready. Mantl makes it easier by integrating the different components and providing the glue software that integrates the components. In this blog, I will cover the following:

  • Distributed Microservice infrastructure components and the need for Mantl.
  • Mantl Architecture.
  • Mantl installation using Vagrant
  • Mantl installation using AWS public cloud

Microservices infrastructure

Following are typical components in Container based Microservices infrastructure:

Continue reading Microservices Infrastructure using Mantl

Netconf Python ncclient

In my earlier blogs, I had covered basics of Netconf and Yang and how to use Netconf to configure Cisco devices. Recently, I came across this Python ncclient library that simplifies the configuration/monitoring of Networking devices that supports Netconf. Using ncclient library, we can programmatically configure and monitor devices using Netconf. I also found out that Cisco Openstack Neutron plugin uses ncclient library to program the Nexus switches.

I have used Cisco Nexus 3k switch and Cisco VIRL NXOS switch for the examples in this blog.

In my earlier blog on configuring Cisco Nexus devices using Netconf, I covered the following netconf requests.

  1. “get” request using filter to display configuration.
  2. “edit-config” request to change configuration.
  3. “exec-command” to execute raw CLI requests.

In this blog, I will cover the above same tests using Python ncclient library. Even though the examples below are tried from Python interactive shell, the same can be executed as a Python program as well.

First step is to import the ncclient library and create a connection:

Continue reading Netconf Python ncclient

Connecting NXOS VIRL instance to Arista vEoS

In this blog, I will cover the steps that I did to connect Cisco NXOS VIRL switch instance to Arista vEoS switch instance. We can connect any Cisco switch simulated in VIRL, I just picked the NXOS switch type. CML/VIRL supports majority of Cisco switches as VM as well as few external switches from Juniper, Vyatta. External virtual or physical switches can be connected to Cisco switches running inside VIRL using VM Networking magic. I just think it is cool to connect Virtual devices, try out real-time network configurations and see how the device responds.


  • Install CML/VIRL using the procedure here.
  • Install vEoS using the procedure here.
  • I used VMPlayer to run VIRL and vEoS. Connecting across Virtualbox and VMWare player is little painful.

Following is the network I created:

Continue reading Connecting NXOS VIRL instance to Arista vEoS