need to be able to run on Hyper-V. They are deployed as virtual machines.
To function, however, these appliances need traffic to flow to them, which means that
the traffic routing must be changed. This is enabled through user-defined routing
(UDR), which enables the default routing of a virtual network to be modified. An
example is changing the gateway for a subnet to route to the virtual appliance instead
of the default gateway IP that is part of the virtual network, by providing an alternate
next-hop IP for the target address space. Note that the VMs still route to .1 (which
does not actually exist, as it’s routed as part of the VMSwitch functionality), but the
switch now knows to route that traffic to the IP specified as part of the UDR, which is
to the virtual appliance.
The other way to get traffic to a virtual appliance is with port mirroring. Port
mirroring enables packets matching a specific set of criteria to be duplicated in their
exact original form (even the source and destination MAC addresses) and sent to a
specified target, such as a traffic analysis virtual appliance. Port mirroring works for
both inbound and outbound packets and adds no latency or additional overhead of the
VMs whose traffic is being mirrored. The mirror is not part of the primary data path; if
the virtual appliance receiving the mirrored packets falls behind, it will not impact the
source VM. The mirroring is performed completely within the SDNv2 implementation.
Implementing Network Virtualization
In my 2012 R2 version of this book, I walked step by step through deploying network
virtualization and deploying a gateway. SDNv2, however, is different. There are three
primary management planes, and the method of implementing the virtual network,
gateway, SLB, datacenter firewall, UDR, and so on is different. It is also likely to
change over time, especially with SCVMM and Microsoft Azure Stack, so any specific
instructions likely would become antiquated quickly. Thus, for exact details, I
recommend reviewing the Microsoft documents, which are thorough. Nonetheless, I
want to cover the experience briefly when using the three management planes.
Remember, after you pick one, you must continue using it—you cannot switch—with
the exception of leveraging PowerShell to configure UDR and mirroring if using
SCVMM.
POWERSHELL
PowerShell cmdlets are built into Windows Server 2016, and a manual deployment of
every component is possible, which is documented at
https://technet.microsoft.com/en-us/library/mt282165.aspx. The better option,
however, is to use SDNExpress. SDNExpress is a script with accompanying files that is
downloaded from GitHub (so it can be updated). Execute the script, and after about 30
minutes, you will have a completely deployed SDNv2 environment including the
following:
Distributing required certificates