In our previous discussion on virtual networking, we explained how virtual networks are replacing the need for virtual local area network (VLAN) configuration in data centers, and simplifying the grouping and isolation of servers. But we never really explained how the virtual networks are actually accessed, since they “ride” underneath physical networks. So, let’s take a deeper look.
First, Software Defined Networking rides on top of popular virtualization solutions like Hyper-V and VMware, and is provided by all of the major cloud vendors like Amazon, Microsoft, Rackspace and more. Regardless of which network virtualization solution you choose, they all have common elements “under the hood.”
For example, remember that we are trying to group servers on a common IP subnet. The first key element in virtualizing networks was the introduction of the virtual switch. The virtual servers will have virtual network interface controllers and those virtual NICs can be configured to connect to a virtual switch. So, the vendor will be providing a virtual switch in the background. Some vendors even make the virtual switch extensible or very configurable, while others just give you a basic switch. Just like a physical server connected to a physical switch with an IP address, the virtual server is connected to a virtual switch and has an IP address. Each time you create a virtual network, the solution creates a virtual switch in the background to provide the connectivity that the servers need for functionality.
Because each virtual network has its own separate virtual switch, the virtual networks are isolated or separated – even though the entire configuration could exist within a hypervisor management configuration and the virtual servers could literally exist on the same hypervisor physical host. As long as they are deployed on different virtual networks, they are disconnected from each other.
In the example below, the physical network infrastructure includes physical switches and routers/gateways. The virtual networks all show similar components. But remember, those are actually virtual switches and virtual routers/gateways running in the vendor software to provide the networking services necessary for those virtual machines. And, more importantly, they allow for us to provide the isolation – as in the case of the accounting folks – required by the business.
So, how is this isolation created while still allowing for connectivity? Well, encapsulation is the key. Virtual networking encapsulates the IP packet in a larger packet with the actual physical addressing necessary to deliver the packet to the correct host for eventual delivery to the correct virtual server. The two major players in encapsulation for the network virtualization space are Network Virtualization using Generic Routing Encapsulation or NVGRE (Microsoft, Dell, HP, Arista and Intel) and Virtual Extensible LAN or VXLAN (VMware, Cisco, Citrix, Red Hat, etc.)
Both essentially do the same thing, as shown below. The outer MAC and Outer IP Header get the packet to the correct host, which then examines the generic routing encapsulation (GRE) header for the virtual network ID so that it can deliver the payload to the appropriate virtual network. The inner MAC and IP header assure delivery to the correct virtual server.
This solution has many important ramifications. First, it allows the virtual networks – connected via virtual switches – to remain fully isolated and secure. Second, this solution scales to millions of virtual subnets since the GRE subnet identifier is 24-bit. Third, because of the isolation, a given IP subnet range can be used more than once without fear of routing loops. This is of particular interest to hosters, who cannot afford to tell customers which IP subnets they can and cannot use for their servers. These three virtual networks could all exist within a server virtualization farm or in a public cloud infrastructure. The virtual networks are logical networks, so behind all of this we still have physical switches, routers and gateways.
Now, what if we want some routing capability? What if the accounting servers need to communicate with, for instance, the marketing servers? What if we want to place the accounting servers locally, while we want the marketing servers placed in a public cloud? And if these servers are so isolated, how do we manage them? Stay tuned for the next discussion on extending these networks – or connecting them to other networks!
Reach out below for more information or to weigh in on the SDN topic.