Okay so it has been a while since I had something I wanted to really post, but I have been trying to find something useful to talk about regarding Nicira NVP specific use cases. Next week I will be presenting at the New England VTUG, and I wanted to share a little bit about something that we will be talking about in the way of Layer 2 Gateway Use cases. First let me explain what a Nicira NVP layer 2 gateway a little more in detail.
The Nicira Layer 2 Gateway
The component of the infrastructure is a device that lets you extend the layer 2 subnets from pretty much anywhere into the Nicira Logical space. What does this really mean? As an example in most cases in your cloud you need to give the tenant a different IP subnet within the cloud than they may have in their premise datacenter. What if you could actually extend their network into your cloud, thus allowing them to migrate applications on that subnet seamlessly without having to change IP addresses on the applications. Does this sound at all like something that would be useful? Enter the Nicira NVP Layer 2 Gateway. Below is a diagram I will explain, and you will see again next week.
Understanding The Logical Diagram
First you need to understand that the diagram depicts both the physical and the logical spaces, even though technically it is a logical diagram, but stick with me for a minute. The bottom right is the logical representation of the physical network where VLAN 24 and subnet 10.150.24.xxx exists. On that network there is a Database server and a couple Virtual Machines in the premise datacenter
The upper left is the logical diagram representing what I refer to as the Nicira NVP “Logical Space” where we have created a logical switch using the API. On that logical switch are four virtual machines running on hypervisors in the provider’s cloud. So far so good right? Where this gets cool is the logical port on the logical switch shown as VLAN 24 is not only a representation but a real connection into the logical switch. The Layer 2 Gateway is connected on the Logical Switch and tagged for VLAN 24. Once this connection is made and the Layer 2 Gateway can establish STT tunnels to the service node and/or the other transport nodes, we can assign 10.150.24.xxx address to the virtual machines in the provider’s cloud.
If you are starting to see the light here, this is just one of the amazing things Network Virtualization brings to the table, at least from my perspective. The coolness factor on being able to move workloads without changing IP addresses is pretty huge.
Connecting the Layer 2 Gateway
This can be done a number of ways and in fact I am experimenting with some, but the two most common are pretty basic and easy to understand
- There is already direct IP Connectivity between the two sites so the Layer 2 Gateway can reach the hypervisors and the service node
- The Layer 2 Gateway can establish an IPSEC STT Tunnel directly to a service node exposed in a DMZ, and the service node can act as a relay service
Once either of these are established the virtual machines in the cloud provider can essentially be connected with the same IP addresses as the rest of the VLAN and connect to the database and other machines without NAT routing using the STT tunnel. Pretty cool so far right?
The Use Cases
This particular method of connectivity is obviously somewhat unique to Nicira NVP, but clearly there is a few very good use cases both for provider clouds as well as enterprises. One of which I will talk about and demo next week, provided the lab stays online. The others I am working on digging deeper into with my team mates to get more configuration details about how they work. The current use cases I see are:
- Cloud customer on-boarding
- Physical to virtual migrations
- Enterprise Corporate acquisition on-boarding
The one I will be showing and talking more about next week is the last one using both vSphere, Nicira NVP, and VMware View to solve a rapid desktop on-boarding solution for corporate acquisitions without the need for establishing VPN’s or waiting for other difficult network configurations to happen. It will tie into the PowerCLI work done by Andre Leibovici that he posted about a little while ago. I hope to work with him more on refining the scripts we are using as well for future use.
More To Come
I hope this quick little post has gotten you thinking, or maybe even saying….”Wait, What the…?” If so that was my intention. Please let me know what you think and I look forward to presenting this more next week and refining these use cases for further explanation. Have a great New Year and welcome back to the first full week!
I am keeping this short on purpose so I can try to make it digestible over time. It has taken me quite a while to wrap my own head around this and I want to make sure if this is also new to you, it is easy to understand. If this is something you have already seen, please share your comments, and if this is new to you please tell me your thoughts as well.