In Part 1 of this article, we discussed how you can route between VMs on same host using networks connected to “Internal” virtual switch. Now let’s look at how to route between VMs when your lab consists of more than one hosts. Obviously, what I am going to cover isn’t the only way to do this but is one of many. I can certainly go on an on about all other options but I am trying to show the simplest possible one.

Lab Setup

For this lab, we are going to assume a small network where you have two Hyper-V hosts connected via single switch. We aren’t going to be fancy with VLANs on the switch or dual connections on host. Single cable to each host and flat network separated only logically so you won’t be able to talk to VMs on different subnets without routing configured.

I have setup Windows Server 2012 R2 hosts for this article. I have also created two VMs that will go on two networks. These are same VMs, except, they now reside on two separate hosts as well as on two separate network subnets. The VM in “New York” is called NY-S1. The VM in “Europe” is called EU-S1. Here’s what the IP addressing looks like:

Staying with the theme of saving resources and using Hyper-V host as router, we are going to do the same here. Since we have two hosts, pick one that you will use as router.

Host Configuration

As we did in previous article, let’s configure our Windows Server 2012 R2 host first. To keep this simple, I will use elevated PowerShell and run the following:

Set-ItemProperty -Path HKLM:\system\CurrentControlSet\services\Tcpip\Parameters -Name IpEnableRouter -Value 1

There is going to be no response from PowerShell except it will return you back to prompt. If you get something back, most likely it would be because you didn’t elevate PowerShell or you don’t have administrative permissions to edit that registry key.

Since we are changing parameters for TCPIP service, the change won’t be effective until after a reboot. Go ahead and reboot your Hyper-V host now.

Since we are trying to route between two hosts, we can’t use “internal” type of VMSwitch. MAke sure you have atleast one VMswitch of type “external” created and management OS is allowed to share the connection (shown in screenshot below).

You will also find a corresponding NIC on your host which is named vEthernet… in my case it is “vEthernet (Intel(R) 82579LM Gigabit Network Connection – Virtual Switch)”.

Let’s go ahead and add two IP addresses we need for routing to this interface. You can keep existing IP you may have for your lab network as long as the ranges don’t conflict.

New-NetIPAddress -InterfaceAlias ‘vEthernet (Intel(R) 82579LM Gigabit Network Connection – Virtual Switch)’ -IPAddress 172.16.111.1 -PrefixLength 24

New-NetIPAddress -InterfaceAlias ‘vEthernet (Intel(R) 82579LM Gigabit Network Connection – Virtual Switch)’ -IPAddress 172.16.112.1 -PrefixLength 24

This will configure host interfaces with IP addresses that will become default gateway for VMs. HEre’s what your network properties would look like:

Ignore that default gateway I have crossed out in the image as that is for my lab network and isn’t applicable to our scenario here.

With host configuration out of the way we can now connect VMs to the external switch, it not connected already:

Connect-VMNetworkAdapter -VMName NY-S1 –SwitchName ‘Intel(R) 82579LM Gigabit Network Connection – Virtual Switch’

Connect-VMNetworkAdapter -VMName EU-S1 -SwitchName ‘Intel(R) 82579LM Gigabit Network Connection – Virtual Switch’

Notice the name of VSwitch. I have identical host configuration so they seem to be the same switch name, you may have different names per host or even more readable names if you renamed your VSwitch.

Last step is to configure VMs with their respective IP and default gateway. I am sure this isn’t something you need help with so go ahead and take care of that step.

At this time, you should be able to ping EU VM from NY and vice versa. Keep in mind that default firewall rules on your VM may be blocking ICMP and you may get request timed out. If so, check your firewall configuration and allow ICMP or test using something else that is allowed by firewall rules.

How’s that for a router that’s built-into your environment and doesn’t need an extra VM chewing up those valuable computer resources?

Remember, all things discussed in this articles are for your LAB not for your production environment. Please use proper routing for that.

Cheers!