Coauthored By: Ed Liberman
In a lab environment, you oftentimes want to mimic what you will see in a production network. The problem is that you often don’t have the equipment to give you a fair mimic of the real world. This is becoming less of an issue with virtualization, because you can set up multiple VMs on a single system so long as it has the memory to handle the load you’re putting upon it. Where you might come up short is if you wish to work with a multi-site environment but do not have a “true” router to work with. In this case, there is a solution that is relatively simple but requires you to have a decent grasp of subnetting.
There are many worthwhile reasons for learning how to do this. Two in particular that we came across was:
- to obtain a greater understanding of Active Directory sites and site replication
- to perform lab-work with something like cross-site Exchange High Availability to perform datacenter switchovers
You don’t need to have exactly the same equipment and setup that we have here. You just need to have basically what we have in play for this to work.
We’re working with a single Dell T110 server running Windows Server 2008 R2 with Hyper-V. We have a single NIC that is being used by Hyper-V as a virtual switch with a virtual NIC running on the 192.168.1.x network. The IP address of the NIC is 192.168.1.20 with a subnet mask of 255.255.255.0. We have two VMs running Server 2008 R2. The default gateway is a typical 4 port switch with a WAN connection to the Internet (which they call a ‘router’ but it isn’t a true router as we mentioned above, in the sense that it really only routes between an internal network and the Internet, not between multiple subnets).
We would like to have both VM Servers be Domain Controllers but have them set up as different sites in Active Directory. We want it to appear as if each site is connected through a router, and still have it so that both systems can access the Internet through the default gateway.
Note: If you configure one subnet to be the same as the router, this would accomplish having that DC up and running and communicating to the Internet. However, if you go with an abstract IP network for the second server (exp. 10.1.1.x), it will not be able to communicate with the other server or the Internet.
The idea is pretty simple. We need to take the network and subnet it down to allow both systems to appear as if they are in the 192.168.1.x networks, but in reality they sit in two separate subnets. In addition, we need to make sure AD Sites and Services is configured to understand the subnet for each one.
To start with, we decided to borrow three bits from the final octet of our network/node IP configuration. We could have gotten away with only borrowing 2 bits, but that would only give us four subnets to play with and you never know when you want more.
We named our servers: DCSITE1 and DCSITE2. We gave them the subnet mask of 255.255.255.224, which indicates we are borrowing those 3 bits from the node portion and bringing it over to the network portion of the IP address.
To determine the proper host or nodes for each one, we might look at the binary involved using 3 bits from left to right (meaning using 128 | 64 | 32 ):
|Bit Pattern||Decimal Conversion||Potential Host IP|
Note: Networking 101 allows us to have a network that has all 0’s or 1’s from a binary perspective, but not a node that has all 0’s or all 1’s, which is why you see potential host IPs skipping some numbers.
Based upon the potential options, we decided to give DCSITE1 an IP address of 192.168.1.33, with a subnet mask of 255.255.255.224 and a default gateway of 192.168.1.1. We pointed DNS settings back at itself and we made this system a DC and DNS server. We provided a secondary DNS on the Internet.
Now keep in mind, we are breaking some basic rules here by doing this. When you put in the default gateway and it isn’t on the same network as your system, you’ll even get an error (shown in Figure 1) but trust me… it will work. After all, that is the main goal here, isn’t it?
DCSITE2 was given an IP address of 192.168.1.65, which as you can see above, places this system in a different network. The subnet mask was also 255.255.255.224 and a default gateway of 192.168.1.1. In this case, we pointed the DNS settings at the first DNS server and at the Internet.
Next we opened up Active Directory Sites and Services on DCSITE1. We renamed the default first site name to SITE1 and created a second site named SITE2. We created two subnets. The first one was based off the first network and it is 192.168.1.32/27 (note: 27 indicates the number of bits we are using to accomplish the subnet). We attached that subnet to SITE1 (figure 2). We then created a second subnet as 192.168.1.64/27 and connected it to SITE2.
We jumped back over to our DCSITE2 server and joined it to Active Directory, making sure to choose SITE2 in the wizard to ensure we would have both servers separate (as you can see in Figure 3).
Basic network testing was going on throughout the process. We pinged from one system to the other and vice versa. We made sure we could access the Internet. Obviously, it was a good sign when the second DC was able to join the domain as a domain controller. But to test that replication was occurring properly, what we first did was go into AD Sites and Services, expand Sites, Inter-Site Transports, and select IP. From here, you can see the Replication Interval is set to the default 180 minutes (3 hours). You might not want to wait for 3 hours to see if your test is working out, so you can adjust this (and we did) to as low as 15 minutes (as shown in Figure 4).
Then we created a new user in SITE1 and went to have a cup of coffee. We could have forced the replication to happen, but we wanted it to happen naturally. Sure enough when we returned and refreshed the screen, the new user had been replicated over to the DC in Site 2.
None of this is rocket science, but it is a lot of little things that you need to be able to put together. For example, you need to have an understanding of subnetting, an understanding of AD Sites and Services, and basic network troubleshooting and testing. Oftentimes though, it is the simplest solutions that get overlooked when trying to come up with an alternative option to having an expensive router in your lab for a more accurate parallel to production environments.