Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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 can't find answer about how linux processes incoming packets from different VLANs, that do not belong to a subnet assigned to a VLAN.

Imagine this situation. On Linux machine with the following configuration:

  • eth0.100 - assigned address from subnet (eg.
  • eth0.150 - assigned address from subnet (eg.
  • eth0.200 - assigned address from subnet (eg.

the address of the default gateway is pointing to interface eth0.100

On port eth0.150 comes packet with a source address addressed to ​​the service that listens on the The packet is processed by service (higher layer of ISO / OSI model) and new packet (response) is generated to the host At this point the question is how the packet will be processed.

Is Linux first checks the ARP table, and if it have an entry related with host (MAC address) send packet back by eth0.150 or first scan the routing table, and if not find any matches will send packet back by interface eth0.100 (with which it is associated default gateway)?

Could you help find correct answer?

share|improve this question
up vote 1 down vote accepted

After setting up the VLANs and IPs, you have 4 routes in your routing table: directly connected dev eth0.100 directly connected dev eth0.150 directly connected dev eth0.200
default via dev eth0.100

No matter where the packet comes from, on the way out, it will be matched to the routing table. Since is not a part of any network in the routing table, it will be sent out via the default gateway ("all other networks").

ARP is only used inside local ethernet networks, so a packet from will actually have a MAC from a router (somewhere in vlan150) that forwarded it to your host.

When you send an IP packet, you pack it (encapsulate it) inside an Ethernet packet. So when you want to reach (which is probably outside your LAN), you first encapsulate it, and send a packet with your MAC as a source address, and your routers LAN-side MAC as a destination address. The router recieves it, looks just at the IP packet, checks where to route it, and then encapsulates (just the IP packet) in a different Ethernet packet, with its own wan-side MAC as a source address, and an upstreams routers MAC as a destination address. This is then repeted on every ethernet router on the way.

Since the packet from came from another network (not the directly attached one), it had to be routed via a router, and there is no way you can see the MAC address.

Of course, you can set up routing (with multiple routing tables), so that packets coming in from eth0.150, are routed out via a gateway on eth0.150.

EDIT: As noted in the comments, if you have reverse path filtering enabled on those interfaces, the kernel will drop the packet, since the return interface is not the same as the incoming one.

share|improve this answer
No matter where the packet comes from Not really. If reverse path filtering is enabled, then the kernel will actually check the return path before accepting a packet. This option is on by default on some distributions. – BatchyX Mar 3 '13 at 17:17
Yes, but iirc, this has to be explicity enabled, per interface, where you wish to have filtering enabled. – mulaz Mar 3 '13 at 17:23
You can enable it globally. Some distros do it by default. – BatchyX Mar 3 '13 at 17:25

Your Answer


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

Not the answer you're looking for? Browse other questions tagged or ask your own question.