An Introduction to Software Defined Networking with Windows Server 2016

Welcome to Microsoft Mechanics.
Coming up, we look at the new software defined networking capabilities in Windows Server 2016.
We'll show you how you can use SDN to dynamically create, secure, and connect your network
to meet the evolving needs of your apps,
speed of the deployment of your workload,
and contain security vulnerabilities from spreading across your network.
All while reducing your overall infrastructure cost.
Microsoft Mechanics
I'm joined by Greg Cusanza from the Software-Defined Networking Team.
Welcome.
Thanks Matt, it's great to be here.
Software-defined Networking has been talked about for a while, but what are we really trying to solve for here?
Well apps are innovating at a rapid pace.
And often the complex physical infrastructure can't meet the needs of the changing apps.
So rather than solve for this within the constraints of the physical network,
with SDN we virtualize the network and all of its services
so that apps are deployed faster and at a lower cost.
Does SDN work with your existing physical network?
Yes, it actually works on top of your existing network infrastructure.
Here's how.
I've mentioned the complexity of the physical network.
Its complex because every application has a different set of resource requirements.
And, they have intertwined network dependencies.
With SDN, we can reduce the complexity by creating a virtualization layer on top
of the physical network.
So that requirements of each of your applications are met consistently
and independent of the configuration of the physical devices.
This makes your applications run more reliably and more securely.
Even if you grow your physical network infrastructure,
you don't have to worry about breaking the apps.
And your apps can immediately take advantage of new resources.
So what does this virtualization layer you mentioned, consist of?
Well I mentioned before that it comprises the network and services.
All of this is completely automated without needing to configure underlying physical infrastructure.
Can we take a look?
Absolutely.
Let's use a two-tier web application as an example.
So in this illustration,
you'll see that it's going to be a public-facing application.
So it needs to be isolated from the rest of my network
while maintaining its internal connectivity.
My users needed to be highly available to be able to scale out as load increases.
So we need a load-balanced virtual IP to spread across multiple instances.
It needs connectivity to outside of its isolation for Active Directory joining,
or remote desktop access.
And of course it needs to be secure.
So let's start with a blank slate.
In this slate, i'm going to create a Virtual Network.
The most basic unit of isolation.
Then within the network, I'm going to add a Virtual Subnet for my web servers.
And a Virtual Subnet for my file servers.
Finally, I'm going to connect the actual VMs
to the appropriate subnet for the role.
Great.
So let's go to my script and we'll do this in real-time.
Normally we'd have to do this on the physical router,
but here in this powershell script
we're going to first create the objects that represent the virtual network in the first section of the script.
Then we'll add two Virtual Subnets.
Then, the last line applies these objects to create the network.
I'm going to run it right now.
This first script just creates all of those assets?
Exactly, and you can see it only takes a second or two to run.
And then the network's been created.
Now the next step is to attach the VM to this network that I just created.
Here I have a helper function that makes it a little bit easier so I can call it over and over again.
I'm going to call it once for each of the VMs that I'm going to attach to this network.
Two web servers and two file servers.
Exactly.
Let me go and do that.
So now that it's created we can switch over to the first web server VM.
And I can show basic connectivity here.
I do an IP config to show that I got an IP address.
i'll do a ping to show that I have basic connectivity to another VM.
And just to make sure that we really have connectivity,
I'm going to open up Internet Explorer
and connect to the web server on that second VM.
Great, that was incredibly simple, but what are some of the other
important components within the Virtual Network environment?
Well we've added one already.
So you saw me create two subnets.
In order for these two subnets to be able to talk to each other,
distributed routing is added automatically to connect the two subnets together.
Another service that is in SDN Windows Server 2016 provides
is the software load balancer.
It's based on the load balancer technology in Azure.
Now it's included in Windows Server 2016 data center.
So load balancing is critical to cloud workloads,
so they can take advantage of the elasticity of the Cloud?
Right, let me show you how we do that.
So the first thing that we're going to do in our network is we're going to add a virtual IP.
This will load balance to the two web server VMs that I just created.
Later on if we decide to add a third VM,
the load balancer will automatically use it, too.
Let's jump back into the script.
What I'm going to do here is, first in the script
I'm going to create a FrontEndIPConfiguration.
That's what's going to contain the VIP for the application.
Then I'm going to create a BackEndAddressPool to contain the VMs.
And then create a set of LoadBalancingRules
that will kind of tie the two together on port 80 for my web request.
You mentioned VIP being the virtual IP?
Yeah exactly, that's the one address that the clients of the application use to connect in.
One command will make it happen, so let's run this script as well.
There we go.
So we created the load balancer configuration.
The next thing we need to do is add our VMs to it.
So we have to do this once for each of the web server VMs.
So I add VM #1 and then I add VM #2.
Let's run that.
This will also run for just a second or two.
Now that it's done we can go in and we can actually check to make sure that it's actually working.
So I put a uniquely colored webpage on each of the web servers.
So each time I refresh now you'll see a different color comes back.
It's the best way to show that were actually load balancing.
Load balancing across those two VMs?
Exactly.
Then, I can go to the actual app that I've deployed.
Very popular blog.
Yeah, thanks.
So very few applications are as simple as this.
So what happens if I've got a database workload that is outside of my Software Defined Network?
Yeah, for that we have what we call multi-tenant Gateways.
There are three modes that the Gateway works in.
The first is basic layer 3 forwarding for routing between Virtual Networks and VLANs.
The next is site to site VPN for connecting
the virtual network directly to remote sites.
And then there's GRE tunneling
for maintaining address base isolation within your data center.
You can combine these to achieve the level of connectivity that you need.
I can show you my script again
by going back to the demo environment.
For this application we're going to connect our virtual network to our VLAN
with L3 forwarding.
Here we're starting in the web server VM.
This time we're actually trying to go out from the network.
We started a ping to show that it doesn't yet have outbound connectivity.
So, out from the virtual networks to a physical network?
Yes exactly.
So now, let's go back to the script.
I'm going to run it right away so we can get the settings applied.
And then while the settings are actually propagating out to the gateways,
I'm going to take a little bit more of a look at this script.
So up top I have the virtual network.
And I have the physical network which contains the VLAN that I'm going to be connecting to.
Then I take the two and I create a virtual gateway on the virtual network.
Then I configure a connection to the VLAN that I mentioned.
That VLAN was created by my network admin for me to be able to connect to it.
So you would need to coordinate with the networking team to make this a reality?
Yeah that's right, in this case I do have to do that.
But, I also have network address translation available as an option that I could use if I want.
A Network Address Translation would make it so that I could use a completely
private address space for my VMs
and not have to talk to the network admin in order to get that address space allocated to me.
The SDN environment would handle the translation from one to the other.
Let's see now if the settings have been applied.
You can see the ping is still timing out.
And within a second or two.
There we go, so it's now established the connectivity from within the Virtual Network to the outside.
So I can go in and I can do a trace route
to see that it goes first to the distributed router that I mentioned,
then to the virtual gateway that I just created,
the physical gateway,
then onto my destination.
I now have the full ability to send traffic in and out of the Virtual Network.
From the physical world into the virtual world?
Yeah exactly.
Just like it was a real network.
Awesome, so establishing connectivity like this surely opens up your network
to good traffic and bad traffic, does it not?
Yeah, it's the risk customers face every day when they deploy an application.
The first way to address this is using the distributed firewall
to apply the security rules to the virtual subnet,
so that every VM in the subnet gets the right set of rules automatically.
Even if we add another VM at a later time,
it will get automatically the right set of rules.
So we can go back to the script and I can show you this as well.
So in the script I have a helper function to make it easy to define the rules over and over again.
We call the helper once for each rule.
First defining the inbound rules.
And then we define separately the outbound rules
that will then allow it to talk to the file server.
Let's run this.
We save into what we call an Access Control List.
And then the last thing left to do is actually apply it to the Subnet.
That was just one quick script that ran there.
Now we've put it on our first subnet where the web servers are located.
Now let's go to one of the web servers and test the results.
So I can do an ipconfig/flesh to make sure we do fresh DNS request.
So I do a ping sofs.
You can see that I got an address for that machine,
but the ping itself is blocked as we would expect
because I created the rule to block that.
I'm now going to the file explorer,
open up the UNC path to my file server.
Because the file servers is where my web pages are stored
I need to be able to get to that.
That traffic is allowed.
After a few seconds here it went to it's authentication.
You see it gets in and I can go down,
double-click that and you can see the files that are in that file share.
I block the traffic I didn't want, but allowed the traffic that I did want.
So I can go up and show that inbound that the web server is still working.
Great, and all very configurable very granular settings within PowerShell?
Yeah, exactly.
So this will do a lot to reduce the attacked servers
and prevent attacks from spreading within the network.
But, what if I'm already depending on
network appliances or existing security technology from an external source?
Yeah earlier we discussed how a distributed routing
gets added automatically to connect the subnets.
You have control over that router.
In order to be able to send traffic to any virtual appliance connected to the Virtual Network.
As long as that appliance runs on hyper-v,
we call this feature "U-defined routing or UDR".
So we're going to utilize U-defined routing to insert a Linux virtual appliance in our network for traffic analysis.
So we'll go back to the script, here.
And so it's as simple as creating a routing table,
specifying the routing table in the Virtual Subnets where you want it applied.
In this case our route rule says to send any traffic for the 192.168 Subnet
to the virtual appliance at the .254 address.
We're then applying that route table to our two Subnets.
Before we run, let's bring up the Linux appliance on the right.
You can see that it has some basic background traffic that it's sending itself.
But now soon as we run the script watch what happens on the right side.
It'll take a second to apply and there you go.
Now you can see all the traffic that's destined for that .2 subnet
is now going through this Linux VM to be able to process, forward on, and do whatever it wants to it.
It has full control over that now.
And Linux runs great on hyper-v as we know?
Linux and BSD as well.
Great so there's lots of security vendors out there with hyper-v appliances
But there's also appliances that aren't just for security, can I use those as well?
Of course, user-defined routing isn't just for security.
Pick your favorite load balancer, your favorite WAN opitmizer, VPN, you name it.
If it runs on hyper-v as a VM, they can use it in the virtual network with UDR.
So in summary, we saw SDN provide all of the network resources that our two tier app needs,
With all the required security.
That's right and what's more, we did it all with the SDN capabilities
included in Windows Server 2016 Data Center.
We did not have to touch a single physical device in this configuration.
So how do you recommend people get started?
So need to be on hyper-v in Windows Server 2016 Data Center.
But, you can learn more about how to plan and implement into your deployment at the link below.
Thanks Greg for joining us and helping us learn a little more about Software-Defined Networking.
And of course, keep watching Microsoft Mechanics for the latest in tech updates.
Bye for now.
Microsoft Mechanics
http://ift.tt/1hXiZYI

An Introduction to Software Defined Networking with Windows Server 2016

Latest Posts