VMware « Carlos' Corner

Simulating a more interesting environment with Vyatta and VMware ESXi - pt 3

Background

[consider this fair warning that this post is a bit long]

In the first part of this series I planned out my “enterprise” environment for an Exchange 2003 to 2010 upgrade. In the second part I built the internal router and verified it was working with directly connected subnets. At this point I have something resembling the following.

In this entry I’ll work on adding the DMZ router, enabling the firewall on one of its interfaces and adding static routers to it and rtr-home so that it’s reachable from my home LAN (essentially the stuff in the red box below). There are two phases to this. The first phase consists of setting up the router and verifying that it is able to reach hosts on the respective subnets it’s directly attached to. As part of this I’ll also set up static routing between rtr-dmz and rtr-home so that we can pass traffic from one subnet to another traversing both routers. In the second phase we’ll set up a very simple firewall ruleset to limit traffic coming out of the DMZ.

Configuring the router

To start I need to create new router rtr-dmz (much as I did in Part 2), with three interfaces. One interface will be on the intranet to DMZ network/VLAN (192.168.4.1/30), another on the DMZ to internet VLAN (192.168.5.1/30)) and the third connected to the DMZ network itself(192.168.254.254/24).

After starting up the VM I assign the IP addresses and enable ssh.

Now I want to verify that I can ping devices on the two interface that are connected to the DMZ subnet(192.168.254.254) and the DMZ to intranet switch (192.168.4.1). I could also check the DMZ to internet interface but don’t have anything else on that side yet whereas I do have a machine in the DMZ and rtr-home is also on the DMZ-to-intranet switch.

Now turning to my PC back on the “Home” LAN I can try to ping the interface of the new dmz router….

Oops! that didn’t work. .. As before I need to add a route on my PC so that it know how to get traffic to that interface through rtr-home.

Now let my try again….

Still no joy… what does traceroute say?

Ok it looks as if traffic is headed in the right direction.

For grins lets ping the DMZ to intranet interface of rtr-home…

Ok so that works and we can see from the traceroute that it’s starting its journey headed in the right direction. The issue is that much like my PC the rtr-dmz needs to know where to send packets destined to come back to a subnet it’s not attached to. To fix this I need to add a static route on rtr-dmz back to my PC. I also need to add routes to the HQ and Remote LANs as well. I’ll start by adding the route to the router:

Now if I try to ping the router from my PC it works as we would expect it to.

With that working its time to add the routes for the HQ and Remote LANs as well.

Now if I look at what I have configured again I’m noticing that rtr-home will also need to have a static route added to get to the DMZ and the DMZ to Internet network (red-lines). This is also true of my PC.

After adding the static routes to rtr-home using 192.168.4.1 as the gateway I’m now able to ping a machine in the DMZ from rtr-home.

Note: Typically for the scenario I’m trying to simulate there would be two sets of traffic flows. One between hosts on the “internet” and “DMZ” and the other between the DMZ and the intranet (HQ and Remote LANs). This means I wouldn’t normally have any traffic coming across rtr-home headed to/thru the 192.168.5.1 interface and so wouldn’t need to add a route for it to rtr-home. But since this my home lab and I prefer being able to ssh/RDP to hosts in the Internet directly rather than using the VM console(s) I’m going to go ahead and add it.

After doing the same on my PC ( this time using 192.168.1.254 as the gateway) I’m also able to ping the machine in the DMZ.

Because machines in the DMZ and on the HQ and Remote LANs will use the rtr-dmz and rtr-home as their default gateways we don’t need to add manual routes to those machines.

Continue reading Simulating a more interesting environment with Vyatta and VMware ESXi – pt 3

Simulating a more interesting environment with Vyatta and VMware ESXi - pt 2

In an earlier post I went through the process of coming up with a solution to be able to test an Exchange 2003 to Exchange 2010 migration using VMs. In order to simulate a multi-site AD environment I wanted to use Vyatta based routers to create my network infrastructure. In this post I’ll actually walk through the process of setting up the ESX and theinternal router. In the next post(s) I’ll go into configuring the DMZ and internet routers and firewalls. As a reminder the environment I want to set up will look like this…

In order to actually be able to implement this I first had to go configure the appropriate networking configuration on each of the ESXi hosts.

First I needed to create a virtual switch utilizing the NIC attached to the crossover cable. This is done by going to the “Configuration” tab for the ESX host within the vSphere Client.

Clicking the “Add Networking” option will walk one through the wizard to configure the new switch. I started by choosing “Virtual Machine” on the Connection Type Screen.

