A couple weekends ago I spent some time getting Vyatta Core 6.1, vyatta-xenserver_VC6.1-2010.10.16_i386 to be precise, deployed in my lab. I found a few tutorials for configuring Vyatta with VMware products, but didn’t really see anything for XenServer. Citrix highlighted the possibilities fairly soon after the XenSource acquisition in a blog post, but that was a couple years ago. Since then Vyatta and Citrix have announced a closer partnership and Vyatta was even part of the C3 Cloud Bridge blueprint. All positive signs that it should be fairly painless, so off we go.
First and foremost you need to download the latest version of their XenServer virtual appliance. If you’re a newbie to Vyatta, like I was, you’ll probably want to grab some documentation as well. The great thing about the appliance is you don’t need to muck about with a custom installation. Once you’ve imported the virtual appliance you should have a new template ready for VM deployments (in my case it was called: vyatta-xenserver_VC6.1-2010.10.16_i386).
You can see in the screenshot above that I’m using 3 physical NICs in my XenServer. The on-board NIC is a dedicated management interface (highlighted in the screenshot) and I’ve bonded a pair of Intel NICs for VM traffic. The third network, without a physical NIC associated to it, is an internal-only network and the primary reason I want the Vyatta router.
With my networks outlined, I’ll walk through the process of configuring the Vyatta router so that the internal-only network (remember: 192.168.48.x/24) can access the lab network (remember: 192.168.24.x/24).
Using the imported template, create a new VM, adjusting the settings as appropriate until you get to the networking configuration. Ensure a virtual interface is added for both the lab and internal-only network(s). Treat the router like you would any other VM; it doesn’t need an interface on the management network, unless you’re using it for VM traffic as well.
Complete the VM setup and have it boot up automatically. To login, use the default credentials: vyatta/vyatta.
Initially, we’re going to configure each interface with an IP address and enable SSH access. You’re not required to use SSH to complete the configuration, but it will allow you to access the CLI without XenCenter in the future.
configureset interfaces ethernet eth0 address 192.168.24.254/24set interfaces ethernet eth1 address 192.168.48.254/24set service sshcommit
You should now have a rudimentary configuration up and running. The two networks won’t be able to communicate with each other yet, but you should definitely be able to ping each interface from another device on the same network segment. In order to get the internal-only network talking to the lab network we’ll configure a NAT rule to pass traffic back and forth.
set service nat rule 1 source address 192.168.48.0/24set service nat rule 1 outbound-interface eth0set service nat rule 1 type masqueradecommit
If you were to stop here, any VM on the internal-only network using 192.168.48.254 as its default gateway would have access to the lab network, BUT it won’t be able to access the Internet. This may not be a big deal in your environment, but I still wanted to access OS updates, software installs, etc. without jumping through too many hoops. To achieve that we need to configure the router to use the default gateway on the lab network.
set system gateway-address 192.168.24.1commit
Test your setup. From a VM on the internal-only network you should be able to ping hosts on the lab network and the Internet. To save the configuration so it persists after a reboot, run this final command in the CLI.
The last thing I did in my environment was configure a static route on my wireless router so that devices on the lab network can access the internal-only network without any client-side modifications. I’m running Tomato v1.28 on a Linksys WRT54G, so adding the static route is under Advanced -> Routing. The exact method for performing this step depends on your wireless router, but the gist of it is that you want all traffic destined for the internal network (192.168.48.x in my case) to use the Vyatta router’s interface as its gateway (192.168.24.254 if you’re following my example).
And with that, you should now have an internal-only network that’s completely accessible from the lab network, but allows you to retain greater control of the isolation. Need a DHCP server for PVS? Want to test the Branch Repeater VPX on separate networks? Start exploring and leave me your feedback in the comments.