Cfrtjryk

Consider the following topology:

I am sending ICMP (ping) packets from host B to 10.0.1.1. They reach the target and the target answers with a reply. The connectivity works fine.

When running, on host A

• 
  tcpdump -i eth1 icmp: I do not see any packets


• 
  tcpdump -i eth2 icmp: I see the packets

Is there a way to check if a packet intended to interface eth1 did reach that interface?

I vaguely remember reading one day that the kernel was handing the reply at eth2 level (which is the first interface the packet reaches) so that could explain why monitoring eth1 does not yield any results.

As for why I would need to check such specific case: I have cases where a packet arrives on an interface of a host (the first one on its way) but does not seem to reach the intended interface (the actual application is not brought up). Such a test would ensure that the firewalling/forwarding is OK and that the problem is elsewhere (in the configuration of the app, a bug in the app, etc)

The subject you're talking about is weak/strong Host model and Linux uses weak one by default.

Is there a way to check if a packet intended to interface eth1 did reach that interface?

I'd say that firewall would allow to put such a constraint.

I have cases where a packet arrives on an interface of a host (the first one on its way) but does not seem to reach the intended interface (the actual application is not brought up). Such a test would ensure that the firewalling/forwarding is OK and that the problem is elsewhere (in the configuration of the app, a bug in the app, etc)

You've mentioned ICMP in your example earlier. What's wrong with using exactly it to verify there's connectivity for real?

Also, at this point you're pretty close to practice of using loopback interfaces for services — it's mainly used coupled with dynamic routing but the main idea is pretty simple: it shouldn't matter what was the interface the request came from, it only matters that it found its way at all and reply can be sent as well. Loopback interfaces are never down unless manually told so — "real" interfaces OTOH can change theirs state due link loss and so on.

In Linux, an incoming packet is routed by checking whether a packet should be handled by the local machine or not. If it should, it is processed directly without first routing it through the "correct interface". The IP address is kindof just an alias for the machine and it doesn't matter which interface the packet arrived on.

The same happens if you locally do telnet 10.0.1.1 - it doesn't appear on eth1 but instead on lo which handles all packets going from the local machine to itself.

For outbound packets however it does make a difference which interface an address belongs to. The kernel first decides how to route a packet and then picks the best source IP for the packets based on that.

If you need to see "all packets" with tcpdump, you can do tcpdump -i any icmp. It will not show you the interface(s), but you will see all packets going for e.g. 10.0.1.1.