In this post, we complete our review logical networks by looking at the implications of Network Virtualization and Externally Defined Networks on your logical network design. Note that in the latter case, the VMM administrator has no insight into how the network is constructed, nor do they have any visibility into the method of network isolation that has been applied.
This blog also marks the final posting dedicated to Logical Networks in SC VMM 2012 SP1. In the next and subsequent posts we change focus, moving on to discuss uplink and network adapter port profiles, port classifications and logical switches. Thanks for staying with us this far, hope you find the future posts just as useful.
Look forward to your feedback and comments.
Nigel Cain & Damian Flynn
In VMM 2012 SP1 you can isolate VM Networks using either traditional VLAN/PVLANS or, if you are using Windows Server 2012 as your host operating system, you can choose to implement Network Virtualization. The latter option addressing the scale limitations associated with a traditional VLANs solution as well as allowing tenants to “bring their own network” or otherwise extend their network into your environment. The diagram at the link below shows each of these options and acts as a reference for the detailed discussion that follows.
In this post, we complete our coverage of logical networks with a discussion of how to isolate workloads with Network Virtualization and externally defined networks.
Network Virtualization introduced in Windows Server 2012 Hyper-V provides administrators with the ability to create multiple virtual networks on a shared physical network. In this approach to isolation, each tenant gets a complete virtual network, which includes support for virtual subnets and virtual routing. Tenants can even use their own IP addresses and subnets in these virtual networks, even if these conflict with or overlap with those used by other tenants. Further, since virtual networks are defined entirely in software, it is not necessary to reconfigure the physical network (unlike VLANs and PVLANS solutions) to onboard or remove tenant networks or to make changes to reflect new business requirements. You can find more details on this approach at the link below:
In the example below, tenant A has two virtual subnets. A virtual router automatically created by Windows Server 2012 Hyper-V connects the two subnets for this tenant and allows virtual machines on each subnet to communicate with each other. Tenant B has a single virtual subnet but still has its own virtual router. The virtual subnet ID and Routing Domain ID shown in the diagram are used by Hyper-V host computers to differentiate network traffic and routing for each of the tenants.
Note: The virtual router does not exist on any one host. It essentially spans all hosts that contain virtual machines that are part of a particular VM network
When using Network Virtualization, your logical network design is relatively simple – create a single Logical Network for all of your customers that will be isolated from each other using network virtualization and configure the properties of the network to “allow new VM Networks created on this network to use network virtualization”.
As with before, you need to create network sites to define the VLANs and IP subnets that are to be associated with the Logical Network in each physical location. Assuming you specify VLANS in your network sites, the physical network must be able to route network traffic between them – VLANS in this case are used by the network administrator for ease of management and control broadcast traffic, they are not used as an isolation mechanism.
Note that An IP Pool must be associated with every single Network Site lined to the logical Network. The IP addresses from these pools, also known as Provider Addresses (or PA) pools, must also be routable between all of the Hyper-V hosts associated with the Logical Network.
You will need to create VM Networks to allow customer virtual machines to connect to and use the Logical Network and you should define a separate VM Network for each tenant, with each one of these VM Networks configured to isolate using Hyper-V network virtualization as shown below. You can also select No Isolation if you want to have the VM network provide virtual machines with direct access to the logical network – a configuration which essentially replicates the behavior found in SC VMM 2012.
Note: The radio button to enable isolation is only available when Provider IP Addresses pools have been defined for the IP protocol (IPv4 or IPv6) supported by the Logical Network as we discussed above.
You also need to define the IP Subnets for each VM Network, setting out the IP addresses that will be used by Virtual Machines connected to that Network. These addresses otherwise known as Consumer Addresses (CA) are completely separate from any other tenant and from the Logical Network and tenants can therefore use their own IP addresses and subnets in their virtual networks, even if these appear to conflict with or otherwise overlap with those used by other tenants. As discussed earlier, each tenant may be allocated multiple subnets as shown in the example below and if this is the case, the Hyper-V host will automatically create a virtual router to ensure that virtual machines on each of these subnets are able to communicate with each other.
Note: VMM installs a DHCP Virtual Switch extension on each host which it manages. If a tenant’s Virtual Machine uses DHCP to request an IP address, the extension will respond by offering an IP address from the IP pool that has been defined for the VM Network.
The Virtual Machine Networks discussed above have no external connectivity by default, meaning that virtual machines connected to them will only be able to communicate with other virtual machines on the same VM Network . A VPN Gateway device can be used to provide a VPN tunnel to a nominated external network or a NVGRE Gateway device to allow virtual machines on the virtual network to communicate with other networks in the local datacenter.
The remote and local networks options (highlighted) are greyed out in the dialog below as no gateway “provider” has been defined in the current installation of SC VMM. The first “production capable” NVGRE gateways that can be registered and configured for use with VM Networks are starting to become available. Microsoft is continuing to work with vendors in this space and is working to provide an “inbox” gateway in the next release of SC VMM..
To briefly summarize, create a single Logical Network for tenants that are to be isolated using Network Virtualization, configured to “allow new VM Networks created on this network to use network virtualization”, defining Network Sites and IP Pools for each location in which the network will be supported. If Network Sites Create VM Networks for each tenant and specify the IP Subnets that they will use. The net result should be a 1 to many mapping between the Logical Network and VM Networks created to support each tenant as shown below:
Externally Defined Networks
Network administrators can optionally configure network settings or capabilities such as logical networks, network sites and IP pools in third party (vendor) network management console and, through a virtual switch extension manager, import these directly into VMM. This approach allows network specialists to focus on and define the logical network, leaving the VMM administrator free to concentrate on the VM Networks and the services that are to be offered to end customers. In this context, the logical network becomes a “black box” to the VMM administrator, in that they can use networks imported through the virtual switch extension manager but have no insight into how the network is constructed, nor do they have any visibility into the method of network isolation that has been applied to a given network as shown below.
We note externally defined networks here only in the sense that VMM administrators need to work closely with their counterparts in the network team to make sure that a consistent model and design structure is being followed. Ideally, network administrators should plan and work out the network configuration in partnership with VMM administrators to ensure that both parties agree on naming conventions and standards for how to define the fabric. You can find more information on virtual switch extension managers in VMM and how to make use of them at the following location:
There are a number of reasons why you might need to create a Logical Network; to facilitate the movement of virtual machines and services across different physical locations, apply settings and capabilities to hosts or virtual machines that have specific network requirements or which require guaranteed service levels, to isolate network traffic or to facilitate access to networks that are configured through / managed by third party network management tools.
In looking at the Logical Networks we created in our example organization, there appears to be little or no requirement to isolate any of the Logical Networks we defined on top of the Datacenter Physical Network. That being said, we could easily justify using some form of isolation for front end web servers (assuming they were accessible from the public Internet) or where we have specialised servers and workloads that need to be isolated from others. As we discussed, you need to assess each logical network and determine what, if any, isolation methodologies you should apply.
The case for isolation for Logical Networks on the provider network is very clear however in that there are multiple customers running workloads on the same physical infrastructure. Where a given physical network or VLAN(S) has been dedicated to a particular customer, clearly no isolation will be required on the Logical Network – only that tenant’s traffic will exist on the network. However, in the case of shared networks, we need to consider which isolation method is best suited both to the customers’ requirements and is supported by the physical network. Network Virtualization clearly offers the most comprehensive and scalable solution but requires NVGRE Gateway Devices to allow virtual machines to communicate with networks in the same Datacenter or VPN Gateway devices to facilitate communication with a defined external network. VLAN/PVLAN isolation can be readily used, is well understood and is supported by most existing network hardware but has management issues at scale. The decision, ultimately, will be based on your business strategy, current and forecast growth patterns and how quickly /easily you can acquire and deploy network gateways that support NVGRE and software defined networking.
There clearly is no clear and simple answer to the question “how many Logical Networks do I need”, since the number will depend on your business requirements, your physical network and any constraints that exist in your physical environment. These blog post should go some way to helping you to identify the set of logical networks you need and the design that is right for your business.