Configured VLAN on the switch consisting of four switchports. Two hosts are connected to the same VLAN on the switch, having IP addresses 10.0.0.77 and 10.0.0.76. I have been trying tagged ports in the VLAN through the webinterface of the switch. If I destroy the vlan on the Linux box and set 10.0.0.78 directly on the.
I created a new VLAN IP for a machine using vconfig add eth0 22Then 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:. VLAN IP of same machine succeeds. VLAN IP of other machine with general ping command fails. VLAN IP of other machine with ping command with eth0 specified succeeds. 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.
![Ubuntu vlan bridge Ubuntu vlan bridge](http://www.techonia.com/wp-content/uploads/2010/03/Linux-Vlan-Trunking-Topology.png)
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 -rnKernel IP routing tableDestination 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.22This 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.