of a word. Many components in Windows Server 2016 Hyper-V share common code
with the Azure implementation, which does not use SCVMM, because, quite simply,
SCVMM was never designed to handle the scale of a mega-cloud like Azure. This
commonality with Azure is critical when you consider products such as Microsoft
Azure Stack, which brings Azure-consistent features on premises, and that means the
networking needs consistent capabilities and implementation. If you are familiar with
Azure networking, many of the components I talk about for SDNv2 will be familiar,
such as network security groups, software load balancer, user-defined routing, virtual
appliances, and more.
The rest of this chapter focuses on the Windows Server 2016 SDNv2 implementation
and not SDNv1. The only reason to use SDNv1 in Windows Server 2016 is for
compatibility with Windows Server 2012 R2 environments, or if you do not have the
Datacenter SKU of Windows Server 2016 (HNVv2 is not in the Standard SKU). Most
Hyper-V environments, however, leverage Datacenter.
Figure 3.33 shows the three planes as they relate to the Windows Server 2016 SDN
solution known as HNVv2 or SDNv2. Notice that although the data plane is still
implemented by Hyper-V, which is the encapsulation using VXLAN or NVGRE, the
control plane is a completely separate new component. The network controller and the
management can be PowerShell, SCVMM, or Microsoft Azure Stack (MAS). For
management, you need to pick one; for the most part, they cannot be used
interchangeably, although there are a few exceptions. If you are using MAS, you don’t
have a choice: MAS will be the management plane. If you are not using MAS, you have
a choice of SCVMM or PowerShell. If you are using SCVMM for other aspects of
Hyper-V management (which you should be), I recommend using SCVMM; however,
you could use PowerShell, which even has an express script to get the basics of SDNv2
deployed quickly. Whichever you pick, that is what you have to use going forward; you
cannot start the creation with PowerShell and then switch to SCVMM, or vice versa.
The exceptions I spoke of relate to SDNv2 deployments from SCVMM. Some features
of SDNv2 are not manageable by SCVMM (although SCVMM is aware of them, so this
will not cause problems), and in those cases PowerShell must be used for the
configuration, which includes features such as user-defined routing and port
mirroring. Network Security Groups (Access Control Lists, ACLs for traffic) can be
configured through SCVMM PowerShell but not through its graphical interface. I
don’t show it in the figure, but while the majority of the data plane is implemented via
the VFP in the VMSwitch (such as the actual virtual networks, ACLs, and quality of
service) there are also components such as the new software load balancer (SLB)
MUX (multiplexor) and gateway, which I cover later in this section.