So, at this point Network Virtualization is turned on. Yea! Now we can use it. But we have to define and know a few things.
One thing we need is a Customer Route also referred to as a Routing Domain (an easier term to use I think, but I will stay consistent with the API terms).
A Customer Route can be described in a couple different ways. And how I describe this affects how I describe other features later on. But the easiest way to describe a Routing Domain / Customer Route is that it is a single Virtual Network.
A Customer Route is a routing container, or a routing domain. It can contain multiple virtual subnets. In the Windows Network Virtualization implementation a Customer Route should represent a single Customer or Tenant. And this customer can then define multiple VLANs within this route.
For example:
Say that you want to translate your current network into a Virtual Network. You have a flat topology using various subnets divided by VLANs.
IP addresses with no VLAN tags are client desktops and services they consume. VLAN 10 is Server management interfaces. VLAN 20 is application server to database server traffic. And so on.
If I was a Hosting provider using Server 2012. I would create one CustomerRoute for you. Within this Route I would establish at least two virtual subnets. One for application server to database traffic, one to isolate the management interfaces. Here is the hard part, how to handle the client to application server traffic. If the application server is exposed on a public IP then I wouldn’t add a virtual subnet. If the application servers are in your datacenter and I am hosting the database servers then I establish Network Virtualization rules so that your ProviderAddress(es) can reach mine (more on this later).
I could go on an on and as I move through the articles I hope the picture of possibilities and dependencies becomes clear.
Regardless what I do within a CustomerRoute, it is yours. It is a single routing container that is isolated from all others. Within this there needs to be at least one VirtualSubnetId and there can be many (more on that next).
Lets define one.
The Customer Route is defined using a GUID. This GUID is referred to as the RoutingDomainId. You have to derive one. Oh, you also need to know what the CA addresses of the VMs will be (the IP subnet that will be used within a particular virtual subnet).
So, lets establish our constants:
$customerName = "Atomic Widgets"
$routingDomainId = "{2ad17590-33b5-45fc-ad3a-90e5ff9b017f}" #Note the brackets in the string, that is important.
$vSubnetId = "5001"
$caDestinationPrefix = "192.168.104.0/24”$caNexthopGw = "0.0.0.0"
What I have done here is that I state that VirtualSubnetId 5001 contains VMs with IP addresses within the 192.168.104.x class C subnet.
I then need to define this CustomerRoute on each Hyper-V Server where there will be VMs participating in this CustomerRoute / Virtual Network.
New-NetVirtualizationCustomerRoute -RoutingDomainID $routingDomainId -VirtualSubnetID $vSubnetId -DestinationPrefix $caDestinationPrefix -NextHop $caNexthopGw -Metric 255
If I did no more than add this Customer Route, and then created VMs on this Hyper-V Server with the VirtualSubnetId of 5001 I will have the equivalent of my own (local) isolated VLAN. The traffic is 100% local to my Hyper-V Server even though this is an External Virtual Switch. It takes the establishment of some additional settings and routing rules for the VM traffic to exit the virtual switch and know where to go.
Actually, I don’t even need to set the Customer Route to have my own private VLAN 5001 within one Virtual Switch. I really only need to set the virtual subnet id on the virtual NIC of the VMs.
Okay, enough of that, lets go back to my Virtual Network that is my CustomerRoute / RoutingDomain…
What if my Virtual Network has multiple VirtualSubnetIds (multiple little internal VLANs)?
Well, you simply add additional CustomerRoute definitions. One for each virtual subnet id.
What does this look like if there are multiple virtual subnets?
PS C:\Users\administrator.BRIANEH> Get-NetVirtualizationCustomerRoute
RoutingDomainID : {99B3D49E-9281-4C8E-81A0-8DC2257FB7EE}
VirtualSubnetID : 7636197
DestinationPrefix : 192.168.4.0/24
NextHop : 0.0.0.0
Metric : 9RoutingDomainID : {99B3D49E-9281-4C8E-81A0-8DC2257FB7EE}
VirtualSubnetID : 9889980
DestinationPrefix : 192.168.3.0/24
NextHop : 0.0.0.0
Metric : 9RoutingDomainID : {99B3D49E-9281-4C8E-81A0-8DC2257FB7EE}
VirtualSubnetID : 4139103
DestinationPrefix : 192.168.2.0/24
NextHop : 0.0.0.0
Metric : 9RoutingDomainID : {99B3D49E-9281-4C8E-81A0-8DC2257FB7EE}
VirtualSubnetID : 11657562
DestinationPrefix : 192.168.1.0/24
NextHop : 0.0.0.0
Metric : 9
The same RoutingDomainID is used, but each subnet is defined with its destination prefix(s). There will be more on that later.
*Just a note, I am working on a good graphical way to describe this all.
No comments:
Post a Comment