Simulating a more interesting environment with Vyatta and VMware ESXi

[Part 2 of this series which involves the actual configuration of the Vyatta routers is now up here -crt]

At work we’ve recently made the decision to migrate to Exchange 2010 from Exchange 2003. While we do have an environment that we can use for some testing of the migration it doesn’t mimic our production environment closely enough for me to be comfortable using it as the sole test area. Given the changes in how Exchange 2010 (E2KX) works vs 2003 I wanted to be able to simulate multiple (2) Active Directory sites (i.e. subnets), a DMZ, and the “Internet” including some really simple firewalls.

I wanted to use virtual machines to go through this exercise so that I could take snapshots and repeat the various steps and/or variations of them if necessary. In order to do this I utilized the Vyatta Community Edition based routers to help create my virtual “enterprise” environment. I’ve talked about Vyatta before in this article. In this post I’ll talk a little about the process I went through to get to my final configuration (shown below).  In subsequent articles I’ll go  through the actual router and VMware configuration process.

My lab environment at home consists of two Dell PowerEdge servers (one a PE2850, the other a 2950 each with 8Gigs of RAM). Both servers are running ESXi 4.0. Since the 2850 can’t run 64 bit VMs I was going to install the Exchange 2003 servers and Windows 2003 DCs on it. Then I’d install VMs running Server 2008R2 on the 2950 with Exchange 2010. Both servers are connected to my home network and since I was going to be using both I wanted to have some way for VMs on each host to be able to communicate with others without necessarily having all the traffic come across my home network. Since both Dells have multiple NICs I connected them with a crossover cable ending up with something like this:

In initially penciling out a plan for what I wanted to do I had nine VMs scattered across four subnets.

Considering my limited resources and my need to keep some other unrelated VMs up and running while I’m testing, I trimmed this down to 7 by combining the Domain Controllers and Exchange 2003 servers together in the HQ and Remote subnets.

In further looking at this from a networking perspective, I was hit with the realization the initial configuration with two routers attached to the HQ and DMZ subnets would require me to manage routing on each individual VM in each of those subnets as well as on each of the routers. As an example one can look at the Exchange 2010 server in the HQ site/subnet.

In this particular case the Exchange server would need to be able to route some traffic to the DMZ via 192.168.2.253 and other traffic to the “Remote” site via 192.168.2.254. (If the server was going to communicate directly with machines in our fake “Internet” I’d have to add yet another routing entry.) I can of course configure a default gateway when configuring the NIC, but still have to manually add a route for the other gateway. This process then has to be repeated on each machine. It then gets more complicated if I want to be able to use Terminal Services (RDP) to connect to the VMs rather than using the VM remote console because I now have to figure out how to connect the virtual routers to my home network and potentially add yet another routing entry.

I decided I’d rather have a single gateway on each subnet (so I only had to specify a default gateway on each VM) and then rely on the routers to do all the routing. I considered a couple of different ways to do this. One option was do something “meshy” where the router for each subnet was connected to common shared subnet.

This would have had the desired effect a single gateway for each subnet regardless of where traffic was going, but would have required 5 virtual routers which seemed a little excessive. Going in the other direction, another option was to have a single router connected to everything.

I ended up with a solution somewhere between the “mesh” and the single mongo router. It employs three routers. I decided on this partly because I wanted to keep things relatively simple especially since I was going to be enabling the firewall functionality between the DMZ and Internet (and wanting to limit the damage I could do to myself when working late at night).

Again, when all was said and done the environment I ended up with looks like the one below. In the next couple of entries I’ll go through the actual process of building the networking side of this.