0

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 192.168.100.0/24 subnet (eg. 192.168.100.2)
  • eth0.150 - assigned address from 192.168.150.0/24 subnet (eg. 192.168.150.2)
  • eth0.200 - assigned address from 192.168.200.0/24 subnet (eg. 192.168.200.2)

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

On port eth0.150 comes packet with a source address 10.0.0.100/24 addressed to ​​the service that listens on the 192.168.150.2. The packet is processed by service (higher layer of ISO / OSI model) and new packet (response) is generated to the host 10.0.0.100. 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 10.0.0.100 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?

j0k
  • 411
  • 9
  • 16
Rafal
  • 3
  • 1

1 Answers1

1

After setting up the VLANs and IPs, you have 4 routes in your routing table:

192.168.100.2/24 directly connected dev eth0.100
192.168.150.2/24 directly connected dev eth0.150
192.168.200.2/24 directly connected dev eth0.200
default via 192.168.100.1 dev eth0.100

No matter where the packet comes from, on the way out, it will be matched to the routing table. Since 10.0.0.100 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 10.0.0.100 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 serverfault.com (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 10.0.0.100 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 10.0.0.100s 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.

mulaz
  • 10,682
  • 1
  • 31
  • 37
  • `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 03 '13 at 17:17
  • Yes, but iirc, this has to be explicity enabled, per interface, where you wish to have filtering enabled. – mulaz Mar 03 '13 at 17:23
  • You can enable it globally. Some distros do it by default. – BatchyX Mar 03 '13 at 17:25