Carlos' Corner » routing

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

cars — Thu, 18 Feb 2010 22:37:37 +0000

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.

In addition I need to add port groups for the network between the DMZ and Internet router (192.168.5.X), as well as the one between the internal router and the DMZ (192.168.4.X). Because I’ll put all three routers on the same host, these last two port groups need only exist on that one host.

When all is said and done there should be 6 port groups defined on the vSwitch on the host where I’ll put the routers and 4 port groups on the other host. Notice that the VLAN IDs for each network match up across the two switches.

I initially tried this setup using an alpha version 6 of Vyatta but the routers felt a little slow to me (though I have no empirical evidence to back that up) so I went back to using version 5 LiveCDs for the routers as discussed in the earlier entry.

Building the internal router

I started by creating a custom VM for the internal or home router with 4 network adapters configured. I used the custom configuration because this VM won’t actually have a virtual hard disk. The four network adapters will be attached to my home LAN (lostroncos_01), the HQ Site Network, the Remote Site Network and the intranet to DMZ network. (Note: This post has a more detailed description of the process I used to create Vyatta routers. )

After powering on the router and opening the VM console I like to enable the NIC on my home network and ssh so I can do the rest of the configuration via an ssh client such as Putty. Once the VM has initially been powered on, I can go back and look at the settings and determine the MAC address of the NIC attached to my home network (lostroncos_01) is 00:0c:29:76:e2:07. Upon logging into the VM console I can go into configure mode by entering the command “configure” and then get a list of the interfaces the router knows about by entering “show interfaces”.

The one I’m interested in initially configuring is eth0. I can tell because the MAC matches the one I took note of earlier. To configure it to use 192.168.1.254 as it’s address and enable ssh I can do the following:

Let’s look at these commands in a little more detail.

The set interfaces command can take a wide variety of arguments. Here I’m specifying that I want to work on an ethernet interface. Other interface types include adsl, bonding, bridge, loopback, multilink, openvpn, serial, tunnel and wirelessmodem.

Even after specifying the type as ethernet and the particular interface (eth0) I can still use one of several subcommands/options.

Because I’m using VMs and a fairly generic setup I really only need to worry about the address option. So I specify the address and netmask notation by specifying the number of bits to use for the netmask (24).

The next command “set service ssh” simply enables the SSH server.

Now I’ve configured the interface and enabled SSH, but the settings haven’t been made active. That’s what the “commit” command does.

Executing the “show interfaces” command again I can see that the IP(v4) address is set for eth0 but not any of the other interfaces. Now I can use my ssh client to connect to the VM to finish the configuration. (One can also use the VMware console to perform all of the configuration steps, I just prefer an external SSH client).

After making sure the MAC addresses and networks match up the way I think they should, I can set the address for each of the other interfaces and commit the changes. Then I can exit the configuration mode by typing “exit” and save the configuration to the virtual floppy using the “init-floppy” command. This then ensures that my configuration will survive reboots of the router.

One of the other things than can be helpful to do is to use the “description” option with set interfacse to provide a little more information when logged into the router.

After doing this for each interface and then committing the changes I can see the descriptions when doing show interfaces from either the configure mode

Or from the actual router shell

Since I happen to already have VMs on both the HQ and Remote networks I can verify basic connectivity from the router by pinging those VMs as well as my PC.

The next trick is to validate that I can ping the HQ and Remote subnets from my physical PC. Since both of those subnets are directly connected to the router I don’t need to add any static routes on the router. However I do need to add a route on my PC to reach those subnets. Otherwise it’ll try to use the default gateway out to my ISP (as shown below) which doesn’t know anything about this lab environment.

To reach the 192.168.[2,3,4] subnets I want to use the interface on rtr-home that’s attached to my home network (192.168.1.254). So using the “route” command from a command prompt on my Windows7 machine I can add the route to 192.168.4.X.

The route command in this case takes a few arguments…

#1 add tells route I’m adding a new one

#2 Next I specify the destination, and since ultimately I’m trying to get to a subnet we’ll specify 192.168.4.0.

#3 & #4 MASK says the next argument is the netmask relative to the destination

#5 is the gateway for this destination, in this case the interface on my virtual router that’s attached to the home network.

Once that’s done I can then try to ping & tracert the 192.168.4.2 interface on the router again.

Executing the “route print” command from the Command Prompt I can see the entry for the 192.168.4.X network as I would expect.

Now that this particular routing entry appears to be working properly I can re-run the route command with the -p option so that it’s persistent across reboots of my home PC.

Next I need to add routes for the 192.168.2.X and 192.168.3.X networks to the PC as well.

At this point, I can try to do a traceroute from my PC to the VM on the HQ Site network that I was able to ping earlier from the router.

Because I’m occasionally paranoid, the next step for me was to connect to the console of the VMs on the HQ (shown below) and Remote (not shown) subnets and verify that I can ping machines on my home LAN across the internal router, rtr-home.

At this point my internal Vyatta router is routing traffic between subnets it is directly connected to (Home LAN, the HQ Site and Remote Site). Once the DMZ and Internet routers are set up some changes will need to be made on the internal router to get traffic to those non-connected subnets. I’ll go through that process in a subsequent post.

-crt

Using Vyatta with VMware

cars — Thu, 18 Sep 2008 08:10:26 +0000

