VMware Communities
em2slyn
Enthusiast
Enthusiast

Workstation 8.0.1 networking problem with Linux (Ubuntu Server 11.10)

Hi Everyone:

I am having network problems with Ubuntu Server 11.10 when installed on Workstation 8.0.1.

The problem occurs when I assign a static IP address to the network adaptor (eth0 in this case). The OS no longer connects to the network and pinging any network device goes without response. I've tried this on the VMnet8 NAT network and on the VMnet5 private network with a WS2K8R2 server configured with RRAS as a gateway. Here are the settings that I use for the eth0 adaptor on a 192.168.100.0/24 subnet:

/etc/network/interfaces

...

auto eth0

iface eth0 inet static
     address 192.168.100.211
     netmask 255.255.255.0
     network 192.168.100.0
     broadcast 192.168.100.255
     gateway 192.168.100.1

# ifdown eth0

# ifup eth0

/etc/resolv.conf

...

nameserver 192.168.100.1

Typing ifconfig at the prompt returns the correct settings for eth0. However, pinging any device goes without response (I enabled ping response from WS2K8R2 gateway). I also tried different addresses just in case, but no change in behavior.

Here's where it gets crazy, when I return the configuration to dhcp

auto eth0

iface eth0 inet dhcp

# ifdown eth0

# ifup eth0

entering ifconfig returns the same address (192.168.100.211) that was set previously despite an entry in the DHCP table of 192.168.100.100. Sometimes ping begins to work again, sometimes not. I then tried pinging the Ubuntu Server from the WS2K8R2 gateway. First I tried the assigned dhcp address (192.168.100.100) and it responds. Then I pinged the static address (192.168.100.211) and it responds too! Mind you, there's nothing else on this network. It is like a ghost connection that some how got left behind in the switch.

After double checking and triple checking the configuration, I figured that maybe there was something I may have missed. I then installed CentOS 6.2 and the DHCP assignment worked fine, however, when I assigned a static IP to eth0 the exact same problem occurred.

I restored the defaults in the Virtual Network Editor to no avail. For comparison, I installed both OSs on MS Hyper-V and alternated between static IPs and DHCPs without problem. I've tested a number of WS2K8 R2 VMs on Workstation 8.0.1 and never had any problems like this. Based on my observations, I am beginning to suspect a Linux networking problem with Workstation 8 but I don't know how to dig into this further to confirm or refute.

Anyway, I've searched the internet without much success and thought I'd see if anyone in the VMware community has experienced this, would attempt to replicate the problem, or is interested in tackling this issue. Any suggestions would be appreciated. Thanks!

Shaun

P.S. Please let me know if there is a more suitable post location if this is not the correct discussion topic.

0 Kudos
4 Replies
srnhpp
Enthusiast
Enthusiast

HI,
Your network is 192.168.100.0.
How you are using static and DHCP ip addressing in same subnet?
When you are configuring--eth0 static how you will conform that all time eth0 will all time get this  address 192.168.100.211? It's may happen that other machine got this IP address.   I think IP conflict is there. Please make sure that IP conflict is not occuring.

Virtual Power
0 Kudos
em2slyn
Enthusiast
Enthusiast

Thanks for the response.

Here's the setup:

DHCP range: 192.168.100.100 - 192.168.100.199

Gateway address: 192.168.100.1

I am using two different configurations for comparison. The first employs the VMnet8 NAT network with the local DNS at 192.168.100.1. The second employs the VMnet5 network with a WS2K8 R2 server as the gateway (NAT only bridged to the VMnet0 network) along with two additional WS2K8 R2 servers at 192.168.100.10 and 192.168.100.20 to serve as the primary and secondary domain controller/DNS systems. In addition, the two servers are arranged in a failover cluster to provide a high-availiblity DHCP service (the SAN is on the VMnet2 network). The cluster network address is 192.168.100.200 and the high-availability DHCP server is assigned to 192.168.100.200. Again, the DHCP scope is assigned from 192.168.100.100 - 192.168.100.199 to mimic the first network. I've deployed this configuration multiple times and I've had no problems.

