Skip to content 
This is the first of five posts on The 5 Tuple Challenge.
Multi-tenancy enables cloud administrators to optimize utilization of their networking assets and provide cost effective solutions while achieving economies of scale. However, Multi-tenancy often presents unique challenges for the cloud network administrators. Each tenant’s network needs to be isolated from other tenants and tenants often need to have their own private address space.
There are many network virtualization technologies such as VLANs to provide isolation at Layer 2, VRF-Lite, Firewall contexts and Load balancer contexts to provide isolation at Layers 3-7. In some cases, Layer 2 isolation is sufficient, but in other cases, providers need to implement a combination of these isolation approaches based on the services they want to offer and resources they have in their infrastructure.
Each tenant’s network needs to be isolated from other tenants and tenants often need to have their own private address space.
Hence, multi-tenancy is very difficult to implement. It is even more complicated in cloud deployments where tenants will come and go. A typical administrator spends 1 to 2 weeks to on-board a tenant. It takes more than 200 CLI commands or API calls and requires deep CCIE level expertise to understand the various services such as firewalls, load-balancers, access gateways, VRF, VLAN, Virtual Access, Port Profiles, etc.
A typical administrator spends 1 to 2 weeks to on-board a tenant. It takes 200+ CLI commands or API calls and requires deep CCIE level expertise.
The problem is more complex in heterogeneous deployments. Physical and virtual network devices – from Cisco, Juniper or F5 – all have different OSes, different features and different notifications. Despite these differences, Cloud administrators need to ensure isolation. To make matters worse, each service has its own management application. This complexity often results in costly mistakes due to manual configuration.
In summary, Multi-tenancy is very effective, but very difficult to implement. What we need is an orchestration solution – a solution that can thoroughly understand the underlying heterogeneous infrastructure, and then provide a normalized view of network resources including capacity and capabilities that can then be bundled into network services.
With nCloudX, it doesn’t matter if your devices are physical or virtual, from Juniper or Cisco or running IOS or NXOS. All of these are treated as network resources and customers will be presented with a network service catalog. Once they order a service from this catalog, nCloudX will orchestrate the service, adhering to a secure multi-tenant architecture.
In my next blog, we will discuss the specific challenges with capacity optimization.
I look forward to seeing you at Cisco Live London 2013.
– Srini Beereddy, January 22nd, 2013.