[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.

The first thing I had to do was create a second virtual switch (vSwitch1) on my ESX box for the second subnet. One could just as easily create port groups and use VLANs on the first switch but I wanted to keep it really simple for now plus I think that conceptually this fits the model a little better.

Creating the second virtual switch

The second virtual switch can be created by navigating to the server node in the Virtual infrastructure client. Then going to the Configuration tab. Select the Add Networking option. Choose the “Virtual machine” connection type. Click next. Choose “create a virtual switch” and uncheck the NIC (if applicable). Click next. Specify a network label. (in my case this is the virtual “remote site”). Click “Next” click Finish

Creating the Vyatta VM.

I started by downloading the Vyatta Live-CD image from http://www.vyatta.com/download/swdl.php. Once I had a local copy of the ISO, I uploaded it to the ESXi box.

Actually creating the VM four our purposes consists of two parts: the initial creation, and then the creation of the floppy image to store the configuration. Because I prefer to keep the floppy image with the VM’s config files I have to perform that portion of the configuration after the VM (and it’s associated folder) is created. Using your good friend the VMware Infrastructure Client here’s the first set of steps to follow, (they’ll probably be fairly familiar with the slight change that we’re not going to add a hard disk).

Steps for Initial creation

File -> New Virtual Machine
Custom Virtual Machine Configuration (Next)
Specify the Virtual Machine’s Name (Next)
Select the Datastore where you want to store the VM (Next)
Choose Linux for the guest Operating System and RHEL5-32bit as the version. (Next)
Select the number of virtual CPUs, I chose 1. (Next)
Specify the amount of memory 128 MB RAM
Specify the number of NICs. For my scenario I chose 2 and assigned one to each virtual switch (Next)
Pick a Scsi adapter type the choice here doesn’t really matter since we won’t be adding a hard drive to this VM.(Next)
Choose “Do Not create a disk”. (Next)
Finish

Now that the VM has been created we want to right click on it in the VIClient and choose “Edit Settings”

In the Virtual Machine Properties window go to the Hardware tab.

Select the Floppy Drive.

1. Choose “Create new floppy image in datastore” as the Device Type
2. Click “Browse” and navigate to the directory in the datastore where you want to keep the floppy image.
3. Specify the name of the floppy image. (ex: vyatta-config) and click “OK.”
4. Ensure that the checkbox next to “Connect at power on” is checked,
5. Click Ok.

Select the CD/DVD Drive

1. Choose Datastore ISO file as the Device Type.
2. Click Browse and navigate to where the ISO image is stored.
3. Set to connect at power on and click OK

You’re now ready to poweron the vm and begin the process of configuring it. Power it on via the VI client and connect to the console. You can log in as ‘vyatta’ with the password ‘vyatta’. The first thing you should do is make sure your VM sees both of the assigned NICs. This can be done by typing: /sbin/ifconfig | grep -i ethernet. You should see two lines of output; one starting with ‘eth0′ the other with ‘eth1′.

 

vyatta@vyatta:/$ /sbin/ifconfig | grep -i ethernet

eth0      Link encap:Ethernet  HWaddr 00:0c:29:be:8e:2d

eth1      Link encap:Ethernet  HWaddr 00:0c:29:be:8e:37

vyatta@vyatta:/$

To configure the router to match our diagram above we’re going to assign eth0 the IP address 192.168.1.10 and use a subnet mask of 255.255.255.0 (/24). The second NIC will be assigned the IP address 192.168.2.10. To do this we’ll enter the four following commands.

configure

Set interfaces ethernet eth0 address 192.168.1.10/24

Set interfaces ethernet eth1 address 192.168.2.10/24

commit

exit

The first ‘configure’ puts Vyatta into configuration mode where we can enter actual configuration commands. You might notice that the prompt changes from vyatta@vyatta:~$ to vyatta@vyatta#. The second command assigns an IP address to the interface eth0, while the third does the same for eth1. The fourth command “commit” actually commits the changes so that they’re in use in the running config. The last command exits the configuration mode and you’ll notice that the prompt has changed back as well

 yatta@vyatta:~$ configure
[edit]
vyatta@vyatta# set interfaces ethernet eth0 address 192.168.1.10/24
[edit]
vyatta@vyatta# set interfaces ethernet eth1 address 192.168.2.10/24
[edit]
vyatta@vyatta# commit
[edit]
vyatta@vyatta# exit
exit
vyatta@vyatta:~$

To validate that this is now the running configuration you can type: show configuration

Now to ensure that this configuration sticks with the VM between reboots we need to initialize the attached floppy by entering ‘init-floppy’ This will cause the VM to (re)format the floppy and write the configuration to the floppy.

vyatta@vyatta:/$ init-floppy

This will erase all data on floppy /dev/fd0.

Your configuration was saved in: /media/floppy/config/config.boot

vyatta@vyatta:/$

To validate that the configuration has been properly saved to the floppy and will be automatically available and in use upon reboot you can reboot the VM by typing “reboot” and waiting for the VM to reboot. Upon logging back in you can again run the ’show configuration’ command to see if the config has been kept through the reboot.

How do I know routing is working?

Now that the router has been set up with an interface on each of your virtual switches/subnets you need to verify that it will actually route packets between the two subnets. One way to do this is to create two VMs, one on each virtual switch configured to use the appropriate router interface as its default router. That can be a bunch of work just to test the routing depending on what kind of guest you use. Another option which I used to do my intital testing was to create two more VMs using the Vyatta LiveCD. Simply by entering a few commands I can quickly have a configured VM on each subnet that I can use to ping back and forth with. For the VM on the 192.168.1 subnet I could enter the following commands to configure the new VM.

configure
set interfaces eth0 address 192.168.1.11/24
set system gateway-address 192.168.1.1
commit
exit

Enabling SSH

I also like to enable ssh access for the vyatta router so I can use Putty from my Windows box to administer the VM and not have to use the VI Client console. That can be done by entering:

configure
set service ssh
commit
exit

Saving your configuration

Again to ensure that this is kept in the config through reboots you need to execute the ‘init-floppy’ command.