1

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 172.22.125.154

# ifconfig eth3.3

eth3.3 Link encap:Ethernet HWaddr 00:0C:29:F1:DF:DC
               inet addr:172.22.125.154 Bcast:172.22.255.255 Mask:255.255.0.0
               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 172.22.125.3 -I eth3.3
PING 172.22.125.3 (172.22.125.3) from 172.22.125.154 eth3.3: 56(84) bytes of data.

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

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

4 Answers 4

3

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.

1

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.

0

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 1.2.3.4/24

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

1
  • That's right. I should have added netmask. I added netmask ifconfig eth3.3 172.22.125.154 netmask 255.255.255.0 But that did not resolve the issue. I still get the same result.
    – Sabu Thaliyath
    Nov 12, 2009 at 9:13
0

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

tcpdump -i <interface> 'src 172.22.125.154 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 172.22.125.154

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 172.22.125.154 perhaps the src computer where you setup 172.22.125.154 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

1
  • # tcpdump -i eth3.3 tcpdump: 15:52:02.409845 arp who-has 172.22.125.7 tell 172.22.125.154 15:52:03.410592 arp who-has 172.22.125.7 tell 172.22.125.154 15:52:04.410350 arp who-has 172.22.125.7 tell 172.22.125.154 .. 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, 2009 at 10:31

You must log in to answer this question.