Posts tagged Networking

Shorewall and VMware ESX/ESXi 4.x Networking Issues

0
1 year ago
by Colin Barker in , ,

At Blue Sky every once in a while we set up Shorewall servers for customers, Linux Based Open Source firewall software, which is actually pretty good for what it can do. They have been running fine on physical boxes, and as virtual machines on ESX 3.x environments for a while now, however an issue arose when we started to install vSphere (ESX/ESXi 4.0 / 4.1) servers over the past year, where suddenly these firewalls just were not moving the data from one network to the other. Typically for customers we install Shorewall in a NAT configuration mode.

This stumped us for a while, it stumped VMware for a while, even the community came along and had a go, and while got me half the solution, it never quite worked.

So for those having any issues, here are a few more things to try, which worked for Blue Sky! (Although I do keep forgetting to run the final part of this!)

The first thing to look out for is the following. As a default, when you create a VM, most of the options will lend you towards setting up a network card as “Flexible”. This is really handy, as in most cases, this is an emulated network card which the drivers are available / installed on most OS’s out there. Handy! And technically you could run with this type of network card on any server. You wouldn’t get the full feature set you get with the other type of cards, but it will do. VMware also offers you a number of other types, but in the new vSphere world, they have a new type called “VMXNET3″. This is only available on version 7 VM’s (which will only go on 4.x ESX servers), there are the other VMXNET drivers, which will work on other systems, but for this case, I a going to stick with VMXNET3.

What we end up doing is, once we have installed the OS with the Flexible driver, and installed the Guest VMware Tools (they contain the drivers for the VMXNET3 network card), I shutdown the VM and re-add the network cards, ensuring they are VMXNET3.

Once the OS boots up, everything seems fine (and though changes in the config to ensure that you are pointing to the new MAC addresses of these network cards!), however, Shorewall still has an issue.

The final bit of the puzzle, lay in something called TCP Segmentation Offloading. Something which virtually, is not needed, which on a physical level is very handy. As this is not needed, and brings a large overhead to the vm, I downloaded a tool called “ethtool” (in the case of Fedora, you can get it using yum), and typed in the following command for all interfaces.

ethtool -K ethX tso off gso off

Without any rebooting, all the systems behind the Shorewall works.

It’s not much at the end of the day, but I thought I would share this with the world!

Initial Multi-Homed Datacentre Diagram

Hosting in “The Cloud” – Blue Sky Hosting Project (Part 1)

0
1 year ago
by Colin Barker in

I am sure most people out there have heard “The Cloud” being used to talk about parts of the internet, and how it is the future of the system, however a lot of people take this for granted.

A lot of the big companies out there, have time, money and man power to throw at such a system that they don’t need to really think to hard about it. At Blue Sky Hosting, a need for such a system has been requested, and now we are putting man power towards it.

The challenge sounds simple, we need to be able to fail over to a second data centre, with either no or minimal down time to the services we host. This in practice, however, is not so simple.

The internet as we know it, has many servers, clients, mobile devices, all attached to it (I could go on, but I am sure I would need a life time to describe them all!), all requesting data from servers or services locally or globally, all interconnected in such a way that it should make it indestructible.. or so they say! Your request for the website you are looking for, will travel out through your router or modem, through more routers, cables, copper, fibre, the great firewall of xyz country, before reaching its destination, returning to you the data you requested.

Web site hosting is one of the many, more popular services which people are looking to ensure that it stays up and available 24/7/356, and a lot of these people will call you in the middle of the night as their site has vanished for a few seconds. However with this comes one of the inherent problems with the internet. DNS.

DNS is a simple process, like you looking for a name in a phone book, your website name say, http://www.bluesky.co.uk, will be processed by your computer, and looked up by your local, remote, ISP’s DNS servers to return a number, or IP address, in this case 83.245.106.75. This of course (should!) point to your server, and through the magic of the internet, up pops your website. Typically your server with the website, is hosted at a data centre somewhere out there, and it sits there happily returning your “calls” for data, and is none the wiser that the local cleaner has decided that they want to plug their hoover into the main power inlet for the whole building, taking out the entire facility!

What can you do then? Typically IP’s are locked to the physical location that the server is in. (In most cases). You could update the DNS record for your website, to point it to another data centre, but one of the “features” of DNS, is that it will keep the looked up entry somewhere cached for a period of time. Like you writing the number from the phone book on a post-it-note, then when they replace the phone book, you still using the post it note, till you chuck it away.

Most larger ISP’s and major hosting companies do have a way around this, however this project is to bring us up to this level. Over the next few months, I will document what we do as a company, so that hopefully it will help other people out there solve problems like this in the future.

In the mean time, here is a simple diagram of what we want to set up. I will go into this in more detail another day.

Initial Multi-Homed Datacentre Diagram

Go to Top