can't manage ESX 4 host from different subnet

[talion83]

We recently incorporated a very simple VLAN setup...none of the VM's or the ESX are directly affected, users were moved off of the main network and onto their own subnets.

From the individual VLAN's I can get to every single PC/server. All routing is working fine...except for directly to the ESX host (the VM's on it are fine). I can not ping the ESX host IP's. If I move my PC back to the server subnet/VLAN I can ping and manage them fine, but once I put the PC on a different subnet I lose that ability (again, all of the VM's on the host work fine from any VLAN, and they can ping any PC on any VLAN...).

The VLAN setup is very basic - the individual switches are on their respective VLAN. Nothing is tagged (all ports are in 'untagged' status for their appropriate VLAN) and no ports are handling more then a single VLAN (so no trunking ports, etc...they are setup as simple 'access' ports). I just can't figure out why communication is fine to all of the VM's, but not the host itself.

As indicated above, nothing at all changed with the network for the ESX hosts and subseqent VM's...only change was to take all of the users off of the same subnet as the servers.

any thoughts?

[kumarsenthild]

Hi,

Are you configured proper Gateway for a Subnet?

Can you give the result of this command in Your PC :- tracert <esxip>

Regards

Senthil Kumar D

[talion83]

The gateway is correct both on the PC side and the ESX side. From the other subnet trace routes hit the gateway (10.0.2.1) and then expire after that.

edit it should be the next Hop. It should go Gateway>ESX, there are no other routers/L3 devices inbetween to hit (ie: doing a VM on the ESX goes 1>10.0.2.1, 2>VM).

The ESX servers Service Console is set to the same default gateway as all of the VM's and other devices on that subnet (main firewall). The PC has its gateway to the L3 switch. Yes there are routes in the firewall for the subnet to the L3 switch (routing works fine through the VLAN/Subnet for any other PC/server and internet).

I know I must be missing something on the ESX, I just can't seem to figure out what it is.

Under Configuration>DNS Routing the default gateways for Service Console is set to firewall (same as all of the other devices on this subnet) and the VMKernel (only on SAN vswitch) is set to its subnet (the SAN side is not directly connected to the main network).

[kumarsenthild]

Are you able ping VM from your PC & from SC?

Regards

Senthil Kumar D

[talion83]

yes all of the VM's work fine, i just can't get to the service console.

[kumarsenthild]

Hi,

Fire this commands in service console/SSh

1) #cat /etc/sysconfig/network

check the Gateway and sevice console switch(vswif0)

2) service network service ;- service network restart

Regards

Senthil Kumar D

[a_p_]

I'm confused.

You write:

"... The gateway is correct both on the PC side and the ESX side. From the other subnet trace routes hit the gateway ( 10.0.2.1 ) and then expire after that.

edit it should be the next Hop. It should go Gateway>ESX, there are no other routers/L3 devices inbetween to hit (ie: doing a VM on the ESX goes 1>20.0.2.1, 2>VM).

The ESX servers Service Console is set to the same default gateway as all of the VM's and other devices on that subnet (main firewall). The PC has its gateway to the L3 switch. ..."

There is definitely something wrong with your IP configuration!

What is the correct gateway? "10.0.2.1" or "20.0.2.1"

If the gateways are different then you should have two vSwitches, connected to different NIC's on different switches (VLAN's) and your service console IP address should be 10.0.2.xxx (depending on the subnet mask you are using)

If the gateways are the same (20.0.2.1), then your service console has to be something like 20.0.2.xxx.

André

[talion83]

that was a misstype. The gateway for the devices on that VLAN is 10.0.2.1, the Gateway for the ESX is 10.0.0.1

Why should the service console require being on the same VLAN as the PC? As long as the routing is setup then the packets should pass correctly between the VLAN's, as it is for all of the VM's located on the ESX server. I have managed ESX servers across subnets before, so I know that it works...it is just a question of why it doesn't appear to like a Subnet via a VLAN.

[EVW]

If log on to your ESX serverfrom the console, can you ping the default gateway ? And can you also ping the IP address of your workstation ?

Are there any access-lists involved on your switch that may block access from your subnet / IP address ?

[talion83]

there are no access lists which would be causing an issue.

pinging 10.0.0.1 is successful, pinging 10.0.2.1 fails. A tracert to 10.0.2.1 shows it trying to use 10.0.10.1 (SAN subnet...there is a service console on the SAN subnet as well). But if I do a route - n, it shows the default gateway set as 10.0.0.1 (0.0.0.0 - 10.0.0.1; the only other routes are 10.0.0.0 and 10.0.10.0). So it is showing that it sees the default gateway as 10.0.0.1, so not sure why it is attempting to use 10.0.10.1 when accessing 10.0.2.1.

kumarsenthild:

the sysconfig/network is showing 10.0.0.1 as the default gateway, but it doesn't list anything about the service console:

# cat /etc/sysconfig/network

NETWORKING=yes

HOSTNAME=****.mydoman*.com

GATEWAY=10.0.0.1

IPV6_AUTOCONF=no

NETWORKING_IPV6=no

your second suggestion - that will restart the entire network service for the entire ESX box correct?

[kumarsenthild]

Hi,

You need to re-configure the Service Console IP setttings.

Note:- before do the below the setting you must have separate Switch for Service Console. if yes fire the commands

1) First delete your vswitches and vswif for Service Console with these commands:

esxcfg-vswif -d vswif0

esxcfg-vswitch -d vSwitch0

2) create the new one and new port group as follows:

esxcfg-vswitch -a vSwitch0

esxcfg-vswitch -L Regards

Senthil Kumar D

[talion83]

Upon looking further at that routing table I realized what the issue was.

While it has the correct default gateway for 0.0.0.0 broadcasts, and showed 10.0.0.0 > 10.0.0.1 and 10.0.10.0 > 10.0.10.1, the problem was that the 10.0.10.0 network mask was 0.0.0.0. So it was using this as the broadcast for any 10 network address unless another route was already listed (ie: 10.0.0.0 network). By removing 10.0.10.0 mask 0.0.0.0, setting the correct mask (255.255.255.0), it is now pinging through.

Now I just need to remember what file to modify to keep this setting persistant.