The reason I am using this setup is that I'm testing a lab configuration for school. I use duplicate networks to evaluate incremental changes in configuration and demostrate redundant setups, failover clustering, and SAN configurations. The VMnet8 NAT network serves as the stripped-down network for comparing individual demonstration elements. The reason that I'm adding the Ubuntu server in this configuration is that I was evaluating the impact of deploying a FOG (Free Open-source Ghosting--See FOGProject.org) server within the infrastructure. FOG runs on Linux distributions and Ubuntu is recommended (CentOS less so since it requires some tweaking). Regardless, the problem occurs on both the VMnet5 network and the stripped-down VMnet8 network while setting up the bare-bones Ubuntu or CentOS servers. Very confusing.

Since there have been multiple build-ups and tear-downs of this configuration, I've been sure to ping addresses prior to setting the Ubuntu Server to make sure nothing is there. As expected, ping returns that a host is not present at either the expected DHCP assigned address (192.168.100.100) or the static address. In addition, this happens with other addresses as well such as 192.168.100.25 and 192.168.100.50 so it is not unique to the 192.168.100.211 address.

I'm kind of stumped at this point and plan to deploy this setup in a sandbox to get a handle on what's going on. I'm more than happy to elaborate on the configuration and respond to questions. Thank you!

Shaun

0 Kudos
em2slyn
Enthusiast
Enthusiast

I noticed a typo: The cluster network address is 192.168.100.200 and the high-availability DHCP server is at 192.168.100.210 not 192.168.100.200 as written. Sorry about that.

Shaun

0 Kudos
em2slyn
Enthusiast
Enthusiast

Hi Folks:

I believe that I solved the problem. To change a network adaptor IP assignment from DHCP to static, the sequence of steps is important.

Here's the proper sequence:

Step 1: Check your network interface configuration

# ifconfig -a

Step 2: Bring down the Ethernet adaptor while /etc/network/interfaces still identifies eth0 as DHCP

# ifdown eth0

Step 3: Modify /etc/network/interfaces with static ip configuration

# nano /etc/network/interfaces

iface eth0 inetstatic

     address 192.168.100.211

     netmask 255.255.255.0

     network 192.168.100.0

     broadcast 192.168.100.255

     gateway 192.168.100.1

Step 4: Bring up eth0

# ifup eth0

Step 5: Ensure /etc/resolv.conf lists the proper DNS

# nano /etc/resolv.conf

namespace 192.168.100.1

Step 6: Reboot

# reboot

Finding the proper sequence is kind of challenging if reading the online blogs. First, most postings use the command

# /etc/init.d/networking restart

after modifying the /etc/network/interfaces file which returns a message indicated that it is deprecated. Ubuntu recommends the ifdown and ifup commands, however, some posts run the two commands in sequence after modifying /etc/network/interfaces. Apparently this leads to problems since it does not bring down the dhclient process because it sees the adaptor configured with a static IP (see http://askubuntu.com/questions/4826/switching-a-server-to-static-ip-from-dhcp). This causes the "ghost adaptor" effect where you can ping both the old adaptor address assigned by DHCP and the new static adaptor address and get a response.

Also, most posts seem to recommend a reboot once the adaptor settings are changed. I noticed that after assigning the adaptor with a static address that ifconfig will continue to report the address assigned by DHCP. Rebooting releases the all the processes involved and makes a fresh start with the correct assignments. Checking the adaptor settings with ifconfig after the reboot yields the correct address.

As a last step, I double checked by pinging both the old DHCP and the new static addresses and only the new address responded. So this was not a problem with VMware Workstation 8.0.1 at all. Yay!

Have a GREAT DAY!!

Shaun

0 Kudos