Using the Ping command with VLAN IP's

Question

I created a new VLAN IP for a machine using

vconfig add eth0 22

Then I did a:

ifconfig eth0.22 192.168.3.2 netmask 255.255.255.0 up`.

After this, when I do a ping 192.168.3.2 it's successful.

After this, when I redo this process to create another VLAN IP on another machine in the same local network (192.168.3.1), and ping it, it is unsuccessful. However it is successful if I ping it as with the command ping 192.168.3.1 -I eth0.

My question is, what is happening internally which causes the:

1. VLAN IP of same machine succeeds.
2. VLAN IP of other machine with general ping command fails.
3. VLAN IP of other machine with ping command with eth0 specified succeeds.

Solution

You are creating a VLAN, which means (in this case) that any packets emitted from the eth0.22 packet are prefixed with an 802.1Q header (a tag) saying that the packet is destined for VLAN 22. The switch accepts this packet on a trunked interface and forwards the packet out of any ports that are defined as allowing VLAN 22 (or defined as allowing any VLANs).

If the egress interface is a access switchport (ie, not a trunk) then the 802.1Q header is removed, and the packet forwarded. If the port is a trunk, the 802.1Q tag is left in place.

In order for all this to work, you need a managed switch - one that understand VLANs. In your case, you either don't have one, or the ports you are connecting to are not configured as trunks.

With an unmanaged switch, a tagged packet is not understood, and so it is discarded.

What is happening in your case is when you do a ping, your OS will choose the appropriate interface - eth0.22 and so send the packet out with a 802.1q tag.

The OS chooses the appropriate interface based on the routing table. As 192.168.3.0 is explictly connected to the eth0.22 interface, then any packets for this network are sent via this interace by default. See the routing table:

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
[..snip..]
192.168.3.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0.22

This then gets dropped at the switch as it doesn't know how to handle it.

When you force the ping out of the eth0 interface, it is going out of an untagged interface, and so the switch understands the packet, and forwards it. The receiving machine sees it, and by a quirk of the way ping works, will respond out of the interface the ping arrived on, rather than the more appropriate eth0.22 interface.

It might be the case that while ping works, other services might not.

If you want to use VLANs, then you need a VLAN capable switch, otherwise, you can just use secondary addressing on the eth0 interface if you don't have one.

The reason why this works when you are pinging yourself is that the 802.1q tagging does not happen until egress. So if 192.168.3.1 is pinging 192.168.3.1, it will not emit the packet onto the network, and so not tag it.

Comments

[sbhatla]

Secondly, can we say for sure that when I ping the other machine's VLAN IP using 'ping 192.168.3.1', my machine is successfully sending it out on its interface eth0.22 after tagging it, and its the intermediate router/switch that is causing the problem?

[Paul]

I have updated the answer for your first question, and for the second one, we can't be 100% certain. We can assume that the routing occurred correctly, and so we can ssume the packet was tagged. So it either got dropped at the switch, or the switch is correctly set-up and forwared the packet, and the problem is the configuration of the receiving machine. Any number of things could cause the problem but the switch is the most likely cause, until we have more data to go from.

[Paul]

Hi @sbhatla, what was the outcome, was it the switch?