Setting up a Multi-Subnet Infrastructure without a Router between Subnets
http://www.petri.co.il/set-up-a-multi-subnet-infrastructure-without-a-router.htm
Setting up a Multi-Subnet Infrastructure without a Router between Subnets
Printer Friendly Version
Coauthored By: Ed Liberman
Overview
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.
Over 70% of network issues are caused by faulty configurations or unauthorized changes. SolarWinds Network Configuration Manager (NCM) helps you reduce or eliminate those issues by continuously monitoring device configurations and providing immediate notification of config changes so you can resolve issues before they impact users. NCM supports multi-vendor network environments with a rich web-based console providing point-and-click simplicity and easy access to config data Download a free, fully-functional 30-day trial of Network Configuration Manager - start backing up & tracking network configs in less than an hour!
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
Our Setup
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.
FREE 3-Month Trial » Windows Azure
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).
The Goal
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 Method
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 000 0 1-30 001 32 33-62 010 64 65-94 011 96 97-126 100 128 129-158 101 160 161-190 110 192 193-222 111 224 225-254Note: 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?
Figure 1: The error message you'll see when you attempt to connect to the default gateway.
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.
Figure 2: Creating new subnets and attaching them to sites.
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).
Figure 3: AD Sites and Services showing both subnets and each DC in a different subnet
Testing
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).
Figure 4: The new replication interval settings are in place
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.
Summary
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.
FREE Trial » Comprehensive Virtualization Management
(via Instapaper)
Brief message sent from a handheld device.
No comments:
Post a Comment