Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am using Centos 5.3 VM created on VMWare ESXi 4.0.0. I created a vlan interface with tag 3 on my interface eth3 and gave it an IP in the same subnet as other machines in the vlan. When I tried pinging another machine through the newly created vlan interface (eth3.3) it does not ping. But if I try to ping through the actual interface eth3 it pings. I thought it was supposed to work the other way. I do not understand how to troubleshoot. Can anybody give me some pointers on how to troubleshoot this ? Here are the steps I did :-

# ifconfig eth3

eth3        Link encap:Ethernet HWaddr 00:0C:29:F1:DF:DC
               inet6 addr: fe80::20c:29ff:fef1:dfdc/64 Scope:Link
               UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
               RX packets:29522 errors:0 dropped:0 overruns:0 frame:0
              TX packets:142 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:2319562 (2.2 MiB) TX bytes:30298 (29.5 KiB)
              Base address:0x2080 Memory:d8940000-d8960000

# vconfig add eth3 3
Added VLAN with VID == 3 to IF -:eth3:-

# ifconfig eth3.3

# ifconfig eth3.3

eth3.3 Link encap:Ethernet HWaddr 00:0C:29:F1:DF:DC
               inet addr: Bcast: Mask:
               inet6 addr: fe80::20c:29ff:fef1:dfdc/64 Scope:Link
               UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
               RX packets:0 errors:0 dropped:0 overruns:0 frame:0
               TX packets:33 errors:0 dropped:0 overruns:0 carrier:0
               collisions:0 txqueuelen:0
               RX bytes:0 (0.0 b) TX bytes:7944 (7.7 KiB)

# ping -I eth3.3
PING ( from eth3.3: 56(84) bytes of data.

--- ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

# ping -I eth3
PING ( from eth3: 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=1.67 ms
64 bytes from icmp_seq=2 ttl=64 time=1.85 ms

share|improve this question

Unless you configured eth3 in vmware to be a trunked interface this is not going to work.

most likely what you want to do is configure the vlans in vmware, and then assign eth3 to be on vlan3(in vmware). You shouldn't need to be configuring vlans inside of a VM.

share|improve this answer

Are you sure that your ESX networks and physical switch ports are correctly configured as far as your VLAN requirements are concerned? If you want to be able to handl VLAN tagging within your Guest OS then the Port Group that your VM's Eth3 nic is mapped to in the VM Settings must be configured in VGT mode and VLAN tags have to be left unmodified by your physical switch on the physical port(s) that the uplinks used by that Port Group. One other possibility is that NIC teaming on the vSwitch may be causing problems for your physical switch infrastructure, having traffic work in one direction but fail in the reverse direction is one symptom of that. How are they configured in this case (how many uplinks for the vSwitch, do you have any policy overrides on the Port Group, do the uplinks connect to separate phsyical switches?

Your problem may well be internal to the machine but it's a good idea to check that the underlying virtual network is good before wasting time in the Guest OS unnecessarily.

There are three VLAN tagging modes supported by ESX Servers:

  • VGT - Virtual Guest Tagging. – vSwitch passes the network packets to the guest OS leaving the 802.1Q tags unmodified. If you need to support [multiple] VLANs within your Guest OS this is the mode you need to enable. You enable VGT mode by selecting VLAN ID 4095 on the Port Group the Guest's NIC is mapped to.
  • EST - External Switch Tagging. VLAN tags are handled entirely by the physical switches and never presented to the ESX host, 802.1q vlan tags are removed before being transmitted to the ESX server nics and added to packets received from them. The guest's network is unaware of the VLAN tagging. No VLAN configuration is required on either the ESX host or the Guest OS.
  • VST - Virtual Switch Tagging. In this mode, VLAN tags are handled by the vSwitch and the guest OS sees no VLAN traffic - the specific VLAN ID's have to be configured on the Port's\Port Groups on that vSwitch.

There is an excellent overview of this (and pretty much everything else you ever wanted to know about ESX vSwitch configuration) in a series of 7 Blog posts by Ken Cline - you can find the first one here, the ESX VLAN concepts are discussed towards the end of the post.

share|improve this answer

I am not a linux guru (I run NetBSD) but did you correctly specify the subnet mask on the ifconfig line?

On NetBSD, I'd have to use something like

ifconfig vlan3

for a or 0xffffff00 (24-bit network mask no matter how you slice it.)

share|improve this answer
That's right. I should have added netmask. I added netmask ifconfig eth3.3 netmask But that did not resolve the issue. I still get the same result. – Sabu Thaliyath Nov 12 '09 at 9:13

If possible, you could on the recieving end run tcpdump like:

tcpdump -i <interface> 'src and icmp'

If the ping is sent there but no reply, the recieving end might not know how to send to that end.

do: traceroute

Is it using the correct gateway to send? Is the gateway it tries with able to send to that network?

If it doesn't send to perhaps the src computer where you setup has a routing problem or you haven't properly configured(netmask, gateway etc) the vlan on the src computer.

my 2 cents...

EDIT: Shooting in the dark here ;) Try enabling proxy arp echo 1 > /proc/sys/net/ipv4/conf/eth3/proxy_arp

share|improve this answer
# tcpdump -i eth3.3 tcpdump: 15:52:02.409845 arp who-has tell 15:52:03.410592 arp who-has tell 15:52:04.410350 arp who-has tell .. 5 packets captured 5 packets received by filter 0 packets dropped by kernel....... -> arp is not working..I wonder why ? I can ping the same dst machine from other physical machines in the same subnet. It is only from this VM that arp is not working – Sabu Thaliyath Nov 12 '09 at 10:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.