On the next page I choose to create a new virtual switch and pick the appropriate physical NIC that will be used to communicate with the other host. (If I had the capacity to put all the VMs one one host I could create the vSwitch without having to specify a network adapter)

Then I created an initial Port Group and specified a VLAN ID for it. In this case for the Remote Site (192.168.3.X/24) I’m specifying VLAN ID 23.

Once completed the new virtual switch should look similar to the one shown below.

Now that the vSwitch has been created, I can add port groups for the other networks: DMZ (192.168.254.X), Internet (10.0.0.X) and HQ(192.168.2.X). Each one of these should have a unique VLAN ID associated with it which is also used when these port groups get created on the second host.

Continue reading Simulating a more interesting environment with Vyatta and VMware ESXi – pt 2

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.

The final environment as laid out on two interconnected servers

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:

Physical view of the network

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

Isolated environment with multiple gateways per subnet

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.

Consolidating functions to reduce # of VMs

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.

Continue reading Simulating a more interesting environment with Vyatta and VMware ESXi

Nagios ESX3i Scripts and ESX4i

This is just an update, but the scripts I wrote for use with Nagios and ESX3i seem to work just fine with ESX4i (at least in my home lab environment using Dell Poweredge 2850s).

Simple Neverfail monitoring with Zabbix part 1

Background

This is the first of a couple of posts on how I’ve cobbled together some basic monitoring of Neverfail’s Neverfail Heartbeat H/A software which is also now the basis for VMWare’s vCenter Server Heartbeat. Since Neverfail seems to consider their command lines privileged information I will only cover how to do some simple monitoring using the registry. When starting on this effort internally I was only interested initially in figuring out a quick and simple way to get the info I needed and not so much on the how to get it into something part.

I’ve been working with another team where I work to look at Zabbix as an alternative for some of the monitoring we do in our environment. We use Microsoft Operations Manager 2005 (MOM) but haven’t fully cut over from out previous monitoring solution. I had looked at Zabbix earlier as a potential solution for monitoring a bunch of VMware ESX boxes but another team ended up getting tasked with that particular duty. So I had had some experience with Zabbix but hadn’t done too much with it since.

One of the things that’d been rattling around in my brain is using the capabilities of using the zabbix_sender feature/client to monitor some of other components/things we can’t easily get into MOM. Zabbix_Sender is a utility that is available for use with Zabbix that allows one to “send” information to Zabbix. In my case it was appealing because we’re already running two different monitoring agents on the Exchange servers where we have Neverfail installed. Since I only wanted to use Zabbix to monitor a small set of data related specifically to Neverfail zabbix_sender lets me do that without having to run the fullblown zabbix_agent as a service on the boxes.

Continue reading Simple Neverfail monitoring with Zabbix part 1

Using Vyatta with VMware

[Note: I've started another series of posts using Vyatta in VMware for a more complex environment that starts with this one- crt (2/20/2010)]

After finally getting around to clearing space in the garage and getting an old Dell PowerEdge 2650 I’d acquired up and running with VMware ESXi I started to think about what I’d need to do to set up a few tests/scenarios I wanted to play with. One of these includes the use of Read Only Domain Controllers in Windows Server 2008. Setting up a virtualized Domain Controller (DC) in VMware is easy enough, the trick was trying to figure out how to simulate multiple IP subnets given that I only have one ESX box at the moment.

At work I can do the whole assigning port groups and VLANs thing and let our physical routers do the routing. For my home lab what I needed was some sort of virtual router that didn’t require 1) a bunch of work to configure, 2) lots of resources on my small host. That’s where Vyatta comes in. In addition to their networking appliances they also provide a “Community Edition” of their software as either a Virtual Appliance (for VMware server it appears) or as a Live CD.

I’ve chosen to use the Live CD for my particular lab scenario because it’s much smaller and since it’s based on an ISO image I can have multiple installations/configurations for just the cost of a virtual floppy image for each instance.

Ultimately my goal is to get to a configuration resembling the following diagram all on one physical server:

In this post I’ll describe setting up Vyatta using the LiveCD image and validating that routing is happening.

Continue reading Using Vyatta with VMware

Carlos' Corner

Translate this

Categories

The back catalog

Simulating a more interesting environment with Vyatta and VMware ESXi - pt 3

Background

Configuring the router

Simulating a more interesting environment with Vyatta and VMware ESXi - pt 2

Simulating a more interesting environment with Vyatta and VMware ESXi

Nagios ESX3i Scripts and ESX4i

Simple Neverfail monitoring with Zabbix part 1

Background

Using Vyatta with VMware

Recent Posts

Recent Comments

Admin Stuff