VMware Fusion 4.1.3 掩码问题导致主机不能正常访问网络

之前成功将MAC OS 10.6.8 升级到Mountain Lion 10.8，之前安装的VMware fusion版本也不兼容10.8，重新下载了新的4.1.3的fusion版本，昨天在使用的时候发现一个问题，那就是不打开fusion时，在MAC OS本机能正常访问我们的测试环境（172.20.10.x/255.255.255.0）。但是一打开fusion，就无法访问测试环境。试了好几次都出现同样的问题。

今天中午闲来无事，就想找找到底是什么原因导致，不会是因为升级到新版本的fusion或新版本的Mountain Lion就出现这个bug了吧，想想Apple应该不会这么大意吧。根据现象第一反应应该是网络的问题。

1、 在本机测试

~~~matoMacBook-Pro:~ $ ifconfig

部分省略

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

options=2b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4>

ether c8:2a:14:16:0e:9d

inet6 fe80::ca2a:14ff:fe16:e9d%en0 prefixlen 64 scopeid 0x4

inet 172.20.1.251 netmask 0xfffffe00 broadcast 172.20.1.255

media: autoselect (1000baseT <full-duplex>)

status: active

此时能ping通172.20.10.155

2、启动vmware fusion

~~~matoMacBook-Pro:~ $ ifconfig

部分省略

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

options=2b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4>

ether c8:2a:14:16:0e:9d

inet6 fe80::ca2a:14ff:fe16:e9d%en0 prefixlen 64 scopeid 0x4

inet 172.20.1.251 netmask 0xfffffe00 broadcast 172.20.1.255

media: autoselect (1000baseT <full-duplex>)

status: active

vmnet1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

ether 00:50:56:c0:00:01

inet 172.16.103.1 netmask 0xffffff00 broadcast 172.16.103.255

vmnet8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

ether 00:50:56:c0:00:08

inet 172.20.0.211 netmask 0xffff0000 broadcast 172.20.255.255

此时能ping不通172.20.10.155

发现多了两个vmnet1，vmnet8接口，玩过VMware的都知道这是虚拟网络，vmnet1是host-only的方式，vmnet8是NAT的方式。我注意到vmnet8的掩码是255.255.0.0，可是我记得咱们的办公网络好像是24位的，猜测应该是这个问题，果断修改vmnet8啊，可是咱不会啊，没办法，有强大的google，啥都不怕，找出这么一篇文章--

《Modifying the DHCP settings of vmnet1 and vmnet8 in Fusion 》 http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1026510

要注意你的fusion是哪个版本的，我的是4.1.3，解决起来就简单咯。

sudo vi /Library/Preferences/VMware\ Fusion/networking

VERSION=1,0

answer VNET_1_DHCP yes

answer VNET_1_DHCP_CFG_HASH *********************************

answer VNET_1_HOSTONLY_NETMASK 255.255.255.0

answer VNET_1_HOSTONLY_SUBNET 172.16.103.0

answer VNET_1_VIRTUAL_ADAPTER yes

answer VNET_1_VIRTUAL_ADAPTER_ADDR 172.16.103.1

answer VNET_8_DHCP yes

answer VNET_8_DHCP_CFG_HASH *********************************

answer VNET_8_HOSTONLY_NETMASK 255.255.0.0

answer VNET_8_HOSTONLY_SUBNET 172.20.0.0

answer VNET_8_NAT yes

answer VNET_8_VIRTUAL_ADAPTER yes

answer VNET_8_VIRTUAL_ADAPTER_ADDR 172.20.0.211

确实是16位的掩码，改成24位的，保存退出，重新启动fusion，再ping 测试环境，一切正常。

具体是什么原因导致的，我也不清楚，之前用的MAC OS10.6.8+vmware fusion 3是正常的，不知道为什么升级之后就不行了。

但是问题是为什么虚拟机的网络会影响到主机呢？这就像儿子怎么反过来打老子了？？请教了公司的一CCIE，他一讲，我是豁然开朗啊。





如上拓扑图所示，vmware fusion启动之后其实就是创建了一个vm port。以下分三个阶段说明

1、未启动fusion之前，此时172.20.1.X要访问172.20.10.X/24网段，会直接查找默认网关（172.20.1.1），此时能正常访问。

2、启动fusion之后，vm port由于此时是172.20.0.0/16位的，而目的地是24位掩码，因此它会认为是直连路由，而直连路由要优先于默认网关的，因此从主机ping 172.20.10.x/24网段，它会从vm port走，而vm port是不知道如何到达172.20.10.x/24网段，因此主机也无法ping通。

3、将vmnet8的掩码改成24位后，此时vm port也是172.20.0.X/24位，而目的地是172.20.10.x/24，是不同的网段，即不是直连路由，因此会走默认路由，所以修改后能ping通。

PS：直连路由就是它的接口所连接的网络所能到达的网络 。

至此，就能解释以上的现象了！
本文出自 “star&storage” 博客，请务必保留此出处http://taotao1240.blog.51cto.com/731446/960484