As we know, there are known knowns; there are
things we know we know. We also know there are
known unknowns; that is to say we know there are
some things we do not know. But there are also
unknown unknowns - the ones we don’t know we
don’t know.

Donald Rumsfeld - Feb. 12, 2002, Department of Defense news briefing

Here is a recent problem I banged my head against for way too long.

I was given a DVD containing a VMWare guest operating system (CentOS). The CentOS installation included a tool I needed to evaluate. This guest OS was a fully self-contained unit - it contained the software for the server (the actual software product under evaluation), plus an Oracle database, which acted as the repository used by the server. It was a basic appliance - the sort of thing a sales person could load onto their laptop and take on the road.

In our workplace, our PCs are assigned dynamic IP addresses - well, the IP addresses are not guaranteed to be static, but in reality they don’t change every time you reboot your PC.

I wanted to make this demo server visible on our network, so that two of my colleagues could also connect to it and evaluate it, using its web interface. I therefore really wanted the guest to have its own IP address - no big deal for the evaluators to use the guest OS’s IP address in the URL.

Out of the box, the CentOS guest was not configured to see the network. I checked the VMWare network settings for the guest OS - it was set to “bridged” - in other words, it would connect directly to the network via the host’s network card - but it needed its own valid IP address - and it won’t get one allocated to it , if it can’t see the network…

$ ping google.com  
ping: unknown host google.com

Some digging (from the host, of course) led me to the awesome YoLinux site, which contains some excellent networking tutorials, that even I was able to follow.  Here is just one:

Linux networking tutorial

In the end, after not too much trial-and-error, I only needed to make modest changes to two files:

/etc/sysconfig/network:

NETWORKING=yes  
GATEWAY=[IP address of host’s gateway]  
GATEWAYDEV=eth0 [a typical name]  
HOSTNAME=[the guest OS server name]

/etc/sysconfig/network-scripts/ifcfg-eth0:

DEVICE=eth0  
ONBOOT=yes  
BOOTPROTO=dhcp  
USERCTL=no  
PEERDNS=yes  
DNS1=[whatever it is for the host]  
DNS2=[likewise]  
DHCP_HOSTNAME=[whatever it is for the host]

For my set-up, it was the dhcp setting that allowed the guest OS to acquire an IP address.

“Great”, I hear you say, “but my situation is different”. Yes, there are a many variations on the above, but this is what worked for me with minimal fuss. The “fill in the blanks” settings are readily grabbed from the host OS (assuming it’s Windows) by using the ipconfig /all command. If you need to make changes and don’t want to reboot your guest every time you tweak something, then the command service network restart will apply your latest settings.

And, of course, the next time you reboot the guest, you will automagically connect to your network. No need to go through this process every time.

I gave the VM guest to a colleague to install on his PC - since he also wanted to evaluate the product. So, I set it all up for him - step-by-step doing on his host and guest what I’d done on mine.

And it didn’t work.

No network connectivity. No Google pings. No nothing.

I retraced my steps. I compared my set-up to his. I compared it again. I uninstalled the whole lot and re-installed. I got him to check everything, twice. No joy

This all took, on and off, the best part of three hours.

I called Network Support.

The guy asked me, “Do you both work in the same building?”. I figured he wanted to swing by, and take a look. “No”, I replied, “we’re in different buildings”. He asked, “Which ones?” I told him.

“In that case, it’s probably a port security problem”, he said.

He explained how my colleague’s building has port security implemented. When you plug any device - say, your laptop - into a given ethernet port in the wall of your office, port security says, “do I recognize the MAC address of this device?”. If the answer is “no” then the port is not enabled for that device. It’s what prevents anyone from outside the company from waltzing in with their own laptop, plugging it into any old network port in a quiet corner of the office, and getting instant access to the office network. Also, each port was restricted to only having one device active on the port. My colleague’s VM guest showed up as a second device - no dice.

My building did not have port security implemented, at that time. Hence, I had no issues.

The network support guy asked me for the port security & MAC address of the host PC - and he twiddled some Cisco dials back at Network Command HQ.

And it just worked.

It’s like when Skype, by default, appropriates port 80 - and suddenly the web server that always ran just fine on your PC stops working…

But that’s what happens when you don’t know what you don’t know.